[openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
bdobreli at redhat.com
Tue Oct 17 08:31:22 UTC 2017
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 <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:
>>>> 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
>>> 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
>> 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev