On 10/22/18 5:40 PM, Matt Riedemann wrote:
On 10/22/2018 4:35 PM, Adrian Turjak wrote:
The one other open question I have is about the Adjutant change [2]. I
know Adjutant is very new and I'm not sure what upgrades look like for
that project, so I don't really know how valuable adding the upgrade
check framework is to that project. Is it like Horizon where it's
mostly stateless and fed off plugins? Because we don't have an upgrade
check CLI for Horizon for that reason.
[1]
https://review.openstack.org/#/q/topic:upgrade-checkers+(status:open+OR+status:merged)
[2]https://review.openstack.org/#/c/611812/
Adjutant's codebase is also going to be a bit unstable for the next few
cycles while we refactor some internals (we're not marking it 1.0 yet).
Once the current set of ugly refactors planned for late Stein are done I
may look at building some upgrade checking, once we also work out what
out upgrade checking should look like. Probably mostly checking config
changes, database migration states, and plugin compatibility.
Adjutant already has a concept of startup checks at least, which while
not anywhere near as extensive as they should be, mostly amount to
making sure your config file looks 'mostly' sane regarding plugins
before starting up the service, and we do intend to expand on that, plus
we can reuse a large chunk of that for upgrade checking.
OK it seems there is not really any point in trying to satisfy the
upgrade checkers goal for Adjutant in Stein then. Should we just abandon
the change?
Can't we just add a noop command like we are for the services that don't
currently need upgrade checks?
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
