Hmm, this isn’t exported through the REST API, so should it be in shared/api and swagger as opposed to just being internal to the scriplet API and be documented there instead?
I did ponder about that. But in the end thought it made sense to keep it together with the other public api types because we reference existing api types for the other scriptlet function documentation and this way it’ll appear in the api docs along side the other types referenced. I was also thinking we want to provide the same level of api stability that we do with the rest api even if we dont expect anyone to actually use it from a Go app. So keeping it in the api package will make it clear it should not be trifled with lightly.
Hmm, fair enough about API guarantees. I guess we just need to make it clear through comments that this isn’t part of the REST API.
Anyway, we have a similar situation with some of the bits of the /dev/lxd API and likely will face more of that with the deployments API. We’ll need a way to have all of those bits of APIs better tracked.
Maybe we should just go with sub-packages of the api package?
Yeah the devlxd isnt so different as its a rest api still (and thus could use a go client of course).
I’ll see if we can use a separate package or name prefix to make it clearer while still being in the swagger docs.
I’ve updated the PR so that the InstanceResources type is in a sub package called shared/api/scriptlet and so doesn’t show in the swagger docs (as I realised the models aren’t viewable separately anyway), and instead linked to the godocs for the types in our docs.
1 Like
This PR alters the instance_placement function signature that removes the reason argument and changes the request argument type to be an api/scriptlet.InstancePlacement equivalent dict type, which will now contain both Reason and Project fields.
This allows for the instance’s project to be passed to the placement scriptlet.
Is this planned for back port to current LTS (5.0) as well? I know I would very much appreciate having this feature especially in my environment. I currently have a 3 servers with 1 of them having a lot more ram/cpu processing power so I’d love the ability to have more go towards that cluster node than the others
We’re not planning on backporting this one as it pulls quite a bit of extra code which distributions packaging our LTS versions would be quite unhappy to have to deal with.
For LXD 5.0.x, I guess one thing you could do is play with cluster groups or just disable targeting on specific servers. It’s not as flexible, but you can at least alter what servers would be getting instances by default and manually target the others when needed.
This PR updates the StarlarkMarshal function to convert Go structs to Starlark objects:
Hi
I’m using this scriptlet for creating instance and is very applicable.
Is there any plan to use this script at changing instance resources and auto migrate instance to proper target?
Hi @alizowghi, it is the intention of this PR to enable the scriptlet placement scheduler when moving instances to a different target:
1 Like