Open Stack

On 25 October 2017 at 10:10, Flavio Percoco <flavio at 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.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
>>
>> __________________________________________________________________________
>> 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
>
>
> --
> @flaper87
> Flavio Percoco
>
> __________________________________________________________________________
> 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
>

I'll be there too.

@evrardjp
Jean-Philippe Evrard