[requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Matthew Thode
We have a problem in requirements that projects that don't have the
cycle-with-intermediary release model (most of the cycle-with-milestones
model) don't get integrated with requirements until the cycle is fully
done.  This causes a few problems.

* These projects don't produce a consumable release for requirements
until end of cycle (which does not accept beta releases).

* The former causes old requirements to be kept in place, meaning caps,
exclusions, etc. are being kept, which can cause conflicts.

* Keeping the old version in requirements means that cross dependencies
are not tested with updated versions.

This has hit us with the mistral and tripleo projects particularly
(tagged in the title).  They disallow pbr-3.0.0 and in the case of
mistral sqlalchemy updates.

[mistral]
mistral - blocking sqlalchemy - milestones

[tripleo]
os-refresh-config - blocking pbr - milestones
os-apply-config - blocking pbr - milestones
os-collect-config - blocking pbr - milestones

[nova]
os-vif - blocking pbr - intermediary

[horizon]
django-openstack-auth - blocking django - intermediary


So, here's what needs doing.

Those projects that are already using the cycle-with-intermediary model
should just do a release.

For those that are using cycle-with-milestones, you will need to change
to the cycle-with-intermediary model, and do a full release, both can be
done at the same time.

If anyone has any questions or wants clarifications this thread is good,
or I'm on irc as prometheanfire in the #openstack-requirements channel.

--
Matthew Thode (prometheanfire)


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Jay Pipes
On 05/30/2017 02:36 PM, Matthew Thode wrote:
> [nova]
> os-vif - blocking pbr - intermediary

Sorry for the delay. We'll fix this up today. We'll need to cut a new
release of os-traits too given a bug we ran into today...

Thanks for keeping us honest!

Best,
-jay

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Doug Hellmann-2
In reply to this post by Matthew Thode
Excerpts from Matthew Thode's message of 2017-05-30 13:36:02 -0500:

> We have a problem in requirements that projects that don't have the
> cycle-with-intermediary release model (most of the cycle-with-milestones
> model) don't get integrated with requirements until the cycle is fully
> done.  This causes a few problems.
>
> * These projects don't produce a consumable release for requirements
> until end of cycle (which does not accept beta releases).
>
> * The former causes old requirements to be kept in place, meaning caps,
> exclusions, etc. are being kept, which can cause conflicts.
>
> * Keeping the old version in requirements means that cross dependencies
> are not tested with updated versions.
>
> This has hit us with the mistral and tripleo projects particularly
> (tagged in the title).  They disallow pbr-3.0.0 and in the case of
> mistral sqlalchemy updates.
>
> [mistral]
> mistral - blocking sqlalchemy - milestones
>
> [tripleo]
> os-refresh-config - blocking pbr - milestones
> os-apply-config - blocking pbr - milestones
> os-collect-config - blocking pbr - milestones
>
> [nova]
> os-vif - blocking pbr - intermediary
>
> [horizon]
> django-openstack-auth - blocking django - intermediary
>
>
> So, here's what needs doing.
>
> Those projects that are already using the cycle-with-intermediary model
> should just do a release.
>
> For those that are using cycle-with-milestones, you will need to change
> to the cycle-with-intermediary model, and do a full release, both can be
> done at the same time.
>
> If anyone has any questions or wants clarifications this thread is good,
> or I'm on irc as prometheanfire in the #openstack-requirements channel.
>

We probably want to add a review criteria to the requirements list that
projects using the cycle-with-milestone model are not added to the list
to avoid this issue in the future.

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Matthew Thode
On 05/30/2017 02:51 PM, Doug Hellmann wrote:

> Excerpts from Matthew Thode's message of 2017-05-30 13:36:02 -0500:
>> We have a problem in requirements that projects that don't have the
>> cycle-with-intermediary release model (most of the cycle-with-milestones
>> model) don't get integrated with requirements until the cycle is fully
>> done.  This causes a few problems.
>>
>> * These projects don't produce a consumable release for requirements
>> until end of cycle (which does not accept beta releases).
>>
>> * The former causes old requirements to be kept in place, meaning caps,
>> exclusions, etc. are being kept, which can cause conflicts.
>>
>> * Keeping the old version in requirements means that cross dependencies
>> are not tested with updated versions.
>>
>> This has hit us with the mistral and tripleo projects particularly
>> (tagged in the title).  They disallow pbr-3.0.0 and in the case of
>> mistral sqlalchemy updates.
>>
>> [mistral]
>> mistral - blocking sqlalchemy - milestones
>>
>> [tripleo]
>> os-refresh-config - blocking pbr - milestones
>> os-apply-config - blocking pbr - milestones
>> os-collect-config - blocking pbr - milestones
>>
>> [nova]
>> os-vif - blocking pbr - intermediary
>>
>> [horizon]
>> django-openstack-auth - blocking django - intermediary
>>
>>
>> So, here's what needs doing.
>>
>> Those projects that are already using the cycle-with-intermediary model
>> should just do a release.
>>
>> For those that are using cycle-with-milestones, you will need to change
>> to the cycle-with-intermediary model, and do a full release, both can be
>> done at the same time.
>>
>> If anyone has any questions or wants clarifications this thread is good,
>> or I'm on irc as prometheanfire in the #openstack-requirements channel.
>>
>
> We probably want to add a review criteria to the requirements list that
> projects using the cycle-with-milestone model are not added to the list
> to avoid this issue in the future.
>
> Doug
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Good idea, added in https://review.openstack.org/469234

--
Matthew Thode (prometheanfire)


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Emilien Macchi-4
In reply to this post by Matthew Thode
On Tue, May 30, 2017 at 8:36 PM, Matthew Thode
<[hidden email]> wrote:

> We have a problem in requirements that projects that don't have the
> cycle-with-intermediary release model (most of the cycle-with-milestones
> model) don't get integrated with requirements until the cycle is fully
> done.  This causes a few problems.
>
> * These projects don't produce a consumable release for requirements
> until end of cycle (which does not accept beta releases).
>
> * The former causes old requirements to be kept in place, meaning caps,
> exclusions, etc. are being kept, which can cause conflicts.
>
> * Keeping the old version in requirements means that cross dependencies
> are not tested with updated versions.
>
> This has hit us with the mistral and tripleo projects particularly
> (tagged in the title).  They disallow pbr-3.0.0 and in the case of
> mistral sqlalchemy updates.
>
> [mistral]
> mistral - blocking sqlalchemy - milestones
>
> [tripleo]
> os-refresh-config - blocking pbr - milestones
> os-apply-config - blocking pbr - milestones
> os-collect-config - blocking pbr - milestones

These are cycle-with-milestones., like os-net-config for example,
which wasn't mentioned in this email. It has the same releases as
os-net-config also, so I'm confused why these 3 cause issue, I
probably missed something.

Anyway, I'm happy to change os-*-config (from TripleO) to be
cycle-with-intermediary. Quick question though, which tag would you
like to see, regarding what we already did for pike-1?

Thanks,

> [nova]
> os-vif - blocking pbr - intermediary
>
> [horizon]
> django-openstack-auth - blocking django - intermediary
>
>
> So, here's what needs doing.
>
> Those projects that are already using the cycle-with-intermediary model
> should just do a release.
>
> For those that are using cycle-with-milestones, you will need to change
> to the cycle-with-intermediary model, and do a full release, both can be
> done at the same time.
>
> If anyone has any questions or wants clarifications this thread is good,
> or I'm on irc as prometheanfire in the #openstack-requirements channel.
>
> --
> Matthew Thode (prometheanfire)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Emilien Macchi

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Matthew Thode
On 05/30/2017 04:08 PM, Emilien Macchi wrote:

> On Tue, May 30, 2017 at 8:36 PM, Matthew Thode
> <[hidden email]> wrote:
>> We have a problem in requirements that projects that don't have the
>> cycle-with-intermediary release model (most of the cycle-with-milestones
>> model) don't get integrated with requirements until the cycle is fully
>> done.  This causes a few problems.
>>
>> * These projects don't produce a consumable release for requirements
>> until end of cycle (which does not accept beta releases).
>>
>> * The former causes old requirements to be kept in place, meaning caps,
>> exclusions, etc. are being kept, which can cause conflicts.
>>
>> * Keeping the old version in requirements means that cross dependencies
>> are not tested with updated versions.
>>
>> This has hit us with the mistral and tripleo projects particularly
>> (tagged in the title).  They disallow pbr-3.0.0 and in the case of
>> mistral sqlalchemy updates.
>>
>> [mistral]
>> mistral - blocking sqlalchemy - milestones
>>
>> [tripleo]
>> os-refresh-config - blocking pbr - milestones
>> os-apply-config - blocking pbr - milestones
>> os-collect-config - blocking pbr - milestones
>
> These are cycle-with-milestones., like os-net-config for example,
> which wasn't mentioned in this email. It has the same releases as
> os-net-config also, so I'm confused why these 3 cause issue, I
> probably missed something.
>
> Anyway, I'm happy to change os-*-config (from TripleO) to be
> cycle-with-intermediary. Quick question though, which tag would you
> like to see, regarding what we already did for pike-1?
>
> Thanks,
>
Pike is fine as it's just master that has this issue.  The problem is
that the latest release blocks the pbr from upper-constraints from being
coinstallable.

>> [nova]
>> os-vif - blocking pbr - intermediary
>>
>> [horizon]
>> django-openstack-auth - blocking django - intermediary
>>
>>
>> So, here's what needs doing.
>>
>> Those projects that are already using the cycle-with-intermediary model
>> should just do a release.
>>
>> For those that are using cycle-with-milestones, you will need to change
>> to the cycle-with-intermediary model, and do a full release, both can be
>> done at the same time.
>>
>> If anyone has any questions or wants clarifications this thread is good,
>> or I'm on irc as prometheanfire in the #openstack-requirements channel.
>>
>> --
>> Matthew Thode (prometheanfire)
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>

--
Matthew Thode (prometheanfire)


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Doug Hellmann-2
Excerpts from Matthew Thode's message of 2017-05-30 16:11:41 -0500:

> On 05/30/2017 04:08 PM, Emilien Macchi wrote:
> > On Tue, May 30, 2017 at 8:36 PM, Matthew Thode
> > <[hidden email]> wrote:
> >> We have a problem in requirements that projects that don't have the
> >> cycle-with-intermediary release model (most of the cycle-with-milestones
> >> model) don't get integrated with requirements until the cycle is fully
> >> done.  This causes a few problems.
> >>
> >> * These projects don't produce a consumable release for requirements
> >> until end of cycle (which does not accept beta releases).
> >>
> >> * The former causes old requirements to be kept in place, meaning caps,
> >> exclusions, etc. are being kept, which can cause conflicts.
> >>
> >> * Keeping the old version in requirements means that cross dependencies
> >> are not tested with updated versions.
> >>
> >> This has hit us with the mistral and tripleo projects particularly
> >> (tagged in the title).  They disallow pbr-3.0.0 and in the case of
> >> mistral sqlalchemy updates.
> >>
> >> [mistral]
> >> mistral - blocking sqlalchemy - milestones
> >>
> >> [tripleo]
> >> os-refresh-config - blocking pbr - milestones
> >> os-apply-config - blocking pbr - milestones
> >> os-collect-config - blocking pbr - milestones
> >
> > These are cycle-with-milestones., like os-net-config for example,
> > which wasn't mentioned in this email. It has the same releases as
> > os-net-config also, so I'm confused why these 3 cause issue, I
> > probably missed something.
> >
> > Anyway, I'm happy to change os-*-config (from TripleO) to be
> > cycle-with-intermediary. Quick question though, which tag would you
> > like to see, regarding what we already did for pike-1?
> >
> > Thanks,
> >
>
> Pike is fine as it's just master that has this issue.  The problem is
> that the latest release blocks the pbr from upper-constraints from being
> coinstallable.

The issue is that even with beta releases like we publish at
milestones, new versions of these projects won't be installed in
gate jobs because we have to give pip special instructions to allow
pre-releases and we, as a rule, do not give it those instructions.
The result is that we need anything that is going to be installed
as via pip to be releasable at any point in the cycle, to address
dependency issues like we're dealing with here, and that means
changing the model back to cycle-with-intermediary.

This isn't something I foresaw when we talked about making all of
the TripleO components use a consistent model in the past. I'm sorry
for the oversight.

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Thierry Carrez
In reply to this post by Matthew Thode
Matthew Thode wrote:
> We have a problem in requirements that projects that don't have the
> cycle-with-intermediary release model (most of the cycle-with-milestones
> model) don't get integrated with requirements until the cycle is fully
> done.  This causes a few problems.
> [...]

Makes sense. Rules that apply for libraries should apply to other strong
dependencies.

> This has hit us with the mistral and tripleo projects particularly
> (tagged in the title).  They disallow pbr-3.0.0 and in the case of
> mistral sqlalchemy updates.
>
> [mistral]
> mistral - blocking sqlalchemy - milestones

I wonder why mistral is in requirements. Looks like tripleo-common is
depending on it ? Could someone shine some light on this ? It might just
mean mistral-lib is missing a few functions, and switching the release
model of mistral itself might be overkill ?

--
Thierry Carrez (ttx)


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Ренат Ахмеров

On 31 May 2017, 15:08 +0700, Thierry Carrez <[hidden email]>, wrote:

This has hit us with the mistral and tripleo projects particularly
(tagged in the title). They disallow pbr-3.0.0 and in the case of
mistral sqlalchemy updates.

[mistral]
mistral - blocking sqlalchemy - milestones

I wonder why mistral is in requirements. Looks like tripleo-common is
depending on it ? Could someone shine some light on this ? It might just
mean mistral-lib is missing a few functions, and switching the release
model of mistral itself might be overkill ?

This dependency is currently needed to create custom Mistral actions. It was originally not the best architecture and one of the reasons to create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by moving all that’s needed for creating actions into a lib (plus something else). The thing is that the transition is not over and APIs that we put into ‘mistral-lib’ are still experimental. The plan is to complete this initiative, including docs and needed refactoring, till the end of Pike.

What possible negative consequences may we have if we switch release model to "cycle-with-intermediary”? Practically, all our releases, even those made after milestones, are considered stable and I don’t see issues if we’ll be producing full releases every time. Btw, how does stable branch maintenance work in this case? I guess it should be the same, one stable branch per cycle. I’d appreciate if you could clarify this.

Renat Akhmerov
@Nokia

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Rob Cresswell (rcresswe)
In reply to this post by Matthew Thode

[horizon]
django-openstack-auth - blocking django - intermediary

https://review.openstack.org/#/c/469420 is up to release django_openstack_auth. Sorry for the delays.

Rob

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Emilien Macchi-4
In reply to this post by Matthew Thode
On Tue, May 30, 2017 at 11:11 PM, Matthew Thode
<[hidden email]> wrote:

> On 05/30/2017 04:08 PM, Emilien Macchi wrote:
>> On Tue, May 30, 2017 at 8:36 PM, Matthew Thode
>> <[hidden email]> wrote:
>>> We have a problem in requirements that projects that don't have the
>>> cycle-with-intermediary release model (most of the cycle-with-milestones
>>> model) don't get integrated with requirements until the cycle is fully
>>> done.  This causes a few problems.
>>>
>>> * These projects don't produce a consumable release for requirements
>>> until end of cycle (which does not accept beta releases).
>>>
>>> * The former causes old requirements to be kept in place, meaning caps,
>>> exclusions, etc. are being kept, which can cause conflicts.
>>>
>>> * Keeping the old version in requirements means that cross dependencies
>>> are not tested with updated versions.
>>>
>>> This has hit us with the mistral and tripleo projects particularly
>>> (tagged in the title).  They disallow pbr-3.0.0 and in the case of
>>> mistral sqlalchemy updates.
>>>
>>> [mistral]
>>> mistral - blocking sqlalchemy - milestones
>>>
>>> [tripleo]
>>> os-refresh-config - blocking pbr - milestones
>>> os-apply-config - blocking pbr - milestones
>>> os-collect-config - blocking pbr - milestones
>>
>> These are cycle-with-milestones., like os-net-config for example,
>> which wasn't mentioned in this email. It has the same releases as
>> os-net-config also, so I'm confused why these 3 cause issue, I
>> probably missed something.
>>
>> Anyway, I'm happy to change os-*-config (from TripleO) to be
>> cycle-with-intermediary. Quick question though, which tag would you
>> like to see, regarding what we already did for pike-1?
>>
>> Thanks,
>>
>
> Pike is fine as it's just master that has this issue.  The problem is
> that the latest release blocks the pbr from upper-constraints from being
> coinstallable.

Done, please review: https://review.openstack.org/#/c/469530/

Thanks,

>>> [nova]
>>> os-vif - blocking pbr - intermediary
>>>
>>> [horizon]
>>> django-openstack-auth - blocking django - intermediary
>>>
>>>
>>> So, here's what needs doing.
>>>
>>> Those projects that are already using the cycle-with-intermediary model
>>> should just do a release.
>>>
>>> For those that are using cycle-with-milestones, you will need to change
>>> to the cycle-with-intermediary model, and do a full release, both can be
>>> done at the same time.
>>>
>>> If anyone has any questions or wants clarifications this thread is good,
>>> or I'm on irc as prometheanfire in the #openstack-requirements channel.
>>>
>>> --
>>> Matthew Thode (prometheanfire)
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: [hidden email]?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>
>
> --
> Matthew Thode (prometheanfire)
>



--
Emilien Macchi

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Thierry Carrez
In reply to this post by Ренат Ахмеров
Renat Akhmerov wrote:

> On 31 May 2017, 15:08 +0700, Thierry Carrez <[hidden email]>, wrote:
>>> [mistral]
>>> mistral - blocking sqlalchemy - milestones
>>
>> I wonder why mistral is in requirements. Looks like tripleo-common is
>> depending on it ? Could someone shine some light on this ? It might just
>> mean mistral-lib is missing a few functions, and switching the release
>> model of mistral itself might be overkill ?
>
> This dependency is currently needed to create custom Mistral actions. It
> was originally not the best architecture and one of the reasons to
> create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by
> moving all that’s needed for creating actions into a lib (plus something
> else). The thing is that the transition is not over and APIs that we put
> into ‘mistral-lib’ are still experimental. The plan is to complete this
> initiative, including docs and needed refactoring, till the end of Pike.
>
> What possible negative consequences may we have if we switch release
> model to "cycle-with-intermediary”?

There are no "negative" consequences. There are just consequences in
choosing a new release model, so I don't want mistral to switch to that
model *only* because it didn't complete moving some code out of mistral
proper into a more consumable mistral-lib. It feels like we wouldn't be
having that discussion if the code was more adequately split :)

