Re: [openstack-dev] [requirements][ptls] HELP! Thawing the requirements repo

2017-08-11 Thread Tony Breeds 
Hi All,
The requirements repo is now branched.  If your project does NOT
have a stable/pike branch please review any bot generated changes *very*
carefully until you do have a stable/pike branch.

If you're not sure ask in #openstack-requirements for a team member to
do a quick review.

Yours Tony.


signature.asc
Description: PGP 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][ptls] HELP! Thawing the requirements repo

2017-08-07 Thread Armando M. 
On 6 August 2017 at 23:33, Akihiro Motoki  wrote:

> 2017-08-07 11:59 GMT+09:00 Tony Breeds :
> > Hi All,
> > So as you all know we've frozen the requirements repo and it will
> > stay frozen until after all the cycle-with-milestones projects have
> > stable/pike branches.  That's pretty normal.
> >
> > The last couple of cycles we've seen issues with projects that crate
> > stable/pike branches *after* we've thawed/re-opened requirements repo
> > for $next_release.
> >
> > What happens is those projects are still stabilising for pike but
> > getting requirements updates for queens.  When they *do* branch for pike
> > they quickly get a proposal-bot change which seems to take things
> > backwards.  This bad for (at least) a couple of reasons.
> >
> > 1. Those projects are testing against the wrong requirements
> > 2. You end up with a patch release for $project that radically changes
> > the requirements for $project.
>
> Yeah, totally agree the above.
>
> >
> > So I need some help identifying which projects are going to fall into
> > this scenario.  The easy to identify ones are cycle-trailing and we can
> > easily cope with that by as there are only 4 of them.  My instinct tells
> > me that many of the neutron (stadium?) and horizon-plugin projects will
> > fall into this boat.
>
> I think neutron stadium and horizon plugin projects with
> cycle-with-intermediary are potentially affected.
> They tends to ship a final release (and cut a stable branch if necessary).
>
> I think we can easily list such projects for official projects.
> It is not easy to do it for hosted projects as we don't know their
> release models.
> Do we want to take care of hosted projects?
>
>
> The following is about official projects.
>
> According to the release repo, there is no *official* neutron stadium
> projects with cycle-with-intermediary release model.
> networking-hyperv (of the winstackers project) adopts
> cycle-with-intermediary model and it looks affected.
>
> Grepping the release deliverables, *official* horizon plugin projects
> with cycle-with-intermediary models are:
>
> $ grep release-model `grep -l horizon-plugin deliverables/pike/*.yaml`
> | grep -v cycle-with-milestones | cut -d : -f 1
> deliverables/pike/cloudkitty-dashboard.yaml
> deliverables/pike/ironic-ui.yaml
> deliverables/pike/karbor-dashboard.yaml
> deliverables/pike/magnum-ui.yaml
> deliverables/pike/manila-ui.yaml
> deliverables/pike/monasca-ui.yaml
> deliverables/pike/senlin-dashboard.yaml
> deliverables/pike/solum-dashboard.yaml
> deliverables/pike/tacker-horizon.yaml
> deliverables/pike/vitrage-dashboard.yaml
> deliverables/pike/watcher-dashboard.yaml
> deliverables/pike/zun-ui.yaml
>
>
> In addition, regarding neutron stadium projects and horizon plugin
> projects,
> they also need to update the branch (from master to stable/pike) of
> neutron or horizon repo
> as they installs neutron or horizon using tox_install.sh
> (in addition to the branch of requirements repo).
> This needs to happen just after stable/pike branch of neutron or
> horizon is created.
>

The switch to cycle-with-milestone [1] for all projects under neutron
governance (except neutron-lib and ovsdbapp that are libraries) was done
with the explicit intent of avoiding the overdue cut of stable branches for
the current release, which may lead to the exact problem that Tony stated
here.

[1] https://review.openstack.org/#/c/437699/


>
> Thanks,
> Akihiro
>
> > Once we know the scope of the affected projects we can work out how to
> > thaw the requirements repo with minimum impact.  The alternative is to
> > have the requirements repo frozen for > 1 month which no one wants.
> >
> > Yours Tony.
> >
> > 
> __
> > 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][ptls] HELP! Thawing the requirements repo

2017-08-07 Thread Akihiro Motoki 
2017-08-07 11:59 GMT+09:00 Tony Breeds :
> Hi All,
> So as you all know we've frozen the requirements repo and it will
> stay frozen until after all the cycle-with-milestones projects have
> stable/pike branches.  That's pretty normal.
>
> The last couple of cycles we've seen issues with projects that crate
> stable/pike branches *after* we've thawed/re-opened requirements repo
> for $next_release.
>
> What happens is those projects are still stabilising for pike but
> getting requirements updates for queens.  When they *do* branch for pike
> they quickly get a proposal-bot change which seems to take things
> backwards.  This bad for (at least) a couple of reasons.
>
> 1. Those projects are testing against the wrong requirements
> 2. You end up with a patch release for $project that radically changes
> the requirements for $project.

Yeah, totally agree the above.

>
> So I need some help identifying which projects are going to fall into
> this scenario.  The easy to identify ones are cycle-trailing and we can
> easily cope with that by as there are only 4 of them.  My instinct tells
> me that many of the neutron (stadium?) and horizon-plugin projects will
> fall into this boat.

I think neutron stadium and horizon plugin projects with
cycle-with-intermediary are potentially affected.
They tends to ship a final release (and cut a stable branch if necessary).

I think we can easily list such projects for official projects.
It is not easy to do it for hosted projects as we don't know their
release models.
Do we want to take care of hosted projects?


The following is about official projects.

According to the release repo, there is no *official* neutron stadium
projects with cycle-with-intermediary release model.
networking-hyperv (of the winstackers project) adopts
cycle-with-intermediary model and it looks affected.

Grepping the release deliverables, *official* horizon plugin projects
with cycle-with-intermediary models are:

$ grep release-model `grep -l horizon-plugin deliverables/pike/*.yaml`
| grep -v cycle-with-milestones | cut -d : -f 1
deliverables/pike/cloudkitty-dashboard.yaml
deliverables/pike/ironic-ui.yaml
deliverables/pike/karbor-dashboard.yaml
deliverables/pike/magnum-ui.yaml
deliverables/pike/manila-ui.yaml
deliverables/pike/monasca-ui.yaml
deliverables/pike/senlin-dashboard.yaml
deliverables/pike/solum-dashboard.yaml
deliverables/pike/tacker-horizon.yaml
deliverables/pike/vitrage-dashboard.yaml
deliverables/pike/watcher-dashboard.yaml
deliverables/pike/zun-ui.yaml


In addition, regarding neutron stadium projects and horizon plugin projects,
they also need to update the branch (from master to stable/pike) of
neutron or horizon repo
as they installs neutron or horizon using tox_install.sh
(in addition to the branch of requirements repo).
This needs to happen just after stable/pike branch of neutron or
horizon is created.

Thanks,
Akihiro

> Once we know the scope of the affected projects we can work out how to
> thaw the requirements repo with minimum impact.  The alternative is to
> have the requirements repo frozen for > 1 month which no one wants.
>
> Yours Tony.
>
> __
> 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-dev] [requirements][ptls] HELP! Thawing the requirements repo

2017-08-06 Thread Tony Breeds 
Hi All,
So as you all know we've frozen the requirements repo and it will
stay frozen until after all the cycle-with-milestones projects have
stable/pike branches.  That's pretty normal.

The last couple of cycles we've seen issues with projects that crate
stable/pike branches *after* we've thawed/re-opened requirements repo
for $next_release.

What happens is those projects are still stabilising for pike but
getting requirements updates for queens.  When they *do* branch for pike
they quickly get a proposal-bot change which seems to take things
backwards.  This bad for (at least) a couple of reasons.

1. Those projects are testing against the wrong requirements
2. You end up with a patch release for $project that radically changes
the requirements for $project.

So I need some help identifying which projects are going to fall into
this scenario.  The easy to identify ones are cycle-trailing and we can
easily cope with that by as there are only 4 of them.  My instinct tells
me that many of the neutron (stadium?) and horizon-plugin projects will
fall into this boat.

Once we know the scope of the affected projects we can work out how to
thaw the requirements repo with minimum impact.  The alternative is to
have the requirements repo frozen for > 1 month which no one wants.

Yours Tony.


signature.asc
Description: PGP 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