Re: [openstack-dev] [kolla] [requirements] Stepping down as core reviewer
On 18-10-16 18:03:54, ʂʍɒρƞįł Ҟưȴķɒʁʉɨ wrote: > Dear OpenStackers, > > For a few months now, I am not able to contribute to code or reviewing > Kolla and Requirements actively given my current responsibilities, I > would like to take a step back and release my core reviewer ability > for the Kolla and Requirements repositories. > > I want to use this moment to thank the everyone I have had a chance to > work alongside with and I may have troubled. It has been both an honor > and privilege to serve this community and I will continue to do so. > > In the new cloudy world I am sure the paths will cross again. Till > then, Sayo Nara, Take Care. > Sad to see you go, hope to see you around though. Good luck on your journey. It was nice working with you. -- Matthew Thode (prometheanfire) 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] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0
On 18-10-09 11:12:30, Doug Hellmann wrote: > Matthew Thode writes: > > > several projects have had problems with the new release, some have ways > > of working around it, and some do not. I'm sending this just to raise > > the issue and allow a place to discuss solutions. > > > > Currently there is a review proposed to blacklist 9.0.0, but if this is > > going to still be an issue somehow in further releases we may need > > another solution. > > > > https://review.openstack.org/#/c/608835/ > > > > -- > > 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 > > Do you have links to the failure logs or bug reports or something? If I > wanted to help I wouldn't even know where to start. > http://logs.openstack.org/21/607521/2/check/cross-cinder-py35/e15722e/testr_results.html.gz http://logs.openstack.org/21/607521/2/check/cross-glance-py35/e2161d7/testr_results.html.gz http://logs.openstack.org/21/607521/2/check/cross-keystone-py35/908a1c2/testr_results.html.gz -- Matthew Thode (prometheanfire) 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
[openstack-dev] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0
several projects have had problems with the new release, some have ways of working around it, and some do not. I'm sending this just to raise the issue and allow a place to discuss solutions. Currently there is a review proposed to blacklist 9.0.0, but if this is going to still be an issue somehow in further releases we may need another solution. https://review.openstack.org/#/c/608835/ -- Matthew Thode (prometheanfire) 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] [networking-odl][networking-bgpvpn][Telemetry] all requirement updates are currently blocked
On 18-09-07 11:09:15, Julien Danjou wrote: > On Fri, Sep 07 2018, Tony Breeds wrote: > > > On Thu, Sep 06, 2018 at 01:33:12PM +0300, Michel Peterson wrote: > > > >> I remember that before landing the problematic patch [1] there was some > >> discussion around it. Basically the problem was not n-odl but ceilometer > >> not being in pypi, but we never foresaw this problem. > >> > >> Now that the problem is so critical, the question is how can we, from the > >> n-odl team, help in fixing this? I am open to help in any effort that > >> involves n-odl or any other project. > > > > As other have pointed out we can just ask the Telemetry team (PTL on CC) > > why we can't publish ceilometer to pypi? > > You can, I've already said +1 on a review a few weeks ago. :) > Mind linking? I can't find it. > > https://pypi.org/project/ceilometer/ certainly seems to be the right > > project. > > > > The crux of the code issue is: > > from ceilometer.network.statistics import driver > > > > in networking_odl/ceilometer/network/statistics/opendaylight_v2/driver.py > > > > If this is supposed to be used they way you are how are prjects supposed > > to get the ceilometer code? > > -- Matthew Thode 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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked
On 18-09-06 13:33:12, Michel Peterson wrote: > On Wed, Sep 5, 2018 at 6:03 PM, Matthew Thode > wrote: > > > On 18-08-31 19:52:09, Matthew Thode wrote: > > > The requirements project has a co-installability test for the various > > > projects, networking-odl being included. > > > > > > Because of the way the dependancy on ceilometer is done it is blocking > > > all reviews and updates to the requirements project. > > > > > > http://logs.openstack.org/96/594496/2/check/requirements- > > integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505 > > > > The requirements team has gone ahead and made a aweful hack to get gate > > unwedged. The commit message is a very good summary of our reasoning > > why it has to be this way for now. My comment explains our plan going > > forward (there will be a revert prepared as soon as this merges for > > instance). > > > > step 1. merge this > > step 2. look into and possibly fix our tooling (why was the gitref > > addition not rejected by gate) > > step 3. fix networking-odl (release ceilometer) > > step 4. unmerge this > > > > I remember that before landing the problematic patch [1] there was some > discussion around it. Basically the problem was not n-odl but ceilometer > not being in pypi, but we never foresaw this problem. > > Now that the problem is so critical, the question is how can we, from the > n-odl team, help in fixing this? I am open to help in any effort that > involves n-odl or any other project. > > Sorry this message fell through the cracks and I didn't answer before. > > PS: I'm CCing Mike Kolesnik to this email, as he will be going to the PTG > and can represent n-odl. > > [1] https://review.openstack.org/557370/ I think the best choice at this point in time would be to get a ceilometer release onto pypi. At that time you can move to using that version as your project minimum. Just make sure that if you need a new feature you ask them for a release instead of using a git SHA. I'll be at the PTG as well, infra/upgrade/OSA rooms mostly I think. -- Matthew Thode (prometheanfire) 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] Bumping eventlet to 0.24.1
On 18-08-23 09:50:13, Matthew Thode wrote: > This is your warning, if you have concerns please comment in > https://review.openstack.org/589382 . cross tests pass, so that's a > good sign... atm this is only for stein. > I pushed the big red button. -- Matthew Thode (prometheanfire) 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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked
On 18-09-05 17:50:59, thomas.mo...@orange.com wrote: > Mathew, > > networking-odl has now been removed from the requirements of > networking-bgpvpn [1], on master, so networking-odl could be removed from > requirements. > > This is not the case on stable branches, though. > > -Thomas > > [1] https://review.openstack.org/#/c/599422/ > > On 05/09/2018 17:03, Matthew Thode wrote: > > On 18-08-31 19:52:09, Matthew Thode wrote: > > > The requirements project has a co-installability test for the various > > > projects, networking-odl being included. > > > > > > Because of the way the dependancy on ceilometer is done it is blocking > > > all reviews and updates to the requirements project. > > > > > > http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505 > > > > > > If networking-odl is not meant to be used as a library I'd recommend > > > it's removal from networking-bgpvpn (it's test-requirements.txt file). > > > Once that is done networking-odl can be removed from global-requirements > > > and we won't be blocked anymore. > > > > > > As a side note, fungi noticed that when you branched you are still > > > installing ceilometer from master. Also, the ceilometer team > > > doesnt wish it to be used as a library either (like networking-odl > > > doesn't wish to be used as a library). > > > > > The requirements team has gone ahead and made a aweful hack to get gate > > unwedged. The commit message is a very good summary of our reasoning > > why it has to be this way for now. My comment explains our plan going > > forward (there will be a revert prepared as soon as this merges for > > instance). > > > > step 1. merge this > > step 2. look into and possibly fix our tooling (why was the gitref addition > > not rejected by gate) > > step 3. fix networking-odl (release ceilometer) > > step 4. unmerge this > > > > > > __ > > 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 > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > Yep, we discussed doing that (and it's still an option). We decided to do something a bit more verbose though and have a plan. Just need to get ceilometer to release to pypi... -- Matthew Thode (prometheanfire) 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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked
On 18-08-31 19:52:09, Matthew Thode wrote: > The requirements project has a co-installability test for the various > projects, networking-odl being included. > > Because of the way the dependancy on ceilometer is done it is blocking > all reviews and updates to the requirements project. > > http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505 > > If networking-odl is not meant to be used as a library I'd recommend > it's removal from networking-bgpvpn (it's test-requirements.txt file). > Once that is done networking-odl can be removed from global-requirements > and we won't be blocked anymore. > > As a side note, fungi noticed that when you branched you are still > installing ceilometer from master. Also, the ceilometer team > doesnt wish it to be used as a library either (like networking-odl > doesn't wish to be used as a library). > The requirements team has gone ahead and made a aweful hack to get gate unwedged. The commit message is a very good summary of our reasoning why it has to be this way for now. My comment explains our plan going forward (there will be a revert prepared as soon as this merges for instance). step 1. merge this step 2. look into and possibly fix our tooling (why was the gitref addition not rejected by gate) step 3. fix networking-odl (release ceilometer) step 4. unmerge this -- Matthew Thode (prometheanfire) 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] check-requirements and you
On 18-09-05 07:04:12, Andreas Jaeger wrote: > On 2018-09-05 05:20, Matthew Thode wrote: > > With the move to per-project requirements (aka divergent requirements) > > we started allowing projects to have differing exclusions and minimums. > > As long as projects still tested against upper-constraints we were good. > > > > Part of the reason why we use upper-constraints is to ensure that > > project A and project B are co-installable. This is especially useful > > to distro packagers who can then target upper-constraints for any > > package updates they need. Another reason is that we (the requirements > > team) reviews new global-requirements for code quality, licencing and > > the like, all of which are useful to Openstack as a whole. > > > > If a projects dependencies are compatible with the global list, and the > > global list is compatible with the upper-constraints, then the > > projects' dependencies are compatible with the upper-constraints. > > > > All the above lets us all work together and use any lib listed in > > global-requirements (at the upper-constraints version). This is all > > ensured by having the check-requirements job enabled for your project. > > It helps ensure co-installability, code quality, python version > > compatibility, etc. So please make sure that if you are running > > everything in your own zuul config (not project-config) that you have > > the check-requirements job as well. > > > And also set up and run the lower-constraints jobs - you can use the new > template openstack-lower-constraints-jobs for this, > Of course!!! Lower-constraints are useful (again, mainly for packagers, but also to know the state of our dependencies). Specifying and testing lower-constraints means that there's less potential for bugs that are caused because a project missed the deprecation of some library feature that they used. It also means that we have a second set of constraints (one that's just for that project) that we know works and can be targeted if needed. This massively increases the flexibility of deployments and packaging. -- Matthew Thode (prometheanfire) 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
[openstack-dev] check-requirements and you
With the move to per-project requirements (aka divergent requirements) we started allowing projects to have differing exclusions and minimums. As long as projects still tested against upper-constraints we were good. Part of the reason why we use upper-constraints is to ensure that project A and project B are co-installable. This is especially useful to distro packagers who can then target upper-constraints for any package updates they need. Another reason is that we (the requirements team) reviews new global-requirements for code quality, licencing and the like, all of which are useful to Openstack as a whole. If a projects dependencies are compatible with the global list, and the global list is compatible with the upper-constraints, then the projects' dependencies are compatible with the upper-constraints. All the above lets us all work together and use any lib listed in global-requirements (at the upper-constraints version). This is all ensured by having the check-requirements job enabled for your project. It helps ensure co-installability, code quality, python version compatibility, etc. So please make sure that if you are running everything in your own zuul config (not project-config) that you have the check-requirements job as well. -- Matthew Thode (prometheanfire) 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
[openstack-dev] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked
The requirements project has a co-installability test for the various projects, networking-odl being included. Because of the way the dependancy on ceilometer is done it is blocking all reviews and updates to the requirements project. http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505 If networking-odl is not meant to be used as a library I'd recommend it's removal from networking-bgpvpn (it's test-requirements.txt file). Once that is done networking-odl can be removed from global-requirements and we won't be blocked anymore. As a side note, fungi noticed that when you branched you are still installing ceilometer from master. Also, the ceilometer team doesnt wish it to be used as a library either (like networking-odl doesn't wish to be used as a library). -- Matthew Thode (prometheanfire) 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] [kolla][tripleo][oslo][all] Bumping eventlet to 0.24.1
On 18-08-31 07:44:44, Jim Rollenhagen wrote: > On Thu, Aug 30, 2018 at 11:10 PM, Matthew Thode > wrote: > > > On 18-08-30 20:52:46, Matthew Thode wrote: > > > On 18-08-23 09:50:13, Matthew Thode wrote: > > > > This is your warning, if you have concerns please comment in > > > > https://review.openstack.org/589382 . cross tests pass, so that's a > > > > good sign... atm this is only for stein. > > > > > > > > > > Consider yourself on notice, https://review.openstack.org/589382 is > > > planned to be merged on monday. > > > > > > > A bit more of follow up since that was so dry. There are some projects > > that have not branched (mainly cycle-trailing and plugins). > > > > There has historically been some breakage with each eventlet update, > > this one is not expected to be much different unfortunately. Currently > > there are known issues with oslo.service but they look solvable. A list > > of all projects using eventlet is attached. > > > > The full list of non-branched projects will be at the bottom of this > > message, but the projects that I think should be more careful are the > > following. > > > > kolla kolla-ansible heat-agents heat-dashboard tripleo-ipsec > > > > the rest of the repos seem to be plugins, which I'm personally less > > concerned about, but should still be branched (preferably sooner rather > > than later). > > > > Tempest plugins, like tempest, are not meant to be branched: > http://lists.openstack.org/pipermail/openstack-dev/2018-August/133211.html > Yep, it's only on the list because the command used to generate it can't handle projects that should not branch. > > > > > > ansible-role-container-registry > > ansible-role-redhat-subscription > > ansible-role-tripleo-modify-image > > barbican-tempest-plugin > > blazar-tempest-plugin > > cinder-tempest-plugin > > cloudkitty-tempest-plugin > > congress-tempest-plugin > > designate-tempest-plugin > > devstack-plugin-amqp1 > > devstack-plugin-kafka > > ec2api-tempest-plugin > > heat-agents > > heat-dashboard > > heat-tempest-plugin > > ironic-tempest-plugin > > keystone-tempest-plugin > > kolla-ansible > > kolla > > kuryr-tempest-plugin > > magnum-tempest-plugin > > manila-tempest-plugin > > mistral-tempest-plugin > > monasca-kibana-plugin > > monasca-tempest-plugin > > murano-tempest-plugin > > networking-generic-switch-tempest-plugin > > neutron-tempest-plugin > > octavia-tempest-plugin > > oswin-tempest-plugin > > patrole > > release-test > > sahara-tests > > senlin-tempest-plugin > > solum-tempest-plugin > > telemetry-tempest-plugin > > tempest-tripleo-ui > > tempest > > tripleo-ipsec > > trove-tempest-plugin > > vitrage-tempest-plugin > > watcher-tempest-plugin > > zaqar-tempest-plugin > > zun-tempest-plugin > > > > -- > > 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 > > > > > __ > 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: 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] [kolla][tripleo][oslo][all] Bumping eventlet to 0.24.1
On 18-08-30 20:52:46, Matthew Thode wrote: > On 18-08-23 09:50:13, Matthew Thode wrote: > > This is your warning, if you have concerns please comment in > > https://review.openstack.org/589382 . cross tests pass, so that's a > > good sign... atm this is only for stein. > > > > Consider yourself on notice, https://review.openstack.org/589382 is > planned to be merged on monday. > A bit more of follow up since that was so dry. There are some projects that have not branched (mainly cycle-trailing and plugins). There has historically been some breakage with each eventlet update, this one is not expected to be much different unfortunately. Currently there are known issues with oslo.service but they look solvable. A list of all projects using eventlet is attached. The full list of non-branched projects will be at the bottom of this message, but the projects that I think should be more careful are the following. kolla kolla-ansible heat-agents heat-dashboard tripleo-ipsec the rest of the repos seem to be plugins, which I'm personally less concerned about, but should still be branched (preferably sooner rather than later). ansible-role-container-registry ansible-role-redhat-subscription ansible-role-tripleo-modify-image barbican-tempest-plugin blazar-tempest-plugin cinder-tempest-plugin cloudkitty-tempest-plugin congress-tempest-plugin designate-tempest-plugin devstack-plugin-amqp1 devstack-plugin-kafka ec2api-tempest-plugin heat-agents heat-dashboard heat-tempest-plugin ironic-tempest-plugin keystone-tempest-plugin kolla-ansible kolla kuryr-tempest-plugin magnum-tempest-plugin manila-tempest-plugin mistral-tempest-plugin monasca-kibana-plugin monasca-tempest-plugin murano-tempest-plugin networking-generic-switch-tempest-plugin neutron-tempest-plugin octavia-tempest-plugin oswin-tempest-plugin patrole release-test sahara-tests senlin-tempest-plugin solum-tempest-plugin telemetry-tempest-plugin tempest-tripleo-ui tempest tripleo-ipsec trove-tempest-plugin vitrage-tempest-plugin watcher-tempest-plugin zaqar-tempest-plugin zun-tempest-plugin -- Matthew Thode (prometheanfire) ++--+--++ | Repository | Filename | Line | Text | ++--+--++ | airship-drydock| requirements-lock.txt | 12 | eventlet==0.23.0 | | airship-promenade | requirements-frozen.txt | 17 | eventlet==0.23.0 | | apmec | requirements.txt | 11 | eventlet!=0.18.3,!=0.20.1,<0.21.0,>=0.18.2 # MIT | | astara | requirements.txt |5 | eventlet!=0.18.3,>=0.18.2 # MIT| | astara-appliance | requirements.txt |7 | eventlet!=0.18.3,>=0.18.2 # MIT| | astara-horizon | test-requirements.txt |9 | eventlet!=0.18.3,>=0.18.2 # MIT| | barbican | requirements.txt |8 | eventlet>=0.18.2,!=0.18.3,!=0.20.1 # MIT | | bareon | requirements.txt |5 | eventlet!=0.18.3,>=0.18.2 # MIT| | bilean | requirements.txt |7 | eventlet>=0.17.4 | | blazar | requirements.txt |8 | eventlet!=0.18.3,!=0.20.1,>=0.1
Re: [openstack-dev] Bumping eventlet to 0.24.1
On 18-08-23 09:50:13, Matthew Thode wrote: > This is your warning, if you have concerns please comment in > https://review.openstack.org/589382 . cross tests pass, so that's a > good sign... atm this is only for stein. > Consider yourself on notice, https://review.openstack.org/589382 is planned to be merged on monday. -- Matthew Thode (prometheanfire) 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] Update global upper constraint of Kubernetes from 7.0.0 to 6.0.0
On 18-08-30 20:48:39, Yossi Boaron wrote: > Hi Matthew, > > Seems that Openshift version 0.7 was released few hours ago, this version > should work properly with kubernetes. > I"ll update my PR to change openshift upper constraint to 0.7 and leave K8S > at 7.0.0 > > 10x > Yossi > > בתאריך יום ה׳, 30 באוג׳ 2018, 19:12, מאת Matthew Thode < > prometheanf...@gentoo.org>: > > > On 18-08-30 17:54:24, Yossi Boaron wrote: > > > Hi All, > > > > > > Kubernetes upper constraint was changed lately from 6.0.0 to 7.0.0 [1]. > > > Currently, the Openshift python client can't work with Kubernetes 7.0.0, > > > this caused by a version pinning issue (pulled in Kubernetes 7.0.0). > > > As a result of that, we are unable to run some of our tempest tests in > > > kuryr-kubernetes project. > > > > > > As a temporary (till an Openshift version that supports kubernets 7.0.0 > > > will be released) we would like to suggest to set back kubernetes upper > > > constraint to 6.0.0 [2]. > > > > How long til a version that supports >=7.0.0 comes out? > > > > > > > > Do you see any problem with this approach? > > > Sounds great, thanks -- Matthew Thode (prometheanfire) 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] Update global upper constraint of Kubernetes from 7.0.0 to 6.0.0
On 18-08-30 17:54:24, Yossi Boaron wrote: > Hi All, > > Kubernetes upper constraint was changed lately from 6.0.0 to 7.0.0 [1]. > Currently, the Openshift python client can't work with Kubernetes 7.0.0, > this caused by a version pinning issue (pulled in Kubernetes 7.0.0). > As a result of that, we are unable to run some of our tempest tests in > kuryr-kubernetes project. > > As a temporary (till an Openshift version that supports kubernets 7.0.0 > will be released) we would like to suggest to set back kubernetes upper > constraint to 6.0.0 [2]. How long til a version that supports >=7.0.0 comes out? > > Do you see any problem with this approach? > > Best regards > Yossi > > [1] - https://review.openstack.org/#/c/594495/ > [2] - https://review.openstack.org/#/c/595569/ -- Matthew Thode (prometheanfire) 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] live_migration only using 8 Mb speed
On 18-08-23 14:33:44, Satish Patel wrote: > Matt, > > I am going to override following in user_variable.yml file in that > case do i need to run ./bootstrap-ansible.sh script? > > ## Nova service > nova_git_repo: https://git.openstack.org/openstack/nova > nova_git_install_branch: a9c9285a5a68ab89a6543d143c364d90a01cd51c # > HEAD of "stable/queens" as of 06.08.2018 > nova_git_project_group: nova_all > > > > On Thu, Aug 23, 2018 at 7:18 AM, Satish Patel wrote: > > I'm testing this in lab, no load yet > > > > Sent from my iPhone > > > >> On Aug 23, 2018, at 2:30 AM, Matthew Thode > >> wrote: > >> > >>> On 18-08-22 23:04:57, Satish Patel wrote: > >>> Mathew, > >>> > >>> I haven't applied any patch yet but i am noticing in cluster some host > >>> migrating VM super fast and some host migrating very slow. Is this > >>> known behavior? > >>> > >>> On Wed, Aug 22, 2018 at 11:28 AM, Matthew Thode > >>> wrote: > >>>> On 18-08-22 10:58:48, Satish Patel wrote: > >>>>> Matthew, > >>>>> > >>>>> I have two option looks like, correct me if i am wrong. > >>>>> > >>>>> 1. I have two option, upgrade minor release from 17.0.7-6-g9187bb1 to > >>>>> 17.0.8-23-g0aff517 and upgrade full OSA > >>>>> > >>>>> 2. Just do override as you said "nova_git_install_branch:" in my > >>>>> /etc/openstack_deploy/user_variables.yml file, and run playbooks. > >>>>> > >>>>> > >>>>> I think option [2] is safe to just touch specific component, also am i > >>>>> correct about override in /etc/openstack_deploy/user_variables.yml > >>>>> file? > >>>>> > >>>>> You mentioned "nova_git_install_branch: > >>>>> dee99b1ed03de4b6ded94f3cf6d2ea7214bca93b" but i believe it should be > >>>>> "a9c9285a5a68ab89a6543d143c364d90a01cd51c" am i correct? > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Aug 22, 2018 at 10:46 AM, Matthew Thode > >>>>> wrote: > >>>>>> On 18-08-22 10:33:11, Satish Patel wrote: > >>>>>>> Thanks Matthew, > >>>>>>> > >>>>>>> Can i put that sha in my OSA at > >>>>>>> playbooks/defaults/repo_packages/openstack_services.yml by hand and > >>>>>>> run playbooks [repo/nova] ? > >>>>>>> > >>>>>>> On Wed, Aug 22, 2018 at 10:24 AM, Matthew Thode > >>>>>>> wrote: > >>>>>>>> On 18-08-22 08:35:09, Satish Patel wrote: > >>>>>>>>> Currently in stable/queens i am seeing this sha > >>>>>>>>> https://github.com/openstack/openstack-ansible/blob/stable/queens/ansible-role-requirements.yml#L112 > >>>>>>>>> > >>>>>>>>> On Wed, Aug 22, 2018 at 2:02 AM, Matthew Thode > >>>>>>>>> wrote: > >>>>>>>>>> On 18-08-22 01:57:17, Satish Patel wrote: > >>>>>>>>>>> What I need to upgrade, any specific component? > >>>>>>>>>>> > >>>>>>>>>>> I have deployed openstack-ansible > >>>>>>>>>>> > >>>>>>>>>>> Sent from my iPhone > >>>>>>>>>>> > >>>>>>>>>>>>> On Aug 22, 2018, at 1:06 AM, Matthew Thode > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 18-08-22 01:02:53, Satish Patel wrote: > >>>>>>>>>>>>> Matthew, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks for reply, Look like i don't have this patch > >>>>>>>>>>>>> https://review.openstack.org/#/c/591761/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> So i have to patch following 3 file manually? > >>>>>>>>>>>>> > >>>>>>>>>>>>> nova/tests/unit/virt/libvir
[openstack-dev] Bumping eventlet to 0.24.1
This is your warning, if you have concerns please comment in https://review.openstack.org/589382 . cross tests pass, so that's a good sign... atm this is only for stein. -- Matthew Thode (prometheanfire) 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] live_migration only using 8 Mb speed
On 18-08-22 23:04:57, Satish Patel wrote: > Mathew, > > I haven't applied any patch yet but i am noticing in cluster some host > migrating VM super fast and some host migrating very slow. Is this > known behavior? > > On Wed, Aug 22, 2018 at 11:28 AM, Matthew Thode > wrote: > > On 18-08-22 10:58:48, Satish Patel wrote: > >> Matthew, > >> > >> I have two option looks like, correct me if i am wrong. > >> > >> 1. I have two option, upgrade minor release from 17.0.7-6-g9187bb1 to > >> 17.0.8-23-g0aff517 and upgrade full OSA > >> > >> 2. Just do override as you said "nova_git_install_branch:" in my > >> /etc/openstack_deploy/user_variables.yml file, and run playbooks. > >> > >> > >> I think option [2] is safe to just touch specific component, also am i > >> correct about override in /etc/openstack_deploy/user_variables.yml > >> file? > >> > >> You mentioned "nova_git_install_branch: > >> dee99b1ed03de4b6ded94f3cf6d2ea7214bca93b" but i believe it should be > >> "a9c9285a5a68ab89a6543d143c364d90a01cd51c" am i correct? > >> > >> > >> > >> On Wed, Aug 22, 2018 at 10:46 AM, Matthew Thode > >> wrote: > >> > On 18-08-22 10:33:11, Satish Patel wrote: > >> >> Thanks Matthew, > >> >> > >> >> Can i put that sha in my OSA at > >> >> playbooks/defaults/repo_packages/openstack_services.yml by hand and > >> >> run playbooks [repo/nova] ? > >> >> > >> >> On Wed, Aug 22, 2018 at 10:24 AM, Matthew Thode > >> >> wrote: > >> >> > On 18-08-22 08:35:09, Satish Patel wrote: > >> >> >> Currently in stable/queens i am seeing this sha > >> >> >> https://github.com/openstack/openstack-ansible/blob/stable/queens/ansible-role-requirements.yml#L112 > >> >> >> > >> >> >> On Wed, Aug 22, 2018 at 2:02 AM, Matthew Thode > >> >> >> wrote: > >> >> >> > On 18-08-22 01:57:17, Satish Patel wrote: > >> >> >> >> What I need to upgrade, any specific component? > >> >> >> >> > >> >> >> >> I have deployed openstack-ansible > >> >> >> >> > >> >> >> >> Sent from my iPhone > >> >> >> >> > >> >> >> >> > On Aug 22, 2018, at 1:06 AM, Matthew Thode > >> >> >> >> > wrote: > >> >> >> >> > > >> >> >> >> >> On 18-08-22 01:02:53, Satish Patel wrote: > >> >> >> >> >> Matthew, > >> >> >> >> >> > >> >> >> >> >> Thanks for reply, Look like i don't have this patch > >> >> >> >> >> https://review.openstack.org/#/c/591761/ > >> >> >> >> >> > >> >> >> >> >> So i have to patch following 3 file manually? > >> >> >> >> >> > >> >> >> >> >> nova/tests/unit/virt/libvirt/test_driver.py213 > >> >> >> >> >> nova/tests/unit/virt/test_virt_drivers.py2 > >> >> >> >> >> nova/virt/libvirt/driver.py > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> On Wed, Aug 22, 2018 at 12:42 AM, Matthew Thode > >> >> >> >> >> wrote: > >> >> >> >> >>> On 18-08-22 00:27:08, Satish Patel wrote: > >> >> >> >> >>>> Folks, > >> >> >> >> >>>> > >> >> >> >> >>>> I am running openstack queens and hypervisor is kvm, my live > >> >> >> >> >>>> migration > >> >> >> >> >>>> working fine. but somehow it stuck to 8 Mb network speed and > >> >> >> >> >>>> taking > >> >> >> >> >>>> long time to migrate 1G instance. I have 10Gbps network and > >> >> >> >> >>>> i have > >> >> >> >> >>>> tried to copy 10G file between two compute node and it did > >> >> >> >> >>>> copy in 2 > >> >> &g
Re: [openstack-dev] [barbican][oslo][release][requirements] FFE request for castellan
On 18-08-22 23:06:36, Ade Lee wrote: > Thanks guys, > > Sorry - it was not clear to me if I was supposed to do anything > further. It seems like the requirements team has approved the FFE and > the release has merged. Is there anything further I need to do? > > Thanks, > Ade > > On Tue, 2018-08-21 at 14:16 -0500, Matthew Thode wrote: > > On 18-08-21 14:00:41, Ben Nemec wrote: > > > Because castellan is in global-requirements, we need an FFE from > > > requirements too. Can someone from the requirements team respond > > > to the > > > review? Thanks. > > > > > > On 08/16/2018 04:34 PM, Ben Nemec wrote: > > > > The backport has merged and I've proposed the release here: > > > > https://review.openstack.org/592746 > > > > > > > > On 08/15/2018 11:58 AM, Ade Lee wrote: > > > > > Done. > > > > > > > > > > https://review.openstack.org/#/c/592154/ > > > > > > > > > > Thanks, > > > > > Ade > > > > > > > > > > On Wed, 2018-08-15 at 09:20 -0500, Ben Nemec wrote: > > > > > > > > > > > > On 08/14/2018 01:56 PM, Sean McGinnis wrote: > > > > > > > > On 08/10/2018 10:15 AM, Ade Lee wrote: > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > I'd like to request a feature freeze exception to get > > > > > > > > > the > > > > > > > > > following > > > > > > > > > change in for castellan. > > > > > > > > > > > > > > > > > > https://review.openstack.org/#/c/575800/ > > > > > > > > > > > > > > > > > > This extends the functionality of the vault backend to > > > > > > > > > provide > > > > > > > > > previously uninmplemented functionality, so it should > > > > > > > > > not break > > > > > > > > > anyone. > > > > > > > > > > > > > > > > > > The castellan vault plugin is used behind barbican in > > > > > > > > > the > > > > > > > > > barbican- > > > > > > > > > vault plugin. We'd like to get this change into Rocky > > > > > > > > > so that > > > > > > > > > we can > > > > > > > > > release Barbican with complete functionality on this > > > > > > > > > backend > > > > > > > > > (along > > > > > > > > > with a complete set of passing functional tests). > > > > > > > > > > > > > > > > This does seem fairly low risk since it's just > > > > > > > > implementing a > > > > > > > > function that > > > > > > > > previously raised a NotImplemented exception. However, > > > > > > > > with it > > > > > > > > being so > > > > > > > > late in the cycle I think we need the release team's > > > > > > > > input on > > > > > > > > whether this > > > > > > > > is possible. Most of the release FFE's I've seen have > > > > > > > > been for > > > > > > > > critical > > > > > > > > bugs, not actual new features. I've added that tag to > > > > > > > > this > > > > > > > > thread so > > > > > > > > hopefully they can weigh in. > > > > > > > > > > > > > > > > > > > > > > As far as releases go, this should be fine. If this doesn't > > > > > > > affect > > > > > > > any other > > > > > > > projects and would just be a late merging feature, as long > > > > > > > as the > > > > > > > castellan > > > > > > > team has considered the risk of adding code so late and is > > > > > > > comfortable with > > > > > > > that, this is OK. > > > > > > > > > > > > > > Castellan follows the cycle-with-intermediary release > > > > > > > model, so the > > > > > > > final Rocky > > > > > > > release just needs to be done by next Thursday. I do see > > > > > > > the > > > > > > > stable/rocky > > > > > > > branch has already been created for this repo, so it would > > > > > > > need to > > > > > > > merge to > > > > > > > master first (technically stein), then get cherry-picked to > > > > > > > stable/rocky. > > > > > > > > > > > > Okay, sounds good. It's already merged to master so we're > > > > > > good > > > > > > there. > > > > > > > > > > > > Ade, can you get the backport proposed? > > > > > > > > > > I've approved it for a UC only bump > > We are still waiting on https://review.openstack.org/594541 to merge, but I already voted and noted that it was FFE approved. -- Matthew Thode (prometheanfire) 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] live_migration only using 8 Mb speed
On 18-08-22 10:58:48, Satish Patel wrote: > Matthew, > > I have two option looks like, correct me if i am wrong. > > 1. I have two option, upgrade minor release from 17.0.7-6-g9187bb1 to > 17.0.8-23-g0aff517 and upgrade full OSA > > 2. Just do override as you said "nova_git_install_branch:" in my > /etc/openstack_deploy/user_variables.yml file, and run playbooks. > > > I think option [2] is safe to just touch specific component, also am i > correct about override in /etc/openstack_deploy/user_variables.yml > file? > > You mentioned "nova_git_install_branch: > dee99b1ed03de4b6ded94f3cf6d2ea7214bca93b" but i believe it should be > "a9c9285a5a68ab89a6543d143c364d90a01cd51c" am i correct? > > > > On Wed, Aug 22, 2018 at 10:46 AM, Matthew Thode > wrote: > > On 18-08-22 10:33:11, Satish Patel wrote: > >> Thanks Matthew, > >> > >> Can i put that sha in my OSA at > >> playbooks/defaults/repo_packages/openstack_services.yml by hand and > >> run playbooks [repo/nova] ? > >> > >> On Wed, Aug 22, 2018 at 10:24 AM, Matthew Thode > >> wrote: > >> > On 18-08-22 08:35:09, Satish Patel wrote: > >> >> Currently in stable/queens i am seeing this sha > >> >> https://github.com/openstack/openstack-ansible/blob/stable/queens/ansible-role-requirements.yml#L112 > >> >> > >> >> On Wed, Aug 22, 2018 at 2:02 AM, Matthew Thode > >> >> wrote: > >> >> > On 18-08-22 01:57:17, Satish Patel wrote: > >> >> >> What I need to upgrade, any specific component? > >> >> >> > >> >> >> I have deployed openstack-ansible > >> >> >> > >> >> >> Sent from my iPhone > >> >> >> > >> >> >> > On Aug 22, 2018, at 1:06 AM, Matthew Thode > >> >> >> > wrote: > >> >> >> > > >> >> >> >> On 18-08-22 01:02:53, Satish Patel wrote: > >> >> >> >> Matthew, > >> >> >> >> > >> >> >> >> Thanks for reply, Look like i don't have this patch > >> >> >> >> https://review.openstack.org/#/c/591761/ > >> >> >> >> > >> >> >> >> So i have to patch following 3 file manually? > >> >> >> >> > >> >> >> >> nova/tests/unit/virt/libvirt/test_driver.py213 > >> >> >> >> nova/tests/unit/virt/test_virt_drivers.py2 > >> >> >> >> nova/virt/libvirt/driver.py > >> >> >> >> > >> >> >> >> > >> >> >> >> On Wed, Aug 22, 2018 at 12:42 AM, Matthew Thode > >> >> >> >> wrote: > >> >> >> >>> On 18-08-22 00:27:08, Satish Patel wrote: > >> >> >> >>>> Folks, > >> >> >> >>>> > >> >> >> >>>> I am running openstack queens and hypervisor is kvm, my live > >> >> >> >>>> migration > >> >> >> >>>> working fine. but somehow it stuck to 8 Mb network speed and > >> >> >> >>>> taking > >> >> >> >>>> long time to migrate 1G instance. I have 10Gbps network and i > >> >> >> >>>> have > >> >> >> >>>> tried to copy 10G file between two compute node and it did copy > >> >> >> >>>> in 2 > >> >> >> >>>> minute, so i am not seeing any network issue also. > >> >> >> >>>> > >> >> >> >>>> it seem live_migration has some bandwidth limit, I have tried > >> >> >> >>>> following option in nova.conf but it didn't work > >> >> >> >>>> > >> >> >> >>>> live_migration_bandwidth = 500 > >> >> >> >>>> > >> >> >> >>>> My nova.conf look like following: > >> >> >> >>>> > >> >> >> >>>> live_migration_uri = > >> >> >> >>>> "qemu+ssh://nova@%s/system?no_verify=1=/var/lib/nova/.ssh/id_rsa" > >> >> >> >>>> live_migration_tunnelled = True > >> >> >> >>>> live_migra
Re: [Openstack] live_migration only using 8 Mb speed
On 18-08-22 10:33:11, Satish Patel wrote: > Thanks Matthew, > > Can i put that sha in my OSA at > playbooks/defaults/repo_packages/openstack_services.yml by hand and > run playbooks [repo/nova] ? > > On Wed, Aug 22, 2018 at 10:24 AM, Matthew Thode > wrote: > > On 18-08-22 08:35:09, Satish Patel wrote: > >> Currently in stable/queens i am seeing this sha > >> https://github.com/openstack/openstack-ansible/blob/stable/queens/ansible-role-requirements.yml#L112 > >> > >> On Wed, Aug 22, 2018 at 2:02 AM, Matthew Thode > >> wrote: > >> > On 18-08-22 01:57:17, Satish Patel wrote: > >> >> What I need to upgrade, any specific component? > >> >> > >> >> I have deployed openstack-ansible > >> >> > >> >> Sent from my iPhone > >> >> > >> >> > On Aug 22, 2018, at 1:06 AM, Matthew Thode > >> >> > wrote: > >> >> > > >> >> >> On 18-08-22 01:02:53, Satish Patel wrote: > >> >> >> Matthew, > >> >> >> > >> >> >> Thanks for reply, Look like i don't have this patch > >> >> >> https://review.openstack.org/#/c/591761/ > >> >> >> > >> >> >> So i have to patch following 3 file manually? > >> >> >> > >> >> >> nova/tests/unit/virt/libvirt/test_driver.py213 > >> >> >> nova/tests/unit/virt/test_virt_drivers.py2 > >> >> >> nova/virt/libvirt/driver.py > >> >> >> > >> >> >> > >> >> >> On Wed, Aug 22, 2018 at 12:42 AM, Matthew Thode > >> >> >> wrote: > >> >> >>> On 18-08-22 00:27:08, Satish Patel wrote: > >> >> >>>> Folks, > >> >> >>>> > >> >> >>>> I am running openstack queens and hypervisor is kvm, my live > >> >> >>>> migration > >> >> >>>> working fine. but somehow it stuck to 8 Mb network speed and taking > >> >> >>>> long time to migrate 1G instance. I have 10Gbps network and i have > >> >> >>>> tried to copy 10G file between two compute node and it did copy in > >> >> >>>> 2 > >> >> >>>> minute, so i am not seeing any network issue also. > >> >> >>>> > >> >> >>>> it seem live_migration has some bandwidth limit, I have tried > >> >> >>>> following option in nova.conf but it didn't work > >> >> >>>> > >> >> >>>> live_migration_bandwidth = 500 > >> >> >>>> > >> >> >>>> My nova.conf look like following: > >> >> >>>> > >> >> >>>> live_migration_uri = > >> >> >>>> "qemu+ssh://nova@%s/system?no_verify=1=/var/lib/nova/.ssh/id_rsa" > >> >> >>>> live_migration_tunnelled = True > >> >> >>>> live_migration_bandwidth = 500 > >> >> >>>> hw_disk_discard = unmap > >> >> >>>> disk_cachemodes = network=writeback > >> >> >>>> > >> >> >>> > >> >> >>> Do you have a this patch (and a couple of patches up to it)? > >> >> >>> https://bugs.launchpad.net/nova/+bug/1786346 > >> >> >>> > >> >> > > >> >> > I don't know if that would cleanly apply (there are other patches that > >> >> > changed those functions within the last month and a half. It'd be > >> >> > best > >> >> > to upgrade and not do just one patch (which would be an untested > >> >> > process). > >> >> > > >> > > >> > The sha for nova has not been updated yet (next update is 24-48 hours > >> > away iirc), once that's done you can use the head of stable/queens from > >> > OSA and run a inter-series upgrade (but the minimal thing to do would be > >> > to run repo-build and os-nova plays). I'm not sure when that sha bump > >> > will be tagged in a full release if you would rather wait on that. > > > > it's this sha that needs updating. > > https://github.com/openstack/openstack-ansible/blob/stable/queens/playbooks/defaults/repo_packages/openstack_services.yml#L173 > > I'm not sure how you are doing overrides, but set the following as an override, then rerun the repo-build playbook (to rebuild the nova venv) then rerun the nova playbook to install it. nova_git_install_branch: dee99b1ed03de4b6ded94f3cf6d2ea7214bca93b -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] live_migration only using 8 Mb speed
On 18-08-22 08:35:09, Satish Patel wrote: > Currently in stable/queens i am seeing this sha > https://github.com/openstack/openstack-ansible/blob/stable/queens/ansible-role-requirements.yml#L112 > > On Wed, Aug 22, 2018 at 2:02 AM, Matthew Thode > wrote: > > On 18-08-22 01:57:17, Satish Patel wrote: > >> What I need to upgrade, any specific component? > >> > >> I have deployed openstack-ansible > >> > >> Sent from my iPhone > >> > >> > On Aug 22, 2018, at 1:06 AM, Matthew Thode > >> > wrote: > >> > > >> >> On 18-08-22 01:02:53, Satish Patel wrote: > >> >> Matthew, > >> >> > >> >> Thanks for reply, Look like i don't have this patch > >> >> https://review.openstack.org/#/c/591761/ > >> >> > >> >> So i have to patch following 3 file manually? > >> >> > >> >> nova/tests/unit/virt/libvirt/test_driver.py213 > >> >> nova/tests/unit/virt/test_virt_drivers.py2 > >> >> nova/virt/libvirt/driver.py > >> >> > >> >> > >> >> On Wed, Aug 22, 2018 at 12:42 AM, Matthew Thode > >> >> wrote: > >> >>> On 18-08-22 00:27:08, Satish Patel wrote: > >> >>>> Folks, > >> >>>> > >> >>>> I am running openstack queens and hypervisor is kvm, my live migration > >> >>>> working fine. but somehow it stuck to 8 Mb network speed and taking > >> >>>> long time to migrate 1G instance. I have 10Gbps network and i have > >> >>>> tried to copy 10G file between two compute node and it did copy in 2 > >> >>>> minute, so i am not seeing any network issue also. > >> >>>> > >> >>>> it seem live_migration has some bandwidth limit, I have tried > >> >>>> following option in nova.conf but it didn't work > >> >>>> > >> >>>> live_migration_bandwidth = 500 > >> >>>> > >> >>>> My nova.conf look like following: > >> >>>> > >> >>>> live_migration_uri = > >> >>>> "qemu+ssh://nova@%s/system?no_verify=1=/var/lib/nova/.ssh/id_rsa" > >> >>>> live_migration_tunnelled = True > >> >>>> live_migration_bandwidth = 500 > >> >>>> hw_disk_discard = unmap > >> >>>> disk_cachemodes = network=writeback > >> >>>> > >> >>> > >> >>> Do you have a this patch (and a couple of patches up to it)? > >> >>> https://bugs.launchpad.net/nova/+bug/1786346 > >> >>> > >> > > >> > I don't know if that would cleanly apply (there are other patches that > >> > changed those functions within the last month and a half. It'd be best > >> > to upgrade and not do just one patch (which would be an untested > >> > process). > >> > > > > > The sha for nova has not been updated yet (next update is 24-48 hours > > away iirc), once that's done you can use the head of stable/queens from > > OSA and run a inter-series upgrade (but the minimal thing to do would be > > to run repo-build and os-nova plays). I'm not sure when that sha bump > > will be tagged in a full release if you would rather wait on that. it's this sha that needs updating. https://github.com/openstack/openstack-ansible/blob/stable/queens/playbooks/defaults/repo_packages/openstack_services.yml#L173 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] live_migration only using 8 Mb speed
On 18-08-22 01:57:17, Satish Patel wrote: > What I need to upgrade, any specific component? > > I have deployed openstack-ansible > > Sent from my iPhone > > > On Aug 22, 2018, at 1:06 AM, Matthew Thode > > wrote: > > > >> On 18-08-22 01:02:53, Satish Patel wrote: > >> Matthew, > >> > >> Thanks for reply, Look like i don't have this patch > >> https://review.openstack.org/#/c/591761/ > >> > >> So i have to patch following 3 file manually? > >> > >> nova/tests/unit/virt/libvirt/test_driver.py213 > >> nova/tests/unit/virt/test_virt_drivers.py2 > >> nova/virt/libvirt/driver.py > >> > >> > >> On Wed, Aug 22, 2018 at 12:42 AM, Matthew Thode > >> wrote: > >>> On 18-08-22 00:27:08, Satish Patel wrote: > >>>> Folks, > >>>> > >>>> I am running openstack queens and hypervisor is kvm, my live migration > >>>> working fine. but somehow it stuck to 8 Mb network speed and taking > >>>> long time to migrate 1G instance. I have 10Gbps network and i have > >>>> tried to copy 10G file between two compute node and it did copy in 2 > >>>> minute, so i am not seeing any network issue also. > >>>> > >>>> it seem live_migration has some bandwidth limit, I have tried > >>>> following option in nova.conf but it didn't work > >>>> > >>>> live_migration_bandwidth = 500 > >>>> > >>>> My nova.conf look like following: > >>>> > >>>> live_migration_uri = > >>>> "qemu+ssh://nova@%s/system?no_verify=1=/var/lib/nova/.ssh/id_rsa" > >>>> live_migration_tunnelled = True > >>>> live_migration_bandwidth = 500 > >>>> hw_disk_discard = unmap > >>>> disk_cachemodes = network=writeback > >>>> > >>> > >>> Do you have a this patch (and a couple of patches up to it)? > >>> https://bugs.launchpad.net/nova/+bug/1786346 > >>> > > > > I don't know if that would cleanly apply (there are other patches that > > changed those functions within the last month and a half. It'd be best > > to upgrade and not do just one patch (which would be an untested > > process). > > The sha for nova has not been updated yet (next update is 24-48 hours away iirc), once that's done you can use the head of stable/queens from OSA and run a inter-series upgrade (but the minimal thing to do would be to run repo-build and os-nova plays). I'm not sure when that sha bump will be tagged in a full release if you would rather wait on that. -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] live_migration only using 8 Mb speed
On 18-08-22 01:02:53, Satish Patel wrote: > Matthew, > > Thanks for reply, Look like i don't have this patch > https://review.openstack.org/#/c/591761/ > > So i have to patch following 3 file manually? > > nova/tests/unit/virt/libvirt/test_driver.py213 > nova/tests/unit/virt/test_virt_drivers.py2 > nova/virt/libvirt/driver.py > > > On Wed, Aug 22, 2018 at 12:42 AM, Matthew Thode > wrote: > > On 18-08-22 00:27:08, Satish Patel wrote: > >> Folks, > >> > >> I am running openstack queens and hypervisor is kvm, my live migration > >> working fine. but somehow it stuck to 8 Mb network speed and taking > >> long time to migrate 1G instance. I have 10Gbps network and i have > >> tried to copy 10G file between two compute node and it did copy in 2 > >> minute, so i am not seeing any network issue also. > >> > >> it seem live_migration has some bandwidth limit, I have tried > >> following option in nova.conf but it didn't work > >> > >> live_migration_bandwidth = 500 > >> > >> My nova.conf look like following: > >> > >> live_migration_uri = > >> "qemu+ssh://nova@%s/system?no_verify=1=/var/lib/nova/.ssh/id_rsa" > >> live_migration_tunnelled = True > >> live_migration_bandwidth = 500 > >> hw_disk_discard = unmap > >> disk_cachemodes = network=writeback > >> > > > > Do you have a this patch (and a couple of patches up to it)? > > https://bugs.launchpad.net/nova/+bug/1786346 > > I don't know if that would cleanly apply (there are other patches that changed those functions within the last month and a half. It'd be best to upgrade and not do just one patch (which would be an untested process). -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack] live_migration only using 8 Mb speed
On 18-08-22 00:27:08, Satish Patel wrote: > Folks, > > I am running openstack queens and hypervisor is kvm, my live migration > working fine. but somehow it stuck to 8 Mb network speed and taking > long time to migrate 1G instance. I have 10Gbps network and i have > tried to copy 10G file between two compute node and it did copy in 2 > minute, so i am not seeing any network issue also. > > it seem live_migration has some bandwidth limit, I have tried > following option in nova.conf but it didn't work > > live_migration_bandwidth = 500 > > My nova.conf look like following: > > live_migration_uri = > "qemu+ssh://nova@%s/system?no_verify=1=/var/lib/nova/.ssh/id_rsa" > live_migration_tunnelled = True > live_migration_bandwidth = 500 > hw_disk_discard = unmap > disk_cachemodes = network=writeback > Do you have a this patch (and a couple of patches up to it)? https://bugs.launchpad.net/nova/+bug/1786346 -- Matthew Thode (prometheanfire) signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [barbican][oslo][release][requirements] FFE request for castellan
On 18-08-21 14:00:41, Ben Nemec wrote: > Because castellan is in global-requirements, we need an FFE from > requirements too. Can someone from the requirements team respond to the > review? Thanks. > > On 08/16/2018 04:34 PM, Ben Nemec wrote: > > The backport has merged and I've proposed the release here: > > https://review.openstack.org/592746 > > > > On 08/15/2018 11:58 AM, Ade Lee wrote: > > > Done. > > > > > > https://review.openstack.org/#/c/592154/ > > > > > > Thanks, > > > Ade > > > > > > On Wed, 2018-08-15 at 09:20 -0500, Ben Nemec wrote: > > > > > > > > On 08/14/2018 01:56 PM, Sean McGinnis wrote: > > > > > > On 08/10/2018 10:15 AM, Ade Lee wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > I'd like to request a feature freeze exception to get the > > > > > > > following > > > > > > > change in for castellan. > > > > > > > > > > > > > > https://review.openstack.org/#/c/575800/ > > > > > > > > > > > > > > This extends the functionality of the vault backend to provide > > > > > > > previously uninmplemented functionality, so it should not break > > > > > > > anyone. > > > > > > > > > > > > > > The castellan vault plugin is used behind barbican in the > > > > > > > barbican- > > > > > > > vault plugin. We'd like to get this change into Rocky so that > > > > > > > we can > > > > > > > release Barbican with complete functionality on this backend > > > > > > > (along > > > > > > > with a complete set of passing functional tests). > > > > > > > > > > > > This does seem fairly low risk since it's just implementing a > > > > > > function that > > > > > > previously raised a NotImplemented exception. However, with it > > > > > > being so > > > > > > late in the cycle I think we need the release team's input on > > > > > > whether this > > > > > > is possible. Most of the release FFE's I've seen have been for > > > > > > critical > > > > > > bugs, not actual new features. I've added that tag to this > > > > > > thread so > > > > > > hopefully they can weigh in. > > > > > > > > > > > > > > > > As far as releases go, this should be fine. If this doesn't affect > > > > > any other > > > > > projects and would just be a late merging feature, as long as the > > > > > castellan > > > > > team has considered the risk of adding code so late and is > > > > > comfortable with > > > > > that, this is OK. > > > > > > > > > > Castellan follows the cycle-with-intermediary release model, so the > > > > > final Rocky > > > > > release just needs to be done by next Thursday. I do see the > > > > > stable/rocky > > > > > branch has already been created for this repo, so it would need to > > > > > merge to > > > > > master first (technically stein), then get cherry-picked to > > > > > stable/rocky. > > > > > > > > Okay, sounds good. It's already merged to master so we're good > > > > there. > > > > > > > > Ade, can you get the backport proposed? > > > > I've approved it for a UC only bump -- Matthew Thode (prometheanfire) 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
[openstack-dev] [requirements] moved to [storyboard]
We've moved, please forward future correspondence to the following location. https://storyboard.openstack.org/#!/project/openstack/requirements -- Matthew Thode (prometheanfire) 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] [releases][requirements][cycle-with-intermediary][cycle-trailing] requirements is going to branch stable/rocky at ~08-15-2018 2100Z
On 18-08-14 11:13:13, Matthew Thode wrote: > This is to warn and call out all those projects that do not have a > stable/rocky branch yet. > > If you are in the folloing list your project will need to realize that > your master is testing against the requirements/constraints from stein, > not rocky. Any branching / tests you do will need to keep that in mind. > > ansible-role-container-registry > ansible-role-redhat-subscription > ansible-role-tripleo-modify-image > barbican-tempest-plugin > blazar-tempest-plugin > cinder-tempest-plugin > cloudkitty-dashboard > cloudkitty-tempest-plugin > cloudkitty > congress-tempest-plugin > designate-tempest-plugin > ec2api-tempest-plugin > heat-agents > heat-dashboard > heat-tempest-plugin > instack-undercloud > ironic-tempest-plugin > karbor-dashboard > karbor > keystone-tempest-plugin > kuryr-kubernetes > kuryr-libnetwork > kuryr-tempest-plugin > magnum-tempest-plugin > magnum-ui > manila-tempest-plugin > mistral-tempest-plugin > monasca-kibana-plugin > monasca-tempest-plugin > murano-tempest-plugin > networking-generic-switch-tempest-plugin > networking-hyperv > neutron-tempest-plugin > octavia-tempest-plugin > os-apply-config > os-collect-config > os-net-config > os-refresh-config > oswin-tempest-plugin > paunch > python-tricircleclient > sahara-tests > senlin-tempest-plugin > solum-tempest-plugin > swift > tacker-horizon > tacker > telemetry-tempest-plugin > tempest-tripleo-ui > tempest > tripleo-common-tempest-plugin > tripleo-ipsec > tripleo-ui > tripleo-validations > trove-tempest-plugin > vitrage-tempest-plugin > watcher-tempest-plugin > zaqar-tempest-plugin > zun-tempest-plugin > zun-ui > zun > > kolla-ansible > kolla > puppet-aodh > puppet-barbican > puppet-ceilometer > puppet-cinder > puppet-cloudkitty > puppet-congress > puppet-designate > puppet-ec2api > puppet-freezer > puppet-glance > puppet-glare > puppet-gnocchi > puppet-heat > puppet-horizon > puppet-ironic > puppet-keystone > puppet-magnum > puppet-manila > puppet-mistral > puppet-monasca > puppet-murano > puppet-neutron > puppet-nova > puppet-octavia > puppet-openstack_extras > puppet-openstacklib > puppet-oslo > puppet-ovn > puppet-panko > puppet-qdr > puppet-rally > puppet-sahara > puppet-swift > puppet-tacker > puppet-tempest > puppet-tripleo > puppet-trove > puppet-vitrage > puppet-vswitch > puppet-watcher > puppet-zaqar > python-tripleoclient > tripleo-common > tripleo-heat-templates > tripleo-image-elements > tripleo-puppet-elements > > So please branch :D > we branched, also we are working on migrating to storyboard -- Matthew Thode (prometheanfire) 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
[openstack-dev] [releases][requirements][cycle-with-intermediary][cycle-trailing] requirements is going to branch stable/rocky at ~08-15-2018 2100Z
This is to warn and call out all those projects that do not have a stable/rocky branch yet. If you are in the folloing list your project will need to realize that your master is testing against the requirements/constraints from stein, not rocky. Any branching / tests you do will need to keep that in mind. ansible-role-container-registry ansible-role-redhat-subscription ansible-role-tripleo-modify-image barbican-tempest-plugin blazar-tempest-plugin cinder-tempest-plugin cloudkitty-dashboard cloudkitty-tempest-plugin cloudkitty congress-tempest-plugin designate-tempest-plugin ec2api-tempest-plugin heat-agents heat-dashboard heat-tempest-plugin instack-undercloud ironic-tempest-plugin karbor-dashboard karbor keystone-tempest-plugin kuryr-kubernetes kuryr-libnetwork kuryr-tempest-plugin magnum-tempest-plugin magnum-ui manila-tempest-plugin mistral-tempest-plugin monasca-kibana-plugin monasca-tempest-plugin murano-tempest-plugin networking-generic-switch-tempest-plugin networking-hyperv neutron-tempest-plugin octavia-tempest-plugin os-apply-config os-collect-config os-net-config os-refresh-config oswin-tempest-plugin paunch python-tricircleclient sahara-tests senlin-tempest-plugin solum-tempest-plugin swift tacker-horizon tacker telemetry-tempest-plugin tempest-tripleo-ui tempest tripleo-common-tempest-plugin tripleo-ipsec tripleo-ui tripleo-validations trove-tempest-plugin vitrage-tempest-plugin watcher-tempest-plugin zaqar-tempest-plugin zun-tempest-plugin zun-ui zun kolla-ansible kolla puppet-aodh puppet-barbican puppet-ceilometer puppet-cinder puppet-cloudkitty puppet-congress puppet-designate puppet-ec2api puppet-freezer puppet-glance puppet-glare puppet-gnocchi puppet-heat puppet-horizon puppet-ironic puppet-keystone puppet-magnum puppet-manila puppet-mistral puppet-monasca puppet-murano puppet-neutron puppet-nova puppet-octavia puppet-openstack_extras puppet-openstacklib puppet-oslo puppet-ovn puppet-panko puppet-qdr puppet-rally puppet-sahara puppet-swift puppet-tacker puppet-tempest puppet-tripleo puppet-trove puppet-vitrage puppet-vswitch puppet-watcher puppet-zaqar python-tripleoclient tripleo-common tripleo-heat-templates tripleo-image-elements tripleo-puppet-elements So please branch :D -- Matthew Thode (prometheanfire) 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][release][osc] FFE osc-lib 1.11.1 release
On 18-08-14 13:56:28, Akihiro Motoki wrote: > 2018年8月14日(火) 13:38 Matthew Thode : > > > > On 18-08-14 13:19:27, Akihiro Motoki wrote: > > > Hi, > > > > > > I would like to request FFE for osc-lib 1.11.1 release. > > > > > > https://review.openstack.org/591556 > > > > > > osc-iib commit e3d772050f3f4de6369b3dd1ba1269e2903666f7 replaced > > > issubclass() with isinstance() unexpectedly. > > > As a result, osc-lib 1.11.0 breaks existing OSC plugins and > > > the neutronclient OSC plugin gate is now broken. > > > To fix the gate, osc-lib 1.11.1 release would be appreciated. > > > > > > upper-constraints is bumped to osc-lib 1.11.1. > > > It is better to block osc-lib 1.11.0 but I am familiar whether we need > > > to block it or not. > > > > > > > What libs (further down the dep tree) would need the exclusion? They'd > > likely also need a FFE for at least a UC bump. > > You have my (and requirements) ack for a UC only bump at least. > > AFAIK all OSC plugins and OSC directly consume osc-lib and there is no > libs to consume osc-lib. > In this case, we don't need to block a specific version of osc-lib, right? > Perhaps it is just because I don't understand the current policy well. > > From neutronclient and other OSC plugin perspective, it is fine to bump UC > only. > The current list is the following. ++-+--+---+ | Repository | Filename | Line | Text | ++-+--+---+ | openstack-zuul-jobs| playbooks/legacy/requirements-integration-dsvm/run.yaml | 76 | export PROJECTS="openstack/osc-lib $PROJECTS" | | openstack-zuul-jobs| playbooks/legacy/requirements-integration-dsvm-ubuntu-trusty/run.yaml | 77 | export PROJECTS="openstack/osc-lib $PROJECTS" | | osc-placement | requirements.txt |8 | osc-lib>=1.2.0 # Apache-2.0 | | osops-tools-contrib| ansible_requirements.txt | 31 | osc-lib==1.1.0 | | python-adjutantclient | requirements.txt |9 | osc-lib>=1.5.1 # Apache-2.0 | | python-aodhclient | requirements.txt |7 | osc-lib>=1.0.1 # Apache-2.0 | | python-cyborgclient| requirements.txt | 16 | osc-lib>=1.8.0 # Apache-2.0 | | python-designateclient | requirements.txt |6 | osc-lib>=1.8.0 # Apache-2.0 | | python-distilclient| requirements.txt |4 | osc-lib>=1.7.0 # Apache-2.0 | | python-glareclient | requirements.txt | 13 | osc-lib>=1.7.0 # Apache-2.0 | | python-heatclient | requirements.txt |9 | osc-lib>=1.8.0 # Apache-2.0 | | python-iotronicclient | requirements.txt |9 | osc-lib>=1.2.0 # Apache-2.0 | | python-ironic-inspector-client | requirements.txt |5 | osc-lib>=1.8.0 # Apache-2.0 | | python-ironicclient| requirements.txt |9 | osc-lib>=1.10.0 # Apache-2.0 | | python-karborclient| requirements.txt
Re: [openstack-dev] [requirements][release][osc] FFE osc-lib 1.11.1 release
On 18-08-14 13:19:27, Akihiro Motoki wrote: > Hi, > > I would like to request FFE for osc-lib 1.11.1 release. > > https://review.openstack.org/591556 > > osc-iib commit e3d772050f3f4de6369b3dd1ba1269e2903666f7 replaced > issubclass() with isinstance() unexpectedly. > As a result, osc-lib 1.11.0 breaks existing OSC plugins and > the neutronclient OSC plugin gate is now broken. > To fix the gate, osc-lib 1.11.1 release would be appreciated. > > upper-constraints is bumped to osc-lib 1.11.1. > It is better to block osc-lib 1.11.0 but I am familiar whether we need > to block it or not. > What libs (further down the dep tree) would need the exclusion? They'd likely also need a FFE for at least a UC bump. You have my (and requirements) ack for a UC only bump at least. -- Matthew Thode (prometheanfire) 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][heat][congress] gabbi<1.42.1 causing error in queens dsvm
On 18-08-13 16:10:30, Eric K wrote: > It appears that gabbi<1.42.1 is causing on error with heat tempest > plugin in congress stable/queens dsvm job [1][2][3]. The issue was > addressed in heat tempest plugin [4], but the problem remains for > stable/queens jobs because the queens upper-constraint is still at > 1.40.0 [5]. > > Any suggestions on how to proceed? Thank you! > > [1] https://bugs.launchpad.net/heat-tempest-plugin/+bug/1749218 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1609361 > [3] > http://logs.openstack.org/41/567941/2/check/congress-devstack-api-mysql/c232d8a/job-output.txt.gz#_2018-08-13_11_46_28_441837 > [4] https://review.openstack.org/#/c/544025/ > [5] > https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L245 > iirc, a UC bump is allowed if it fixes gating, so that's alright by me (reqs) -- Matthew Thode (prometheanfire) 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][release][docs] FFE for openstackdocstheme 1.21.2
On 18-08-13 20:28:23, Andreas Jaeger wrote: > On 2018-08-13 19:16, Andreas Jaeger wrote: > > On 2018-08-13 18:40, Petr Kovar wrote: > > > Hi all, > > > > > > This is a request for an FFE to release openstackdocstheme 1.21.2. > > > > > > > This mostly fixes usability issues in rendering docs content, so we would > > > like to update the theme across all project team docs on docs.o.o. > > > > I suggest to release quickly a 1.21.3 with > > https://review.openstack.org/#/c/585517/ - and use that one instead. > > Release request: > https://review.openstack.org/591485 > Would this be a upper-constraint only bump? If so reqs acks it -- Matthew Thode (prometheanfire) 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][tricircle] FFE for python-tricircleclient
On 18-08-10 11:20:13, Sean McGinnis wrote: > This is a requirements FFE to raise the upper-constraints for > python-tricircleclient. > > This client only has some requirements and CI changes merged, but it has not > > done any releases during the rocky cycle. It is well past client lib freeze, > > but as stated in our policy, we will need to force a final release so there > is > a rocky version and these requirements and CI changes are in the stable/rocky > > branch of the repo. > > requirements FFE approved for UC only. -- Matthew Thode (prometheanfire) 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][karbor] FFE for python-karborclient
On 18-08-10 11:18:33, Sean McGinnis wrote: > This is requesting a requirements FFE to raise u-c for python-karborclient. > > This client only has some requirements and CI changes merged, but it has not > done any releases during the rocky cycle. It is well past client lib freeze, > but as stated in our policy, we will need to force a final release so there is > a rocky version and these requirements and CI changes are in the stable/rocky > branch of the repo. > > There is one caveat with this release in that the karbor service has not done > a > release for rocky yet. If one is not done by the final cycle-with-intermediary > deadline, karbor will need to be excluded from the Rocky coordinated release. > This would include service and clients. > requirements FFE approved for UC only. -- Matthew Thode (prometheanfire) 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][ffe] FFE for python-designateclient 2.10.0
On 18-08-10 16:28:00, Graham Hayes wrote: > Hi all, > > I would like to ask for a FFE to release python-designateclient 2.10.0 > [1] > > We did not do a release at all during the rocky cycle, and this allows > us to create a stable/rocky branch > > It just requires a U-C bump, and contains a few bug fixes from 2.9.0. > > Thanks, > > Graham > > 1 - https://review.openstack.org/590776 > As discussed during the releases meeting, ack from reqs -- Matthew Thode (prometheanfire) 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][release][congress] FFE request to bump python-monascaclient to 1.12.1
On 18-08-08 18:00:35, Eric K wrote: > Requesting the raised minimun just for openstack/congress. > https://review.openstack.org/#/c/590021/ > > No re-release required; it'll just take effect in RC1. > > > > On 8/8/18, 2:06 PM, "Matthew Thode" wrote: > > >On 18-08-08 13:14:08, Eric K wrote: > >> python-monascaclient 1.12.0 paired with osc-lib 1.11.0 seems to > >> experience a problem around Session. > >> > >> python-monascaclient 1.12.1 fixes the issue [1]. So I'd like to bump > >> congress requirements to python-monascaclient>=1.12.1 if it is not > >> disruptive to packaging [2]. If it is disruptive, we can just note it > >> as a known issue. > > > >Which project(s) will need the new minimum? Those projects would need > >re-releases. Then my question then becomes if those projects need a > >raised minumum too, and for which project(s). And so on. > > SGTM then, ack by requirements -- Matthew Thode (prometheanfire) 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][release][congress] FFE request to bump doc req sphinx to 1.7.3
On 18-08-08 18:00:14, Eric K wrote: > Requesting the raised minimun just for openstack/congress. > https://review.openstack.org/#/c/589995/ > > No re-release required; it'll just take effect in RC1. > > On 8/8/18, 2:07 PM, "Matthew Thode" wrote: > > >On 18-08-08 13:20:47, Eric K wrote: > >> Lower versions of sphinx seems to experience a problem where the > >> exclude_patterns option is not in effect. I'd like to bump the > >> docs/requirements to sphinx>=1.7.3 if it is not disruptive to > >> packaging. If it is disruptive to packaging we can leave it as is. > >> > >> Thanks! > >> > >> https://review.openstack.org/#/c/589995/ > >> > > > >Which project(s) will need the new minimum? Those projects would need > >re-releases. Then my question then becomes if those projects need a > >raised minumum too, and for which project(s). And so on. > > ack from requirements then -- Matthew Thode (prometheanfire) 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][release][congress] FFE request to bump doc req sphinx to 1.7.3
On 18-08-08 13:20:47, Eric K wrote: > Lower versions of sphinx seems to experience a problem where the > exclude_patterns option is not in effect. I'd like to bump the > docs/requirements to sphinx>=1.7.3 if it is not disruptive to > packaging. If it is disruptive to packaging we can leave it as is. > > Thanks! > > https://review.openstack.org/#/c/589995/ > Which project(s) will need the new minimum? Those projects would need re-releases. Then my question then becomes if those projects need a raised minumum too, and for which project(s). And so on. -- Matthew Thode (prometheanfire) 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][release][congress] FFE request to bump python-monascaclient to 1.12.1
On 18-08-08 13:14:08, Eric K wrote: > python-monascaclient 1.12.0 paired with osc-lib 1.11.0 seems to > experience a problem around Session. > > python-monascaclient 1.12.1 fixes the issue [1]. So I'd like to bump > congress requirements to python-monascaclient>=1.12.1 if it is not > disruptive to packaging [2]. If it is disruptive, we can just note it > as a known issue. Which project(s) will need the new minimum? Those projects would need re-releases. Then my question then becomes if those projects need a raised minumum too, and for which project(s). And so on. -- Matthew Thode (prometheanfire) 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] [release] FFE for python-cloudkittyclient 2.0.0
On 18-08-08 17:57:32, Christophe Sauthier wrote: > > > Le 2018-08-08 17:44, Matthew Thode a écrit : > > On 18-08-08 16:49:51, Christophe Sauthier wrote: > > > Hello all > > > > > > I'd like to ask for a FFE to release for python-cloudkittyclient > > > 2.0.0 > > > > > > The review is located here : > > > > > > Since it is the first time we are asking for such thing so please do > > > not > > > hesitate to point me if I am not doing things right. > > > > Will you require a bump to the minimum version required in requirements > > files? > > We can do a bump since only the cloudkitty-dashboard depends on the client. > SGTM then, ack from reqs -- Matthew Thode (prometheanfire) 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] [release] FFE for python-cloudkittyclient 2.0.0
On 18-08-08 16:49:51, Christophe Sauthier wrote: > Hello all > > I'd like to ask for a FFE to release for python-cloudkittyclient 2.0.0 > > The review is located here : > > Since it is the first time we are asking for such thing so please do not > hesitate to point me if I am not doing things right. Will you require a bump to the minimum version required in requirements files? -- Matthew Thode (prometheanfire) 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] 答复: Re: [python-senlinclient][release][requirements]FFE for python-senlinclient 1.8.0
On 18-08-08 19:05:50, liu.xuefe...@zte.com.cn wrote: > Yes, just need upper-constraints raised for this. > > On Tue, Aug 07, 2018 at 03:25:39PM -0500, Sean McGinnis wrote: > > Added requirements tag to the subject since this is a requirements FFE. > > > > On Tue, Aug 07, 2018 at 11:44:04PM +0800, liu.xuefe...@zte.com.cn wrote: > > > hi, all > > > > > > > > > I'd like to request an FFE to release 1.8.0(stable/rocky) > > > for python-senlinclient. > > > > > > The CURRENT_API_VERSION has been changed to "1.10", we need this release. > > > > > XueFeng, do you just need upper-constraints raised for this, or also the > minimum version? From that last sentence, I'm assuming you need to ensure only > 1.8.0 is used for Rocky deployments. > OK, if it's JUST upper-constraints that needs to change then FFE approved by requirements. -- Matthew Thode (prometheanfire) 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] PTG Denver Horns
On 18-08-07 23:18:26, David Medberry wrote: > Requests have finally been made (today, August 7, 2018) to end the horns on > the train from Denver to Denver International airport (within the city > limits of Denver.) Prior approval had been given to remove the FLAGGERS > that were stationed at each crossing intersection. > > Of particular note (at the bottom of the article): > > There’s no estimate for how long it could take the FRA to approve quiet > zones. > > ref: > https://www.9news.com/article/news/local/next/denver-officially-asks-fra-for-permission-to-quiet-a-line-horns/73-581499094 > > I'd recommend bringing your sleeping aids, ear plugs, etc, just in case not > approved by next month's PTG. (The Renaissance is within Denver proper as > near as I can tell so that nearby intersection should be covered by this > ruling/decision if and when it comes down.) > Thanks for the update, if you are up to it, keeping us informed on this would be nice, if only for the hilarity. -- Matthew Thode (prometheanfire) 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][sdk][release] FFE request for os-service-types
On 18-08-07 18:19:35, Monty Taylor wrote: > Heya! > > I'd like to request a FFE for os-service-types to release 1.3.0. > > The main change is the inclusion of the qinling data from > service-types-authority, as well as the addition of an alias for magnum. > > There are also two minor changes to the python portion - a parameter was > added to get_service_type allowing for a more permissive approach to unknown > service - and the library now handles life correctly if a service type is > requested with the incorrect number of _'s and -'s. > > Nothing should need a lower bounds bump - only the normal U-C bump. > ack'd -- Matthew Thode (prometheanfire) 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][release] FFE for openstacksdk 0.17.2
On 18-08-07 07:35:55, Monty Taylor wrote: > Hey all, > > I'd like to request an FFE to release 0.17.2 of openstacksdk from > stable/rocky. > > Infra discovered an issue that affects the production nodepool related to > the multi-threaded TaskManager and exception propagation. When it gets > triggered, we lose an entire cloud of capacity (whoops) until we restart the > associated nodepool-launcher process. > > Nothing in OpenStack uses the particular feature in openstacksdk in question > (yet), so nobody should need to even bump constraints. > Well, considering constraints is the minimum you can ask for an FFE for, we'll go with that :P FFE approved -- Matthew Thode (prometheanfire) 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] [release][requirements][python-magnumclient] Magnumclient FFE
On 18-08-06 21:37:12, Spyros Trigazis wrote: > It is constraints only. There is no project > that requires the new version. > > Spyros > > On Mon, 6 Aug 2018, 19:36 Matthew Thode, wrote: > > > On 18-08-06 18:34:42, Spyros Trigazis wrote: > > > Hello, > > > > > > I have requested a release for python-magnumclient [0]. > > > Per Doug Hellmann's comment in [0], I am requesting a FFE for > > > python-magnumclient. > > > > > > > My question to you is if this needs to be a constraints only thing or if > > there is some project that REQUIRES this new version to work (in which > > case that project needs to update it's exclusions or minumum). > > Has my ack then -- Matthew Thode (prometheanfire) 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] [release][requirements][python-magnumclient] Magnumclient FFE
On 18-08-06 18:34:42, Spyros Trigazis wrote: > Hello, > > I have requested a release for python-magnumclient [0]. > Per Doug Hellmann's comment in [0], I am requesting a FFE for > python-magnumclient. > My question to you is if this needs to be a constraints only thing or if there is some project that REQUIRES this new version to work (in which case that project needs to update it's exclusions or minumum). -- Matthew Thode (prometheanfire) 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][ffe] Critical bug found in python-cinderclient
On 18-07-31 15:50:42, Doug Hellmann wrote: > Excerpts from Sean McGinnis's message of 2018-07-31 14:15:08 -0500: > > A critical bug has been found in python-cinderclient that is impacting both > > horizon and python-openstackclient (at least). > > > > https://bugs.launchpad.net/cinder/+bug/1784703 > > > > tl;dr is, something new was added with a microversion, but support for that > > was > > done incorrectly such that nothing less than that new microversion would be > > allowed. This patch addresses the issue: > > > > https://review.openstack.org/587601 > > > > Once that lands we will need a new python-cinderclient release to unbreak > > clients. We may want to blacklist python-cinderclient 4.0.0, but I think at > > least just raising the upper-constraints should get things working again. > > > > Sean > > > > Both adding the exclusion and changing the upper constraint makes sense, > since it will ensure that bad version never makes it back into the > constraints list. > > We don't need to sync the exclusion setting into all of the projects > that depend on the client, so we won't need a new release of any of the > downstream consumers. > > We could add the exclusion to OSC on master, just for accuracy's sake. > Ya, it sounds like this is a valid FFE -- Matthew Thode (prometheanfire) 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
[openstack-dev] [ptg][requiremets] - Stein Etherpad
https://etherpad.openstack.org/p/stein-PTG-requirements That is all -- Matthew Thode (prometheanfire) 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][ffe] glance_store 0.26.1 (to be released)
On 18-07-31 16:43:00, Erno Kuvaja wrote: > Hi all, > > We found a critical bug on glance_store release 0.26.0 (the final > release for Rocky) preventing us to consume the multihash work for > Glance Rocky release. > > We would like to include https://review.openstack.org/#/c/587098 > containing the missing wrappers for the feature to work. And have > requirement bump to 0.26.1 (once tagged) for Rocky release. The change > is well isolated and self contained, not affecting the behavior apart > from the consumption of the multihash feature. > Looks fine, you may consider bumping the min defined in downstream consumers but lgtm otherwise. ++--+--+---+ | Repository | Filename | Line | Text | ++--+--+---+ | glance | requirements.txt | 49 | glance-store>=0.22.0 # Apache-2.0 | | glare | requirements.txt | 50 | glance-store>=0.22.0 # Apache-2.0 | | upstream-institute-virtual-environment | elements/upstream-training/static/tmp/requirements.txt | 64 | glance-store==0.22.0 | ++--+--+-------+ -- Matthew Thode (prometheanfire) 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] [FFE][requirements] Bump ansible-runner u-c to 1.0.5
On 18-07-31 17:30:02, Jakub Libosvar wrote: > Hi all, > > I want to ask for FFE at this time to bump upper-constraint version of > ansible-runner library from 1.0.4 to 1.0.5. > > Reason: ansible-runner 1.0.4 has an issue when running with currently > used eventlet version because of missing select.poll() in eventlet [1]. > The fix [2] is present in 1.0.5 ansible-runner version. > > Impact: networking-ansible project uses Neutron project and > ansible-runner together and Neutron monkey patches code with eventlet. > This fails all operations at networking-ansible. > > Statement: networking-ansible is the only project using ansible-runner > in OpenStack world [3] so if we release Rocky with 1.0.4, the only > project using it becomes useless. Bumping the version at this later > stage will not affect any other project beside networking-ansible. > > [1] https://github.com/ansible/ansible-runner/issues/90 > [2] > https://github.com/ansible/ansible-runner/commit/5608e786eb96408658604e75ef3db3c9a6b39308 > [3] http://codesearch.openstack.org/?q=ansible-runner=nope== Looks good, you may want to update the minimum in networking-ansible, but lgtm otherwise. | networking-ansible | requirements.txt |5 | ansible-runner>=1.0.3 # Apache-2.0 | -- Matthew Thode (prometheanfire) 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][release] FFE for openstacksdk 0.17.1
On 18-07-30 08:33:32, Monty Taylor wrote: > Heya, > > I'd like to request a FFE to release 0.17.1 of openstacksdk from > stable/rocky. The current rocky release, 0.17.0, added a feature (being able > to pass data directly to an object upload rather that requiring a file or > file-like object) - but it is broken if you pass an interator because it > (senselessly) tries to run len() on the data parameter. > > The new feature is not used anywhere in OpenStack yet. The first consumer > (and requestor of the feature) is Infra, who are looking at using it as part > of our efforts to start uploading build log files to swift. > > We should not need a g-r bump - since nothing in OpenStack uses the feature > yet, none of the OpenStack projects need their depends changed. OTOH, > openstacksdk is a thing we expect end-users to use, and once they see the > shiny new feature they might use it - and then be sad that it's half broken. > As long as it's only a UC bump you have my ack. -- Matthew Thode (prometheanfire) 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][release] FFE for os-vif 1.11.1
On 18-07-26 10:43:05, melanie witt wrote: > Hello, > > I'd like to ask for an exception to add os-vif 1.11.1 to stable/rocky. The > current release for rocky, 1.11.0, added a new feature: the NoOp Plugin, but > it's not actually usable (it's not being loaded) because we missed adding a > file to the setup.cfg. > > We have fixed the problem in a one liner add to setup.cfg [1] and we would > like to be able to do another release 1.11.1 for rocky to include this fix. > That way, the NoOp Plugin feature advertised in the release notes [2] for > rocky would be usable for consumers. > > [1] https://review.openstack.org/585530 > [2] > https://docs.openstack.org/releasenotes/os-vif/unreleased.html#relnotes-1-11-0 > Yep, we talked about it in the release channel. +++--++ | Repository | Filename | Line | Text | +++--++ | kuryr-kubernetes | requirements.txt | 18 | os-vif!=1.8.0,>=1.7.0 # Apache-2.0 | | nova | requirements.txt | 59 | os-vif!=1.8.0,>=1.7.0 # Apache-2.0 | | nova-lxd | requirements.txt |7 | os-vif!=1.8.0,>=1.9.0 # Apache-2.0 | | networking-bigswitch | requirements.txt |6 | os-vif>=1.1.0 # Apache-2.0 | | networking-bigswitch | test-requirements.txt | 25 | os-vif>=1.1.0 # Apache-2.0 | | networking-midonet | test-requirements.txt | 40 | os-vif!=1.8.0,>=1.7.0 # Apache-2.0 | +++--++ All these projects would need re-releases if you plan on raising the minimum. They would also need reviews submitted individually for that. A upper-constraint only fix would not need that, but would also still allow consumers to encounter the bug, up to you to decide. LGTM otherwise. -- Matthew Thode (prometheanfire) 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
[openstack-dev] [Requirements][PTL][Election] Nomination of Matthew Thode (prometheanfire) for PTL of the Requirements project
I would like to announce my candidacy for PTL of the Requirements project for the Stein cycle. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible (stuff like eventlet). 3. Publish constraints and requirements to streamline the freeze process. https://bugs.launchpad.net/openstack-requirements/+bug/1719006 is the bug tracking the publish job. 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. 5. Find more cores to smooth out the review process. I look forward to continue working with you in this cycle, as your PTL or not. -- Matthew Thode (prometheanfire) 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
[openstack-announce] [OSSA-2018-002] GET /v3/OS-FEDERATION/projects leaks project information (CVE-2018-14432)
=== OSSA-2018-002: GET /v3/OS-FEDERATION/projects leaks project information === :Date: July 25, 2018 :CVE: CVE-2018-14432 Affects ~~~ - Keystone: <11.0.4, ==12.0.0, ==13.0.0 Description ~~~ Kristi Nikolla with Boston University reported a vulnerability in Keystone federation. By doing GET /v3/OS-FEDERATION/projects an authenticated user may discover projects they have no authority to access, leaking all projects in the deployment and their attributes. Only Keystone with the /v3/OS-FEDERATION endpoint enabled via policy.json is affected. Patches ~~~ - https://review.openstack.org/585802 (Ocata) - https://review.openstack.org/585792 (Pike) - https://review.openstack.org/585788 (Queens) - https://review.openstack.org/585782 (Rocky) Credits ~~~ - Kristi Nikolla from Boston University (CVE-2018-14432) References ~~ - https://launchpad.net/bugs/1779205 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14432 signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[Openstack] [OSSA-2018-002] GET /v3/OS-FEDERATION/projects leaks project information (CVE-2018-14432)
=== OSSA-2018-002: GET /v3/OS-FEDERATION/projects leaks project information === :Date: July 25, 2018 :CVE: CVE-2018-14432 Affects ~~~ - Keystone: <11.0.4, ==12.0.0, ==13.0.0 Description ~~~ Kristi Nikolla with Boston University reported a vulnerability in Keystone federation. By doing GET /v3/OS-FEDERATION/projects an authenticated user may discover projects they have no authority to access, leaking all projects in the deployment and their attributes. Only Keystone with the /v3/OS-FEDERATION endpoint enabled via policy.json is affected. Patches ~~~ - https://review.openstack.org/585802 (Ocata) - https://review.openstack.org/585792 (Pike) - https://review.openstack.org/585788 (Queens) - https://review.openstack.org/585782 (Rocky) Credits ~~~ - Kristi Nikolla from Boston University (CVE-2018-14432) References ~~ - https://launchpad.net/bugs/1779205 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14432 signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [release][ptl] Deadlines this week
On 18-07-23 14:20:59, Sean McGinnis wrote: > Just a quick reminder that this week is a big one for deadlines. > > This Thursday, July 26, is our scheduled deadline for feature freeze, soft > string freeze, client library freeze, and requirements freeze. > > String freeze is necessary to give our i18n team a chance at translating error > strings. You are highly encouraged not to accept proposed changes containing > modifications in user-facing strings (with consideration for important bug > fixes of course). Such changes should be rejected by the review team and > postponed until the next series development opens (which should happen when > RC1 is published). > > The other freezes are to allow library changes and other code churn to settle > down before we get to RC1. Import feature freeze exceptions should be > requested > from the project's PTL for them to decide if the risk is low enough to allow > changes to still be accepted. > > Requirements updates will need a feature freeze exception from the > requirements > team. Those should be requested by sending a request to openstack-dev with the > subject line containing "[requirements][ffe]". > > For more details, please refer to our published Rocky release schedule: > > https://releases.openstack.org/rocky/schedule.html > Final reminder, the requirements freeze starts tomorrow. I still see some projects trickling in, so this is your final warning. Starting tomorrow you will have to make a FFE request to the list first. -- Matthew Thode (prometheanfire) 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] [release] Release countdown for week R-5, July 23-27
On 18-07-19 10:42:11, Sean McGinnis wrote: > > Development Focus > - > > Teams should be focused on implementing planned work. Work should be wrapping > up on client libraries to meet the client lib deadline Thursday, the 26th. > > General Information > --- > > The final client library release is on Thursday the 26th. Releases will only > be > allowed for critical fixes in libraries after this point as we stabilize > requirements and give time for any unforeseen impacts from lib changes to > trickle through. > > If release critical library or client library releases are needed for Rocky > past the freeze dates, you must request a Feature Freeze Exception (FFE) from > the requirements team before we can do a new release to avoid having something > released in Rocky that is not actually usable. This is done by posting to the > openstack-dev mailing list with a subject line similar to: > > [$PROJECT][requirements] FFE requested for $PROJECT_LIB > > Include justification/reasoning for why a FFE is needed for this lib. If/when > the requirements team OKs the post-freeze update, we can then process a new > release. Including a link to the FFE in the release request is not required, > but would be helpful in making sure we are clear to do a new release. > > When requesting these library releases, you should also include the stable > branching request with the review (as an example, see the "branches" section > here: > > http://git.openstack.org/cgit/openstack/releases/tree/deliverables/pike/os-brick.yaml#n2) > > Cycle-trailing projects are reminded that all reviews to the requirements > project will have a procedural -2 unless it recieves a FFE until stable/rocky > is branched. > > Upcoming Deadlines & Dates > -- > > Stein PTL nominations: July 24-31 (pending finalization) > Final client library release deadline: July 26 > Rocky-3 Milestone: July 26 > RC1 deadline: August 9 > Projects should also make sure their requirements files are up to date as OpenStack now uses per-project requirements. Further projects should make sure they have a release containing the update. This means that updates to the requirements files falls to the individual projects and not the requirements bot. It is recommended that you have a lower-constraints.txt file and test with it to know when you need to update. See the following example for how to run a basic tox LC job. https://github.com/openstack/oslo.db/blob/master/tox.ini#L76-L81 -- Matthew Thode (prometheanfire) 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][storyboard] Updates between SB and LP
On 18-07-16 13:12:32, Kendall Nelson wrote: > Hey Tony :) > > So I think the best way to deal with it would to disable bug reporting for > requirements in LP (so nothing new can get filed there and the index won't > be discoverable but you can still edit the old bugs) and then to do > periodic runs of the migration script to pick up any changes that have > happened. > > As for dumping SB changes back into LP I don't know that there is a way. > Maybe someone else has an idea. Hopefully by updating the description of > the reqs project in LP, people will know where to look for the new/current > information. > > Hope that helps! > > -Kendall (diablo_rojo) > > On Wed, Jul 11, 2018 at 11:54 PM Tony Breeds > wrote: > > > Hi all, > > The requirements team is only a light user of Launchpad and we're > > looking at moving to StoryBoard as it looks like for the most part it'll > > be a better fit. > > > > To date the thing that has stopped us doing this is the handling of > > bugs/stories that are shared between LP and SB. > > > > Assume that requirements had migrated to SB, how would be deal with bugs > > like: https://bugs.launchpad.net/openstack-requirements/+bug/1753969 > > > > Is there a, supportable, bi-directional path between SB and LP? > > > > I suspect the answer is No. I imagine if we only wanted to get > > updates from LP reflected in our SB story we could just leave the > > bug tracker open on LP and run the migration tool "often". > > The feature we use most heavilly is the cross project tracking. I'm just not sure how we'd deal with that when some projects are on LP and some on SB. How would we communicate something like the pycrypto removal in that case? https://bugs.launchpad.net/openstack-requirements/+bug/1749574 -- Matthew Thode (prometheanfire) 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] [all][ptl][release] deadline for non-client library releases 19 July
03-24 21:03:12 -0400 add lower-constraints job > * d42d448 2018-03-15 09:34:12 + Updated from global requirements > * 95445e1 2018-03-02 17:59:50 +0800 Update links in README > * 4e05b9a 2018-01-24 18:10:59 + Update reno for stable/queens > | * e65e119 2018-01-24 01:36:41 + Updated from global requirements > |/ > * 8a9bcee 2018-01-18 03:35:02 + Updated from global requirements > * 5d0fb11 2018-01-08 12:28:50 -0600 Follow the new PTI for document build > > > > [ Unreleased changes in openstack/sushy (master) ] > > Changes between 1.5.0 and e540017 > > * 1831b87 2018-06-28 17:46:21 +0300 Remove etag from Bios > * e96cb4e 2018-06-26 14:02:44 +0300 Hide Attribute Registry property in Bios > * fb44452 2018-06-25 10:59:32 +0300 Introduce BIOS API > > > > [ Unreleased changes in openstack/tosca-parser (master) ] > > Changes between 1.0.0 and 3eb67e7 > > * 3eb67e7 2018-06-06 15:27:01 -0400 fix tox python3 overrides > * 009e5f2 2018-06-01 11:47:48 -0500 Handle deriving from custom policy > definitions > * d5cacdb 2018-05-30 08:30:00 -0700 Add EXPERIMENTAL support for MEC > | * 129720c 2018-05-17 22:18:44 +0900 Follow the new PTI for document build > |/ > * 55c0663 2018-05-16 16:38:20 +0900 Switch from oslosphinx to > openstackdocstheme > we seem to have a lot of projects with requirements updates not merged as well. If those updates are wanted they should be merged and a release made. https://review.openstack.org/#/q/is:open+branch:master+owner:proposal-bot+topic:openstack/requirements -- Matthew Thode (prometheanfire) 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][infra] Maintaining constraints for several python versions
On 18-07-12 13:52:56, Jeremy Stanley wrote: > On 2018-07-12 06:37:52 -0700 (-0700), Clark Boylan wrote: > [...] > > I think most of the problems with Fedora stability are around > > bringing up a new Fedora every 6 months or so. They tend to change > > sufficiently within that time period to make this a fairly > > involved exercise. But once working they work for the ~13 months > > of support they offer. I know Paul Belanger would like to iterate > > more quickly and just keep the most recent Fedora available > > (rather than ~2). > [...] > > Regardless its instability/churn makes it unsuitable for stable > branch jobs because the support lifetime of the distro release is > shorter than the maintenance lifetime of our stable branches. Would > probably be fine for master branch jobs but not beyond, right? I'm of the opinion that we should decouple from distro supported python versions and rely on what versions upstream python supports (longer lifetimes than our releases iirc). -- Matthew Thode (prometheanfire) 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][taskflow] networkx migration
On 18-07-09 15:15:23, Matthew Thode wrote: > We have a patch that looks good, can we get it merged? > > https://review.openstack.org/#/c/577833/ > Anyone from taskflow around? Maybe it's better to just mail the ptl. -- Matthew Thode (prometheanfire) 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
[openstack-dev] [requirements][taskflow] networkx migration
We have a patch that looks good, can we get it merged? https://review.openstack.org/#/c/577833/ -- Matthew Thode (prometheanfire) 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][stable][docs] updating openstackdocstheme in stable branches
On 18-06-26 09:03:40, Doug Hellmann wrote: > Requirements team, > > At some point in the next few months we're going to want to raise > the constraint on openstackdocstheme in all of the old branches so > we can take advantage of a new feature for showing the supported > status of each version of a project. That feature isn't implemented > yet, but I thought it would be good to discuss in advance the need > to update the dependency and how to do it. > > The theme is released under an independent release model and does > not currently have stable branches. It depends on pbr and dulwich, > both of which should already be in the requirements and constraints > lists (dulwich is a dependency of reno). > > I think that means the simplest thing to do would be to just update > the constraint for the theme in the stable branches. Does that seem > right? > > If we can make that happen before we start the zuul configuration > porting work that we're going to do as part of the python3-first > goal, then we can take advantage of those patches to trigger doc > rebuilds in all of the projects. > Yep, talked about this in the reqs channel, seems like a good idea/plan. -- Matthew Thode (prometheanfire) 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] [all][requirements] we need to talk about eventlet
On 18-06-25 10:58:26, Doug Hellmann wrote: > Excerpts from Matthew Thode's message of 2018-06-25 09:38:28 -0500: > > On 18-06-25 08:59:23, Doug Hellmann wrote: > > > Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500: > > > > The short of it is that we are currently using eventlet 0.20.0. The bot > > > > proposes 0.22.1 which fails updates, I think we need to start bugging > > > > projects that fail the cross test jobs. What do you think? > > > > > > > > > > By "bugging" do you mean we should file bugs, or something else? > > > > > > > Yes, to start, it'd look something like this. > > > > https://bugs.launchpad.net/openstack-requirements/+bug/1749574 > > OK, tracking issues like that will work. You might also need a > storyboard story for projects that have already migrated. > Ya, I'm not sure what to do there. Requirements hasn't migrated because other projects haven't migrated (we really need to be on both systems unfortunately). Is it possible to half migrate? -- Matthew Thode (prometheanfire) 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] [all][requirements] we need to talk about eventlet
On 18-06-25 08:59:23, Doug Hellmann wrote: > Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500: > > The short of it is that we are currently using eventlet 0.20.0. The bot > > proposes 0.22.1 which fails updates, I think we need to start bugging > > projects that fail the cross test jobs. What do you think? > > > > By "bugging" do you mean we should file bugs, or something else? > Yes, to start, it'd look something like this. https://bugs.launchpad.net/openstack-requirements/+bug/1749574 > Which version of eventlet is actually being used in the various > distros? > For Gentoo it's 0.20.1 right now, but that's mainly because I haven't updated it myself (because Openstack). -- Matthew Thode (prometheanfire) 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
[openstack-dev] [all][requirements] we need to talk about eventlet
The short of it is that we are currently using eventlet 0.20.0. The bot proposes 0.22.1 which fails updates, I think we need to start bugging projects that fail the cross test jobs. What do you think? -- Matthew Thode (prometheanfire) 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] [tc] [ptl] PTL E-mail addresses on rendered team pages
On 18-06-15 15:29:07, Jeremy Stanley wrote: > On 2018-06-15 10:23:36 -0500 (-0500), Matthew Thode wrote: > [...] > > Not sure it'd help but one option we do is to create aliases based > > on the title. Though since the PTLs don't have addresses on the > > openstack domain an alias may not make as much sense, it'd have to > > be a full account forward. It's useful for centralized spam > > filtering. > > I'm not personally comfortable having someone else decide for me > what is or isn't spam, and I doubt I'm alone in that. > -- > Jeremy Stanley That makes sense, it'd only be for openstack ptl emails, still makes sense. -- Matthew Thode (prometheanfire) 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] [tc] [ptl] PTL E-mail addresses on rendered team pages
On 18-06-15 15:00:50, Jeremy Stanley wrote: > Governance tooling change https://review.openstack.org/575554 is > currently up for review to start displaying current PTL E-mail > addresses on the team specific pages linked from the projects index > https://governance.openstack.org/tc/reference/projects/ page. > > Since https://review.openstack.org/234420 merged a few years ago > we've been tracking PTL E-mail addresses in the structured data from > which we generate those pages, but the Sphinx extension we're using > was never amended to include them. Having somewhere consistent to > point members of the community who need to reach out to the PTL of a > team in private (and may not have easy access or comfort to do so via > IRC privmsg) would be useful. Right now we're stuck telling people > to dig around in a YAML file for them, which is not an especially > friendly answer. > > A knee-jerk reaction any time E-mail addresses get displayed > somewhere new is that it's going to increase the amount of spam > those addresses receive. Keep in mind that we've been publishing all > of them on a Web page for years now, just one which is only > convenient for spammers and not one which is convenient for people > who might have a legitimate need to contact our PTLs. > -- > Jeremy Stanley Not sure it'd help but one option we do is to create aliases based on the title. Though since the PTLs don't have addresses on the openstack domain an alias may not make as much sense, it'd have to be a full account forward. It's useful for centralized spam filtering. -- Matthew Thode (prometheanfire) 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
[openstack-dev] [all][requirements][docs]
Sphinx is being updated from 1.6.7 to 1.7.5. You may need to update your docs/templates to work with it. -- Matthew Thode (prometheanfire) 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][daisycloud][freezer][fuel][tatu][trove] pycrypto is dead andinsecure, you should migrate
On 18-06-14 01:28:14, Zhang Fan wrote: > Hi, Matthew > > > Sorry for the late updates on patches. Trove team members recently are sort > of busy with daily work. And it takes me awhile to get back focusing the > upstream. Fortunately, we are still there, and trove is still alive :) > > > About removing pycryto dependency, there are two patches, as [0] is merged > and [1] is on the way, thanks Zhao Chao for working on [0]: > > > [0].https://review.openstack.org/#/c/560292/ > > [1].https://review.openstack.org/#/c/573070/ > > Thanks anyone who helps us on this improments and looks forward to have more > contributors joining us in OpenStack/Trove ! > > > Best wishes. > Fan Zhang > > Original Message > Sender: Matthew Thode > Recipient: > openstack-dev@lists.openstack.org > Date: Wednesday, Jun 13, 2018 23:23 > Subject: Re: > [openstack-dev][requirements][daisycloud][freezer][fuel][tatu][trove] > pycrypto is dead andinsecure, you should migrate > > > On 18-06-13 20:53:06, Rong Zhu wrote: > > Hi, Matthew > > > > Solum removed pycryto dependency in [0] > > > > [0]: https://review.openstack.org/#/c/574244/ > > > > -- > > Thanks, > > Rong Zhu > > Yep, just in time for the next reminder email too :D > > > ++-+--+---+ > > | Repository | Filename > >| Line | Text > > | > > ++-+--+---+ > > | daisycloud-core| code/daisy/requirements.txt > >| 17 | pycrypto>=2.6 # Public Domain > > | > > | freezer| requirements.txt > >| 21 | pycrypto>=2.6 # Public Domain > > | > > | fuel-dev-tools | > > contrib/fuel-setup/requirements.txt |5 > > | pycrypto==2.6.1 | > > | fuel-web | nailgun/requirements.txt > >| 24 | pycrypto>=2.6.1 > > | > > | tatu | requirements.txt > >|7 | pycrypto>=2.6.1 > > | > > | tatu | test-requirements.txt > >|7 | pycrypto>=2.6.1 > > | > > | trove | > > integration/scripts/files/requirements/fedora-requirements.txt | 30 > > | pycrypto>=2.6 # Public Domain| > > | trove | > > integration/scripts/files/requirements/ubuntu-requirements.txt | 29 > > | pycrypto>=2.6 # Public Domain| > > | trove | requirements.txt > >| 47 | pycrypto>=2.6 # Public Domain > > | > > ++-+--+---+ > > Reverse order this time :D > > trove has https://review.openstack.org/#/c/573070 which is making good > progress > > The rest (tatu, fuel, freezer, daisycloud-core) I don't see any reviews, > starting to wonder if they watch the list. > Thanks for the work on it :D On a related note I've created https://review.openstack.org/575163 for freezer (depends on Doug's work though). -- Matthew Thode (prometheanfire) 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] PTG Denver 2018 Registration & Hotel Info
On 18-06-13 13:29:54, Kendall Waters wrote: > The fourth Project Teams Gathering will be held September 10-14th back at the > Renaissance Stapleton Hotel in Denver, Colorado (3801 Quebec Street, Denver, > Colorado 80207). > > REGISTRATION AND HOTEL > Registration is now available here: https://denver2018ptg.eventbrite.com > <https://denver2018ptg.eventbrite.com/> > > The price is currently USD $399 until August 23 at 6:59 UTC. After that date, > the price will be USD $599 so buy your pass before the price increases! > > We've reserved a very limited block of discounted hotel rooms at $149/night > USD (does not include breakfast) with the Renaissance Denver Stapleton Hotel > <https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18=resvlink_mobi=yes> > where the event will be held. Please move quickly to reserve a room by > August 20th or until they sell out! > > TRAIN NEAR HOTEL > The hotel has informed us that the RTD is anticipating the area near the > Renaissance Denver Stapleton Hotel being deemed a quiet zone by end of July, > with a more realistic completion date of August 15th. This means there should > not be any train horns during the week of the PTG! > > HELPFUL LINKS: > Registration: https://denver2018ptg.eventbrite.com > <https://denver2018ptg.eventbrite.com/> > Visa Invitation Letter (deadline August 24): > https://openstackfoundation.formstack.com/forms/visa_form_denver_2018_ptg > <https://openstackfoundation.formstack.com/forms/visa_form_denver_2018_ptg> > Travel Support Program (first round deadline July 1): > https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018 > <https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018> > Sponsorship: https://www.openstack.org/ptg#tab_sponsor > <https://www.openstack.org/ptg#tab_sponsor> > Book a Hotel Room (deadline August 20): > https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18=resvlink_mobi=yes > > <https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18=resvlink_mobi=yes> > Feel free to reach out to me directly with any questions, looking forward to > seeing everyone in Denver! > What if we want that train experience. I feel like there will be something missing without it. -- Matthew Thode (prometheanfire) 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][daisycloud][freezer][fuel][tatu][trove] pycrypto is dead and insecure, you should migrate
On 18-06-13 20:53:06, Rong Zhu wrote: > Hi, Matthew > > Solum removed pycryto dependency in [0] > > [0]: https://review.openstack.org/#/c/574244/ > > -- > Thanks, > Rong Zhu Yep, just in time for the next reminder email too :D > ++-+--+---+ > | Repository | Filename > | Line | Text > | > ++-+--+---+ > | daisycloud-core| code/daisy/requirements.txt > | 17 | pycrypto>=2.6 # Public Domain > | > | freezer| requirements.txt > | 21 | pycrypto>=2.6 # Public Domain > | > | fuel-dev-tools | > contrib/fuel-setup/requirements.txt |5 | > pycrypto==2.6.1 | > | fuel-web | nailgun/requirements.txt > | 24 | pycrypto>=2.6.1 > | > | tatu | requirements.txt > |7 | pycrypto>=2.6.1 > | > | tatu | test-requirements.txt > |7 | pycrypto>=2.6.1 > | > | trove | > integration/scripts/files/requirements/fedora-requirements.txt | 30 | > pycrypto>=2.6 # Public Domain| > | trove | > integration/scripts/files/requirements/ubuntu-requirements.txt | 29 | > pycrypto>=2.6 # Public Domain| > | trove | requirements.txt > | 47 | pycrypto>=2.6 # Public Domain > | > ++-+--+---+ Reverse order this time :D trove has https://review.openstack.org/#/c/573070 which is making good progress The rest (tatu, fuel, freezer, daisycloud-core) I don't see any reviews, starting to wonder if they watch the list. -- Matthew Thode (prometheanfire) 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][daisycloud][freezer][fuel][solum][tatu][trove] pycrypto is dead and insecure, you should migrate part 2
On 18-06-04 14:06:24, Matthew Thode wrote: > On 18-05-13 12:22:06, Matthew Thode wrote: > > This is a reminder to the projects called out that they are using old, > > unmaintained and probably insecure libraries (it's been dead since > > 2014). Please migrate off to use the cryptography library. We'd like > > to drop pycrypto from requirements for rocky. > > > > See also, the bug, which has most of you cc'd already. > > > > https://bugs.launchpad.net/openstack-requirements/+bug/1749574 > > > > ++-+--+---+ > | Repository | Filename > | Line | Text > | > ++-+--+---+ > | daisycloud-core| code/daisy/requirements.txt > | 17 | pycrypto>=2.6 # Public Domain > | > | freezer| requirements.txt > | 21 | pycrypto>=2.6 # Public Domain > | > | fuel-dev-tools | > contrib/fuel-setup/requirements.txt |5 | > pycrypto==2.6.1 | > | fuel-web | nailgun/requirements.txt > | 24 | pycrypto>=2.6.1 > | > | solum | requirements.txt > | 24 | pycrypto # Public Domain > | > | tatu | requirements.txt > |7 | pycrypto>=2.6.1 > | > | tatu | test-requirements.txt > |7 | pycrypto>=2.6.1 > | > | trove | > integration/scripts/files/requirements/fedora-requirements.txt | 30 | > pycrypto>=2.6 # Public Domain| > | trove | > integration/scripts/files/requirements/ubuntu-requirements.txt | 29 | > pycrypto>=2.6 # Public Domain| > | trove | requirements.txt > | 47 | pycrypto>=2.6 # Public Domain > | > ++-+--+---+ > > In order by name, notes follow. > > daisycloud-core - looks like AES / random functions are used > freezer - looks like AES / random functions are used > solum - looks like AES / RSA functions are used > trove - has a review!!! https://review.openstack.org/#/c/560292/ > > The following projects are not tracked so we won't wait on them. > fuel-dev-tools, fuel-web, tatu > > so it looks like progress is being made, so we have that going for us, > which is nice. What can I do to help move this forward? > It does not look like the projects (other than trove) are moving forward on this. -- Matthew Thode (prometheanfire) 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][daisycloud][freezer][fuel][solum][tatu][trove] pycrypto is dead and insecure, you should migrate part 2
On 18-05-13 12:22:06, Matthew Thode wrote: > This is a reminder to the projects called out that they are using old, > unmaintained and probably insecure libraries (it's been dead since > 2014). Please migrate off to use the cryptography library. We'd like > to drop pycrypto from requirements for rocky. > > See also, the bug, which has most of you cc'd already. > > https://bugs.launchpad.net/openstack-requirements/+bug/1749574 > ++-+--+---+ | Repository | Filename | Line | Text | ++-+--+---+ | daisycloud-core| code/daisy/requirements.txt | 17 | pycrypto>=2.6 # Public Domain | | freezer| requirements.txt | 21 | pycrypto>=2.6 # Public Domain | | fuel-dev-tools | contrib/fuel-setup/requirements.txt |5 | pycrypto==2.6.1 | | fuel-web | nailgun/requirements.txt | 24 | pycrypto>=2.6.1 | | solum | requirements.txt | 24 | pycrypto # Public Domain | | tatu | requirements.txt |7 | pycrypto>=2.6.1 | | tatu | test-requirements.txt |7 | pycrypto>=2.6.1 | | trove | integration/scripts/files/requirements/fedora-requirements.txt | 30 | pycrypto>=2.6 # Public Domain| | trove | integration/scripts/files/requirements/ubuntu-requirements.txt | 29 | pycrypto>=2.6 # Public Domain| | trove | requirements.txt | 47 | pycrypto>=2.6 # Public Domain | ++-+--+---+ In order by name, notes follow. daisycloud-core - looks like AES / random functions are used freezer - looks like AES / random functions are used solum - looks like AES / RSA functions are used trove - has a review!!! https://review.openstack.org/#/c/560292/ The following projects are not tracked so we won't wait on them. fuel-dev-tools, fuel-web, tatu so it looks like progress is being made, so we have that going for us, which is nice. What can I do to help move this forward? -- Matthew Thode (prometheanfire) 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] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5
On 18-05-17 13:51:06, Tony Breeds wrote: > On Wed, May 16, 2018 at 04:14:36PM -0500, Matthew Thode wrote: > > On 18-05-16 17:07:09, Doug Hellmann wrote: > > > Excerpts from Matthew Thode's message of 2018-05-16 15:59:47 -0500: > > > > Sphinx has breaking changes (yet again) and we need to figure out how to > > > > deal with it. I think the fix will be simple for affected projects, but > > > > we should probably move forward on this. The error people are getting > > > > seems to be 'Field list ends without a blank line; unexpected unindent.' > > > > > > > > I'd like to keep on 1.7.4 and have the affected projects fix the error > > > > so we can move on, but the revert has been proposed (and approved to get > > > > gate unbroken for them). https://review.openstack.org/568248 Any > > > > advice from the community is welcome. > > > > > > > > > > Is it sphinx, or docutils? > > > > > > Do you have an example of the error? > > > > > > > From https://bugs.launchpad.net/networking-midonet/+bug/1771092 > > > > 2018-05-13 14:22:06.176410 | ubuntu-xenial | Warning, treated as error: > > 2018-05-13 14:22:06.176967 | ubuntu-xenial | > > /home/zuul/src/git.openstack.org/openstack/networking-midonet/midonet/neutron/db/l3_db_midonet.py:docstring > > of > > midonet.neutron.db.l3_db_midonet.MidonetL3DBMixin.get_router_for_floatingip:8:Field > > list ends without a blank line; unexpected unindent. > > > > Perhaps the sphinx parser just got more strict? > Yep -- Matthew Thode (prometheanfire) 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] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5
On 18-05-16 17:07:09, Doug Hellmann wrote: > Excerpts from Matthew Thode's message of 2018-05-16 15:59:47 -0500: > > Sphinx has breaking changes (yet again) and we need to figure out how to > > deal with it. I think the fix will be simple for affected projects, but > > we should probably move forward on this. The error people are getting > > seems to be 'Field list ends without a blank line; unexpected unindent.' > > > > I'd like to keep on 1.7.4 and have the affected projects fix the error > > so we can move on, but the revert has been proposed (and approved to get > > gate unbroken for them). https://review.openstack.org/568248 Any > > advice from the community is welcome. > > > > Is it sphinx, or docutils? > > Do you have an example of the error? > From https://bugs.launchpad.net/networking-midonet/+bug/1771092 2018-05-13 14:22:06.176410 | ubuntu-xenial | Warning, treated as error: 2018-05-13 14:22:06.176967 | ubuntu-xenial | /home/zuul/src/git.openstack.org/openstack/networking-midonet/midonet/neutron/db/l3_db_midonet.py:docstring of midonet.neutron.db.l3_db_midonet.MidonetL3DBMixin.get_router_for_floatingip:8:Field list ends without a blank line; unexpected unindent. -- Matthew Thode (prometheanfire) 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
[openstack-dev] [all][requirements][docs] sphinx update to 1.7.4 from 1.6.5
Sphinx has breaking changes (yet again) and we need to figure out how to deal with it. I think the fix will be simple for affected projects, but we should probably move forward on this. The error people are getting seems to be 'Field list ends without a blank line; unexpected unindent.' I'd like to keep on 1.7.4 and have the affected projects fix the error so we can move on, but the revert has been proposed (and approved to get gate unbroken for them). https://review.openstack.org/568248 Any advice from the community is welcome. -- Matthew Thode (prometheanfire) 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][barbican][daisycloud][freezer][fuel][heat][pyghmi][rpm-packaging][solum][tatu][trove] pycrypto is dead and insecure, you should migrate
On 18-05-15 12:25:04, Zane Bitter wrote: > On 13/05/18 13:22, Matthew Thode wrote: > > This is a reminder to the projects called out that they are using old, > > unmaintained and probably insecure libraries (it's been dead since > > 2014). Please migrate off to use the cryptography library. We'd like > > to drop pycrypto from requirements for rocky. > > > > See also, the bug, which has most of you cc'd already. > > > > https://bugs.launchpad.net/openstack-requirements/+bug/1749574 > > > > ++-+--+---+ > > | Repository | Filename > >| Line | Text > > | > > ++-+--+---+ > > | barbican | requirements.txt > >| 25 | pycrypto>=2.6 # Public Domain > > | > > | daisycloud-core| code/daisy/requirements.txt > >| 17 | pycrypto>=2.6 # Public Domain > > | > > | freezer| requirements.txt > >| 21 | pycrypto>=2.6 # Public Domain > > | > > | fuel-web | nailgun/requirements.txt > >| 24 | pycrypto>=2.6.1 > > | > > | heat-cfnclient | requirements.txt > >|2 | PyCrypto>=2.1.0 > > | > > AFAICT heat-cfnclient isn't actually using PyCrypto, even though it's listed > in requirements.txt. The whole project is just a light wrapper around > python-boto (though this wasn't always the case IIRC), so I suspect it's > just relying on boto for all of the auth stuff. > Thanks for the notice, submitted a review to remove it. https://review.openstack.org/568646 > > | pyghmi | requirements.txt > >|1 | pycrypto>=2.6 > > | > > | rpm-packaging | requirements.txt > >| 189 | pycrypto>=2.6 # Public Domain > > | > > | solum | requirements.txt > >| 24 | pycrypto>=2.6 # Public Domain > > | > > | tatu | requirements.txt > >|7 | pycrypto>=2.6.1 > > | > > | tatu | test-requirements.txt > >|7 | pycrypto>=2.6.1 > > | > > | trove | > > integration/scripts/files/requirements/fedora-requirements.txt | 30 > > | pycrypto>=2.6 # Public Domain| > > | trove | > > integration/scripts/files/requirements/ubuntu-requirements.txt | 29 > > | pycrypto>=2.6 # Public Domain| > > | trove | requirements.txt > >| 47 | pycrypto>=2.6 # Public Domain > > | > > ++-+--+---+ > > > > > > > > __ > > 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: 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
[openstack-dev] [zVMCloudConnector][python-zvm-sdk][requirements] Unblock webob-1.8.1
Please unblock webob-1.8.1, you are the only library holding it back at this point. I don't see a way to submit code to the project so I cc'd the project in launchpad. https://bugs.launchpad.net/openstack-requirements/+bug/1765748 -- Matthew Thode (prometheanfire) 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
[openstack-dev] [requirements][barbican][daisycloud][freezer][fuel][heat][pyghmi][rpm-packaging][solum][tatu][trove] pycrypto is dead and insecure, you should migrate
This is a reminder to the projects called out that they are using old, unmaintained and probably insecure libraries (it's been dead since 2014). Please migrate off to use the cryptography library. We'd like to drop pycrypto from requirements for rocky. See also, the bug, which has most of you cc'd already. https://bugs.launchpad.net/openstack-requirements/+bug/1749574 ++-+--+---+ | Repository | Filename | Line | Text | ++-+--+---+ | barbican | requirements.txt | 25 | pycrypto>=2.6 # Public Domain | | daisycloud-core| code/daisy/requirements.txt | 17 | pycrypto>=2.6 # Public Domain | | freezer| requirements.txt | 21 | pycrypto>=2.6 # Public Domain | | fuel-web | nailgun/requirements.txt | 24 | pycrypto>=2.6.1 | | heat-cfnclient | requirements.txt |2 | PyCrypto>=2.1.0 | | pyghmi | requirements.txt |1 | pycrypto>=2.6 | | rpm-packaging | requirements.txt | 189 | pycrypto>=2.6 # Public Domain | | solum | requirements.txt | 24 | pycrypto>=2.6 # Public Domain | | tatu | requirements.txt |7 | pycrypto>=2.6.1 | | tatu | test-requirements.txt |7 | pycrypto>=2.6.1 | | trove | integration/scripts/files/requirements/fedora-requirements.txt | 30 | pycrypto>=2.6 # Public Domain| | trove | integration/scripts/files/requirements/ubuntu-requirements.txt | 29 | pycrypto>=2.6 # Public Domain| | trove | requirements.txt | 47 | pycrypto>=2.6 # Public Domain | ++-+--+-----------+ -- Matthew Thode (prometheanfire) 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
[openstack-dev] [requirements][glare][mogan][solum][compute-hyperv][kingbird][searchlight][swauth][networking-powervm][rpm-packaging][os-win] uncaping eventlet
Please review your particular uncaping patch (all but rpm-packaging are passing gate it looks like). We'd like to move on to a newer eventlet for rocky. https://review.openstack.org/#/q/topic:uncap-eventlet+status:open -- Matthew Thode (prometheanfire) 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above
On 18-05-10 11:09:41, Jim Rollenhagen wrote: > On Thu, May 10, 2018 at 11:05 AM, Matthew Thode <prometheanf...@gentoo.org> > wrote: > > > On 18-05-09 15:14:37, Matthew Thode wrote: > > > On 18-05-09 12:24:32, Clay Gerrard wrote: > > > > On Wed, May 9, 2018 at 12:08 PM, Matthew Thode < > > prometheanf...@gentoo.org> > > > > wrote: > > > > > > > > > > > > > > * Proper fix would be to make ceph support the account field > > > > > > > > > > > > > Is the 'rgw_swift_account_in_url' option not correct/sufficient? > > > > > > > > > > I didn't see that option, I'll test and get back to you on it. > > > > > > > Confirmed that the option works. > > > > Awesome. Can someone submit a patch? It will need to remove the special URL > building for radosgw linked earlier in the thread, and add a reference to > this config option in the docs: > https://git.openstack.org/cgit/openstack/ironic/tree/doc/source/admin/radosgw.rst > > Thanks! > Sure, I can make a first pass at it. Given swift removing support for the 'other' method, there will be other changes too though. -- Matthew Thode (prometheanfire) 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above
On 18-05-09 15:14:37, Matthew Thode wrote: > On 18-05-09 12:24:32, Clay Gerrard wrote: > > On Wed, May 9, 2018 at 12:08 PM, Matthew Thode <prometheanf...@gentoo.org> > > wrote: > > > > > > > > * Proper fix would be to make ceph support the account field > > > > > > > Is the 'rgw_swift_account_in_url' option not correct/sufficient? > > > > I didn't see that option, I'll test and get back to you on it. > Confirmed that the option works. > > > * Workaround would be to specify an old swiftclient to install (3.1.0, > > > pre-ocata) > > > > > > > Doesn't seem great if a sysadmin wants to co-install the newer swiftclient > > cli > > > > > > > * Workaround would be to for swiftclient to be forked and 'fixed' > > > > > > > > Not clear to me what the "fix" would be here - just don't do validation? > > I'll assume the "fork threat" here is for completeness/emphasis :D > > > > Do you know if ironic works with "normal" swift tempurls or only the > > radosgw implementation of the swift api? > > > -- Matthew Thode 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above
On 18-05-09 12:24:32, Clay Gerrard wrote: > On Wed, May 9, 2018 at 12:08 PM, Matthew Thode <prometheanf...@gentoo.org> > wrote: > > > > > * Proper fix would be to make ceph support the account field > > > > Is the 'rgw_swift_account_in_url' option not correct/sufficient? > I didn't see that option, I'll test and get back to you on it. > > * Workaround would be to specify an old swiftclient to install (3.1.0, > > pre-ocata) > > > > Doesn't seem great if a sysadmin wants to co-install the newer swiftclient > cli > > > > * Workaround would be to for swiftclient to be forked and 'fixed' > > > > > Not clear to me what the "fix" would be here - just don't do validation? > I'll assume the "fork threat" here is for completeness/emphasis :D > > Do you know if ironic works with "normal" swift tempurls or only the > radosgw implementation of the swift api? > -- Matthew Thode (prometheanfire) 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] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above
On 18-05-09 13:42:02, Jim Rollenhagen wrote: > On Wed, May 9, 2018 at 11:22 AM, Matthew Thode <prometheanf...@gentoo.org> > wrote: > > > python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw > > tempurls. That is, there was no official support, but it still worked. > > > > In 3.2.0 (specifically the linked commit(s)) tempurls were validated to > > require /v1/account/container/object, which does not work with radosgw > > as it expects /v1/container/object. This means that radosgw tempurls > > fail to work, which further means that radosgw will stop working for > > things like ironic. > > > > I can see the point that swiftclient should not care about ceph not > > fully implementing the swift spec and not supporting the radosgw url > > syntax, but it seems like a step back. If this is not fixed then things > > like ironic will not work with radosgw for Ocata and above (as that's > > when this change was made). We'd need to wait for either ceph to fix > > this and support the account part of the url (probably just dropping it) > > or have people fork python-swiftclient to 'fix' it. > > > > I'm not sure what the right answer is... > > > > Sounds like in the meantime ironic should pin python-swiftclient, yes? > That's one solution. The following three solutions are what I see as ways forward if swiftclient isn't changed. * Proper fix would be to make ceph support the account field * Workaround would be to specify an old swiftclient to install (3.1.0, pre-ocata) * Workaround would be to for swiftclient to be forked and 'fixed' -- Matthew Thode (prometheanfire) 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
[openstack-dev] [swift][ironic][ceph][radosgw] radosgw "support" in python-swiftclient droped for ocata and above
python-swiftclient prior to 3.2.0 seemed to incidentally support radosgw tempurls. That is, there was no official support, but it still worked. In 3.2.0 (specifically the linked commit(s)) tempurls were validated to require /v1/account/container/object, which does not work with radosgw as it expects /v1/container/object. This means that radosgw tempurls fail to work, which further means that radosgw will stop working for things like ironic. I can see the point that swiftclient should not care about ceph not fully implementing the swift spec and not supporting the radosgw url syntax, but it seems like a step back. If this is not fixed then things like ironic will not work with radosgw for Ocata and above (as that's when this change was made). We'd need to wait for either ceph to fix this and support the account part of the url (probably just dropping it) or have people fork python-swiftclient to 'fix' it. I'm not sure what the right answer is... https://github.com/openstack/python-swiftclient/commit/4c955751d340a8f71a2eebdb3c58d90b36874a66 https://github.com/openstack/ironic/blob/214b694f05d200ac1e2ce6db631546f2831c01f7/ironic/common/glance_service/v2/image_service.py#L152-L185 https://bugs.launchpad.net/ironic/+bug/1747384 -- Matthew Thode (prometheanfire) 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] [all][requirements] uncapping eventlet
On 18-04-06 09:41:07, Clark Boylan wrote: > On Fri, Apr 6, 2018, at 9:34 AM, Matthew Thode wrote: > > On 18-04-06 09:02:29, Jens Harbott wrote: > > > 2018-04-05 19:26 GMT+00:00 Matthew Thode <prometheanf...@gentoo.org>: > > > > On 18-04-05 20:11:04, Graham Hayes wrote: > > > >> On 05/04/18 16:47, Matthew Thode wrote: > > > >> > eventlet-0.22.1 has been out for a while now, we should try and use > > > >> > it. > > > >> > Going to be fun times. > > > >> > > > > >> > I have a review projects can depend upon if they wish to test. > > > >> > https://review.openstack.org/533021 > > > >> > > > >> It looks like we may have an issue with oslo.service - > > > >> https://review.openstack.org/#/c/559144/ is failing gates. > > > >> > > > >> Also - what is the dance for this to get merged? It doesn't look like > > > >> we > > > >> can merge this while oslo.service has the old requirement restrictions. > > > >> > > > > > > > > The dance is as follows. > > > > > > > > 0. provide review for projects to test new eventlet version > > > >projects using eventlet should make backwards compat code changes at > > > >this time. > > > > > > But this step is currently failing. Keystone doesn't even start when > > > eventlet-0.22.1 is installed, because loading oslo.service fails with > > > its pkg definition still requiring the capped eventlet: > > > > > > http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482 > > > > > > So it looks like we need to have an uncapped release of oslo.service > > > before we can proceed here. > > > > > > > Ya, we may have to uncap and rely on upper-constraints to keep openstack > > gate from falling over. The new steps would be the following: > > My understanding of our use of upper constraints was that this should > (almost) always be the case for (almost) all dependencies. We should rely on > constraints instead of requirements caps. Capping libs like pbr or eventlet > and any other that is in use globally is incredibly difficult to work with > when you want to uncap it because you have to coordinate globally. Instead if > using constraints you just bump the constraint and are done. > > It is probably worthwhile examining if we have any other deps in the > situation and proactively addressing them rather than waiting for when we > really need to fix them. > That's constantly on our list of things to do. In the past the only time we've capped is when we know upstream is realeasing breaking versions and we want to hold off for a cycle or until it's fixed. It also has the benefit of telling consumers/packagers about something 'hard breaking'. networkx is next on the list... -- Matthew Thode (prometheanfire) 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] [all][requirements] uncapping eventlet
On 18-04-06 09:02:29, Jens Harbott wrote: > 2018-04-05 19:26 GMT+00:00 Matthew Thode <prometheanf...@gentoo.org>: > > On 18-04-05 20:11:04, Graham Hayes wrote: > >> On 05/04/18 16:47, Matthew Thode wrote: > >> > eventlet-0.22.1 has been out for a while now, we should try and use it. > >> > Going to be fun times. > >> > > >> > I have a review projects can depend upon if they wish to test. > >> > https://review.openstack.org/533021 > >> > >> It looks like we may have an issue with oslo.service - > >> https://review.openstack.org/#/c/559144/ is failing gates. > >> > >> Also - what is the dance for this to get merged? It doesn't look like we > >> can merge this while oslo.service has the old requirement restrictions. > >> > > > > The dance is as follows. > > > > 0. provide review for projects to test new eventlet version > >projects using eventlet should make backwards compat code changes at > >this time. > > But this step is currently failing. Keystone doesn't even start when > eventlet-0.22.1 is installed, because loading oslo.service fails with > its pkg definition still requiring the capped eventlet: > > http://logs.openstack.org/21/533021/4/check/legacy-requirements-integration-dsvm/7f7c3a8/logs/screen-keystone.txt.gz#_Apr_05_16_11_27_748482 > > So it looks like we need to have an uncapped release of oslo.service > before we can proceed here. > Ya, we may have to uncap and rely on upper-constraints to keep openstack gate from falling over. The new steps would be the following: 1. uncap eventlet https://review.openstack.org/559367 2. push uncapped eventlet out via requirements updates to all consumers 3. make review in requirements changing upper-constraints.txt for eventlet 4. projects depend on requirements change to do work on the new eventlet the patch generated should merge into project without the requirements change merged (this means the change should pass in the dependant review (to test 0.22.1) AND in a separate non-dependant review (test the current constraint). You would merge the non-dependant once both reviews are passing. 5. Once some non-determined set of projects work with the new eventlet we'd merge the updated upper-constraint into requirements. steps 2 and 3 can happen in parallel, projects can move to step 4 after step 3 is done (step 2 is only needed for their project and their project's dependencies). There is bound to be projects that will break as they didn't take the opportunity to fix themselves, but this should help reduce breakage. I suggest a 1 month deadline after step 2/3 is considered complete before step 5 is performed. -- Matthew Thode (prometheanfire) 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] [all][requirements] uncapping eventlet
On 18-04-05 20:11:04, Graham Hayes wrote: > On 05/04/18 16:47, Matthew Thode wrote: > > eventlet-0.22.1 has been out for a while now, we should try and use it. > > Going to be fun times. > > > > I have a review projects can depend upon if they wish to test. > > https://review.openstack.org/533021 > > It looks like we may have an issue with oslo.service - > https://review.openstack.org/#/c/559144/ is failing gates. > > Also - what is the dance for this to get merged? It doesn't look like we > can merge this while oslo.service has the old requirement restrictions. > The dance is as follows. 0. provide review for projects to test new eventlet version projects using eventlet should make backwards compat code changes at this time. 1. uncap requirements for eventlet (do not raise upper constraint) step 0 does not have to be done for this to occur, but it'd be nice. 2. make sure all projects in projects.txt uncap eventlet (this is harder now that we have per-project requirements) 3. raise the constraint for eventlet, optionally also raise the global requirement for it as well -- Matthew Thode (prometheanfire) 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
[openstack-dev] [all][requirements] uncapping eventlet
eventlet-0.22.1 has been out for a while now, we should try and use it. Going to be fun times. I have a review projects can depend upon if they wish to test. https://review.openstack.org/533021 -- Matthew Thode (prometheanfire) 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] [infra][qa][requirements] Pip 10 is on the way
On 18-03-31 15:00:27, Jeremy Stanley wrote: > According to a notice[1] posted to the pypa-announce and > distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0 > is expected to be released in two weeks (over the April 14/15 > weekend). We know it's at least going to start breaking[2] DevStack > and we need to come up with a plan for addressing that, but we don't > know how much more widespread the problem might end up being so > encourage everyone to try it out now where they can. > I'd like to suggest locking down pip/setuptools/wheel like openstack ansible is doing in https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt We could maintain it as a separate constraints file (or infra could maintian it, doesn't mater). The file would only be used for the initial get-pip install. -- Matthew Thode (prometheanfire) 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
[openstack-dev] [requirements] Our job is done, time to close up shop.
The requirements project had a good run, but things seem to be winding down. We only break openstack a couple times a cycle now, and that's just not acceptable. The graph must go up and to the right. So, it's time for the requirements project to close up shop. So long and thanks for all the fish. -- Matthew Thode (prometheanfire) 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
[openstack-dev] [barbican][nova-powervm][pyghmi][solum][trove] Switching to cryptography from pycrypto
Here's the current status. I'd like to ask the projects what's keeping them from removing pycrypto in facor of a maintained library. Open reviews barbican: - (merge conflict) https://review.openstack.org/#/c/458196 - (merge conflict) https://review.openstack.org/#/c/544873 nova-powervm: no open reviews - in test-requirements, but not actually used? - made https://review.openstack.org/558091 for it pyghmi: - (merge conflict) https://review.openstack.org/#/c/331828 - (merge conflict) https://review.openstack.org/#/c/545465 - (doesn't change the import) https://review.openstack.org/#/c/545182 solum: no open reviews - looks like only a couple of functions need changing trove: no open reviews - mostly uses the random feature -- Matthew Thode (prometheanfire) 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] [infra][releases][requirements][l2gw] Latest requirements
On 18-03-22 14:50:43, Gary Kotton wrote: > Hi, > We have a problem with the l2gw tags. The requirements file indicates that we > should be pulling in >=12.0.0 and in fact its pulling networking_l2gw-2016.1.0 > Please see > http://207.189.188.190/logs/neutron/554292/4/tempest-api-vmware-tvd-t/logs/stack.sh.log.txt.gz#_2018-03-22_08_56_03_905 > Thanks > Gary It sounds like those versions need to be unpublished. This will likely involve both infra and the releases team (not requirements). I've tagged them to get their attention (and mentioned this in the releases irc channel). -- Matthew Thode (prometheanfire) 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] [all][requirements] a plan to stop syncing requirements into projects
ntly > > >following the global requirements lists to specify different > > >lower bounds from that global list, as long as those lower bounds > > >still allow the dependencies to be co-installable. (The upper > > >bounds, managed through the upper-constraints.txt list, would > > >still be built by selecting the newest compatible version because > > >that is how pip's dependency resolver works.) > > > > > > 2. We should stop syncing dependencies by turning off the > > >propose-update-requirements job entirely. > > > > > >Turning off the job will stop the bot from proposing more > > >dependency updates to projects. > > > > > >As part of deleting the job we can also remove the "requirements" > > >case from playbooks/proposal/propose_update.sh, since it won't > > >need that logic any more. We can also remove the update-requirements > > >command from the openstack/requirements repository, since that > > >is the tool that generates the updated list and it won't be > > >needed if we aren't proposing updates any more. > > > > > > 3. Remove the minimum specifications from the global requirements > > >list to make clear that the global list is no longer expressing > > >minimums. > > > > > >This clean-up step has been a bit more controversial among the > > >requirements team, but I think it is a key piece. As the minimum > > >versions of dependencies diverge within projects, there will no > > >longer *be* a real global set of minimum values. Tracking a list of > > >"highest minimums", would either require rebuilding the list from the > > >settings in all projects, or requiring two patches to change the > > >minimum version of a dependency within a project. > > > > > >Maintaining a global list of minimums also implies that we > > >consider it OK to run OpenStack as a whole with that list. This > > >message conflicts with the message we've been sending about the > > >upper constraints list since that was established, which is that > > >we have a known good list of versions and deploying all of > > >OpenStack with different versions of those dependencies is > > >untested. > > > > > > > As noted above I think that gathering the min versions/maskings from > > openstack projects to be valuable (especially to packagers who already > > use our likely invalid values already). > > OK. I don't feel that strongly about the cleanup work, so if we want to > keep the lower bounds in place I think that's OK. > > > > > > After these 3 steps are done, the requirements team will continue > > > to maintain the global-requirements.txt and upper-constraints.txt > > > files, as before. Adding a new dependency to a project will still > > > involve a review step to add it to the global list so we can monitor > > > licensing, duplication, python 3 support, etc. But adjusting the > > > version numbers once that dependency is in the global list will be > > > easier. > > > > > > > Thanks for writing this up, I think it looks good in general, but like > > you mentioned before, there is some discussion to be had about gathering > > and creating a versionspec from all of openstack for requirements. > > > -- Matthew Thode (prometheanfire) 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] [all][requirements] a plan to stop syncing requirements into projects
of a dependency within a project. > >Maintaining a global list of minimums also implies that we >consider it OK to run OpenStack as a whole with that list. This >message conflicts with the message we've been sending about the >upper constraints list since that was established, which is that >we have a known good list of versions and deploying all of >OpenStack with different versions of those dependencies is >untested. > As noted above I think that gathering the min versions/maskings from openstack projects to be valuable (especially to packagers who already use our likely invalid values already). > After these 3 steps are done, the requirements team will continue > to maintain the global-requirements.txt and upper-constraints.txt > files, as before. Adding a new dependency to a project will still > involve a review step to add it to the global list so we can monitor > licensing, duplication, python 3 support, etc. But adjusting the > version numbers once that dependency is in the global list will be > easier. > Thanks for writing this up, I think it looks good in general, but like you mentioned before, there is some discussion to be had about gathering and creating a versionspec from all of openstack for requirements. -- Matthew Thode (prometheanfire) 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] [all][requirements] a plan to stop syncing requirements into projects
On 18-03-15 09:45:38, Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2018-03-15 14:34:50 +0100: > > Doug Hellmann wrote: > > > [...] > > > TL;DR > > > - > > > > > > Let's stop copying exact dependency specifications into all our > > > projects to allow them to reflect the actual versions of things > > > they depend on. The constraints system in pip makes this change > > > safe. We still need to maintain some level of compatibility, so the > > > existing requirements-check job (run for changes to requirements.txt > > > within each repo) will change a bit rather than going away completely. > > > We can enable unit test jobs to verify the lower constraint settings > > > at the same time that we're doing the other work. > > > > Thanks for the very detailed plan, Doug. It all makes sense to me, > > although I have a precision question (see below). > > > > > [...] > > >We also need to change requirements-check to look at the exclusions > > >to ensure they all appear in the global-requirements.txt list > > >(the local list needs to be a subset of the global list, but > > >does not have to match it exactly). We can't have one project > > >excluding a version that others do not, because we could then > > >end up with a conflict with the upper constraints list that could > > >wedge the gate as we had happen in the past. > > > [...] > > > 2. We should stop syncing dependencies by turning off the > > >propose-update-requirements job entirely. > > > > > >Turning off the job will stop the bot from proposing more > > >dependency updates to projects. > > > [...] > > > After these 3 steps are done, the requirements team will continue > > > to maintain the global-requirements.txt and upper-constraints.txt > > > files, as before. Adding a new dependency to a project will still > > > involve a review step to add it to the global list so we can monitor > > > licensing, duplication, python 3 support, etc. But adjusting the > > > version numbers once that dependency is in the global list will be > > > easier. > > > > How would you set up an exclusion in that new world order ? We used to > > add it to the global-requirements file and the bot would automatically > > sync it to various consuming projects. > > > > Now since any exclusion needs to also appear on the global file, you > > would push it first in the global-requirements, then to the project > > itself, is that correct ? In the end the global-requirements file would > > only contain those exclusions, right ? > > > > The first step would need to be adding it to the global-requirements.txt > list. After that, it would depend on how picky we want to be. If the > upper-constraints.txt list is successfully updated to avoid the release, > we might not need anything in the project. If the project wants to > provide detailed guidance about compatibility, then they could add the > exclusion. For example, if a version of oslo.config breaks cinder but > not nova, we might only put the exclusion in global-requirements.txt and > the requirements.txt for cinder. > I wonder if we'd be able to have projects decide via a flag in their tox or zuul config if they'd like to opt into auto-updating exclusions only. -- Matthew Thode (prometheanfire) 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
