[requirements][ptls] HELP! Thawing the requirements repo

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

[requirements][ptls] HELP! Thawing the requirements repo

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.

__________________________________________________________________________
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][ptls] HELP! Thawing the requirements repo

Akihiro MOTOKI-2
2017-08-07 11:59 GMT+09:00 Tony Breeds <[hidden email]>:

> 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: [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][ptls] HELP! Thawing the requirements repo

Armando M.


On 6 August 2017 at 23:33, Akihiro Motoki <[hidden email]> wrote:
2017-08-07 11:59 GMT+09:00 Tony Breeds <[hidden email]>:
> 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. 

 

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

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


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [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][OpenStackAnsible][kolla][tripleo] Upcoming requirements thaw.

Tony Breeds
In reply to this post by Tony Breeds
Hello!
    The requirements team is expecting the re-open the master branch
shortly after we create a stable/pike branch.  This means that
cycle-training projects may (will?) start seeing bot generated
requirements syncs intended for queens.  I tried to come up with an
automated way to block this and failed.  This measn it's going to fall
on your teams to block all requirements updates you branch your repo's for pike.

If you think a change is destined for pike feel free to reach out for
clarification.

Alos if you can think of a better way to handle this in 6 months we're
all ears :)

For the sake of completeness here's a list of repos[1] I expect you'll need
to keep an eye on.

openstack-ansible                                  OpenStackAnsible    
openstack-ansible-apt_package_pinning              OpenStackAnsible    
openstack-ansible-ceph_client                      OpenStackAnsible    
openstack-ansible-galera_client                    OpenStackAnsible    
openstack-ansible-galera_server                    OpenStackAnsible    
openstack-ansible-haproxy_server                   OpenStackAnsible    
openstack-ansible-lxc_container_create             OpenStackAnsible    
openstack-ansible-lxc_hosts                        OpenStackAnsible    
openstack-ansible-memcached_server                 OpenStackAnsible    
openstack-ansible-openstack_hosts                  OpenStackAnsible    
openstack-ansible-openstack_openrc                 OpenStackAnsible    
openstack-ansible-ops                              OpenStackAnsible    
openstack-ansible-os_almanach                      OpenStackAnsible    
openstack-ansible-os_aodh                          OpenStackAnsible    
openstack-ansible-os_barbican                      OpenStackAnsible    
openstack-ansible-os_ceilometer                    OpenStackAnsible    
openstack-ansible-os_cinder                        OpenStackAnsible    
openstack-ansible-os_cloudkitty                    OpenStackAnsible    
openstack-ansible-os_designate                     OpenStackAnsible    
openstack-ansible-os_freezer                       OpenStackAnsible    
openstack-ansible-os_glance                        OpenStackAnsible    
openstack-ansible-os_gnocchi                       OpenStackAnsible    
openstack-ansible-os_heat                          OpenStackAnsible    
openstack-ansible-os_horizon                       OpenStackAnsible    
openstack-ansible-os_ironic                        OpenStackAnsible    
openstack-ansible-os_keystone                      OpenStackAnsible    
openstack-ansible-os_magnum                        OpenStackAnsible    
openstack-ansible-os_molteniron                    OpenStackAnsible    
openstack-ansible-os_monasca                       OpenStackAnsible    
openstack-ansible-os_monasca-agent                 OpenStackAnsible    
openstack-ansible-os_monasca-ui                    OpenStackAnsible    
openstack-ansible-os_neutron                       OpenStackAnsible    
openstack-ansible-os_nova                          OpenStackAnsible    
openstack-ansible-os_octavia                       OpenStackAnsible    
openstack-ansible-os_rally                         OpenStackAnsible    
openstack-ansible-os_sahara                        OpenStackAnsible    
openstack-ansible-os_searchlight                   OpenStackAnsible    
openstack-ansible-os_swift                         OpenStackAnsible    
openstack-ansible-os_tempest                       OpenStackAnsible    
openstack-ansible-os_trove                         OpenStackAnsible    
openstack-ansible-os_watcher                       OpenStackAnsible    
openstack-ansible-os_zaqar                         OpenStackAnsible    
openstack-ansible-pip_install                      OpenStackAnsible    
openstack-ansible-plugins                          OpenStackAnsible    
openstack-ansible-rabbitmq_server                  OpenStackAnsible    
openstack-ansible-repo_build                       OpenStackAnsible    
openstack-ansible-repo_server                      OpenStackAnsible    
openstack-ansible-rsyslog_client                   OpenStackAnsible    
openstack-ansible-rsyslog_server                   OpenStackAnsible    
openstack-ansible-specs                            OpenStackAnsible    
openstack-ansible-tests                            OpenStackAnsible    
kolla                                              kolla              
kolla-ansible                                      kolla              
kolla-kubernetes                                   kolla              
diskimage-builder                                  tripleo            
instack-undercloud                                 tripleo            
os-apply-config                                    tripleo            
os-collect-config                                  tripleo            
os-refresh-config                                  tripleo            
tripleo-common                                     tripleo            
tripleo-heat-templates                             tripleo            
tripleo-validations                                tripleo      

Yours Tony.

[1] It could be all .. I didn't check that ;P

__________________________________________________________________________
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Tony Breeds
In reply to this post by Tony Breeds

Hi All,
    In an effort to qualify which projects are likley to be affected if
when we open the requirements repo I generated a list of all repos that:

