Open Stack

On 24/10/18 2:09 AM, Ben Nemec wrote:
>
>
> 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?


I mostly was responding to this in the review itself rather than on here.

We are probably going to have reason for an upgrade check in Adjutant,
my main gripe is, Adjutant is Django based and there isn't a good point
in adding a separate cli when we already expose 'adjutant-api' as a
proxy to manage.py and as such we should just register the upgrade check
as a custom Django admin command.

More so because all of the logic needed to actually run the check in
future will require Django settings to be configured. We don't actually
use any oslo libraries yet so the current code for the check doesn't
actually make sense in context.

I'm fine with a noop check, but we have to make it fit.