Open Stack

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.Fox at 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 [inc007 at 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 <emilien at redhat.com> wrote:
>> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez <thierry at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi