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

2017-06-28 Thread Renat Akhmerov 
Cool, thanks Dougal!

Renat Akhmerov
@Nokia

On 28 Jun 2017, 15:21 +0700, Dougal Matthews , wrote:
> > On 23 June 2017 at 12:52, Thierry Carrez  wrote:
> > > Dougal Matthews wrote:
> > > >>     We have been trying to break the requirement on mistral (from
> > > >>     tripleo-common) but it is proving to be harder than expected. We 
> > > >>are
> > > >>     really doing some nasty things, but I wont go into details here :-)
> > > >>     If anyone is interested, feel free to reach out.
> > > >
> > > > After sending that we did make some solid progress. We are two patches
> > > > away from breaking the link AFAICT.
> > > >
> > > > 1. https://review.openstack.org/#/c/454719/
> > > > 2. https://review.openstack.org/#/c/476866/
> > > >
> > > > Both have some errors that need to be resolved but it is looking much
> > > > closer now.
> > >
> > > That's definitely the best way to handle the situation, so if you are
> > > confident that we can complete the transition to depending on
> > > mistral-lib before the non-client lib freeze (~ July 20), we should try
> > > that.
> >
> > Almost there. All the changes we need have landed in tripleo-common. 
> > Mistral is no longer imported (only mistral-lib is).
> >
> > I have proposed a tripleo-common release [1] and a patch to remove Mistral 
> > from the global requirements [2].
> >
> >
> > [1]: https://review.openstack.org/#/c/478426/
> > [2]: https://review.openstack.org/#/c/477450/
> >
> >
> > >
> > > --
> > > 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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-28 Thread Dougal Matthews 
On 23 June 2017 at 12:52, Thierry Carrez  wrote:

> Dougal Matthews wrote:
> >> We have been trying to break the requirement on mistral (from
> >> tripleo-common) but it is proving to be harder than expected. We are
> >> really doing some nasty things, but I wont go into details here :-)
> >> If anyone is interested, feel free to reach out.
> >
> > After sending that we did make some solid progress. We are two patches
> > away from breaking the link AFAICT.
> >
> > 1. https://review.openstack.org/#/c/454719/
> > 2. https://review.openstack.org/#/c/476866/
> >
> > Both have some errors that need to be resolved but it is looking much
> > closer now.
>
> That's definitely the best way to handle the situation, so if you are
> confident that we can complete the transition to depending on
> mistral-lib before the non-client lib freeze (~ July 20), we should try
> that.
>

Almost there. All the changes we need have landed in tripleo-common.
Mistral is no longer imported (only mistral-lib is).

I have proposed a tripleo-common release [1] and a patch to remove Mistral
from the global requirements [2].


[1]: https://review.openstack.org/#/c/478426/
[2]: https://review.openstack.org/#/c/477450/



>
> --
> 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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-23 Thread Renat Akhmerov 
We'll do that.

Thanks

Renat Akhmerov
@Nokia

23 июня 2017 г., 18:54 +0700, Thierry Carrez , писал:
> Dougal Matthews wrote:
> > > We have been trying to break the requirement on mistral (from
> > > tripleo-common) but it is proving to be harder than expected. We are
> > > really doing some nasty things, but I wont go into details here :-)
> > > If anyone is interested, feel free to reach out.
> >
> > After sending that we did make some solid progress. We are two patches
> > away from breaking the link AFAICT.
> >
> > 1. https://review.openstack.org/#/c/454719/
> > 2. https://review.openstack.org/#/c/476866/
> >
> > Both have some errors that need to be resolved but it is looking much
> > closer now.
>
> That's definitely the best way to handle the situation, so if you are
> confident that we can complete the transition to depending on
> mistral-lib before the non-client lib freeze (~ July 20), we should try
> that.
>
> --
> 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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-23 Thread Thierry Carrez 
Dougal Matthews wrote:
>> We have been trying to break the requirement on mistral (from
>> tripleo-common) but it is proving to be harder than expected. We are
>> really doing some nasty things, but I wont go into details here :-)
>> If anyone is interested, feel free to reach out.
> 
> After sending that we did make some solid progress. We are two patches
> away from breaking the link AFAICT.
> 
> 1. https://review.openstack.org/#/c/454719/
> 2. https://review.openstack.org/#/c/476866/
> 
> Both have some errors that need to be resolved but it is looking much
> closer now.

That's definitely the best way to handle the situation, so if you are
confident that we can complete the transition to depending on
mistral-lib before the non-client lib freeze (~ July 20), we should try
that.

-- 
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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-23 Thread Dougal Matthews 
On 22 June 2017 at 14:01, Dougal Matthews  wrote:

