I figured that Sydney would be a great opportunity to have face2face discussion around this topic, and I commit to be there and try to make progress on this discussion. I would love to get some people representing their deployment projects and operators as well.
Please join us : https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20456/what-do-operators-want-from-the-stable-policy and probably https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20480/upstream-lts-releases Thanks, On Tue, Oct 17, 2017 at 8:32 AM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > So, my $0.02. > > A supported/recent version of a tool to install an unsupported version of a > software is not a bad thing. > > OpenStack has a bad reputation (somewhat deservedly) for being hard to > upgrade. This has mostly gotten better over time but there are still a large > number of older, unsupported deployments at this point. > > Sometimes, burning down the cloud isn't an option and sometimes upgrading in > place isn't an option either, and they are stuck on an unsupported version. > > Being able to deploy with a more modern installer the same version of the > cloud your running in production and shift the load to it (sideways upgrade), > but then have an upgrade path provided by the tool would be a great thing. > > Thanks, > Kevin > ________________________________________ > From: Michał Jastrzębski [inc...@gmail.com] > Sent: Monday, October 16, 2017 3:50 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] > [puppet] Proposing changes in stable policy for installers > > So my 0.02$ > > Problem with handling Newton goes beyond deployment tools. Yes, it's > popular to use, but if our dependencies (openstack services > themselves) are unmaintained, so should we. If we say "we support > Newton" in deployment tools, we make kind of promise we can't keep. If > for example there is CVE in Nova that affects Newton, there is nothing > we can do about it and our "support" is meaningless. > > Not having LTS kind of model was issue for OpenStack operators > forever, but that's not problem we can solve in deployment tools > (although we are often asked for that because our communities are > largely operators and we're arguably closest projects to operators). > > I, for one, think we should keep current stable policy, not make > exception for deployment tools, and address this issue across the > board. What Emilien is describing is real issue that hurts operators. > > On 16 October 2017 at 15:38, Emilien Macchi <emil...@redhat.com> wrote: >> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez <thie...@openstack.org> >> wrote: >>> Emilien Macchi wrote: >>>> [...] >>>> ## Proposal >>>> >>>> Proposal 1: create a new policy that fits for projects like installers. >>>> I kicked-off something here: https://review.openstack.org/#/c/511968/ >>>> (open for feedback). >>>> Content can be read here: >>>> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases >>>> Tag created here: https://review.openstack.org/#/c/511969/ (same, >>>> please review). >>>> >>>> The idea is really to not touch the current stable policy and create a >>>> new one, more "relax" that suits well for projects like installers. >>>> >>>> Proposal 2: change the current policy and be more relax for projects >>>> like installers. >>>> I haven't worked on this proposal while it was something I was >>>> considering doing first, because I realized it could bring confusion >>>> in which projects actually follow the real stable policy and the ones >>>> who have exceptions. >>>> That's why I thought having a dedicated tag would help to separate them. >>>> >>>> Proposal 3: no change anywhere, projects like installer can't claim >>>> stability etiquette (not my best option in my opinion). >>>> >>>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla, >>>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has >>>> this need), please get involved in the review process. >>> >>> My preference goes to proposal 1, however rather than call it "relaxed" >>> I would make it specific to deployment/lifecycle or cycle-trailing >>> projects. >>> >>> Ideally this policy could get adopted by any such project. The >>> discussion started on the review and it's going well, so let's see where >>> it goes :) >> >> Thierry, when I read your comment on Gerrit I understand you prefer to >> amend the existing policy and just make a note for installers (which >> is I think the option #2 that I proposed). Can you please confirm >> that? >> So far I see option #1 has large consensus here, I'll wait for >> Thierry's answer to continue to work on it. >> >> Thanks for the feedback so far! >> -- >> Emilien Macchi >> >> __________________________________________________________________________ >> 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 > > __________________________________________________________________________ > 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 > > __________________________________________________________________________ > 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 -- Emilien Macchi __________________________________________________________________________ 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
