CA-400060: Sm feature intersection #6069
Conversation
Vincent-lau
force-pushed
the
private/shul2/sm-feature-check2
branch
2 times, most recently
from
10e58fa
to
5e7eec5
Compare
ocaml/idl/datamodel.ml
Outdated
| @@ -4994,11 +4994,21 @@ module SM = struct | |||
| , "capabilities of the SM plugin, with capability version \ | |||
| numbers" | |||
| ) | |||
| ; ( Changed | |||
| , "24.34.0" | |||
There was a problem hiding this comment.
- This probably needs to be changed before actually being merged
Vincent-lau
force-pushed
the
private/shul2/sm-feature-check2
branch
2 times, most recently
from
8b0f6a2
to
6bce2b4
Compare
Vincent-lau
force-pushed
the
private/shul2/sm-feature-check2
branch
2 times, most recently
from
74b67dc
to
45e1578
Compare
|
I had a couple of questions:
|
Vincent-lau
force-pushed
the
private/shul2/sm-feature-check2
branch
from
45e1578
to
e700ae7
Compare
Yes, dbsync_slave is execute on any host when it starts, both coordinator and other hosts. And a standalone host is simply a coordinator of a pool of one host.
Yes, I think the way is works is that a host does remove its pending features, but only after it restarts again? That may be alright for the purpose. The DB field is not public. |
Vincent-lau
force-pushed
the
private/shul2/sm-feature-check2
branch
from
bc526a0
to
9e179d6
Compare
I think that was a valid point, it does not get removed after the feature is moved from pending to non-pending, and gets stored in the db forever. I have added some code to remove it once all hosts know this feature. |
| @@ -51,6 +51,8 @@ let prototyped_of_field = function | |||
| Some "22.26.0" | |||
| | "VTPM", "persistence_backend" -> | |||
| Some "22.26.0" | |||
| | "SM", "host_pending_features" -> | |||
| Some "24.36.0-next" | |||
There was a problem hiding this comment.
This will be changed to 24.37.0 whenever we tag and release 24.37.0
Vincent-lau
force-pushed
the
private/shul2/sm-feature-check2
branch
from
9455d31
to
2ec0ac6
Compare
`host_pending_features` represents the features that are available on some of the hosts in the pool, but not all of them. Note the way this field is initialised in the `SM.create` code means that it will only contain new features that appear during upgrade. This means a feature that is added into `SM.features` during creation will stay there even if it is not available on all hosts. But we should not end up in this situation in the first place. Also change the meaning of `Sm.features` to be pool-wide. Signed-off-by: Vincent Liu <[email protected]>
NEW Sm features that are found during an upgrde will now only be available when they are available on all of the hosts. Add logic to keep track of features that are only availabe on some of the hosts in the pool, and declare them in `Sm.feature` only when all of the hosts have declared this. Also move `Storage_access.on_xapi_start` to `dbsync_slave` as this needs to be run on all hosts for each sm to get a chance to say what features they have. Signed-off-by: Vincent Liu <[email protected]>
Implement a new `assert_sm_features_compatiable` in pre_join_checks so that if the joining host does not have compatible sm features, it will be denied entry into the pool. Signed-off-by: Vincent Liu <[email protected]>
There are two parts to this PR:
Now I did not create a new class just for SM features as I feel having a decidated class for something that is supposed to be quite a temporary state (as this is only supposed to happen during an upgrade) is an overkill. But I am open to suggestions.