Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn if code and schema are of different versions #41

Open
jrha opened this issue Mar 26, 2015 · 5 comments
Open

Warn if code and schema are of different versions #41

jrha opened this issue Mar 26, 2015 · 5 comments

Comments

@jrha
Copy link
Member

jrha commented Mar 26, 2015

Modules using data from the configuration tree should issue a warning if the version of their Perl module is different from the schema version used to validate their tree, this can occur if sites do not pin their package versions or build modified packages.

This is a high level tracker to track the implementation of this across repositories as required.

@jrha
Copy link
Member Author

jrha commented Mar 26, 2015

Many components already provide a version number such as:

"/software/components/pam/version" = '${no-snapshot-version}';

Which might help in the implementation of this.

@ned21
Copy link
Contributor

ned21 commented Oct 28, 2015

Please make this optional since our package upgrade schedules are not synchronised to our template releases.

@stdweird
Copy link
Member

@ned21 can you clarify a bit more? are you running schemas that are out of sync with components? who puts the schema in place (maunal or scripted?). and how do you expect the component to do the right thing?

decoupling schema and component is not for the faint of heart, we had our share of self inflicted issues and that's the main reason i'd like to have this.

regardless, ofcourse this will be an opt-in possibility to prevent you from doing wrong things. i see this in a first phase only logging warning or error, not anything more than that.

@ned21
Copy link
Contributor

ned21 commented Oct 29, 2015

Running schemas that are backwards and forwards compatible with different code releases is quite common in the database world - it's how people do A/B testing, etc. We just take care to only deploy breaking schema changes when we know a code change has propagated to our plant.

We're managing ok so far but it does take us ages to upgrade and we are currently doing it component by component since we were moving from the pre-unit test versions versions to the maven built code base.

@jrha
Copy link
Member Author

jrha commented Nov 2, 2015

Indeed! But it makes sense to have a reporting mechanism for the versions (and when they differ) which is what this is about.

@jrha jrha modified the milestones: 16.2, 15.12 Dec 7, 2015
@jrha jrha removed this from the 16.2 milestone Jan 12, 2016
ttyS4 pushed a commit to ttyS4/ncm-ncd that referenced this issue Dec 15, 2017
use mkpath instead of make_path to allow EL5 unittests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants