Exactly. I thought of something like this in the payload to /1.0/state:
{"ready": true|false}
Sounds good!
Can we delete the key instead? To clear the slate so to speak and potentially differentiate between when a process inside the instance has set it to false vs a daemon restart/instance stop.
Effectively the missing key means âunknown, assume not readyâ.
Also a point on the implementation of that query. We will want that to be done in a single query for all instances on the server, so should be doable using a DELETE FROM instances_config WHERE key = "volatile.last_state.ready" with a JOIN instances to filter by node_id.
Is there a need for the yaml setting here?
Or is it just there for convenience of consumers that are written in Go?
Other than that, looks good thanks!
I donât know, I usually set json and yaml because everything in shared/api is that way.
1 Like
Approved
@monstermunchkin I was chatting to @stgraber about this and we were thinking that having DevlxdStatePost.Ready field may prove to be unnecessarily restrictive in the future if we wanted to allow additional instance states to be set by the guest (one idea was the ability to set an instance state to âbrokenâ for example).
So how about we change DevlxdStatePost.Ready to DevlxdStatePost.State as a string, and only allow started or ready to be submitted to it.
To avoid having a state string in a state API endpoint, I was actually considering adding state to /1.0 and use PUT /1.0 to change the state from the guest.
Effectively: curl --unix-socket /dev/lxd/sock -X PATCH -d '{"state": "READY"}' lxd/1.0
2 Likes
Yep that avoids the jitter.