First, the cycle-with-intermediary model means that every tag is a
"release", which is expected to be consumed by users. You have to be
pretty sure that it works -- there won't be any release candidates to
protect you. This means your automated testing coverage needs to be
pretty good.

Second, the cycle-with-intermediary model is less "driven" by the
release team -- you won't have as many reminders (like milestones), or
best-practice deadlines (like feature freeze) to help you. Your team is
basically doing release management internally, deciding when to release,
when to slow down, etc.

As such, this model appeals either to very young projects (which need a
lot of flexibility and need to put things out fast), and very mature
projects (where automated testing coverage is pretty complete, release
liaisons take up much of the release management, and things don't change
that often). Projects in the middle usually prefer the
cycle-with-milestones model.

> Practically, all our releases, even
> those made after milestones, are considered stable and I don’t see
> issues if we’ll be producing full releases every time.

Yes, it sounds like you could switch to that model without too much pain.

> Btw, how does
> stable branch maintenance work in this case? I guess it should be the
> same, one stable branch per cycle. I’d appreciate if you could clarify this.

There is no change in terms of stable releases, you still maintain only
one branch per cycle. The last intermediary release in a given cycle is
where the stable branch for the cycle is cut.

--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Ренат Ахмеров
Thanks Thierry.

To me it sounds like even a better release model for us. We can discuss it with a team at the next team meeting and make a decision.

Renat Akhmerov
@Nokia

On 1 Jun 2017, 17:06 +0700, Thierry Carrez <[hidden email]>, wrote:
Renat Akhmerov wrote:
On 31 May 2017, 15:08 +0700, Thierry Carrez <[hidden email]>, wrote:
[mistral]
mistral - blocking sqlalchemy - milestones

I wonder why mistral is in requirements. Looks like tripleo-common is
depending on it ? Could someone shine some light on this ? It might just
mean mistral-lib is missing a few functions, and switching the release
model of mistral itself might be overkill ?

This dependency is currently needed to create custom Mistral actions. It
was originally not the best architecture and one of the reasons to
create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by
moving all that’s needed for creating actions into a lib (plus something
else). The thing is that the transition is not over and APIs that we put
into ‘mistral-lib’ are still experimental. The plan is to complete this
initiative, including docs and needed refactoring, till the end of Pike.

What possible negative consequences may we have if we switch release
model to "cycle-with-intermediary”?

There are no "negative" consequences. There are just consequences in
choosing a new release model, so I don't want mistral to switch to that
model *only* because it didn't complete moving some code out of mistral
proper into a more consumable mistral-lib. It feels like we wouldn't be
having that discussion if the code was more adequately split :)

First, the cycle-with-intermediary model means that every tag is a
"release", which is expected to be consumed by users. You have to be
pretty sure that it works -- there won't be any release candidates to
protect you. This means your automated testing coverage needs to be
pretty good.