1. Subscribe to requirements management
2. Do not already have a stable/pike branch
3. Do not follow the cycle-with-milestones, cycle-trailing or
   independent release models
4. Are not a 'branchless' project (tempest or tempest-plugin)

These repos I believe *should* have a stable/pike branch or will see
problems when we open openstack/requirements.  Those issues were
described in [1]

It turns out close to 1/3rd of projects that subscribe to requirements
management are not ready for us to re-open for master.  So we need you
help to get that number down to a much more acceptable number.

The good news is it's pretty easy to fix this with the cool tools and
workflow in the releases repo[2].  I suspect that the 'service' will
take care of themselves, and the horizon-plugins are waiting to horizon
to cut RC1.

Repos with type: horizon-plugin
ironic-ui                                          ironic              
manila-ui                                          manila              
monasca-ui                                         monasca            
neutron-fwaas-dashboard                            neutron            
solum-dashboard                                    solum              
tacker-horizon                                     tacker              
watcher-dashboard                                  watcher            
zun-ui                                             zun                

Repos with type: other
python-openstackclient                             OpenStackClient    
patrole                                            Quality Assurance  
heat-agents                                        heat                
ironic-inspector                                   ironic              
ironic-python-agent                                ironic              
kuryr-kubernetes                                   kuryr              
monasca-common                                     monasca            
monasca-notification                               monasca            
monasca-persister                                  monasca            
monasca-transform                                  monasca            

Repos with type: service
ironic                                             ironic              
monasca-api                                        monasca            
monasca-log-api                                    monasca            
swift                                              swift              
tricircle                                          tricircle          
vitrage                                            vitrage            
watcher                                            watcher            
zun                                                zun

Those are the easy items.

The following repos don't seem to use the openstack/releases repo so I
have less information there.

i18n                                               I18n                
almanach                                                              
blazar                                                                
blazar-nova                                                            
compute-hyperv                                                        
ekko                                                                  
gce-api                                                                
glare                                                                  
ironic-staging-drivers                                                
kosmos                                                                
masakari                                                              
masakari-monitors                                                      
mixmatch                                                              
mogan                                                                  
nemesis                                                                
networking-dpm                                                        
networking-fujitsu                                                    
networking-generic-switch                                              
networking-l2gw                                                        
networking-powervm                                                    
neutron-vpnaas                                                        
neutron-vpnaas-dashboard                                              
nova-dpm                                                              
nova-lxd                                                              
nova-powervm                                                          
os-xenapi                                                              
python-blazarclient                                                    
python-cratonclient                                                    
python-glareclient                                                    
python-kingbirdclient                                                  
python-masakariclient                                                  
python-moganclient                                                    
python-oneviewclient                                                  
python-openstacksdk                                                    
python-valenceclient                                                  
swauth                                                                
tap-as-a-service                                                      
trio2o                                                                
valence                                                                
vmware-nsx                                                            
vmware-nsxlib                                                          
openstackclient                                    OpenStackClient    
anchor                                             Security            
ceilometer-powervm                                 Telemetry          
ec2-api                                            ec2-api            
horizon-cisco-ui                                   horizon            
bifrost                                            ironic              
ironic-python-agent-builder                        ironic              
magnum                                             magnum              
magnum-ui                                          magnum              
manila-image-elements                              manila              
murano-agent                                       murano              
octavia-dashboard                                  octavia            
senlin-dashboard                                   senlin              
tacker                                             tacker              
networking-hyperv                                  winstackers  

It'd be great to get some of these repos represented in
openstack/releases.  Having a confirmed release-model would go a long
way to clearing up the list. An alternate approach would be to remove
redundant items from projects.txt

Yours Tony.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120720.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120816.html

__________________________________________________________________________
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

witold.bedyk@est.fujitsu.com
Hi Tony,

stable/pike branches for Monasca repos are on the way

https://review.openstack.org/492101

Cheers
Witek



