settingsLogin | Registersettings

[openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Oct 17, 2017 in openstack-dev by emilien_at_redhat.co (36,940 points)   2 6 9

15 Responses

0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

On 16 October 2017 at 12:27, Thierry Carrez thierry@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 Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by Jean-Philippe_Evrard (1,360 points)   2
0 votes

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" thierry@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 Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by Steven_Dake_(stdake) (24,540 points)   2 10 23
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by Doug_Hellmann (87,520 points)   3 4 9
0 votes

On Mon, Oct 16, 2017 at 7:33 AM, Steven Dake (stdake) stdake@cisco.com 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" thierry@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 Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by aschultz_at_redhat.c (5,800 points)   2 2 4
0 votes

On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake) stdake@cisco.com 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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by Steven_Hardy (16,900 points)   2 7 11
0 votes

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" shardy@redhat.com wrote:

On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake) <stdake@cisco.com> 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-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by Steven_Dake_(stdake) (24,540 points)   2 10 23
0 votes

On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez thierry@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by emilien_at_redhat.co (36,940 points)   2 6 9
0 votes

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@redhat.com wrote:
On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez thierry@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 16, 2017 by Michał_Jastrzębski (9,220 points)   1 5 5
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Oct 17, 2017 by Thierry_Carrez (57,480 points)   3 8 13
...