Second, the cycle-with-intermediary model is less "driven" by the
release team -- you won't have as many reminders (like milestones), or
best-practice deadlines (like feature freeze) to help you. Your team is
basically doing release management internally, deciding when to release,
when to slow down, etc.

As such, this model appeals either to very young projects (which need a
lot of flexibility and need to put things out fast), and very mature
projects (where automated testing coverage is pretty complete, release
liaisons take up much of the release management, and things don't change
that often). Projects in the middle usually prefer the
cycle-with-milestones model.

Practically, all our releases, even
those made after milestones, are considered stable and I don’t see
issues if we’ll be producing full releases every time.

Yes, it sounds like you could switch to that model without too much pain.

Btw, how does
stable branch maintenance work in this case? I guess it should be the
same, one stable branch per cycle. I’d appreciate if you could clarify this.

There is no change in terms of stable releases, you still maintain only
one branch per cycle. The last intermediary release in a given cycle is
where the stable branch for the cycle is cut.

--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Thierry Carrez
Note that it's technically too late to change the release model
(milestone-1 is the deadline), but since that kills two birds with one
stone, I'd be willing to grant mistral an exception (as long as it's
done before milestone-2, which is next week).

Renat Akhmerov wrote:

> Thanks Thierry.
>
> To me it sounds like even a better release model for us. We can discuss
> it with a team at the next team meeting and make a decision.
>
> Renat Akhmerov
> @Nokia
>
> On 1 Jun 2017, 17:06 +0700, Thierry Carrez <[hidden email]>, wrote:
>> Renat Akhmerov wrote:
>>> On 31 May 2017, 15:08 +0700, Thierry Carrez <[hidden email]>,
>>> wrote:
>>>>> [mistral]
>>>>> mistral - blocking sqlalchemy - milestones
>>>>
>>>> I wonder why mistral is in requirements. Looks like tripleo-common is
>>>> depending on it ? Could someone shine some light on this ? It might just
>>>> mean mistral-lib is missing a few functions, and switching the release
>>>> model of mistral itself might be overkill ?
>>>
>>> This dependency is currently needed to create custom Mistral actions. It
>>> was originally not the best architecture and one of the reasons to
>>> create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by
>>> moving all that’s needed for creating actions into a lib (plus something
>>> else). The thing is that the transition is not over and APIs that we put
>>> into ‘mistral-lib’ are still experimental. The plan is to complete this
>>> initiative, including docs and needed refactoring, till the end of Pike.
>>>
>>> What possible negative consequences may we have if we switch release
>>> model to "cycle-with-intermediary”?
>>
>> There are no "negative" consequences. There are just consequences in
>> choosing a new release model, so I don't want mistral to switch to that
>> model *only* because it didn't complete moving some code out of mistral
>> proper into a more consumable mistral-lib. It feels like we wouldn't be
>> having that discussion if the code was more adequately split :)
>>
>> First, the cycle-with-intermediary model means that every tag is a
>> "release", which is expected to be consumed by users. You have to be
>> pretty sure that it works -- there won't be any release candidates to
>> protect you. This means your automated testing coverage needs to be
>> pretty good.
>>
>> Second, the cycle-with-intermediary model is less "driven" by the
>> release team -- you won't have as many reminders (like milestones), or
>> best-practice deadlines (like feature freeze) to help you. Your team is
>> basically doing release management internally, deciding when to release,
>> when to slow down, etc.
>>
>> As such, this model appeals either to very young projects (which need a
>> lot of flexibility and need to put things out fast), and very mature
>> projects (where automated testing coverage is pretty complete, release
>> liaisons take up much of the release management, and things don't change
>> that often). Projects in the middle usually prefer the
>> cycle-with-milestones model.
>>
>>> Practically, all our releases, even
>>> those made after milestones, are considered stable and I don’t see
>>> issues if we’ll be producing full releases every time.
>>
>> Yes, it sounds like you could switch to that model without too much pain.
>>
>>> Btw, how does
>>> stable branch maintenance work in this case? I guess it should be the
>>> same, one stable branch per cycle. I’d appreciate if you could
>>> clarify this.
>>
>> There is no change in terms of stable releases, you still maintain only
>> one branch per cycle. The last intermediary release in a given cycle is
>> where the stable branch for the cycle is cut.
>>
>> --
>> Thierry Carrez (ttx)
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Ренат Ахмеров
We have a weekly meeting next Monday, will it be too late?

