In my old schema I had a ‘must’ statement.
I then changed my schema and removed the must statement.
When I changed the schema in my confd.cdb directory and then restart confd it still yells about this must restriction, and does not let me connect to the cli.
The way I upgrade the schema is by coying the aaa_init-*fxs, system-*.fxs, aaa_init-*.xml, and system-xsd-init-*.xml, where the wildcard stands for the version of the schema I just created.
I don’t completely understand how the yang upgrade process works, so I am not sure I am doing it right, although I do see my new files in confd.cdb.
Data Model Upgrade is described in Chapter 13 of the ConfD User Guide. You can also find examples for the same under examples.confd/in_service_upgrade.
However, we do not perform an in-service upgrade. Why would the upgrade fail, then?
I read chapter 13 of the ConfD User Guide, but the only reference to my issue is this:
If the upgrade includes new validation points, or the validation logic for existing validation points
has changed, the new validators must connect to ConfD and register for their validation points before
maapi_commit_upgrade() is called.
My case is the second - validation logic has changed. However, I do not have a validation point, unless you consider a ‘must’ statement a validation point.
It is also not clear to me how performing the code assists me here: how do I permit the new, non-restrictive schema definition in the sequence described?
In short - I still do not understand why a removal of a constraint show fail the upgrade - the constraint is no longer in the schema, so how come confd thinks it’s still there?