Morgan Fainberg <morgan.fainb...@gmail.com> wrote on 08/24/2014 12:01:37 PM:
> ... > > Keystone saw an oddity with the new sample config generator > (changing how options are sorted and therefore changing the way the > sample config is rendered). This could be a similar / related issue. > > Most of the projects stopped gating on "up-to-date" sample config a > few reasons, the first is that with external library dependencies > you never know when / if something upstream will break the test run > (e.g. New Oslo.config or new keystonemiddleware). > > Now imagine that issue occurred and was blocking a gate-fixing bug > (happened at least a couple times). > > In short, making sample config being up-to-date to merge code causes > a lot if headaches. > > Different projects handle this differently. Nova doesn't have a > sample config in tree, keystone updates on a semi-regular basis > (sometimes as part of a patch, sometimes as a separate patch). > Keystone team is looking at adding a simple non-voting gate job (if > infra doesn't mind) that will tell us the config is out of date. > > While it is nice to always have an updated sample config, I think it > is not worth the breakage / issues it adds to the gate. > > It might make sense to standardize how we handle sample config files > across the projects or at least standardize on removing the gate > block if the config is out of date. I know it was floated earlier > that there would be a proposal bot job (like translations) for > sample config files, but I don't remember the specifics of why it > wasn't well liked. Consistency would be nice. The must-have is just to document each project's procedure (accurately, of course). Thanks, Mike
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev