[ocm-machine-pools] nodepool subnet specdrift #4140
Conversation
| or self.subnet != pool.subnet | ||
| # if the nodepool in app-interface does not define a subnet explicitely | ||
| # we don't consider it a diff. we don't manage it | ||
| or (pool.subnet is not None and self.subnet != pool.subnet) |
There was a problem hiding this comment.
so this means we'll have non matching data between app-interface and the reality ?
There was a problem hiding this comment.
i added the promised phase 2 to this MR in the to open an app-interface MR to patch the missing subnets. this way we don't have non-matching data.
There was a problem hiding this comment.
Does that mean we should never apply subnet from app-interface to ocm? When app-interface pool subnet is not None and we have a different subnet value in current pool, this condition will be true, and show as diff, is this expected?
There was a problem hiding this comment.
we can and we should specify subnets for day2 node pool operations. but at installtime we can't influence it and we end up with a set of pools where ROSA decides how to spread them accross the available private subnets.
we can improve on this behaviour once there is the ability to create HCP clusters without node pools at install time. becaues then we wait until the cluster is ready and ocm-machine-pools can create the pools in the explicitely defined subnets.
There was a problem hiding this comment.
Does that mean we should never apply subnet from app-interface to ocm? When app-interface pool subnet is not None and we have a different subnet value in current pool, this condition will be true, and show as diff, is this expected?
once a node pool has been created, its subnet ID can't be changed anymore. at this point OCM becomes the source of truth for it. we implemented the notion of an
invalid_diffto highlight the problem, so it is expected thathas_diffshows a diff in subnet between a-i and OCM.
So for the use case of nodepools have been recreated on OCM side without app-interface involvement, this diff will show in has_diff but will fail invalid_diff check, the integration will fail until patch mr merged, is this expected?
There was a problem hiding this comment.
yes, it still makes us aware and we need to intervene. we should not do things manually in OCM.
| or self.subnet != pool.subnet | ||
| # if the nodepool in app-interface does not define a subnet explicitely | ||
| # we don't consider it a diff. we don't manage it | ||
| or (pool.subnet is not None and self.subnet != pool.subnet) |
There was a problem hiding this comment.
Does that mean we should never apply subnet from app-interface to ocm? When app-interface pool subnet is not None and we have a different subnet value in current pool, this condition will be true, and show as diff, is this expected?
geoberle
force-pushed
the
ignore-undefined-subnet-on-nodepool
branch
from
f5e21ce
to
03af593
Compare
once a node pool has been created, its subnet ID can't be changed anymore. at this point OCM becomes the source of truth for it. we implemented the notion of an |
geoberle
force-pushed
the
ignore-undefined-subnet-on-nodepool
branch
from
97868ab
to
2c1b5c4
Compare
geoberle
changed the title
defining the subnet id of a `machinePool` is optional in app-interface. if such a machinepool maps to a nodepool of an HCP, we don't highlight it as a diff and don't manage this property. Signed-off-by: Gerd Oberlechner <[email protected]>
…if missing there Signed-off-by: Gerd Oberlechner <[email protected]>
Signed-off-by: Gerd Oberlechner <[email protected]>
Signed-off-by: Gerd Oberlechner <[email protected]>
Signed-off-by: Gerd Oberlechner <[email protected]>
Signed-off-by: Gerd Oberlechner <[email protected]>
Signed-off-by: Gerd Oberlechner <[email protected]>
Signed-off-by: Gerd Oberlechner <[email protected]>
Signed-off-by: Gerd Oberlechner <[email protected]>
geoberle
force-pushed
the
ignore-undefined-subnet-on-nodepool
branch
from
2c1b5c4
to
9eb593a
Compare
specifying the subnet IDs of HCP nodepools in the clusters file upfront the cluster installation does not work well with how the rosa cli creates nodepools during cluster creation. there is no way to influence nodepool subnet placement at this stage. so it makes sense to not specify the subnets of HCP nodepools in app-interface during cluster creation
BUT
we can patch them in the cluster file once they are known!
this PR opens an MR to add the subnet IDs to the cluster file if it is not defined yet.
bonus: this PR will also ignore clusters that are not ready yet for machine pool management (
spec.idnot set yet). this avoidsocm-machine-poolreconcile errors during cluster provisioning.reminder:
demo MR: https://gitlab.cee.redhat.com/goberlec/app-interface/-/merge_requests/12/diffs
part of https://issues.redhat.com/browse/APPSRE-9883