On 25 October 2017 at 10:10, Flavio Percoco <fla...@redhat.com> wrote: > On 24/10/17 15:35 -0700, Emilien Macchi wrote: >> >> 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 > > > I'm interested in joining this discussion! > Flavio > > >> 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 > > > -- > @flaper87 > Flavio Percoco > > __________________________________________________________________________ > 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 >
I'll be there too. @evrardjp Jean-Philippe Evrard __________________________________________________________________________ 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