Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
On 10/23/18 9:55 PM, Adrian Turjak wrote: 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. What I'm trying to avoid is creating any snowflake upgrade processes. It may not make sense for Adjutant to do this in isolation, but Adjutant doesn't exist in isolation. Also, if I understand correctly, you're proposing to add startup checks instead of upgrade checks. The downside I see there is that you have to have already restarted the service before the check runs so if there's a problem now you have downtime. With a standalone upgrade check you can run the check while the old version of the code is still running. If problems are found you fix them before doing the restart. That said, I don't particularly care how the upgrade check is implemented. If 'adjutant-status upgrade check' just calls 'adjutant-api --check' or something else that returns 0 or non-0 appropriately that satisfies me. I don't want to cross the line into foolish consistency either. :-) -Ben __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
On Tue, 2018-10-23 at 16:40 -0500, Matt Riedemann wrote: > On 10/23/2018 1:41 PM, Sean McGinnis wrote: > > > Yeah, but part of the reason for placeholders was consistency > > > across all of > > > the services. I guess if there are never going to be upgrade > > > checks in > > > adjutant then I could see skipping it, but otherwise I would > > > prefer to at > > > least get the framework in place. > > > > > +1 > > > > Even if there is nothing to check at this point, I think having the > > facility > > there is a benefit for projects and scripts that are going to be > > consuming > > these checks. Having nothing to check, but having the status check > > there, is > > going to be better than everything needing to keep a list of which > > projects to > > run the checks on and which not. > > > > Sure, that works for me as well. I'm not against adding > placeholder/noop > checks knowing that nothing is immediately obvious to replace those > in > Stein, but could be done later when the opportunity arises. If it's > debatable on a per-project basis, then I'd defer to the core team > for > the project. > +1 on what Ben, Matt, and Sean said there. __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
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. __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
On 10/23/2018 1:41 PM, Sean McGinnis wrote: Yeah, but part of the reason for placeholders was consistency across all of the services. I guess if there are never going to be upgrade checks in adjutant then I could see skipping it, but otherwise I would prefer to at least get the framework in place. +1 Even if there is nothing to check at this point, I think having the facility there is a benefit for projects and scripts that are going to be consuming these checks. Having nothing to check, but having the status check there, is going to be better than everything needing to keep a list of which projects to run the checks on and which not. Sure, that works for me as well. I'm not against adding placeholder/noop checks knowing that nothing is immediately obvious to replace those in Stein, but could be done later when the opportunity arises. If it's debatable on a per-project basis, then I'd defer to the core team for the project. -- Thanks, Matt __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
On Tue, Oct 23, 2018 at 10:30:23AM -0400, Ben Nemec wrote: > > > On 10/23/18 9:58 AM, Matt Riedemann wrote: > > On 10/23/2018 8:09 AM, Ben Nemec wrote: > > > Can't we just add a noop command like we are for the services that > > > don't currently need upgrade checks? > > > > We could, but I was also hoping that for most projects we will actually > > be able to replace the noop / placeholder check with *something* useful > > in Stein. > > > > Yeah, but part of the reason for placeholders was consistency across all of > the services. I guess if there are never going to be upgrade checks in > adjutant then I could see skipping it, but otherwise I would prefer to at > least get the framework in place. > +1 Even if there is nothing to check at this point, I think having the facility there is a benefit for projects and scripts that are going to be consuming these checks. Having nothing to check, but having the status check there, is going to be better than everything needing to keep a list of which projects to run the checks on and which not. __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
On 10/23/18 9:58 AM, Matt Riedemann wrote: On 10/23/2018 8:09 AM, Ben Nemec wrote: Can't we just add a noop command like we are for the services that don't currently need upgrade checks? We could, but I was also hoping that for most projects we will actually be able to replace the noop / placeholder check with *something* useful in Stein. Yeah, but part of the reason for placeholders was consistency across all of the services. I guess if there are never going to be upgrade checks in adjutant then I could see skipping it, but otherwise I would prefer to at least get the framework in place. __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
On 10/23/2018 8:09 AM, Ben Nemec wrote: Can't we just add a noop command like we are for the services that don't currently need upgrade checks? We could, but I was also hoping that for most projects we will actually be able to replace the noop / placeholder check with *something* useful in Stein. -- Thanks, Matt __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
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? -- Thanks, Matt __ 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
Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update
On 20/10/18 4:09 AM, Matt Riedemann wrote: > The big news this week is we have a couple of volunteer developers > from NEC (Akhil Jain and Rajat Dhasmana) who are pushing the base > framework changes across a lot of the projects [1]. I'm trying to > review as many of these as I can. The request now is for the core > teams on these projects to review them as well so we can keep moving, > and then start thinking about non-placeholder specific checks for each > project. > > 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. __ 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