> -----Original Message-----
> From: Tony Breeds [mailto:[hidden email]]
> Sent: Donnerstag, 10. August 2017 07:47
> To: OpenStack Development Mailing List <openstack-
> [hidden email]>
> Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality
> Assurance][Security][Telemetry][ec2-
> api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neu
> tron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst
> ...
>
>
> Hi All,
>     In an effort to qualify which projects are likley to be affected if when we
> open the requirements repo I generated a list of all repos that:
>
> 1. Subscribe to requirements management
> 2. Do not already have a stable/pike branch 3. Do not follow the cycle-with-
> milestones, cycle-trailing or
>    independent release models
> 4. Are not a 'branchless' project (tempest or tempest-plugin)
>
> These repos I believe *should* have a stable/pike branch or will see
> problems when we open openstack/requirements.  Those issues were
> described in [1]
>
> It turns out close to 1/3rd of projects that subscribe to requirements
> management are not ready for us to re-open for master.  So we need you
> help to get that number down to a much more acceptable number.
>
> The good news is it's pretty easy to fix this with the cool tools and workflow
> in the releases repo[2].  I suspect that the 'service' will take care of
> themselves, and the horizon-plugins are waiting to horizon to cut RC1.
>
> Repos with type: horizon-plugin
> ironic-ui                                          ironic
> manila-ui                                          manila
> monasca-ui                                         monasca
> neutron-fwaas-dashboard                            neutron
> solum-dashboard                                    solum
> tacker-horizon                                     tacker
> watcher-dashboard                                  watcher
> zun-ui                                             zun
>
> Repos with type: other
> python-openstackclient                             OpenStackClient
> patrole                                            Quality Assurance
> heat-agents                                        heat
> ironic-inspector                                   ironic
> ironic-python-agent                                ironic
> kuryr-kubernetes                                   kuryr
> monasca-common                                     monasca
> monasca-notification                               monasca
> monasca-persister                                  monasca
> monasca-transform                                  monasca
>
> Repos with type: service
> ironic                                             ironic
> monasca-api                                        monasca
> monasca-log-api                                    monasca
> swift                                              swift
> tricircle                                          tricircle
> vitrage                                            vitrage
> watcher                                            watcher
> zun                                                zun
>
> Those are the easy items.
>
> The following repos don't seem to use the openstack/releases repo so I have
> less information there.
>
> i18n                                               I18n
> almanach
> blazar
> blazar-nova
> compute-hyperv
> ekko
> gce-api
> glare
> ironic-staging-drivers
> kosmos
> masakari
> masakari-monitors
> mixmatch
> mogan
> nemesis
> networking-dpm
> networking-fujitsu
> networking-generic-switch
> networking-l2gw
> networking-powervm
> neutron-vpnaas
> neutron-vpnaas-dashboard
> nova-dpm
> nova-lxd
> nova-powervm
> os-xenapi
> python-blazarclient
> python-cratonclient
> python-glareclient
> python-kingbirdclient
> python-masakariclient
> python-moganclient
> python-oneviewclient
> python-openstacksdk
> python-valenceclient
> swauth
> tap-as-a-service
> trio2o
> valence
> vmware-nsx
> vmware-nsxlib
> openstackclient                                    OpenStackClient
> anchor                                             Security
> ceilometer-powervm                                 Telemetry
> ec2-api                                            ec2-api
> horizon-cisco-ui                                   horizon
> bifrost                                            ironic
> ironic-python-agent-builder                        ironic
> magnum                                             magnum
> magnum-ui                                          magnum
> manila-image-elements                              manila
> murano-agent                                       murano
> octavia-dashboard                                  octavia
> senlin-dashboard                                   senlin
> tacker                                             tacker
> networking-hyperv                                  winstackers
>
> It'd be great to get some of these repos represented in openstack/releases.
> Having a confirmed release-model would go a long way to clearing up the list.
> An alternate approach would be to remove redundant items from
> projects.txt
>
> Yours Tony.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> August/120720.html
> [2] http://lists.openstack.org/pipermail/openstack-dev/2017-
> August/120816.html
__________________________________________________________________________
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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

joehuang
In reply to this post by Tony Breeds
Hello,

Tricircle plans to cut stable/pike branch on August 22nd, it has dependency on Neutron stable/pike creation.

Best Regards
Chaoyi Huang (joehuang)

________________________________________
From: Tony Breeds [[hidden email]]
Sent: 10 August 2017 13:46
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

Hi All,
    In an effort to qualify which projects are likley to be affected if
when we open the requirements repo I generated a list of all repos that:

1. Subscribe to requirements management
2. Do not already have a stable/pike branch
3. Do not follow the cycle-with-milestones, cycle-trailing or
   independent release models
4. Are not a 'branchless' project (tempest or tempest-plugin)

These repos I believe *should* have a stable/pike branch or will see
problems when we open openstack/requirements.  Those issues were
described in [1]

It turns out close to 1/3rd of projects that subscribe to requirements
management are not ready for us to re-open for master.  So we need you
help to get that number down to a much more acceptable number.

The good news is it's pretty easy to fix this with the cool tools and
workflow in the releases repo[2].  I suspect that the 'service' will
take care of themselves, and the horizon-plugins are waiting to horizon
to cut RC1.

Repos with type: horizon-plugin
ironic-ui                                          ironic
manila-ui                                          manila
monasca-ui                                         monasca
neutron-fwaas-dashboard                            neutron
solum-dashboard                                    solum
tacker-horizon                                     tacker
watcher-dashboard                                  watcher
zun-ui                                             zun

Repos with type: other
python-openstackclient                             OpenStackClient
patrole                                            Quality Assurance
heat-agents                                        heat
ironic-inspector                                   ironic
ironic-python-agent                                ironic
kuryr-kubernetes                                   kuryr
monasca-common                                     monasca
monasca-notification                               monasca
monasca-persister                                  monasca
monasca-transform                                  monasca

Repos with type: service
ironic                                             ironic
monasca-api                                        monasca
monasca-log-api                                    monasca
swift                                              swift
tricircle                                          tricircle
vitrage                                            vitrage
watcher                                            watcher
zun                                                zun

Those are the easy items.

The following repos don't seem to use the openstack/releases repo so I
have less information there.

i18n                                               I18n
almanach
blazar
blazar-nova
compute-hyperv
ekko
gce-api
glare
ironic-staging-drivers
kosmos
masakari
masakari-monitors
mixmatch
mogan
nemesis
networking-dpm
networking-fujitsu
networking-generic-switch
networking-l2gw
networking-powervm
neutron-vpnaas
neutron-vpnaas-dashboard
nova-dpm
nova-lxd
nova-powervm
os-xenapi
python-blazarclient
python-cratonclient
python-glareclient
python-kingbirdclient
python-masakariclient
python-moganclient
python-oneviewclient
python-openstacksdk
python-valenceclient
swauth
tap-as-a-service
trio2o
valence
vmware-nsx
vmware-nsxlib
openstackclient                                    OpenStackClient
anchor                                             Security
ceilometer-powervm                                 Telemetry
ec2-api                                            ec2-api
horizon-cisco-ui                                   horizon
bifrost                                            ironic
ironic-python-agent-builder                        ironic
magnum                                             magnum
magnum-ui                                          magnum
manila-image-elements                              manila
murano-agent                                       murano
octavia-dashboard                                  octavia
senlin-dashboard                                   senlin
tacker                                             tacker
networking-hyperv                                  winstackers

It'd be great to get some of these repos represented in
openstack/releases.  Having a confirmed release-model would go a long
way to clearing up the list. An alternate approach would be to remove
redundant items from projects.txt

Yours Tony.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120720.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120816.html

__________________________________________________________________________
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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

Tony Breeds
In reply to this post by witold.bedyk@est.fujitsu.com
On Thu, Aug 10, 2017 at 07:29:22AM +0000, [hidden email] wrote:
> Hi Tony,
>
> stable/pike branches for Monasca repos are on the way
>
> https://review.openstack.org/492101

Great!

next cycle we'll have to try and match against open reviews to reduce
the noise.

Yours Tony.

__________________________________________________________________________
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

Tony Breeds
In reply to this post by joehuang
On Thu, Aug 10, 2017 at 08:41:40AM +0000, joehuang wrote:
> Hello,
>
> Tricircle plans to cut stable/pike branch on August 22nd, it has
> dependency on Neutron stable/pike creation.

Okay in that case can you block any reviews from the proposal-bot until
you do branch.

Yours Tony.

__________________________________________________________________________
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Akihiro MOTOKI-2
In reply to this post by Tony Breeds
Tony,

Thanks for taking care.

> The following repos don't seem to use the openstack/releases repo so I
> have less information there.

Most of them are projects not under the governance (so-called "hosted"
or "unofficial" projects),
so I am not sure there is a good way to handle them.

I can comment some of them which I am involved in deeply.

> i18n                                               I18n

At now, i18n repo is a part of governance but this is a project which
has no need to cut a release,
so it always follows the master branch of the requirements repo.
It is not a blocker for opening the master branch in the requirements repo.

> neutron-vpnaas
> neutron-vpnaas-dashboard

These projects are neutron related and horizon plugin.
We will do same things for other neutron stadium and horizon plugin projects.

IMHO we don't need to take care of them much.

> python-openstacksdk

python-openstackclient depends on this, so we need to cut stable/branch
from the latest release. The status of the project is being discussed
in the ML thread,
but I believe we need to cut a stable branch. On the other hand, I
think it does not
block the opening of the master of the requirements repo as the latest
release of
python-openstacksdk is enough for Pike release of OSC.

> It'd be great to get some of these repos represented in
> openstack/releases.  Having a confirmed release-model would go a long
> way to clearing up the list. An alternate approach would be to remove
> redundant items from projects.txt

I am not sure that projects not under the TC governance can use
openstack/releases repo.
Is the openstack/release repo for projects under the governance?

Thanks,
Akihiro

2017-08-10 14:46 GMT+09:00 Tony Breeds <[hidden email]>:

>
> Hi All,
>     In an effort to qualify which projects are likley to be affected if
> when we open the requirements repo I generated a list of all repos that:
>
> 1. Subscribe to requirements management
> 2. Do not already have a stable/pike branch
> 3. Do not follow the cycle-with-milestones, cycle-trailing or
>    independent release models
> 4. Are not a 'branchless' project (tempest or tempest-plugin)
>
> These repos I believe *should* have a stable/pike branch or will see
> problems when we open openstack/requirements.  Those issues were
> described in [1]
>
> It turns out close to 1/3rd of projects that subscribe to requirements
> management are not ready for us to re-open for master.  So we need you
> help to get that number down to a much more acceptable number.
>
> The good news is it's pretty easy to fix this with the cool tools and
> workflow in the releases repo[2].  I suspect that the 'service' will
> take care of themselves, and the horizon-plugins are waiting to horizon
> to cut RC1.
>
> Repos with type: horizon-plugin
> ironic-ui                                          ironic
> manila-ui                                          manila
> monasca-ui                                         monasca
> neutron-fwaas-dashboard                            neutron
> solum-dashboard                                    solum
> tacker-horizon                                     tacker
> watcher-dashboard                                  watcher
> zun-ui                                             zun
>
> Repos with type: other
> python-openstackclient                             OpenStackClient
> patrole                                            Quality Assurance
> heat-agents                                        heat
> ironic-inspector                                   ironic
> ironic-python-agent                                ironic
> kuryr-kubernetes                                   kuryr
> monasca-common                                     monasca
> monasca-notification                               monasca
> monasca-persister                                  monasca
> monasca-transform                                  monasca
>
> Repos with type: service
> ironic                                             ironic
> monasca-api                                        monasca
> monasca-log-api                                    monasca
> swift                                              swift
> tricircle                                          tricircle
> vitrage                                            vitrage
> watcher                                            watcher
> zun                                                zun
>
> Those are the easy items.
>
> The following repos don't seem to use the openstack/releases repo so I
> have less information there.
>
> i18n                                               I18n
> almanach
> blazar
> blazar-nova
> compute-hyperv
> ekko
> gce-api
> glare
> ironic-staging-drivers
> kosmos
> masakari
> masakari-monitors
> mixmatch
> mogan
> nemesis
> networking-dpm
> networking-fujitsu
> networking-generic-switch
> networking-l2gw
> networking-powervm
> neutron-vpnaas
> neutron-vpnaas-dashboard
> nova-dpm
> nova-lxd
> nova-powervm
> os-xenapi
> python-blazarclient
> python-cratonclient
> python-glareclient
> python-kingbirdclient
> python-masakariclient
> python-moganclient
> python-oneviewclient
> python-openstacksdk
> python-valenceclient
> swauth
> tap-as-a-service
> trio2o
> valence
> vmware-nsx
> vmware-nsxlib
> openstackclient                                    OpenStackClient
> anchor                                             Security
> ceilometer-powervm                                 Telemetry
> ec2-api                                            ec2-api
> horizon-cisco-ui                                   horizon
> bifrost                                            ironic
> ironic-python-agent-builder                        ironic
> magnum                                             magnum
> magnum-ui                                          magnum
> manila-image-elements                              manila
> murano-agent                                       murano
> octavia-dashboard                                  octavia
> senlin-dashboard                                   senlin
> tacker                                             tacker
> networking-hyperv                                  winstackers
>
> It'd be great to get some of these repos represented in
> openstack/releases.  Having a confirmed release-model would go a long
> way to clearing up the list. An alternate approach would be to remove
> redundant items from projects.txt
>
> Yours Tony.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120720.html
> [2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120816.html
>
> __________________________________________________________________________
> 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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Dmitry Tantsur
In reply to this post by Tony Breeds
Hi Tony!

I hope to finish releasing Ironic stuff next week. We still have a few critical
things to land.

On 08/10/2017 07:46 AM, Tony Breeds wrote:

>
> Hi All,
>      In an effort to qualify which projects are likley to be affected if
> when we open the requirements repo I generated a list of all repos that:
>
> 1. Subscribe to requirements management
> 2. Do not already have a stable/pike branch
> 3. Do not follow the cycle-with-milestones, cycle-trailing or
>     independent release models
> 4. Are not a 'branchless' project (tempest or tempest-plugin)
>
> These repos I believe *should* have a stable/pike branch or will see
> problems when we open openstack/requirements.  Those issues were
> described in [1]
>
> It turns out close to 1/3rd of projects that subscribe to requirements
> management are not ready for us to re-open for master.  So we need you
> help to get that number down to a much more acceptable number.
>
> The good news is it's pretty easy to fix this with the cool tools and
> workflow in the releases repo[2].  I suspect that the 'service' will
> take care of themselves, and the horizon-plugins are waiting to horizon
> to cut RC1.
>
> Repos with type: horizon-plugin
> ironic-ui                                          ironic

This was released already.

> manila-ui                                          manila
> monasca-ui                                         monasca
> neutron-fwaas-dashboard                            neutron
> solum-dashboard                                    solum
> tacker-horizon                                     tacker
> watcher-dashboard                                  watcher
> zun-ui                                             zun
>
> Repos with type: other
> python-openstackclient                             OpenStackClient
> patrole                                            Quality Assurance
> heat-agents                                        heat
> ironic-inspector                                   ironic

Hmm, this should be type:service too, will double-check.

> ironic-python-agent                                ironic
> kuryr-kubernetes                                   kuryr
> monasca-common                                     monasca
> monasca-notification                               monasca
> monasca-persister                                  monasca
> monasca-transform                                  monasca
>
> Repos with type: service
> ironic                                             ironic
> monasca-api                                        monasca
> monasca-log-api                                    monasca
> swift                                              swift
> tricircle                                          tricircle
> vitrage                                            vitrage
> watcher                                            watcher
> zun                                                zun
>
> Those are the easy items.
>
> The following repos don't seem to use the openstack/releases repo so I
> have less information there.
>
> i18n                                               I18n
> almanach
> blazar
> blazar-nova
> compute-hyperv
> ekko
> gce-api
> glare
> ironic-staging-drivers
> kosmos
> masakari
> masakari-monitors
> mixmatch
> mogan
> nemesis
> networking-dpm
> networking-fujitsu
> networking-generic-switch
> networking-l2gw
> networking-powervm
> neutron-vpnaas
> neutron-vpnaas-dashboard
> nova-dpm
> nova-lxd
> nova-powervm
> os-xenapi
> python-blazarclient
> python-cratonclient
> python-glareclient
> python-kingbirdclient
> python-masakariclient
> python-moganclient
> python-oneviewclient
> python-openstacksdk
> python-valenceclient
> swauth
> tap-as-a-service
> trio2o
> valence
> vmware-nsx
> vmware-nsxlib
> openstackclient                                    OpenStackClient
> anchor                                             Security
> ceilometer-powervm                                 Telemetry
> ec2-api                                            ec2-api
> horizon-cisco-ui                                   horizon
> bifrost                                            ironic
> ironic-python-agent-builder                        ironic
> magnum                                             magnum
> magnum-ui                                          magnum
> manila-image-elements                              manila
> murano-agent                                       murano
> octavia-dashboard                                  octavia
> senlin-dashboard                                   senlin
> tacker                                             tacker
> networking-hyperv                                  winstackers
>
> It'd be great to get some of these repos represented in
> openstack/releases.  Having a confirmed release-model would go a long
> way to clearing up the list. An alternate approach would be to remove
> redundant items from projects.txt
>
> Yours Tony.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120720.html
> [2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120816.html
>
>
>
> __________________________________________________________________________
> 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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

Thierry Carrez
In reply to this post by joehuang
joehuang wrote:
> Tricircle plans to cut stable/pike branch on August 22nd, it has dependency on Neutron stable/pike creation.

That sounds a bit late to create your release branch. It doesn't give
you a lot of time to react to critical issues discovered in that
release, as August 24 is the final date to submit new releases for
inclusion before Pike is formally declared released.

My advice would be to do a X.Y.0 release as soon as you can freeze
features (neutron should have their branch this week), and have some
time to produce a X.Y.1 bugfix release if you detect critical issues in
testing.

--
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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

joehuang
Features for tricircle pike has been freezed, and
no exception was asked until now, as you
proposed, If neutron can have branch this
week, we can cut branch earlier.

Thank you, TTX.

________________________________________
From: Thierry Carrez [[hidden email]]
Sent: 10 August 2017 20:39
To: [hidden email]
Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

joehuang wrote:
> Tricircle plans to cut stable/pike branch on August 22nd, it has dependency on Neutron stable/pike creation.

That sounds a bit late to create your release branch. It doesn't give
you a lot of time to react to critical issues discovered in that
release, as August 24 is the final date to submit new releases for
inclusion before Pike is formally declared released.

My advice would be to do a X.Y.0 release as soon as you can freeze
features (neutron should have their branch this week), and have some
time to produce a X.Y.1 bugfix release if you detect critical issues in
testing.

--
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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Matthew Treinish-2
In reply to this post by Tony Breeds
On Thu, Aug 10, 2017 at 03:46:32PM +1000, Tony Breeds wrote:

>
> Hi All,
>     In an effort to qualify which projects are likley to be affected if
> when we open the requirements repo I generated a list of all repos that:
>
> 1. Subscribe to requirements management
> 2. Do not already have a stable/pike branch
> 3. Do not follow the cycle-with-milestones, cycle-trailing or
>    independent release models
> 4. Are not a 'branchless' project (tempest or tempest-plugin)
>
> These repos I believe *should* have a stable/pike branch or will see
> problems when we open openstack/requirements.  Those issues were
> described in [1]
>
> It turns out close to 1/3rd of projects that subscribe to requirements
> management are not ready for us to re-open for master.  So we need you
> help to get that number down to a much more acceptable number.
>
> The good news is it's pretty easy to fix this with the cool tools and
> workflow in the releases repo[2].  I suspect that the 'service' will
> take care of themselves, and the horizon-plugins are waiting to horizon
> to cut RC1.
>
> Repos with type: horizon-plugin
> ironic-ui                                          ironic              
> manila-ui                                          manila              
> monasca-ui                                         monasca            
> neutron-fwaas-dashboard                            neutron            
> solum-dashboard                                    solum              
> tacker-horizon                                     tacker              
> watcher-dashboard                                  watcher            
> zun-ui                                             zun                
>
> Repos with type: other
> python-openstackclient                             OpenStackClient    
> patrole                                            Quality Assurance
Fwiw, patrole is also a tempest plugin. [1] So it should also fall into the
branchless category and you don't need to worry about it branching before
unfreezing requirements.

-Matt Treinish

[1] https://github.com/openstack/patrole/blob/master/README.rst#release-versioning

> heat-agents                                        heat                
> ironic-inspector                                   ironic              
> ironic-python-agent                                ironic              
> kuryr-kubernetes                                   kuryr              
> monasca-common                                     monasca            
> monasca-notification                               monasca            
> monasca-persister                                  monasca            
> monasca-transform                                  monasca            
>
> Repos with type: service
> ironic                                             ironic              
> monasca-api                                        monasca            
> monasca-log-api                                    monasca            
> swift                                              swift              
> tricircle                                          tricircle          
> vitrage                                            vitrage            
> watcher                                            watcher            
> zun                                                zun
>
> Those are the easy items.
>
> The following repos don't seem to use the openstack/releases repo so I
> have less information there.
>
> i18n                                               I18n                
> almanach                                                              
> blazar                                                                
> blazar-nova                                                            
> compute-hyperv                                                        
> ekko                                                                  
> gce-api                                                                
> glare                                                                  
> ironic-staging-drivers                                                
> kosmos                                                                
> masakari                                                              
> masakari-monitors                                                      
> mixmatch                                                              
> mogan                                                                  
> nemesis                                                                
> networking-dpm                                                        
> networking-fujitsu                                                    
> networking-generic-switch                                              
> networking-l2gw                                                        
> networking-powervm                                                    
> neutron-vpnaas                                                        
> neutron-vpnaas-dashboard                                              
> nova-dpm                                                              
> nova-lxd                                                              
> nova-powervm                                                          
> os-xenapi                                                              
> python-blazarclient                                                    
> python-cratonclient                                                    
> python-glareclient                                                    
> python-kingbirdclient                                                  
> python-masakariclient                                                  
> python-moganclient                                                    
> python-oneviewclient                                                  
> python-openstacksdk                                                    
> python-valenceclient                                                  
> swauth                                                                
> tap-as-a-service                                                      
> trio2o                                                                
> valence                                                                
> vmware-nsx                                                            
> vmware-nsxlib                                                          
> openstackclient                                    OpenStackClient    
> anchor                                             Security            
> ceilometer-powervm                                 Telemetry          
> ec2-api                                            ec2-api            
> horizon-cisco-ui                                   horizon            
> bifrost                                            ironic              
> ironic-python-agent-builder                        ironic              
> magnum                                             magnum              
> magnum-ui                                          magnum              
> manila-image-elements                              manila              
> murano-agent                                       murano              
> octavia-dashboard                                  octavia            
> senlin-dashboard                                   senlin              
> tacker                                             tacker              
> networking-hyperv                                  winstackers  
>
> It'd be great to get some of these repos represented in
> openstack/releases.  Having a confirmed release-model would go a long
> way to clearing up the list. An alternate approach would be to remove
> redundant items from projects.txt
>
> Yours Tony.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120720.html
> [2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120816.html


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

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

Re: [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Ian Y. Choi
In reply to this post by Akihiro MOTOKI-2
Akihiro Motoki wrote on 8/10/2017 7:22 PM:
> Tony,
>
> Thanks for taking care.

<snip>
>
>> i18n                                               I18n
> At now, i18n repo is a part of governance but this is a project which
> has no need to cut a release,
> so it always follows the master branch of the requirements repo.
> It is not a blocker for opening the master branch in the requirements repo.
>
</snip>

Right - i18n repository has I18n contributor guide, translation
glossary, and useful scripts with translate.openstack.org
which all do not need to have stable branches to be maintained.

I am not pretty sure but it seems that some project repositories which
are affected by requirements.txt in stable branches
need to follow "stable:follows-policy" [1] for official projects?

And also thanks a lot - since I also keep on eyes for having stable
branches from translation target repositories in Pike release cycle [2].


With many thanks,

/Ian

[1]
https://governance.openstack.org/tc/reference/tags/stable_follows-policy.html
[2] http://git.openstack.org/cgit/openstack/releases/tree/PROCESS.rst#n214

__________________________________________________________________________
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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Tony Breeds
In reply to this post by Dmitry Tantsur
On Thu, Aug 10, 2017 at 12:38:43PM +0200, Dmitry Tantsur wrote:
> Hi Tony!
>
> I hope to finish releasing Ironic stuff next week. We still have a few
> critical things to land.

Cool
 

> On 08/10/2017 07:46 AM, Tony Breeds wrote:
> >
> > Hi All,
> >      In an effort to qualify which projects are likley to be affected if
> > when we open the requirements repo I generated a list of all repos that:
> >
> > 1. Subscribe to requirements management
> > 2. Do not already have a stable/pike branch
> > 3. Do not follow the cycle-with-milestones, cycle-trailing or
> >     independent release models
> > 4. Are not a 'branchless' project (tempest or tempest-plugin)
> >
> > These repos I believe *should* have a stable/pike branch or will see
> > problems when we open openstack/requirements.  Those issues were
> > described in [1]
> >
> > It turns out close to 1/3rd of projects that subscribe to requirements
> > management are not ready for us to re-open for master.  So we need you
> > help to get that number down to a much more acceptable number.
> >
> > The good news is it's pretty easy to fix this with the cool tools and
> > workflow in the releases repo[2].  I suspect that the 'service' will
> > take care of themselves, and the horizon-plugins are waiting to horizon
> > to cut RC1.
> >
> > Repos with type: horizon-plugin
> > ironic-ui                                          ironic
>
> This was released already.
Hmm okay perhaps my repo is out of date.  I'll check that.
 

> > manila-ui                                          manila
> > monasca-ui                                         monasca
> > neutron-fwaas-dashboard                            neutron
> > solum-dashboard                                    solum
> > tacker-horizon                                     tacker
> > watcher-dashboard                                  watcher
> > zun-ui                                             zun
> >
> > Repos with type: other
> > python-openstackclient                             OpenStackClient
> > patrole                                            Quality Assurance
> > heat-agents                                        heat
> > ironic-inspector                                   ironic
>
> Hmm, this should be type:service too, will double-check.
Cool.

Thanks.

Yours Tony.

__________________________________________________________________________
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Tony Breeds
In reply to this post by Matthew Treinish-2
On Thu, Aug 10, 2017 at 10:17:23AM -0400, Matthew Treinish wrote:

> On Thu, Aug 10, 2017 at 03:46:32PM +1000, Tony Breeds wrote:
> >
> > Hi All,
> >     In an effort to qualify which projects are likley to be affected if
> > when we open the requirements repo I generated a list of all repos that:
> >
> > 1. Subscribe to requirements management
> > 2. Do not already have a stable/pike branch
> > 3. Do not follow the cycle-with-milestones, cycle-trailing or
> >    independent release models
> > 4. Are not a 'branchless' project (tempest or tempest-plugin)
> >
> > These repos I believe *should* have a stable/pike branch or will see
> > problems when we open openstack/requirements.  Those issues were
> > described in [1]
> >
> > It turns out close to 1/3rd of projects that subscribe to requirements
> > management are not ready for us to re-open for master.  So we need you
> > help to get that number down to a much more acceptable number.
> >
> > The good news is it's pretty easy to fix this with the cool tools and
> > workflow in the releases repo[2].  I suspect that the 'service' will
> > take care of themselves, and the horizon-plugins are waiting to horizon
> > to cut RC1.
> >
> > Repos with type: horizon-plugin
> > ironic-ui                                          ironic              
> > manila-ui                                          manila              
> > monasca-ui                                         monasca            
> > neutron-fwaas-dashboard                            neutron            
> > solum-dashboard                                    solum              
> > tacker-horizon                                     tacker              
> > watcher-dashboard                                  watcher            
> > zun-ui                                             zun                
> >
> > Repos with type: other
> > python-openstackclient                             OpenStackClient    
> > patrole                                            Quality Assurance
>
> Fwiw, patrole is also a tempest plugin. [1] So it should also fall into the
> branchless category and you don't need to worry about it branching before
> unfreezing requirements.
\o/  I shall update my script and the tracking document.

Thanks.

Yours Tony.

__________________________________________________________________________
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Tony Breeds
In reply to this post by Akihiro MOTOKI-2
On Thu, Aug 10, 2017 at 07:22:56PM +0900, Akihiro Motoki wrote:

> Tony,
>
> Thanks for taking care.
>
> > The following repos don't seem to use the openstack/releases repo so I
> > have less information there.
>
> Most of them are projects not under the governance (so-called "hosted"
> or "unofficial" projects),
> so I am not sure there is a good way to handle them.
>
> I can comment some of them which I am involved in deeply.
>
> > i18n                                               I18n
>
> At now, i18n repo is a part of governance but this is a project which
> has no need to cut a release,
> so it always follows the master branch of the requirements repo.
> It is not a blocker for opening the master branch in the requirements repo.
Okay I'll added that to the 'branchless' group.
 
> > neutron-vpnaas
> > neutron-vpnaas-dashboard
>
> These projects are neutron related and horizon plugin.
> We will do same things for other neutron stadium and horizon plugin projects.
>
> IMHO we don't need to take care of them much.

As long as you block bot-updates from the time we branch (pike) until the time
you branch (pike) that is all that needs to happen
 

> > python-openstacksdk
>
> python-openstackclient depends on this, so we need to cut stable/branch
> from the latest release. The status of the project is being discussed
> in the ML thread,
> but I believe we need to cut a stable branch. On the other hand, I
> think it does not
> block the opening of the master of the requirements repo as the latest
> release of
> python-openstacksdk is enough for Pike release of OSC.
As with the neutron-vpnaas repos, you need to block to bit updates or it
*does* block (or hamper) the requirements repo from re-opening master.

> > It'd be great to get some of these repos represented in
> > openstack/releases.  Having a confirmed release-model would go a long
> > way to clearing up the list. An alternate approach would be to remove
> > redundant items from projects.txt
>
> I am not sure that projects not under the TC governance can use
> openstack/releases repo.
> Is the openstack/release repo for projects under the governance?

I didn't think that was the rule but it's certainly been said enough in
the last 24 hours that it probably is correct.

With that in mind we'd do better if there was a process for Openstack
Hosted projects to follow.

Perhaps they could maintain a 'deliverables/<series>/<project>.yaml in
their own repo that would mirror (but probably get out od sync with,
openstack/releases.  From a requirements POV I just need somewheer to
look for data on the projects that are managed but not official.

Yours Tony.

__________________________________________________________________________
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Tony Breeds
In reply to this post by Ian Y. Choi
On Fri, Aug 11, 2017 at 12:46:20AM +0900, Ian Y. Choi wrote:

> Akihiro Motoki wrote on 8/10/2017 7:22 PM:
> > Tony,
> >
> > Thanks for taking care.
>
> <snip>
> >
> > > i18n                                               I18n
> > At now, i18n repo is a part of governance but this is a project which
> > has no need to cut a release,
> > so it always follows the master branch of the requirements repo.
> > It is not a blocker for opening the master branch in the requirements repo.
> >
> </snip>
>
> Right - i18n repository has I18n contributor guide, translation glossary,
> and useful scripts with translate.openstack.org
> which all do not need to have stable branches to be maintained.
Now that I know what it is I can handle it in my script.  That's fine
 
> I am not pretty sure but it seems that some project repositories which are
> affected by requirements.txt in stable branches
> need to follow "stable:follows-policy" [1] for official projects?

No that is a seperate thing.  That tag asserts that the code delivered
via that repo adheres to the stable policy.

What this email thread is about is repos that subscribe to the
 
Yours Tony.

__________________________________________________________________________
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed

Jeremy Stanley
In reply to this post by Tony Breeds
On 2017-08-11 08:49:18 +1000 (+1000), Tony Breeds wrote:
> On Thu, Aug 10, 2017 at 07:22:56PM +0900, Akihiro Motoki wrote:
[...]

> > I am not sure that projects not under the TC governance can use
> > openstack/releases repo. Is the openstack/release repo for
> > projects under the governance?
>
> I didn't think that was the rule but it's certainly been said
> enough in the last 24 hours that it probably is correct.
>
> With that in mind we'd do better if there was a process for
> Openstack Hosted projects to follow.
>
> Perhaps they could maintain a
> 'deliverables/<series>/<project>.yaml in their own repo that would
> mirror (but probably get out od sync with, openstack/releases.
> From a requirements POV I just need somewheer to look for data on
> the projects that are managed but not official.
Yes, it comes up often enough and as far as I'm aware reviewers
haven't previously rejected unofficial projects who want to receive
requirements updates. There are definitely projects who don't want
to (or for license reasons perhaps even can't) be official teams but
would still like their dependencies to remain compatible with those
of official OpenStack deliverables.
--
Jeremy Stanley

__________________________________________________________________________
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 (968 bytes) Download Attachment
12
Loading...