On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson <m...@not.mn> wrote: > > > On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: > >> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote: >>> The pressure for #2 comes from the inability to skip upgrades and the fact >>> that upgrades are hugely time consuming still. >>> >>> If you want to reduce the push for number #2 and help developers get their >>> wish of getting features into users hands sooner, the path to upgrade >>> really needs to be much less painful. >>> >> >> +1000 >> >> We are upgrading from Kilo to Mitaka. It took 1 year to plan and >> execute the upgrade. (and we skipped a version) >> Scheduling all the relevant internal teams is a monumental task >> because we don't have dedicated teams for those projects and they have >> other priorities. >> Upgrading affects a LOT of our systems, some we don't fully have >> control over. And it can takes months to get new deployment on those >> systems. (and after, we have to test compatibility, of course) >> >> So I guess you can understand my frustration when I'm told to upgrade >> more often and that skipping versions is discouraged/unsupported. >> At the current pace, I'm just falling behind. I *need* to skip >> versions to keep up. >> >> So for our next upgrades, we plan on skipping even more versions if >> the database migration allows it. (except for Nova which is a huge >> PITA to be honest due to CellsV1) >> I just don't see any other ways to keep up otherwise. > > ?!?! > > What does it take for this to never happen again? No operator should need to > plan and execute an upgrade for a whole year to upgrade one year's worth of > code development. > > We don't need new policies, new teams, more releases, fewer releases, or > anything like that. The goal is NOT "let's have an LTS release". The goal > should be "How do we make sure Mattieu and everyone else in the world can > actually deploy and use the software we are writing?" > > Can we drop the entire LTS discussion for now and focus on "make upgrades > take less than a year" instead? After we solve that, let's come back around > to LTS versions, if needed. I know there's already some work around that. > Let's focus there and not be distracted about the best bureaucracy for not > deleting two-year-old branches. > > > --John
John, So... Any concrete ideas on how to achieve that? Thanks, Dims > > > /me puts on asbestos pants > >> >> -- >> Mathieu >> >> _______________________________________________ >> OpenStack-operators mailing list >> openstack-operat...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > __________________________________________________________________________ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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