>
>
> On 22 June 2017 at 11:01, Thierry Carrez  wrote:
>
>> Thierry Carrez wrote:
>> > 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.
>>
>> If there was a decision, I missed it (and in the mean time Mistral
>> published 5.0.0.0b2 for the Pike-2 milestone).
>>
>> Given the situation, I'm fine with giving an exception to Mistral to
>> switch now to cycle-with-intermediary and release 5.0.0 if you think
>> master is currently releasable...
>>
>> Let me know what you think.
>>
>
>
> I think that probably is the best option.
>
> We have been trying to break the requirement on mistral (from
> tripleo-common) but it is proving to be harder than expected. We are really
> doing some nasty things, but I wont go into details here :-) If anyone is
> interested, feel free to reach out.
>

After sending that we did make some solid progress. We are two patches away
from breaking the link AFAICT.

1. https://review.openstack.org/#/c/454719/
2. https://review.openstack.org/#/c/476866/

Both have some errors that need to be resolved but it is looking much
closer now.


>
>
>
>>
>> --
>> Thierry Carrez (ttx)
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-22 Thread Dougal Matthews 
On 22 June 2017 at 11:01, Thierry Carrez  wrote:

> Thierry Carrez wrote:
> > 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.
>
> If there was a decision, I missed it (and in the mean time Mistral
> published 5.0.0.0b2 for the Pike-2 milestone).
>
> Given the situation, I'm fine with giving an exception to Mistral to
> switch now to cycle-with-intermediary and release 5.0.0 if you think
> master is currently releasable...
>
> Let me know what you think.
>


I think that probably is the best option.

We have been trying to break the requirement on mistral (from
tripleo-common) but it is proving to be harder than expected. We are really
doing some nasty things, but I wont go into details here :-) If anyone is
interested, feel free to reach out.



>
> --
> 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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-22 Thread Thierry Carrez 
Thierry Carrez wrote:
> 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.

If there was a decision, I missed it (and in the mean time Mistral
published 5.0.0.0b2 for the Pike-2 milestone).

Given the situation, I'm fine with giving an exception to Mistral to
switch now to cycle-with-intermediary and release 5.0.0 if you think
master is currently releasable...

Let me know what you think.

-- 
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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-13 Thread Emilien Macchi 
On Fri, Jun 9, 2017 at 1:38 PM, Doug Hellmann  wrote:
> 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.

Done: https://review.openstack.org/473974

Please review and let me know if I missed something.

> 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



-- 
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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

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

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

2017-06-09 Thread Alex Schultz 
On Tue, May 30, 2017 at 3:08 PM, Emilien Macchi  wrote:
> On Tue, May 30, 2017 at 8:36 PM, 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.
>>
>> * 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-06 Thread Matthew Thode 
On 06/06/2017 03:21 AM, Dougal Matthews wrote:
> 
> 
> On 31 May 2017 at 09:35, Renat Akhmerov  > wrote:
> 
> 
> On 31 May 2017, 15:08 +0700, Thierry Carrez  >, 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:
> 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
> 


-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-06 Thread Dougal Matthews 
On 31 May 2017 at 09:35, Renat Akhmerov  wrote:

>
> On 31 May 2017, 15:08 +0700, Thierry Carrez ,
> 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-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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

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

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

2017-06-01 Thread Renat Akhmerov 
We have a weekly meeting next Monday, will it be too late?

Renat Akhmerov
@Nokia

On 1 Jun 2017, 20:10 +0700, Thierry Carrez , 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 , wrote:
> > > Renat Akhmerov wrote:
> > > > On 31 May 2017, 15:08 +0700, Thierry Carrez ,
> > > > 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: 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
> >
>
>
> --
> 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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-01 Thread 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 , wrote:
>> Renat Akhmerov wrote:
>>> On 31 May 2017, 15:08 +0700, Thierry Carrez ,
>>> 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: 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
> 


-- 
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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-01 Thread Renat Akhmerov 
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 , wrote:
> Renat Akhmerov wrote:
> > On 31 May 2017, 15:08 +0700, Thierry Carrez , 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: 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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-06-01 Thread Thierry Carrez 
Renat Akhmerov wrote:
> On 31 May 2017, 15:08 +0700, Thierry Carrez , 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-05-31 Thread Emilien Macchi 
On Tue, May 30, 2017 at 11:11 PM, Matthew Thode
 wrote:
> On 05/30/2017 04:08 PM, Emilien Macchi wrote:
>> On Tue, May 30, 2017 at 8:36 PM, 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.
>>>
>>> * 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: openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-05-31 Thread Rob Cresswell (rcresswe) 

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

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

2017-05-31 Thread Renat Akhmerov 

On 31 May 2017, 15:08 +0700, Thierry Carrez , 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-05-31 Thread Thierry Carrez 
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)



signature.asc
Description: OpenPGP digital signature
__
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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

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

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

2017-05-30 Thread Matthew Thode 
On 05/30/2017 04:08 PM, Emilien Macchi wrote:
> On Tue, May 30, 2017 at 8:36 PM, 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.
>>
>> * 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 


-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

2017-05-30 Thread Emilien Macchi 
On Tue, May 30, 2017 at 8:36 PM, 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.
>
> * 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Good idea, added in https://review.openstack.org/469234

-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

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

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

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