Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
On 25 October 2017 at 10:10, Flavio Percoco 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 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 wrote: >>>> >>>> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez >>>> 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
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
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 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 wrote: On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez 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-de
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
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 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 wrote: >> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez >> 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
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
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 wrote: > On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez 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 __ OpenStac
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
On 10/17/17 12:50 AM, Michał Jastrzębski wrote: > 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. I agree we should keep current stable policy and never backport features. It adds too much of the maintenance overhead, high risks of breaking changes and requires a lots of additional testing. So then deployment tools, if want features backported, should not be holding that stable policy tag. > > On 16 October 2017 at 15:38, Emilien Macchi wrote: >> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez >> 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 > -- Best regards, Bogdan Dobrelya, Irc #bogdando __ 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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
Emilien Macchi wrote: > > 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. Sorry I wasn't clear. I started working on tag modifications (to add ACL requirements and make it more clearly main-service-specific) when I realized it was just merely pointing to stable policy. Reading your proposed change it appeared as two variants on the same document... So I figured we could spare the creation of an additional tag. I'm fine with either approach really (solution 1 or solution 2). The important part is to define the variant/other policy in a way that would work for most deployment teams while benefiting the users interested in stability (i.e. a good trade-off between getting desirable fixes and being exposed to unnecessary risk). -- Thierry Carrez (ttx) __ 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] [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 wrote: > On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez 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
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez 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
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
Steve, I can see how #1 might be a problem in general and should be addressed in reasonable ways. For #2, I think your analysis of the tech in use is accurate and if a new policy is made it be general yet inclusive enough to permit lifecycle management tools to improve and grow. Regards -steve On 10/16/17, 8:57 AM, "Steven Hardy" wrote: On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake) wrote: > Emilien, > > I generally thought the stable policy seemed reasonable enough for lifecycle management tools. I’m not sure what specific problems you had in TripleO although I did read your review. Kolla was just tagged with the stable policy, and TMK, we haven’t run into trouble yet, although the Kolla project is stable and has been following the stable policy for about 18 months. If the requirements are watered down, the tag could potentially be meaningless. We haven’t experienced this specific tag enough to know if it needs some refinement for the specific use case of lifecycle management tools. That said, the follows release policy was created to handle the special case of lifecycle management tool’s upstream sources not being ready for lifecycle management tools to release at one coordinated release time. We initially felt the policy was reasonable too, but there are a couple of specific recurring pain points: 1. Services land features which require installer/management tool updates late in the cycle, or the work to update the configuration tooling just doesn't happen fast enough during a given cycle. 2. Vendor integrations, similar to (1) but specific to enabling vendor backends e.g for Neutron etc - the work to enable configuring specific vendor plugins tends to lag the upstream releases (sometimes significantly) because most vendors are focussed on consuming the stable branch releases, not the development/master releases. In an ideal world the answer would be for everyone working on these integrations to land the installer (e.g puppet/TripleO/Kolla/...) patches earlier, but even with the concessions around cycle-trailing deadlines we're finding that there is ongoing pressure to backport integrations which (according to stable-maint policy) are strictly "features" but are actually more integration or enablement of features which do exist in the version of OpenStack we're deploying. Several releases ago (before we adopted stable: follows-policy) we tried to solve this by allowing selected feature backports, but this was insufficiently well defined (and thus abused) so we need some way to enable vendor integrations and exposure of new features in the underlying services, without allowing a backport-everything floodgate to open ;) I think one difference between TripleO/Puppet and Kolla here is AFAIK Kolla has several ways to customize the configuration of deployed services in a fairly unconstrained way, whereas the openstack puppet modules and TripleO publish interfaces via a somewhat more static module and "service plugin" model, which improves discoverability of features e.g for the TripleO UI but causes a headache when you discover support for a new vendor Neutron plugin is required well after the upstream release deadline has passed. Hope that helps clarify somewhat? Steve __ 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
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake) wrote: > Emilien, > > I generally thought the stable policy seemed reasonable enough for lifecycle > management tools. I’m not sure what specific problems you had in TripleO > although I did read your review. Kolla was just tagged with the stable > policy, and TMK, we haven’t run into trouble yet, although the Kolla project > is stable and has been following the stable policy for about 18 months. If > the requirements are watered down, the tag could potentially be meaningless. > We haven’t experienced this specific tag enough to know if it needs some > refinement for the specific use case of lifecycle management tools. That > said, the follows release policy was created to handle the special case of > lifecycle management tool’s upstream sources not being ready for lifecycle > management tools to release at one coordinated release time. We initially felt the policy was reasonable too, but there are a couple of specific recurring pain points: 1. Services land features which require installer/management tool updates late in the cycle, or the work to update the configuration tooling just doesn't happen fast enough during a given cycle. 2. Vendor integrations, similar to (1) but specific to enabling vendor backends e.g for Neutron etc - the work to enable configuring specific vendor plugins tends to lag the upstream releases (sometimes significantly) because most vendors are focussed on consuming the stable branch releases, not the development/master releases. In an ideal world the answer would be for everyone working on these integrations to land the installer (e.g puppet/TripleO/Kolla/...) patches earlier, but even with the concessions around cycle-trailing deadlines we're finding that there is ongoing pressure to backport integrations which (according to stable-maint policy) are strictly "features" but are actually more integration or enablement of features which do exist in the version of OpenStack we're deploying. Several releases ago (before we adopted stable: follows-policy) we tried to solve this by allowing selected feature backports, but this was insufficiently well defined (and thus abused) so we need some way to enable vendor integrations and exposure of new features in the underlying services, without allowing a backport-everything floodgate to open ;) I think one difference between TripleO/Puppet and Kolla here is AFAIK Kolla has several ways to customize the configuration of deployed services in a fairly unconstrained way, whereas the openstack puppet modules and TripleO publish interfaces via a somewhat more static module and "service plugin" model, which improves discoverability of features e.g for the TripleO UI but causes a headache when you discover support for a new vendor Neutron plugin is required well after the upstream release deadline has passed. Hope that helps clarify somewhat? Steve __ 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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
On Mon, Oct 16, 2017 at 7:33 AM, Steven Dake (stdake) wrote: > Emilien, > > I generally thought the stable policy seemed reasonable enough for lifecycle > management tools. I’m not sure what specific problems you had in TripleO > although I did read your review. Kolla was just tagged with the stable > policy, and TMK, we haven’t run into trouble yet, although the Kolla project > is stable and has been following the stable policy for about 18 months. If > the requirements are watered down, the tag could potentially be meaningless. > We haven’t experienced this specific tag enough to know if it needs some > refinement for the specific use case of lifecycle management tools. That > said, the follows release policy was created to handle the special case of > lifecycle management tool’s upstream sources not being ready for lifecycle > management tools to release at one coordinated release time. > > Kollians? Any problems thus far with the stable policy? > > Cheers > -steve > I'm not a Kolla person, but from the Puppet OpenStack stand point we haven't been able to follow stable because we can't guarantee complete configuration coverage for all the services. So while we don't backport breaking changes (ie removing parameters from resources), we do have to backport additions (adding params to resources/etc) as folks start trying to use the upstream services. Since people are not necessarily following master in their deployments, for example there's a significant lag from operators who start trying to upgrade to Newton about the time we're releasing Pike, etc etc. These types of additions could be seen as features because we didn't know we had to add additional code to support the use case in the previous cycle. Generally we're supporting our basic scenarios (which are pretty extensive), but there are end user cases we don't test on a regular basis which pop up from time to time where being able to say we support a 'stable-policy' but will backport non-breaking changes if necessary. Thanks, -Alex > > On 10/16/17, 4:27 AM, "Thierry Carrez" 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 Carrez (ttx) > > __ > 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
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
Excerpts from Emilien Macchi's message of 2017-10-13 15:02:10 -0700: > Greeting folks, > > I hope we can get attention from stable-maint, release-managers and > installers projects. > > > ## Background > > Some projects tried hard to follow stable policy but it didn't finish > well: https://review.openstack.org/#/c/507924/ > This policy is too strict for projects like installers, although it's > not a reason why the projects wouldn't be "stable". > We decided to discuss again about the tag and how it works for installers. > > ## 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. > > Thanks, It seems appropriate for new versions of deployment tools to be extended past the point where other types of projects allow feature additions to add support for new hardware or operating systems to old releases. Option 1 seems like the most straightforward approach, because it doesn't change the definition of the existing tag and cause confusion about which definition applies to a given version of a given project. Doug __ 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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
Emilien, I generally thought the stable policy seemed reasonable enough for lifecycle management tools. I’m not sure what specific problems you had in TripleO although I did read your review. Kolla was just tagged with the stable policy, and TMK, we haven’t run into trouble yet, although the Kolla project is stable and has been following the stable policy for about 18 months. If the requirements are watered down, the tag could potentially be meaningless. We haven’t experienced this specific tag enough to know if it needs some refinement for the specific use case of lifecycle management tools. That said, the follows release policy was created to handle the special case of lifecycle management tool’s upstream sources not being ready for lifecycle management tools to release at one coordinated release time. Kollians? Any problems thus far with the stable policy? Cheers -steve On 10/16/17, 4:27 AM, "Thierry Carrez" 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 Carrez (ttx) __ 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
Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
On 16 October 2017 at 12:27, Thierry Carrez 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 Carrez (ttx) > > __ > 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 Thanks for the work there Emilien! __ 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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
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 Carrez (ttx) __ 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-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
Greeting folks, I hope we can get attention from stable-maint, release-managers and installers projects. ## Background Some projects tried hard to follow stable policy but it didn't finish well: https://review.openstack.org/#/c/507924/ This policy is too strict for projects like installers, although it's not a reason why the projects wouldn't be "stable". We decided to discuss again about the tag and how it works for installers. ## 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. Thanks, -- 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