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
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
