LYB format versioning and compatibility

[frimpler]

Hi Michal,

currently, libyang2 strictly requires a LYB format version==5, as it seems, and refuses to read other/earlier versions of startup files. Are there plans (or already available means) to support also other versions than 5?

Thanks and regards, Frank

[michalvasko]

Not really, all version updates were "fixes" of previous formats that had some required information missing so I do not think it makes sense to support previous versions. While this requires the data to be "updated" every time the version changes, it is an easy thing to do. Also, I think the LYB version should be fairly stable now.

[frimpler]

At least startup DS files are persistent on a NC server (and may represent huge databases). So, you are kind of telling the community, that it is the design of LYB format, that all data get lost, when the server gets a new SW (unless you extract the huge DB e.g. into an XML file). Don't you think, that contradicts the concept of compatibility YANG tries to follow?

[michalvasko]

So, you are kind of telling the community, that it is the design of LYB format, that all data get lost, when the server gets a new SW (unless you extract the huge DB e.g. into an XML file).

Pretty much. It is one of the reasons why a fairly recent change has been made that switched the default datastore plugin from using LYB to JSON so if you use the latest release sysrepo, you will not have to worry about this ever again.

Don't you think, that contradicts the concept of compatibility YANG tries to follow?

Could you clarify what concept exactly you mean? Of course, compatibility is generally desired but not sure what YANG has to do with that.

[frimpler]

I know of the datastore plugin approach and I see the advantages in general. But it does not solve issue when reading the old LYB files is required, unless someone writes a LYB-version-something-plugin, who has the inside knowledge in the differences of the LYB versions. Regarding compatibility: I just mentioned YANG, because designers care a lot to be upward compatible when creating new revisions of YANG modules and so it could be expected the DB behaves.

However, in general, I just wanted clarification what to expect. If you never planned to add support for it, it is as it is.

Thanks, again.

[michalvasko]

Alright and like I said, this problem should now be left in the past once you update to some current version of sysrepo.

[jktjkt]

FYI, on that older sysrepo version we "solved" the compatibility problem by an inotify hook. We gave up on persisting /etc/sysrepo, and instead we dumped the content of the startup DS (which is the only one that matters) to our own persistent location in the JSON format via sysrepocfg -f json -d startup -X, and restored from that file on the next boot.