Renat Akhmerov
@Nokia

On 1 Jun 2017, 20:10 +0700, Thierry Carrez <[hidden email]>, wrote:
Note that it's technically too late to change the release model
(milestone-1 is the deadline), but since that kills two birds with one
stone, I'd be willing to grant mistral an exception (as long as it's
done before milestone-2, which is next week).

Renat Akhmerov wrote:
Thanks Thierry.

To me it sounds like even a better release model for us. We can discuss
it with a team at the next team meeting and make a decision.

Renat Akhmerov
@Nokia

On 1 Jun 2017, 17:06 +0700, Thierry Carrez <[hidden email]>, wrote:
Renat Akhmerov wrote:
On 31 May 2017, 15:08 +0700, Thierry Carrez <[hidden email]>,
wrote:
[mistral]
mistral - blocking sqlalchemy - milestones

I wonder why mistral is in requirements. Looks like tripleo-common is
depending on it ? Could someone shine some light on this ? It might just
mean mistral-lib is missing a few functions, and switching the release
model of mistral itself might be overkill ?

This dependency is currently needed to create custom Mistral actions. It
was originally not the best architecture and one of the reasons to
create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by
moving all that’s needed for creating actions into a lib (plus something
else). The thing is that the transition is not over and APIs that we put
into ‘mistral-lib’ are still experimental. The plan is to complete this
initiative, including docs and needed refactoring, till the end of Pike.

