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

[Jean-Philippe Evrard]

On 25 October 2017 at 10:10, Flavio Percoco <fla...@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@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
>&g

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

[Flavio Percoco]

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.

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

[Emilien Macchi]

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@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
>

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

[Fox, Kevin M]

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

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

[Bogdan Dobrelya]

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  wrote:
>> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez  
>> 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
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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

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

[Thierry Carrez]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Michał Jastrzębski]

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  wrote:
> On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez  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

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

[Emilien Macchi]

On Mon, Oct 16, 2017 at 4:27 AM, Thierry Carrez  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

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

[Steven Dake (stdake)]

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"  wrote:

On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake)  
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-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

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

[Steven Hardy]

On Mon, Oct 16, 2017 at 2:33 PM, Steven Dake (stdake)  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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Alex Schultz]

On Mon, Oct 16, 2017 at 7:33 AM, Steven Dake (stdake)  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"  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-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

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

[Doug Hellmann]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Steven Dake (stdake)]

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"  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-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

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

[Jean-Philippe Evrard]

On 16 October 2017 at 12:27, Thierry Carrez  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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thierry Carrez]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Emilien Macchi]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev