ncm-network: Move nmstate options to new schema

[jrha]

@aka7 as promised this splits out the nmstate specific parts of the schema into the new structure @stdweird designed.

This also defaults to using the new schema and to be honest I don't see a reason to keep the legacy schema file around.

Backwards incompatible from 23.6.0 for anyone setting "nm_manage_dns" = true or more generally for any sites using the current code from master.

[stdweird]

@jrha @ned21 @jouvin i suppose we should give sites one or 2 weeks time to compare generated profiles with changing this boolean.

[ned21]

👍 @aka7 is probably the best person to do that for MS. We have pretty good tools for this so it should be easy to generate, but may take a little bit to analyse any differences.

[aka7]

@jrha thank you for this.

I plan to look into this next week.
I suspect backward incompatibility will be with nm_clean_inactive_conn too.

[aka7]

@jrha the backward incompatible is ok with us, We probably need to move manage_vips into nmstate path, because that is currently only for nsmstate, unless we plan to look at creating loopback interface for network.pm? If we are going have backward incompatible change, its worth looking at other nmstate on options I added recently. like the priority option added for nmstate config.

but I'm struggling to override the two variable introduced in the schema at os level, the network types are included early on in quattor/types/system.pan (in our setup at least). So I'll be interested to know how others are going override these values QUATTOR_TYPES_NETWORK_BACKEND or QUATTOR_TYPES_NETWORK_LEGACY.

Has anyone else tested this? cc @stdweird ?

[aka7]

Tested this internally at ms, LGTM.
Other than the comment made about overriding the variables. and we can possibly move other options into nmstate schema, this can be done later separate PR once this is merged?
Others should test and confirm though.

[aka7]

@stdweird @jrha just checking what is decision on this? At ms, we have tested this, with caveat that you can't override the two global variables early on before the network schema is included, but with some refactoring in our template code we can achieve this by putting in some logic to set the right values we need, legacy, vs initscripts, vs nmstate. And we are ok with backward incompatibility.

I ask this, because there additional changes I have in flight which I'll create pr once this is merged. Also we are looking to go GA with rhel9 before the end of the year so any major changes, I would like to get this in before we go GA. hope this makes sense.

thanks for your help.

[jrha]

Sorry for the delay, we've tested this at RAL with no resulting changes to host profiles, so we're happy and I'd like to go ahead and remove the legacy schema.

[stdweird]

@jrha 👍

[jrha]

I've done the removal of legacy in #1725.