What possible negative consequences may we have if we switch release
model to "cycle-with-intermediary”?

There are no "negative" consequences. There are just consequences in
choosing a new release model, so I don't want mistral to switch to that
model *only* because it didn't complete moving some code out of mistral
proper into a more consumable mistral-lib. It feels like we wouldn't be
having that discussion if the code was more adequately split :)

First, the cycle-with-intermediary model means that every tag is a
"release", which is expected to be consumed by users. You have to be
pretty sure that it works -- there won't be any release candidates to
protect you. This means your automated testing coverage needs to be
pretty good.

Second, the cycle-with-intermediary model is less "driven" by the
release team -- you won't have as many reminders (like milestones), or
best-practice deadlines (like feature freeze) to help you. Your team is
basically doing release management internally, deciding when to release,
when to slow down, etc.

As such, this model appeals either to very young projects (which need a
lot of flexibility and need to put things out fast), and very mature
projects (where automated testing coverage is pretty complete, release
liaisons take up much of the release management, and things don't change
that often). Projects in the middle usually prefer the
cycle-with-milestones model.

Practically, all our releases, even
those made after milestones, are considered stable and I don’t see
issues if we’ll be producing full releases every time.

Yes, it sounds like you could switch to that model without too much pain.

Btw, how does
stable branch maintenance work in this case? I guess it should be the
same, one stable branch per cycle. I’d appreciate if you could
clarify this.

There is no change in terms of stable releases, you still maintain only
one branch per cycle. The last intermediary release in a given cycle is
where the stable branch for the cycle is cut.

--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Thierry Carrez
Renat Akhmerov wrote:
> We have a weekly meeting next Monday, will it be too late?

Before Thursday EOD (when the Pike-2 deadline hits) should be OK.

--
Thierry Carrez (ttx)

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Dougal Matthews
In reply to this post by Ренат Ахмеров


On 31 May 2017 at 09:35, Renat Akhmerov <[hidden email]> wrote:

On 31 May 2017, 15:08 +0700, Thierry Carrez <[hidden email]>, wrote:

This has hit us with the mistral and tripleo projects particularly
(tagged in the title). They disallow pbr-3.0.0 and in the case of
mistral sqlalchemy updates.

[mistral]
mistral - blocking sqlalchemy - milestones

I wonder why mistral is in requirements. Looks like tripleo-common is
depending on it ? Could someone shine some light on this ? It might just
mean mistral-lib is missing a few functions, and switching the release
model of mistral itself might be overkill ?

This dependency is currently needed to create custom Mistral actions. It was originally not the best architecture and one of the reasons to create 'mistral-lib' was in getting rid of dependency on ‘mistral’ by moving all that’s needed for creating actions into a lib (plus something else). The thing is that the transition is not over and APIs that we put into ‘mistral-lib’ are still experimental. The plan is to complete this initiative, including docs and needed refactoring, till the end of Pike.

What possible negative consequences may we have if we switch release model to "cycle-with-intermediary”?

I don't fully understand this, but I have one concern that I'll try and explain.

Mistral master is developed against master of other OpenStack projects (Keystone for auth, and all projects for OpenStack actions). If we were to release 5.0 today, it would mean that Mistral has a release that is tested against unreleased Pike but would need to work with Ocata stable releases (and AFAIK we do not tested Mistral master with Ocata Keystone etc.)

We are very close to breaking the link between tripleo-common and mistral - I would favour that approach and would prefer a nasty hack to rush that along rather than changing Mistrals release cycle. I expect to remove mistral from requirements.txt after the transition anyway.

What needs to happen to remove the dep?
- RDO promotion to get a new mistral-lib release
- After promotion this should start passing https://review.openstack.org/#/c/454719/
- Port this functionality to tripleo-common https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py (we were planning on moving this to mistral-extra, but it could go into tripleo-common as a short term solution)

 

Renat Akhmerov
@Nokia

__________________________________________________________________________
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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Matthew Thode
On 06/06/2017 03:21 AM, Dougal Matthews wrote:

>
>
> On 31 May 2017 at 09:35, Renat Akhmerov <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     On 31 May 2017, 15:08 +0700, Thierry Carrez <[hidden email]
>     <mailto:[hidden email]>>, wrote:
>>
>>>     This has hit us with the mistral and tripleo projects particularly
>>>     (tagged in the title). They disallow pbr-3.0.0 and in the case of
>>>     mistral sqlalchemy updates.
>>>
>>>     [mistral]
>>>     mistral - blocking sqlalchemy - milestones
>>
>>     I wonder why mistral is in requirements. Looks like tripleo-common is
>>     depending on it ? Could someone shine some light on this ? It
>>     might just
>>     mean mistral-lib is missing a few functions, and switching the release
>>     model of mistral itself might be overkill ?
>
>     This dependency is currently needed to create custom Mistral
>     actions. It was originally not the best architecture and one of the
>     reasons to create 'mistral-lib' was in getting rid of dependency on
>     ‘mistral’ by moving all that’s needed for creating actions into a
>     lib (plus something else). The thing is that the transition is not
>     over and APIs that we put into ‘mistral-lib’ are still experimental.
>     The plan is to complete this initiative, including docs and needed
>     refactoring, till the end of Pike.
>
>     What possible negative consequences may we have if we switch release
>     model to "cycle-with-intermediary”?
>
>
> I don't fully understand this, but I have one concern that I'll try and
> explain.
>
> Mistral master is developed against master of other OpenStack projects
> (Keystone for auth, and all projects for OpenStack actions). If we were
> to release 5.0 today, it would mean that Mistral has a release that is
> tested against unreleased Pike but would need to work with Ocata stable
> releases (and AFAIK we do not tested Mistral master with Ocata Keystone
> etc.)
>
This is true and what makes this hard, but the other
cycle-with-intermediary projects do the same thing (make releases when
using other projects master based releases).  So as long as your testing
is good I don't see a problem.

> We are very close to breaking the link between tripleo-common and
> mistral - I would favour that approach and would prefer a nasty hack to
> rush that along rather than changing Mistrals release cycle. I expect to
> remove mistral from requirements.txt after the transition anyway.
>

This would be best, but how long will this take?  How long will mistral
be holding back sqlalchemy updates?

> What needs to happen to remove the dep?
> - RDO promotion to get a new mistral-lib release
> - After promotion this should start passing
> https://review.openstack.org/#/c/454719/
> - Port this functionality to tripleo-common
> https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py
> (we were planning on moving this to mistral-extra, but it could go into
> tripleo-common as a short term solution)
>

Thanks for the update.

>  
>
>
>     Renat Akhmerov
>     @Nokia
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     [hidden email]?subject:unsubscribe
>     <http://OpenStack-dev-request@...?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

--
Matthew Thode (prometheanfire)


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Alex Schultz-2
In reply to this post by Emilien Macchi-4
On Tue, May 30, 2017 at 3:08 PM, Emilien Macchi <[hidden email]> wrote:

> On Tue, May 30, 2017 at 8:36 PM, Matthew Thode
> <[hidden email]> wrote:
>> We have a problem in requirements that projects that don't have the
>> cycle-with-intermediary release model (most of the cycle-with-milestones
>> model) don't get integrated with requirements until the cycle is fully
>> done.  This causes a few problems.
>>
>> * These projects don't produce a consumable release for requirements
>> until end of cycle (which does not accept beta releases).
>>
>> * The former causes old requirements to be kept in place, meaning caps,
>> exclusions, etc. are being kept, which can cause conflicts.
>>
>> * Keeping the old version in requirements means that cross dependencies
>> are not tested with updated versions.
>>
>> This has hit us with the mistral and tripleo projects particularly
>> (tagged in the title).  They disallow pbr-3.0.0 and in the case of
>> mistral sqlalchemy updates.
>>
>> [mistral]
>> mistral - blocking sqlalchemy - milestones
>>
>> [tripleo]
>> os-refresh-config - blocking pbr - milestones
>> os-apply-config - blocking pbr - milestones
>> os-collect-config - blocking pbr - milestones
>
> These are cycle-with-milestones., like os-net-config for example,
> which wasn't mentioned in this email. It has the same releases as
> os-net-config also, so I'm confused why these 3 cause issue, I
> probably missed something.
>
> Anyway, I'm happy to change os-*-config (from TripleO) to be
> cycle-with-intermediary. Quick question though, which tag would you
> like to see, regarding what we already did for pike-1?
>

I ran into a case where I wanted to add python-tripleoclient to
test-requirements for tripleo-heat-templates but it's not in the
global requirements. In looking into adding this, I noticed that
python-tripleoclient and tripleo-common are not
cycle-with-intermediary either. Should/can we update these as well?
tripleo-common is already in the global requirements but I guess since
we've been releasing non-prerelease versions fairly regularly with the
milestones it hasn't been a problem.

Thanks,
-Alex

> Thanks,
>
>> [nova]
>> os-vif - blocking pbr - intermediary
>>
>> [horizon]
>> django-openstack-auth - blocking django - intermediary
>>
>>
>> So, here's what needs doing.
>>
>> Those projects that are already using the cycle-with-intermediary model
>> should just do a release.
>>
>> For those that are using cycle-with-milestones, you will need to change
>> to the cycle-with-intermediary model, and do a full release, both can be
>> done at the same time.
>>
>> If anyone has any questions or wants clarifications this thread is good,
>> or I'm on irc as prometheanfire in the #openstack-requirements channel.
>>
>> --
>> Matthew Thode (prometheanfire)
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Emilien Macchi
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

Doug Hellmann-2
Excerpts from Alex Schultz's message of 2017-06-09 10:54:16 -0600:
> I ran into a case where I wanted to add python-tripleoclient to
> test-requirements for tripleo-heat-templates but it's not in the
> global requirements. In looking into adding this, I noticed that
> python-tripleoclient and tripleo-common are not
> cycle-with-intermediary either. Should/can we update these as well?
> tripleo-common is already in the global requirements but I guess since
> we've been releasing non-prerelease versions fairly regularly with the
> milestones it hasn't been a problem.

Yes, let's get all of the tripleo team's libraries onto the
cycle-with-intermediary release model.

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
12
Loading...