Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison
Hi Doug and guys, I would like to work as oslo-ironic liasison to sync Ironic with Oslo. I will attend the regular Oslo meeting for sure. My IRC name is lintan, and Launchpad id is tan-lin-good Thanks Tan -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Tuesday, May 26, 2015 9:17 PM To: openstack-dev Subject: Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison Excerpts from Ghe Rivero's message of 2015-05-25 09:45:47 -0700: My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero Thanks for your help as liaison, Ghe, the Oslo team appreciates your effort! Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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] Meeting time change
+1 to what Kota said! Matt On May 27, 2015 11:39 AM, Kota TSUYUZAKI tsuyuzaki.k...@lab.ntt.co.jp wrote: Thanks John and all swifters for taking care of Asian Pasific and Australian time zone. Much appreciated :) Kota (2015/05/26 4:32), John Dickinson wrote: Based on discussion over at the summit and over the last few weeks, the Swift team meeting time has changed. The new meeting time is 2100UTC on Wednesdays in #openstack-meeting. The meeting agenda is tracked at https://wiki.openstack.org/wiki/Meetings/Swift --John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] Meeting time change
Thanks John and all swifters for taking care of Asian Pasific and Australian time zone. Much appreciated :) Kota (2015/05/26 4:32), John Dickinson wrote: Based on discussion over at the summit and over the last few weeks, the Swift team meeting time has changed. The new meeting time is 2100UTC on Wednesdays in #openstack-meeting. The meeting agenda is tracked at https://wiki.openstack.org/wiki/Meetings/Swift --John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer][all] Scalable metering
Hello, My idea for Ceilometer scaling is to partition Ceilometer based on project ID ( Sorry I am newbie to Ceilometer, correct me if I am wrong ). Why? 1. Each tenant only cares about the metering data/event/alarm for himself, doesn't cares who else is also using the ceilometers. Project ID could be the orthogonal partition factor for all data stored/evaluated in Ceilometer. That means we don't need to store all projects' data into a same huge storage system, multiple storage backend for different project set can be used in Ceilometer. One front routing layer (based on project ID) can be added before data stored into or retrieved from Ceilometer storage. 2. Polling/collect data on demand. Only if the data has been asked by the tenant, then metering and sampling data will be collected. A tenant is not allowed to use all meter by default, meters/samples could be configured and billing-able. One project ID often has limited corresponding resources, and tenant need to pay for advanced functionality provided by Ceilometer ( how often, how much ). After partition, more physical resource could be allocated to serve some project, but the project must pay more for extra physical resources used. Best Regards Chaoyi Huang ( Joe Huang ) -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Wednesday, May 27, 2015 9:03 AM To: OpenStack Development Mailing List not for usage questions Subject: Re: [openstack-dev] [ceilometer][all] Scalable metering hi Tim, we're still doing some investigation but we're tracking/discussing part of the polling load issue here: https://review.openstack.org/#/c/185084/ we're open to any ideas -- especially from nova api et al experts. cheers, gord From: tim.b...@cern.ch To: openstack-dev@lists.openstack.org Date: Tue, 26 May 2015 17:45:37 + Subject: [openstack-dev] [ceilometer][all] Scalable metering We had a good discussion at the summit regarding ceilometer scaling. Julien has written up some of the items discussed in https://julien.danjou.info/blog/2015/openstack-summit-liberty-vancouve r-ceilometer-gnocchi and there is work ongoing in the storage area for scalable storage of ceilometer data using gnocchi. I'd like community input on the other scalability concern raised during the event, namely the load on other services when ceilometer is enabled. From the blog, Ceilometer hits various endpoints in OpenStack that are poorly designed, and hitting those endpoints of Nova or other components triggers a lot of load on the platform.. I would welcome suggestions on how to identify the potential changes in the OpenStack projects and improve the operator experience when deploying metering. Tim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer][all] Scalable metering
hi Tim, we're still doing some investigation but we're tracking/discussing part of the polling load issue here: https://review.openstack.org/#/c/185084/ we're open to any ideas -- especially from nova api et al experts. cheers, gord From: tim.b...@cern.ch To: openstack-dev@lists.openstack.org Date: Tue, 26 May 2015 17:45:37 + Subject: [openstack-dev] [ceilometer][all] Scalable metering We had a good discussion at the summit regarding ceilometer scaling. Julien has written up some of the items discussed in https://julien.danjou.info/blog/2015/openstack-summit-liberty-vancouver-ceilometer-gnocchi and there is work ongoing in the storage area for scalable storage of ceilometer data using gnocchi. I’d like community input on the other scalability concern raised during the event, namely the load on other services when ceilometer is enabled. From the blog, “Ceilometer hits various endpoints in OpenStack that are poorly designed, and hitting those endpoints of Nova or other components triggers a lot of load on the platform.”. I would welcome suggestions on how to identify the potential changes in the OpenStack projects and improve the operator experience when deploying metering. Tim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Some Changes to Cinder Core
Not a core, but still happy to +1 for Sean. His review is important to improve our work. Thanks to Avishay for your contribution in cinder. 2015-05-27 5:42 GMT+08:00 Ivan Kolodyazhny e...@e0ne.info: +1, Welcome to the team, Sean. Regards, Ivan Kolodyazhny On Wed, May 27, 2015 at 12:07 AM, John Griffith john.griffi...@gmail.com wrote: On Fri, May 22, 2015 at 5:34 PM, Mike Perez thin...@gmail.com wrote: This is long overdue, but it gives me great pleasure to nominate Sean McGinnis for Cinder core. Reviews: https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z Contributions: https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z 30/90 day review stats: http://stackalytics.com/report/contribution/cinder-group/30 http://stackalytics.com/report/contribution/cinder-group/90 As new contributors step up to help in the project, some move onto other things. I would like to recognize Avishay Traeger for his contributions, and now unfortunately departure from the Cinder core team. Cinder core, please reply with a +1 for approval. This will be left open until May 29th. Assuming there are no objections, this will go forward after voting is closed. -- Mike Perez __ 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 +1 __ 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 -- Best Wishes For You! __ 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] PCI pass-through SRIOV
Hi Levi,
Thanks for the replay,
What I need to ask Intel regarding this controller IntelXL710, whether it is
supported for sriov kvm or sriov openstack??
If the query regarding kvm , I tested by creating VF on this controller and
attached to virtual instance and boot it manually on top of KVM hypervisor, Now
am tested it using openstack.
Thanks and Regards,
Raghavendrachari kamsali,
From: Moshe Levi [mailto:mosh...@mellanox.com]
Sent: Tuesday, May 26, 2015 7:54 PM
To: Kamsali, RaghavendraChari [ENGINEERING/IN]; OpenStack Development Mailing
List (not for usage questions); openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV
This is a different error
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] if ret == -1: raise libvirtError
('virDomainCreateWithFlags() failed', dom=self)
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] libvirtError: internal error: process
exited while connecting to monitor: 2015-05-26T04:34:07.980897Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed to
open /dev/vfio/vfio: Operation not permitted
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980951Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed to
setup container for group 49
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980970Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed to
get group 49
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980995Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: Device
initialization failed.
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.981019Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: Device 'vfio-pci'
could not be initialized
You are using intel card therefore I think you should contact them and ask if
this card is supported.
From: Kamsali, RaghavendraChari (Artesyn)
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Tuesday, May 26, 2015 4:49 PM
To: Kamsali, RaghavendraChari (Artesyn); Moshe Levi; OpenStack Development
Mailing List (not for usage questions);
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV
Please find the attachment for the logs when changed in ml2_conf_sriov.ini
From: Kamsali, RaghavendraChari (Artesyn)
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Tuesday, May 26, 2015 1:36 PM
To: Moshe Levi; OpenStack Development Mailing List (not for usage questions);
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: Re: [Openstack] [openstack-dev] PCI pass-through SRIOV
Hi,
Yes I changed it on what you mentioned in ml2_conf_sriov.ini ,but same issue
occurs.
Thanks and Regards,
Raghavendrachari kamsali,
Embedded Computing and Power,
Hyderabad, AndhraPradesh , India
From: Moshe Levi [mailto:mosh...@mellanox.com]
Sent: Tuesday, May 26, 2015 12:58 PM
To: Kamsali, RaghavendraChari [ENGINEERING/IN]; OpenStack Development Mailing
List (not for usage questions);
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV
Hi Kamsali,
This is the error:
Refusing to bind due to unsupported vnic_type: direct
Please add the following to you ml2_conf.ini
supported_pci_vendor_devs = 8086:154c
Thanks,
Moshe Levi
From: Kamsali, RaghavendraChari (Artesyn)
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Monday, May 25, 2015 2:31 PM
To: Moshe Levi; OpenStack Development Mailing List (not for usage questions);
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV
FYI,
Neutron-server logs,
Ml2 config file on compute and controller
Nova.conf file
From: Moshe Levi [mailto:mosh...@mellanox.com]
Sent: Saturday, May 23, 2015 7:53 PM
To: OpenStack Development Mailing List (not for usage questions);
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: Re: [Openstack] [openstack-dev] PCI pass-through SRIOV
Hi Kamsali,
According to the logs you got binding failed error, which mean neutron failed
to bind the port.
Can you send the neutron server log and the your neutron ml2 conf file?
Thank,
Moshe Levi
From: Kamsali, RaghavendraChari
(Artesyn)mailto:raghavendrachari.kams...@artesyn.com
Sent: Saturday, May 23, 2015 6:38 AM
To: OpenStack Development Mailing List (not for usage
questions)mailto:openstack-dev@lists.openstack.org,
Re: [openstack-dev] [App-Catalog] Planning/working session Wednesday in Vancouver
Chris, I am interested in getting more involved. Is there any effort already in place to run this like a regular project, with IRC meetings, etc.? What are the channels, etc., by which I can get involved. Thanks, -Keith On 5/20/15 7:24 AM, Christopher Aedo d...@aedo.net wrote: [Cross-posting to both dev and operators list because I believe this is important to both groups] For those of us who have been working on the OpenStack Community App Catalog (http://apps.openstack.org) yesterday was really exciting. We had a chance to do a quick demo and walk through during they keynote, followed by a longer talk in the afternoon (slides here: http://www.slideshare.net/aedocw/openstack-community-app-catalog-httpappso penstackorg) The wiki page with more details is here: https://wiki.openstack.org/wiki/App-Catalog If you are in Vancouver and are interested in helping improve the Community App Catalog please join us for this working session: http://sched.co/3Rk4 (11:50 room 116/117) Etherpad: https://etherpad.openstack.org/YVR-app-catalog-plans If you can't join the session but have ideas or thoughts you would like to see discussed please add them to the etherpad. I've put down a few of the ideas that have come up so far, but it's definitely not a comprehensive list. We got really great feedback yesterday afternoon and found a lot of people are interested in contributing to the catalog and working together to add improvements. Hopefully you can join us today! -Christopher __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] configuration of plugins in an angularjs world
Hi all, Just a new conundrum for you :) At the top level of our base.html dashboard app, we have some dependencies 'horizon.auth', 'horizon.framework' and 'hz.dashboard' (that name will change to 'horizon.dashboard', but that's for another day). I think we need to remove 'hz.dashboard' from that list of dependencies and the list needs to be finer-grained *and configurable*. Currently in our small dashboard angularjs module structure we have hz.dashboard depend on all its sub-modules. This means that you can't disable some dashboards. The JS files would no longer be loaded (because they are in the enabled structure), but the dependency would remain (because dependency lists are not). Richard __ 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.vmware release 0.13.0 (liberty)
Matt I posted a patch https://review.openstack.org/#/c/185830/1 to fix the nova tests and make it compatible with the oslo.vmware 0.13.0 release. I am fine with the revert and g-r blacklist as oslo.vmware broke the semver but we can also consider this patch as an option. Thanks Sabari On Tue, May 26, 2015 at 2:53 PM, Davanum Srinivas dava...@gmail.com wrote: Vipin, Gary, Can you please accept the revert or figure out the best way to handle this? thanks, dims On Tue, May 26, 2015 at 5:41 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 5/26/2015 4:19 PM, Matt Riedemann wrote: On 5/26/2015 9:53 AM, Davanum Srinivas wrote: We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 There is now a blocking vmware unit tests bug in nova due to the oslo.vmware 0.13.0 release: https://bugs.launchpad.net/nova/+bug/1459021 Since the vmware driver unit test code in nova likes to stub out external APIs there is probably a bug in the nova unit tests rather than an issue in oslo.vmware, but I'm not very familiar so I can't really say. I have a revert for oslo.vmware here: https://review.openstack.org/#/c/185744/ And a block on the 0.13.0 version in global-requirements here: https://review.openstack.org/#/c/185748/ -- Thanks, Matt Riedemann __ 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 -- Davanum Srinivas :: https://twitter.com/dims __
Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support
We would like to participate as well. Monday-Friday Morning US time works for me.. Thanks, Vijay V. From: Samuel Bercovici [mailto:samu...@radware.com] Sent: 26 May 2015 21:39 To: OpenStack Development Mailing List (not for usage questions) Cc: kunalhgan...@gmail.com; v.jain...@gmail.com; do...@a10networks.com Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support Hi, I would also like to participate. Friday is a non-working day in Israel (same as Saturday for most of you). So Monday- Thursday works best for me. -Sam. From: Doug Wiegley [mailto:doug...@parksidesoftware.com] Sent: Saturday, May 23, 2015 8:45 AM To: OpenStack Development Mailing List (not for usage questions) Cc: kunalhgan...@gmail.commailto:kunalhgan...@gmail.com; v.jain...@gmail.commailto:v.jain...@gmail.com; do...@a10networks.commailto:do...@a10networks.com Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support Of those two options, Friday would work better for me. Thanks, doug On May 22, 2015, at 9:33 PM, ki...@macinnes.iemailto:ki...@macinnes.ie wrote: Hi Kunal, Thursday/Friday works for me - early morning PT works best, as I'm based in Ireland. I'll find some specific times the Designate folks are available over the next day or two and provide some options.. Thanks, Kiall On 22 May 2015 7:24 pm, Gandhi, Kunal kunalhgan...@gmail.commailto:kunalhgan...@gmail.com wrote: Hi All I wanted to start a discussion about adding support for GSLB to neutron-lbaas and designate. To be brief for folks who are new to GLB, GLB stands for Global Load Balancing and we use it for load balancing traffic across various geographical regions. A more detail description of GLB can be found at my talk at the summit this week herehttps://www.youtube.com/watch?v=fNR0SW3vj_s. To my understanding, there are two sides to a GSLB - DNS side and LB side. DNS side Most of the GSLB’s provided by various vendors are DNS servers and are authoritative for the GLB domains. The global fqdn’s that belong the GLB domains resolve to multiple public VIP’s across various regions based on various configurations on the global fqdn on the GLB. LBaaS side A few of the common functionalities provided by a standard GSLB provides are health monitoring on the public VIP’s and the local LB’s on which these public VIP’s sit on. Some additional features that a GSLB can provide are configuring admin status and weights on your public VIP’s. Based on these configurations and settings, the GLB returns the appropriate number of public VIP’s to any DNS resolve queries for the global fqdn’s. I would like to have the designate and lbaas to start a discussion on GSLB and discuss the following topics: * What parts of GSLB belongs to Designate and LBaaS ? * Once we have an understanding of the above, my team at eBay/PayPal would like work with the community on submitting a blueprint for this. To kick start this conversation, I would like to schedule an irc meeting regarding this with folks from designate and neutron-lbaas. Please let me know a time and day that works for you guys. I am available on Thursday and Friday next week. Regards Kunal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Manila] About how to hide the dummy destination record during migration
Hi everyone working for Manila, This is Vincent Hou from IBM. I am working on all the migration issues in Cinder. I had one session for the Cinder migration issue in Vancouver and some of you folks attended it. The etherpad link is https://etherpad.openstack.org/p/volume-migration-improvement Per the issue that we had better not let the user see the target volume during migration when issuing command cinder list, we can add an additional flag into the volume table, for example, hidden, into it. The default value is 0, meaning that it will display for cinder list. For the target volume during migration. We can set it to 1, so the user will not be able to see it with the command cinder list. I think it is a straightforward approach we can go with. I just sync up with you folks, so that we can have a consistent way to resolve this issue in both Cinder and Manila. I just need to make sure we are on the same page. Is this solution OK with you folks? Especially @Rodrigo Barbieri and @Erlon Cruz, etc. Looking forward to hearing from you. Thanks. Best wishes, Vincent Hou (侯胜博) Staff Software Engineer, Open Standards and Open Source Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193 __ 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] [App-Catalog] Planning/working session Wednesday in Vancouver
On Tue, May 26, 2015 at 9:22 PM, Keith Bray keith.b...@rackspace.com wrote: I am interested in getting more involved. Is there any effort already in place to run this like a regular project, with IRC meetings, etc.? What are the channels, etc., by which I can get involved. Keith, glad to hear it! You can reference a message sent last week for details on the next steps[1]. The intention is definitely to run this like a regular project, and the first step is to get responses from those interested in joining IRC meetings. Looking forward to working with you on this! [1]: http://lists.openstack.org/pipermail/openstack-dev/2015-May/064624.html -Christopher __ 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] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
I have verified that the following fixes the issue for me locally: https://review.openstack.org/#/c/185486/ This works for rescheduled DHCP instances, multiple DHCP instances, and restarted DHCP instances. I suspect that this is the cleanest thing to back-port because it doesn't add any translatables, scripts, rootwrap changes, or dependencies. For more background, Brian brought this up the dnsmasq discussion email list and it seems like the DHCP client used by Cirros (udhcpc) honors the NAKs while other clients do not.[1] Apparently that client is being 'fixed' to ignore NAK's from other servers, which should effectively defeat the entire point of 'authoritative' DHCP servers. :) However, we still need to fix this on our side since we can't tell people to just change their DHCP client. 1. http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q2/009570.html On Tue, May 26, 2015 at 3:02 PM, Kevin Benton blak...@gmail.com wrote: As long as we confirm that the severity of this bug is accurately represented in the bug report, then this is the first thing we should do. However, see below. We tried this and did not encounter the error in at least one experiment. Are we sure that this is broken everywhere multiple servers is used? I'm checking internally to confirm that we have run this successfully. Outside of the reported bug, I had another person report this behavior to me from Big Switch Networks as well. Additionally, I was just informed today that it was encountered internally here at Mirantis testing the latest stable/juno code. On Tue, May 26, 2015 at 12:37 PM, Carl Baldwin c...@ecbaldwin.net wrote: On Tue, May 26, 2015 at 11:05 AM, Brian Haley brian.ha...@hp.com wrote: On 05/26/2015 01:12 PM, Salvatore Orlando wrote: From the bug Kevin reported it seems multiple dhcp agents per network have been completely broken by the fix for bug #1345947, so a revert of patch [1] (and stable backports) should probably be the first thing to do - if nothing else because the original bug has not nearly the same level of severity of the one it introduced. As long as we confirm that the severity of this bug is accurately represented in the bug report, then this is the first thing we should do. However, see below. We tried this and did not encounter the error in at least one experiment. Are we sure that this is broken everywhere multiple servers is used? I'm checking internally to confirm that we have run this successfully. Before doing this however, I am wondering why the various instances of dnsmasq end up returning NAKs. I expect all instances to have the same hosts file, so they should be able to respond to DHCPDISCOVER/DHCPREQUEST correctly. Is the dnsmasq log telling us exactly why the authoritative setting is preventing us from doing so? (this is more of a curiosity in my side) [1] https://review.openstack.org/#/c/152080/ I also think we should understand more about this problem. I think that understanding more specifics around the bug will help. The details are a bit unclear to me. In the original case, the DHCPREQUEST is for a renew, which is different than for an initial request. If the server does not have a lease entry (which it won't after a restart), then it will NAK, which normally just causes the client to retry at INIT state. I had asked on the dnsmasq list about this [1], and the multiple server question was the wildcard, my testing didn't see the error described in the new bug though. I guess the first proposed fix of re-populating the lease information doesn't seem like such a bad idea any more, but I will reply to my original query with the tcpdump information since I'm confused as to why the second dhcp agent stepped-in with a NAK at all after originally offering the same address as the first dhcp agent [2]. I remember being concerned about the multiple dnsmasq case. I also remember having tried it and thought that it was working as expected. I would agree the best thing to do is revert the stable backports while we work on fixing this in the master branch. I think we can propose the reverts but until we confirm the severity of this bug, I don't want them to merge. Carl __ 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 -- Kevin Benton -- Kevin Benton __ 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] PCI pass-through SRIOV
Hi, Yes I changed it on what you mentioned in ml2_conf_sriov.ini ,but same issue occurs. Thanks and Regards, Raghavendrachari kamsali, Embedded Computing and Power, Hyderabad, AndhraPradesh , India From: Moshe Levi [mailto:mosh...@mellanox.com] Sent: Tuesday, May 26, 2015 12:58 PM To: Kamsali, RaghavendraChari [ENGINEERING/IN]; OpenStack Development Mailing List (not for usage questions); openst...@lists.openstack.org Subject: RE: [openstack-dev] PCI pass-through SRIOV Hi Kamsali, This is the error: Refusing to bind due to unsupported vnic_type: direct Please add the following to you ml2_conf.ini supported_pci_vendor_devs = 8086:154c Thanks, Moshe Levi From: Kamsali, RaghavendraChari (Artesyn) [mailto:raghavendrachari.kams...@artesyn.com] Sent: Monday, May 25, 2015 2:31 PM To: Moshe Levi; OpenStack Development Mailing List (not for usage questions); openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Subject: RE: [openstack-dev] PCI pass-through SRIOV FYI, Neutron-server logs, Ml2 config file on compute and controller Nova.conf file From: Moshe Levi [mailto:mosh...@mellanox.com] Sent: Saturday, May 23, 2015 7:53 PM To: OpenStack Development Mailing List (not for usage questions); openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Subject: Re: [Openstack] [openstack-dev] PCI pass-through SRIOV Hi Kamsali, According to the logs you got binding failed error, which mean neutron failed to bind the port. Can you send the neutron server log and the your neutron ml2 conf file? Thank, Moshe Levi From: Kamsali, RaghavendraChari (Artesyn)mailto:raghavendrachari.kams...@artesyn.com Sent: Saturday, May 23, 2015 6:38 AM To: OpenStack Development Mailing List (not for usage questions)mailto:openstack-dev@lists.openstack.org, openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Hi, Am deploying controller-compute openstack setup , in controller I configured openvswitch bridges and in computed node I configured PCI nic supported SRIOV capability and while am spawning VM am getting following error as in attached file: I followed the link for setting up the sriov https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking and http://www.qlogic.com/solutions/Documents/UsersGuide_OpenStack_SR-IOV.pdf Could any one help me regarding this issue Thanks and Regards, Raghavendrachari kamsali, Embedded Computing and Power, Hyderabad, AndhraPradesh , India __ 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] Stepping Down from Trove Core
On 25/05/15 20:23 -0700, Vipul Sabhaya wrote: I’ll be focusing primarily on Cue going forward, getting it included into the Big Tent, and making it production worthy. Looking forward to this. I haven't done much (anything) in Cue but please, do keep me in the loop and count with me. Cheers, Flavio -- @flaper87 Flavio Percoco pgpWGBAexkSVd.pgp 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] [Neutron] Stepping down from Neutron core team
Salvatore, I have never found your comments pedant, on the contrary they always improved my patches and for sure Neutron in general. It's a pity that you step down as a core but I am glad that you will keep staying in the Neutron community! Rossella On 05/21/2015 05:58 PM, Salvatore Orlando wrote: After putting the whole OpenStack networking contributors community through almost 8 cycles of pedant comments and annoying what if questions, it is probably time for me to relieve neutron contributors from this burden. It has been a pleasure for me serving the Neutron community (or Quantum as it was called at the time), and now it feel right - and probably overdue - to relinquish my position as a core team member in a spirit of rotation and alternation between contributors. Note: Before you uncork your champagne bottles, please be aware that I will stay in the Neutron community as a contributors and I might still end up reviewing patches. Thanks for being so understanding with my pedant remarks, Salvatore __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead
Greetings, TL;DR: Thanks everyone for your feedback. Based on the discussed plans at the summit - I'll be writing more about these later - Zaqar will stick around and play its role in the community. Summit Summary == I'm happy to say that several use cases were discussed at the summit and the difference from previous summits is that we left the room with some action items to make them happen. Cross-project user-facing notifications === https://etherpad.openstack.org/p/liberty-cross-project-user-notifications Besides brainstorming a bit on what things should/should not be notified and what format should be used, we also talked a bit about the available technologies that could be used for this tasks. Zaqar was among those and, AFAICT, at the end of the session we agreed on giving this a try. It'll likely not happen as fast as we want but the action item out of this session was to write a cross-project spec describing the things discussed and the technology that will be adopted. Heat + Zaqar The 2 main areas where Zaqar will be used in Heat are Software Config and Hooks. The minimum requirements (server side) for this are in place already. There's some work to do on the client side that the team will get to asap. Sahara (or other guest agent based services) + Zaqar We discussed 3 different ways to enable services to communicate with their guest agents using Zaqar: 1) Using notification hooks: Assuming the guest agents doesn't need to communicate with the controller, the controller can register a notification hook that will push messages to the guest agent. 2) Inject keystone credentials: The controller would inject keystone credentials into the VM to allow the guest agent to send/receive messages using Zaqar. 3) PreSigned URLs: The controller injects a PreSigned URL in the controller that will grant the guest agent access to a specific tenant/queue with either read or readwrite access. Hallway Discussions === We had a chance to talk to some other folks from teams like Horizon that were also interested in doing some actual integration work with Zaqar as well. Not to mention that some other folks from the puppet team showed interest in helping out with the creation of these manifests. Next Steps == In light of the above, and as mentioned in the TL;DR, Zaqar will stick around and the team, as promised, will focus on making those integrations happen. The team is small, which means we'll carefully pick the tasks we'll be spending time on. As a first step, we should restore our meetings and get to work right away. To favor our contributors in NZ, next week's meeting will be at 21:00 UTC and we'll keep it at that time for 2 weeks. For the Zaqar team (and folks interested), I'll be sending out further emails to sync on the work to do. Special thanks for all the folks that showed interest, participated in sessions and that are committed on making this happen. Lets now make it happen, Flavio -- @flaper87 Flavio Percoco pgp21BCBY9xBK.pgp 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] [Fuel] vxlan support
Hi folks, I have a question about implementation of vxlan for neutron. there is a blueprint on that topic in launchpad from 2014/03/21: https://blueprints.launchpad.net/fuel/+spec/neutron-vxlan-support several fixes have been pushed but all of them have been abandonned or refused. Is there any technical reason to not having vxlan support on fuel or is it just not a priority for product manager? In fuel 5.0 and 5.1 we customize fuel in order to have this segmentation type. starting from fuel 6.0, I have made a plugin for vxlan but not totally satisfied by that way to process. It will be cleaner to having vlxan directly ship into fuel core. So if there is no technical issue and if it not already shiped into the advanced network topic, I can work on a fix to add this feature in fuel 7.0 regards Samuel __ 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] [Ironic][oslo] Stepping down from oslo-ironic liaison
Thanks for all the work Ghe. The project will certainly miss you. Cheers, Lucas On Mon, May 25, 2015 at 5:45 PM, Ghe Rivero g...@debian.org wrote: My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero -- Pinky: Gee, Brain, what do you want to do tonight? The Brain: The same thing we do every night, Pinky—try to take over the world! .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] Port Cinder to Python 3
(Oops, I sent a draft by mistake, sorry about that.) Hi, There is an ongoing effort to port OpenStack applications to Python 3 during the Liberty cycle. The following table gives the status of each application and links to patches: https://wiki.openstack.org/wiki/Python3#OpenStack_applications Specs were accepted for: * heat: https://review.openstack.org/#/c/175340/ * keystone: https://review.openstack.org/#/c/177380/ * neutron: https://review.openstack.org/#/c/172962/ * nova: https://review.openstack.org/176868 For cinder, I ported the last blocking dependency to Python 3, rtslib-fb: https://github.com/agrover/rtslib-fb/pull/62 (There is not release including the fix yet.) MySQL-python should be replaced with PyMySQL to run Python 3 tests, as done in Ironic, Nova and other applications. I started to write patches to port Cinder code to Python 3: https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:py3,n,z Duncan Thomas rejected one of my patch: As commented on https://review.openstack.org/#/c/185411/ I'd really like to be convinced that there's an end in sight for this python3 work, or I'm going to start rejecting it. This change is making the code noticeably harder to read, and has no checks to stop it recurring in future, and is lacking substantial justification as to it's benefits. In the other issue, he wrote: Is there a master list of remaining python3 issues anywhere? At the moment we are introducing more and more little changes into the code, including some really ugly six stuff, without any idea if we are even close to actually being able to work with python3. To be honest, I think that I'd like to see a working python3 tree before we merge any more - we can then pull in the fixes in a clean manner, knowing the end-goal is possible. Thoughts appreciated, otherwise I'm tempted to start hitting -2 on python3 stuff. Ok, I checked the status of Cinder port to Python 3. I merged my pending patches into a local branch and I fixed manually dependencies for tox -e py34 (replace MySQL-python with PyMySQL, install the development version of oslo.vmware). With 4 minor changes, I'm able to run one cinder unit test (cinder/tests/unit/test_quota.py). Cool! The next step will be to run a subset of tests in tox -e py34 to make it pass, and then add a checking job. When the job becomes stable, make it voting to avoid further Python 3 regressions. Then more code should be ported to Python 3 to slowly port the whole Cinder code base. Well, that's exactly the plan approved for Nova, and other OpenStack applications have the same (or a similar) plan for Python 3. About the usage of six: we chose six to add Python 3 support to all other OpenStack libraries and applications. Sorry if it makes the code more ugly. More information on porting code to Python 3: https://wiki.openstack.org/wiki/Python3#Port_Python_2_code_to_Python_3 Victor Stinner aka haypo __ 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] [cinder] Port Cinder to Python 3
Thanks Victor, that is pretty much exactly what I wanted to hear - there's a known, finite plan to get us to fully working with python3. I'll go change my reviews now. On 26 May 2015 at 12:44, Victor Stinner vstin...@redhat.com wrote: (Oops, I sent a draft by mistake, sorry about that.) Hi, There is an ongoing effort to port OpenStack applications to Python 3 during the Liberty cycle. The following table gives the status of each application and links to patches: https://wiki.openstack.org/wiki/Python3#OpenStack_applications Specs were accepted for: * heat: https://review.openstack.org/#/c/175340/ * keystone: https://review.openstack.org/#/c/177380/ * neutron: https://review.openstack.org/#/c/172962/ * nova: https://review.openstack.org/176868 For cinder, I ported the last blocking dependency to Python 3, rtslib-fb: https://github.com/agrover/rtslib-fb/pull/62 (There is not release including the fix yet.) MySQL-python should be replaced with PyMySQL to run Python 3 tests, as done in Ironic, Nova and other applications. I started to write patches to port Cinder code to Python 3: https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:py3,n,z Duncan Thomas rejected one of my patch: As commented on https://review.openstack.org/#/c/185411/ I'd really like to be convinced that there's an end in sight for this python3 work, or I'm going to start rejecting it. This change is making the code noticeably harder to read, and has no checks to stop it recurring in future, and is lacking substantial justification as to it's benefits. In the other issue, he wrote: Is there a master list of remaining python3 issues anywhere? At the moment we are introducing more and more little changes into the code, including some really ugly six stuff, without any idea if we are even close to actually being able to work with python3. To be honest, I think that I'd like to see a working python3 tree before we merge any more - we can then pull in the fixes in a clean manner, knowing the end-goal is possible. Thoughts appreciated, otherwise I'm tempted to start hitting -2 on python3 stuff. Ok, I checked the status of Cinder port to Python 3. I merged my pending patches into a local branch and I fixed manually dependencies for tox -e py34 (replace MySQL-python with PyMySQL, install the development version of oslo.vmware). With 4 minor changes, I'm able to run one cinder unit test (cinder/tests/unit/test_quota.py). Cool! The next step will be to run a subset of tests in tox -e py34 to make it pass, and then add a checking job. When the job becomes stable, make it voting to avoid further Python 3 regressions. Then more code should be ported to Python 3 to slowly port the whole Cinder code base. Well, that's exactly the plan approved for Nova, and other OpenStack applications have the same (or a similar) plan for Python 3. About the usage of six: we chose six to add Python 3 support to all other OpenStack libraries and applications. Sorry if it makes the code more ugly. More information on porting code to Python 3: https://wiki.openstack.org/wiki/Python3#Port_Python_2_code_to_Python_3 Victor Stinner aka haypo __ 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 -- Duncan Thomas __ 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] Stepping Down from Trove Core
Vipul, thanks for all the things you’ve done for Trove over the years. All the best with Cue! Thanks, -amrith From: Vipul Sabhaya [mailto:vip...@gmail.com] Sent: Monday, May 25, 2015 11:24 PM To: OpenStack Development Mailing List Subject: [openstack-dev] Stepping Down from Trove Core Having not been very active in Trove for the past few months, it’s time to step down from the core team. I’ll be focusing primarily on Cue going forward, getting it included into the Big Tent, and making it production worthy. From RedDwarf to Trove to Onwards and Upwards! -Vipul __ 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] [cinder] Port Cinder to Python 3
Hi, There is an ongoing effort to port OpenStack applications to Python 3 during the Liberty cycle. The following table gives the status of each application and links to patches: https://wiki.openstack.org/wiki/Python3#OpenStack_applications Specs were accepted for: * heat: https://review.openstack.org/#/c/175340/ * keystone: https://review.openstack.org/#/c/177380/ * neutron: https://review.openstack.org/#/c/172962/ __ 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] [zaqar]
I am afraid its not so straightforward. The messaging passing between the API and Guestagent is delegated to oslo messaging. Adding support for Zaqar would require us to write some kind of driver for it, or change Trove code to support it. Cheers El lun., 25 may. 2015 a las 10:31, Li Tianqing (jaze...@163.com) escribió: Yes. I mean trove guest agent. How can the vm send messages to rabbitmq in management network? -- Best Li Tianqing At 2015-05-23 04:43:28, Victoria Martínez de la Cruz victo...@vmartinezdelacruz.com wrote: Hi, So, what are you trying to do? With guest agent you are referring to Trove guest agent? Thanks El sáb., 16 may. 2015 a las 5:42, Li Tianqing (jaze...@163.com) escribió: Hello, How can zaqar make guestagent in vm connect to server manager? Can someone give one example? Thanks. -- Best Li Tianqing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Stepping Down from Trove Core
Thanks for all the hard work that you've put into Trove over the years. I understand that with Cue you are going to have much less time to focus on Trove reviews. However you are - and always will be - an integral part of the Trove community. Good luck on Cue! Cheers, -Nikhil Vipul Sabhaya writes: Having not been very active in Trove for the past few months, it’s time to step down from the core team. I’ll be focusing primarily on Cue going forward, getting it included into the Big Tent, and making it production worthy. From RedDwarf to Trove to Onwards and Upwards! -Vipul __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
How about retaining --dhcp-authoritative when dhcp_agents_per_network = 1? I would guess that that is the 90% case. I suppose that would require passing new information from the Neutron server to the DHCP agents; but maybe that's feasible, and it feels like the right thing to do.Also, what are the use cases for dhcp_agents_per_network = 2 ?Regards, Neil From: Doug WiegleySent: Tuesday, 26 May 2015 04:14To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Subject: Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers After a brief IRC conversation with Kevin, he pointed out that we already don’t allow any other ports on the subnet to send DHCP replies, so NAKs are completely unnecessary. I’d be fine just filtering them out for now.Thanks,dougOn May 25, 2015, at 7:54 PM, Kevin Benton blak...@gmail.com wrote:Here is the description of the behavior for --dhcp-authoritative from the dnsmasq page. [1]Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum).As far as I understand it, the original intent of the patch that caused the issue was to fix that refusal to answer lease renewals after a restart. So it wasn't added to get NAKs, it was added to make it respond to renewals before they timeout.1.http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.htmlOn Mon, May 25, 2015 at 7:44 PM, Doug Wiegley doug...@parksidesoftware.com wrote:Option 4, turn off authoritative if we don’t want NAK’s?dougOn May 25, 2015, at 7:35 PM, Kevin Benton blak...@gmail.com wrote:Hi,A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2].This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them.I have two fixes for this so far and a third alternative if we don't like those.The first is hacky, but it's only a few-line change.[3] It adds an iptables rule that just stops the DHCPNAKs from making it to the client. This is clean to back-port but it doesn't protect clients that have filtering disabled (e.g. bare metal).The second persists the DHCP leases to a database.[4] The downside to this was always that being rescheduled to another agent would mean no entries in the lease file. This approach adds a work-around to generate an initial fake lease file based on all of the ports in the network.A third approach that I don't have a patch pushed for yet is very similar to the second. When dnsmasq is in the leasefile-ro mode, it will call the script passed to --dhcp-script to get a list of leases to start with. This script would be built with the same logic as the second one. The only difference between the second approach is that dnsmasq wouldn't persist leases to a database.I'm looking for feedback on how we want to go forward with this in a back-port friendly manner.Cheers,Kevin Benton1.https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z2.https://bugs.launchpad.net/neutron/+bug/14579003.https://review.openstack.org/#/c/185332/4.https://review.openstack.org/#/c/185486/-- Kevin Benton __OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 -- Kevin Benton __OpenStack Development Mailing List (not for usage questions)Unsubscribe:
Re: [openstack-dev] [nova] usefulness of device parameter at volumeAttachment
On 05/26/2015 11:13 AM, Daniel P. Berrange wrote: On Sat, May 23, 2015 at 11:00:32AM +0200, Géza Gémes wrote: Hi, When someone calls nova volume-attach or the block-device-mapping parameter at boot, it is possible to specify a device name for the guest. However I couldn't find any guest OS which would honor this. E.g. with libvirt/kvm, if the guest has two virtio disks already (vda and vdb), specifying vdf would be ignored and the disk will be attached as vdc in the guest. I propose to deprecate this option and at boot where it is not optional to accept only auto as an option. This was a design mistake in the original API which we can't now remove without breaking backcompatibility. While it is still supported, many hypervisors will completely ignore it, so we discourage people from ever using it. Just allow the hypervisor and/or guest OS to pick the device name I have just proposed this yesterday: https://review.openstack.org/#/c/185438/ Removing it from the API is a little bit trickier because it will require a backwards incompatible version bump (this is allowed and all good), but is probably the right thing to do in the long run. I will see if I can propose a patch for this. N. __ 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] [Cinder] Do we need to fix issues in V1 API?
Hello, While fixing issues in V2 API, do we need to fix in V1 API? As per following blueprint description, V1 API is being deprecated in liberty-1. https://blueprints.launchpad.net/cinder/+spec/deprecate-v1-api Thanks Regards, Pranali Deore __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.__ 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] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
Hi, HA on DHCP is done by setting dhcp_agents_per_network = 2, so production deploiements should set dhcp_agents_per_network = 2. Regards, Cédric/ZZelle On Tue, May 26, 2015 at 12:24 PM, neil.jer...@metaswitch.com wrote: How about retaining --dhcp-authoritative when dhcp_agents_per_network = 1? I would guess that that is the 90% case. I suppose that would require passing new information from the Neutron server to the DHCP agents; but maybe that's feasible, and it feels like the right thing to do. Also, what are the use cases for dhcp_agents_per_network = 2 ? Regards, Neil *From: *Doug Wiegley *Sent: *Tuesday, 26 May 2015 04:14 *To: *OpenStack Development Mailing List (not for usage questions) *Reply To: *OpenStack Development Mailing List (not for usage questions) *Subject: *Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers After a brief IRC conversation with Kevin, he pointed out that we already don't allow any other ports on the subnet to send DHCP replies, so NAKs are completely unnecessary. I'd be fine just filtering them out for now. Thanks, doug On May 25, 2015, at 7:54 PM, Kevin Benton blak...@gmail.com wrote: Here is the description of the behavior for --dhcp-authoritative from the dnsmasq page. [1] Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum). As far as I understand it, the original intent of the patch that caused the issue was to fix that refusal to answer lease renewals after a restart. So it wasn't added to get NAKs, it was added to make it respond to renewals before they timeout. 1. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html On Mon, May 25, 2015 at 7:44 PM, Doug Wiegley doug...@parksidesoftware.com wrote: Option 4, turn off authoritative if we don't want NAK's? doug On May 25, 2015, at 7:35 PM, Kevin Benton blak...@gmail.com wrote: Hi, A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2]. This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them. I have two fixes for this so far and a third alternative if we don't like those. The first is hacky, but it's only a few-line change.[3] It adds an iptables rule that just stops the DHCPNAKs from making it to the client. This is clean to back-port but it doesn't protect clients that have filtering disabled (e.g. bare metal). The second persists the DHCP leases to a database.[4] The downside to this was always that being rescheduled to another agent would mean no entries in the lease file. This approach adds a work-around to generate an initial fake lease file based on all of the ports in the network. A third approach that I don't have a patch pushed for yet is very similar to the second. When dnsmasq is in the leasefile-ro mode, it will call the script passed to --dhcp-script to get a list of leases to start with. This script would be built with the same logic as the second one. The only difference between the second approach is that dnsmasq wouldn't persist leases to a database. I'm looking for feedback on how we want to go forward with this in a back-port friendly manner. Cheers, Kevin Benton 1. https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z 2. https://bugs.launchpad.net/neutron/+bug/1457900 3. https://review.openstack.org/#/c/185332/ 4. https://review.openstack.org/#/c/185486/ -- Kevin Benton __ 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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ 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] [Zaqar][all] Zaqar will stay... Lots of work ahead
On 05/26/2015 04:28 AM, Flavio Percoco wrote: Greetings, TL;DR: Thanks everyone for your feedback. Based on the discussed plans at the summit - I'll be writing more about these later - Zaqar will stick around and play its role in the community. \o/ [snip] == Next Steps == In light of the above, and as mentioned in the TL;DR, Zaqar will stick around and the team, as promised, will focus on making those integrations happen. The team is small, which means we'll carefully pick the tasks we'll be spending time on. As a first step, we should restore our meetings and get to work right away. To favor our contributors in NZ, next week's meeting will be at 21:00 UTC and we'll keep it at that time for 2 weeks. For those who didn't know what day the Zaqar meetings are normally, they are on Mondays according to the OpenStack calendar (next meeting on June 1). For the Zaqar team (and folks interested), I'll be sending out further emails to sync on the work to do. Special thanks for all the folks that showed interest, participated in sessions and that are committed on making this happen. Lets now make it happen, Flavio Thanks for the mail Flavio, Ryan -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ 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] [Cinder] Do we need to fix issues in V1 API?
AFAIK, we're going to remove API v1 from Cinder in Liberty. So it makes no sense to fix it in master. Regards, Ivan Kolodyazhny On Tue, May 26, 2015 at 3:36 PM, Duncan Thomas duncan.tho...@gmail.com wrote: I don't think either of those are likely to be accepted for V1, certainly I'd vote against it. They should be fixed in V2 however. On 26 May 2015 at 15:13, Deore, Pranali11 pranali11.de...@nttdata.com wrote: Hi Duncan, I am planning to fix following issues for V1 API, 1. https://bugs.launchpad.net/cinder/+bug/1454244 2. “VolumeNotFound” exception error message should be consistent across all APIs Please suggest. Thanks *From:* Duncan Thomas [mailto:duncan.tho...@gmail.com] *Sent:* 26 May 2015 17:14 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Cinder] Do we need to fix issues in V1 API? In general, V1 is not being changed / fixed, though it is case-by-case, for example security issues will always be fixed. What exactly were you thinking about fixing? On 26 May 2015 at 14:17, Deore, Pranali11 pranali11.de...@nttdata.com wrote: Hello, While fixing issues in V2 API, do we need to fix in V1 API? As per following blueprint description, V1 API is being deprecated in liberty-1. https://blueprints.launchpad.net/cinder/+spec/deprecate-v1-api Thanks Regards, Pranali Deore __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ 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 -- Duncan Thomas __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ 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 -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Do we need to fix issues in V1 API?
Thanks ☺ From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: 26 May 2015 18:07 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] Do we need to fix issues in V1 API? I don't think either of those are likely to be accepted for V1, certainly I'd vote against it. They should be fixed in V2 however. On 26 May 2015 at 15:13, Deore, Pranali11 pranali11.de...@nttdata.commailto:pranali11.de...@nttdata.com wrote: Hi Duncan, I am planning to fix following issues for V1 API, 1. https://bugs.launchpad.net/cinder/+bug/1454244 2. “VolumeNotFound” exception error message should be consistent across all APIs Please suggest. Thanks From: Duncan Thomas [mailto:duncan.tho...@gmail.commailto:duncan.tho...@gmail.com] Sent: 26 May 2015 17:14 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] Do we need to fix issues in V1 API? In general, V1 is not being changed / fixed, though it is case-by-case, for example security issues will always be fixed. What exactly were you thinking about fixing? On 26 May 2015 at 14:17, Deore, Pranali11 pranali11.de...@nttdata.commailto:pranali11.de...@nttdata.com wrote: Hello, While fixing issues in V2 API, do we need to fix in V1 API? As per following blueprint description, V1 API is being deprecated in liberty-1. https://blueprints.launchpad.net/cinder/+spec/deprecate-v1-api Thanks Regards, Pranali Deore __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ 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] Redis as Messaging System
Zaqar provides an option to use Redis as a backend, and Zaqar provides pubsub messaging. On 05/23/2015 03:09 PM, Todd Crane wrote: Does anybody know of a way (either current projects or future plans) to use Redis PubSub as the messaging system for OpenStack? -Todd -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ 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] [tempest][qa][cinder] How to configure tempest with to test volume migration?
Good to see that you will work on this! In addition to the cases that Duncan mentioned, there is also the case of moving a volume between two pools within the same backend. This probably complicates the setup even further. On Mon, May 25, 2015 at 12:31 PM, Duncan Thomas duncan.tho...@gmail.com wrote: There doesn't seem to be an existing tempest test for this. I suggest writing the test so that it looks if there are two volume types defined, and if so uses them. Ideally you should test migration to and from lvm. There is offline migration (volume is available) and online migration (volume is attached), which are two completely separate code paths. Great to hear somebody I'd writing tests for this! On 25 May 2015 10:24, Sheng Bo Hou sb...@cn.ibm.com wrote: Hi everyone, I am planning to add test cases for volume migration for cinder into tempest. I am wondering how to enable multiple back-ends for cinder in tempest, and connect to different back-ends. For example, I configure one back-end for LVM and the other is for IBM Storwize V7000 driver. Then run the test named like test_volume_migration_LVM_Storwize to test if the migration really works fine. About the configuration, is this something tempest can do so far? Or is this something new we need to add? Thank you very much. Best wishes, Vincent Hou (侯胜博) Staff Software Engineer, Open Standards and Open Source Team, Emerging Technology Institute, IBM China Software Development Lab Tel: 86-10-82450778 Fax: 86-10-82453660 Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193 __ 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 -- *Avishay Traeger* *Storage RD* Mobile: +972 54 447 1475 E-mail: avis...@stratoscale.com Web http://www.stratoscale.com/ | Blog http://www.stratoscale.com/blog/ | Twitter https://twitter.com/Stratoscale | Google+ https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts | Linkedin https://www.linkedin.com/company/stratoscale __ 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] Cross-Project meeting, Tue May 26th, 21:00 UTC
Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting today at 21:00 UTC, with the following agenda: * Design Summit feedback (ttx) * CORS Support for OpenStack (krotscheck) [1] * Suggestions to evolve this meeting format in Liberty (ttx) * Open discussion announcements [1] https://review.openstack.org/#/c/179866/ See you there ! For more details on this meeting, please see: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][Plugins] A new 'monitoring' value is now introduced for groups in metadata.yaml
Hi to all, Previously, only limited number of values could be added to 'groups' parameter in metadata.yaml file of the plugin. These are: - network - storage - storage:: cinder - storage:: glance - hypervisor. Now you can also add 'monitoring' if your plugin has the corresponding functionality. This means, you plugin will fall into the required category of the Plugins Catalog. Here is the related CR [1] and updated documentation (if you haven't had a chance to read about 'groups' yet) [2]. Thanks! -- [1] https://review.openstack.org/#/c/185394/ [2] https://wiki.openstack.org/wiki/Fuel/Plugins#Brand_new_features -- Best regards, Irina PI Team Technical Writer skype: ira_live Trello board: https://trello.com/b/3nxd5wFq/irina-povolotskaya-tasks-tracking-board __ 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] [Cinder] Do we need to fix issues in V1 API?
In general, V1 is not being changed / fixed, though it is case-by-case, for example security issues will always be fixed. What exactly were you thinking about fixing? On 26 May 2015 at 14:17, Deore, Pranali11 pranali11.de...@nttdata.com wrote: Hello, While fixing issues in V2 API, do we need to fix in V1 API? As per following blueprint description, V1 API is being deprecated in liberty-1. https://blueprints.launchpad.net/cinder/+spec/deprecate-v1-api Thanks Regards, Pranali Deore __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ 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 -- Duncan Thomas __ 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] [Cinder] Do we need to fix issues in V1 API?
Hi Duncan, I am planning to fix following issues for V1 API, 1. https://bugs.launchpad.net/cinder/+bug/1454244 2. “VolumeNotFound” exception error message should be consistent across all APIs Please suggest. Thanks From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: 26 May 2015 17:14 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] Do we need to fix issues in V1 API? In general, V1 is not being changed / fixed, though it is case-by-case, for example security issues will always be fixed. What exactly were you thinking about fixing? On 26 May 2015 at 14:17, Deore, Pranali11 pranali11.de...@nttdata.commailto:pranali11.de...@nttdata.com wrote: Hello, While fixing issues in V2 API, do we need to fix in V1 API? As per following blueprint description, V1 API is being deprecated in liberty-1. https://blueprints.launchpad.net/cinder/+spec/deprecate-v1-api Thanks Regards, Pranali Deore __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ 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] [Zaqar][all] Zaqar will stay... Lots of work ahead
On 26/05/15 08:23 -0400, Ryan Brown wrote: On 05/26/2015 04:28 AM, Flavio Percoco wrote: [snip] As a first step, we should restore our meetings and get to work right away. To favor our contributors in NZ, next week's meeting will be at 21:00 UTC and we'll keep it at that time for 2 weeks. For those who didn't know what day the Zaqar meetings are normally, they are on Mondays according to the OpenStack calendar (next meeting on June 1). Damn, I always forget something. Yes, meetings are on Mondays with alternate times (15:00 and 21:00 UTC). We'll do 21:00 UTC for 2 weeks to have enough time to sync with folks from NZ. Cheers, Flavio -- @flaper87 Flavio Percoco pgpWFWObxyEAm.pgp 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] Add core approver Sam Yaple
+1 Sam has done an great job integrating his work into Kolla and I look forward to seeing more of his contributions! -Ryan - Original Message - From: Andre Martin martin.an...@kvhasia.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, May 25, 2015 9:37:24 PM Subject: Re: [openstack-dev] [kolla] Add core approver Sam Yaple On May 26, 2015, at 03:59, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: Hi folks, I propose Sam Yaple for core approver for the Kolla team. Sam has a lot of great ideas and has done some really cool work lately. Sam is active in IRC and is starting to pick up more reviews. Of particular interest to me his his idea of merging the work he has done on YAODU into Kolla. This would be fantastic for Kolla and allow us to deliver on our goals of providing high availability which depends on multi-node deployment in our container architecture. Some really complex and nice improvements to the codebase: https://review.openstack.org/#q,Ifc7bac0d827470f506c8b5c004a833da9ce13b90,n,z https://review.openstack.org/#q,Ic0ff96bb8119ddfab15b99e9f1e21cfe8d321dab,n,z https://review.openstack.org/#q,I95101136dad56e9331d8b92cd394495f7bd0576a,n,z Sam's stats for Liberty and Kilo: http://stackalytics.com/?project_type=alluser_id=s8mmodule=kollarelease=all Count my proposal as a +1. Since our core team is only 5 people presently, I think it makes sense to only require one additional +1. Typically projects require 3 +1 votes but have larger core teams, so we will use that in the future. -1 = veto, so vote wisely. Folks often abstain if they are not certain how their vote should go – so don’t feel compelled to vote. I’ll keep the voting open until May 29th. If the vote is unanimous or vetoed prior, I’ll close voting. Huge +1 for me. Sam is an excellent engineer with lots of interesting ideas, he would be a great addition to the core team. Martin Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev PLEASE NOTE: This email, and any attachments hereto, are intended only for use by the specified addressee(s) and may contain legally privileged and/or confidential and/or proprietary information of KVH Co., Ltd. and/or its affiliates (including personal information). If you are not the intended recipient of this email, please immediately notify the sender by email, and please permanently delete the original, any print out and any copies of the foregoing. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] vxlan support
Hi Samuel, VXLAN has critical status in Backlog for 7.0. We are going to include this segmentation type out of the box in 7.0. Meanwhile, you may create plugin for 6.1. Your help will be appreciated. I'll be glad to help you with plugins if you have any questions. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, May 26, 2015 at 10:29 AM, Samuel Bartel samuel.bartel@gmail.com wrote: Hi folks, I have a question about implementation of vxlan for neutron. there is a blueprint on that topic in launchpad from 2014/03/21: https://blueprints.launchpad.net/fuel/+spec/neutron-vxlan-support several fixes have been pushed but all of them have been abandonned or refused. Is there any technical reason to not having vxlan support on fuel or is it just not a priority for product manager? In fuel 5.0 and 5.1 we customize fuel in order to have this segmentation type. starting from fuel 6.0, I have made a plugin for vxlan but not totally satisfied by that way to process. It will be cleaner to having vlxan directly ship into fuel core. So if there is no technical issue and if it not already shiped into the advanced network topic, I can work on a fix to add this feature in fuel 7.0 regards Samuel __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Do we need to fix issues in V1 API?
I don't think either of those are likely to be accepted for V1, certainly I'd vote against it. They should be fixed in V2 however. On 26 May 2015 at 15:13, Deore, Pranali11 pranali11.de...@nttdata.com wrote: Hi Duncan, I am planning to fix following issues for V1 API, 1. https://bugs.launchpad.net/cinder/+bug/1454244 2. “VolumeNotFound” exception error message should be consistent across all APIs Please suggest. Thanks *From:* Duncan Thomas [mailto:duncan.tho...@gmail.com] *Sent:* 26 May 2015 17:14 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Cinder] Do we need to fix issues in V1 API? In general, V1 is not being changed / fixed, though it is case-by-case, for example security issues will always be fixed. What exactly were you thinking about fixing? On 26 May 2015 at 14:17, Deore, Pranali11 pranali11.de...@nttdata.com wrote: Hello, While fixing issues in V2 API, do we need to fix in V1 API? As per following blueprint description, V1 API is being deprecated in liberty-1. https://blueprints.launchpad.net/cinder/+spec/deprecate-v1-api Thanks Regards, Pranali Deore __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ 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 -- Duncan Thomas __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. __ 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 -- Duncan Thomas __ 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] [nova] xen project retrigger
On Mon, 25 May 2015 08:21:22 + Gary Kotton gkot...@vmware.com wrote: Hi, Anyone know how to retriever this CI? Thanks Gary their notification emails say To recheck use 'xen: recheck'. I also got a test failure from them today so maybe there is a general problem. Regards, Alex __ 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] [Fuel] Setting cluster status when provisioning a node
Aleksey, thank you for your feedback. The first thing I’d like to highlight is that both web ui and the cli use the same Nailgun API to perform the same actions so basically we must not treat the command line client any differently. The idea of having a complex status for environment actually seems to be pretty good one. However, that requires a BP so I’ve created an excerpt [1] which I’d like to share. If this feature is scoped, it will get life of many folks easier since it will allow to discard some sophisticated algorithms. - romcheg 1. https://etherpad.openstack.org/p/fuel-cluster-complex-status https://etherpad.openstack.org/p/fuel-cluster-complex-status 25 трав. 2015 о 10:39 Aleksey Kasatkin akasat...@mirantis.com написав(ла): AFAIC, there are several problems (in API) here: 1. We cannot stop/reset particular nodes. 2. Cluster status doesn't address changes which were done via CLI. 3. Cluster status in its current form is not enough to manage cluster (i.e. to determine actions what can be applied to cluster at the moment). It doesn't reflect the fact that some nodes can be in 'provisioned' state, some are in 'provisioning', 'deploying', 'ready' statuses. First two seem clear enough. We could add ability to stop/reset particular nodes and reflect CLI-driven changes in the cluster status. To address the last point my proposal was (bug/1449086/comments/7 https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086/comments/7) to break status into several binary states, i.e. binaries: 'new', 'deployment', 'ready', etc., each of which is set to true when cluster has at least one node in corresponding status (I united 'provisioning', 'provisioned' and 'deploying' into one as it is done now). Now it looks more reasonable to me to keep the original status as is and add bitwise one mentioned above (to address states of different nodes) because 'error' state is determinative for cluster (when cluster is in 'error' state it is no matter that some nodes are in 'ready' state). So, cluster is in 'new' state when all nodes are in 'discover' state, it is in 'operational' state when all nodes are in 'ready' state, cluster is in 'deployment' state when not all of its nodes are in 'discover' or 'ready' state but there are no nodes in 'error' and 'removing' states. New bitwise status is actual in 'deployment' state of cluster. It gives to UI/CLI sufficient data to determine what actions can be applied to cluster at the moment. I've combined some of the states combinations into the table: 'new' flag 'deployment' flag 'ready' flag description, actions allowed false false false There are no nodes in cluster or all nodes are in 'error'/'removing' state. Cluster is in 'new'/'error'/'remove' state here so we don't care about these flags. false true false All nodes are under provisioning/deployment. Deployment can be stopped. true true false Part of nodes is in 'discover' state, remaining part is under provisioning/deployment. Deployment can be started for the first part or/and stopped for the second part of nodes. true false true Part of nodes is in 'discover' state, remaining part is in 'ready' state. Deployment can be started for the first part and second part can be reset. true true true We have some nodes in every of the states: 'discover', provisioning/deployment, 'ready'. So, we can allow different actions for nodes in different states. false true true Part of nodes is under provisioning/deployment, remaining part is in 'ready' state. Deployment can be stopped for the first part and second part can be reset. I didn't show another 2 combinations here as they aren't related to 'deployment' state of cluster (as well as the first one in the table). Also, we should be careful with the order of nodes deployment/reset. I'm not sure whether it is written in our docs that cluster may be non-functional if user tries to deploy nodes in the wrong order (e.g. computes first). We could show some warnings about that. Same applies to selective reset if we will implement it. Aleksey Kasatkin On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me wrote: Hi folks! Recently I encountered an issue [1] that the Deploy Changes button in the web ui is still active when a provisioning of single node is started using the command line client. The background for that issue is that the provisioning task does not seem to update the cluster status correctly and Nailgun’s API returns it as NEW even while some of the node are been provisioned. The reason for raising this thread in the mailing list is that provisioning a node is a feature for developers and basically end-users should not do that. What is the best solution for that: fix Nailgun to set the correct status, or make this
Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison
Excerpts from Ghe Rivero's message of 2015-05-25 09:45:47 -0700: My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero Thanks for your help as liaison, Ghe, the Oslo team appreciates your effort! Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node
Oleg, Aleksander also proposed a nice proposed a nice solution [1] which is to have a complex status for cluster. That, however, looks like a BP so I’ve created an excerpt [2] for it and we will try to discuss it scope it for 7.0, if there is a consensus. References: 1. http://lists.openstack.org/pipermail/openstack-dev/2015-May/064670.html http://lists.openstack.org/pipermail/openstack-dev/2015-May/064670.html 2. https://etherpad.openstack.org/p/fuel-cluster-complex-status https://etherpad.openstack.org/p/fuel-cluster-complex-status - romcheg 22 трав. 2015 о 22:32 Oleg Gelbukh ogelb...@mirantis.com написав(ла): Roman, I'm totally for fixing Nailgun. However, the status of environment is not simply function of statuses of nodes in it. Ideally, it should depend on whether appropriate number of nodes of certain roles are in 'ready' status. For the meantime, it would be enough if environment was set to 'operational' when all nodes in it become 'ready', no matter how they were deployed (i.e. via Web UI or CLI). -- Best regards, Oleg Gelbukh On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me wrote: Hi folks! Recently I encountered an issue [1] that the Deploy Changes button in the web ui is still active when a provisioning of single node is started using the command line client. The background for that issue is that the provisioning task does not seem to update the cluster status correctly and Nailgun’s API returns it as NEW even while some of the node are been provisioned. The reason for raising this thread in the mailing list is that provisioning a node is a feature for developers and basically end-users should not do that. What is the best solution for that: fix Nailgun to set the correct status, or make this provisioning feature available only for developers? 1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086 https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086 - romcheg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] [Neutron] Stepping down from Neutron core team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/21/2015 05:58 PM, Salvatore Orlando wrote: After putting the whole OpenStack networking contributors community through almost 8 cycles of pedant comments and annoying what if questions, it is probably time for me to relieve neutron contributors from this burden. It has been a pleasure for me serving the Neutron community (or Quantum as it was called at the time), and now it feel right - and probably overdue - to relinquish my position as a core team member in a spirit of rotation and alternation between contributors. Note: Before you uncork your champagne bottles, please be aware that I will stay in the Neutron community as a contributors and I might still end up reviewing patches. I only hope that you won't stay for too long without dropping knowledge bombs upon us, as you usually do. Thanks for all your efforts till now and in the future, Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVZHOXAAoJEC5aWaUY1u57UV4IAIXHUQQdMa7yH4Dkb4YR/l45 Md2HHmxZ9DgYhLttCnhKWVWNstlwKaZNMM4s/uqQxBOrPTpxnJLEOxDc2mwvWppf bsi5f9y6h8uOt3XJwiY4KR/1+bRafaeLeFDOLooyXQHVlMZ7tT9zExg6MeFneO8I xRBbK+DLTwk0jcDsBr5Y6ZI63DkiTeE4PoeRNiLzXQUS7i98PnL+TpVAVL0OHKrC y9hIOZqzd2OsSeOD/njFdhTXa7dn+gUwTisTf6Jh9jXpgIC8rhz5Y95pgi8f4tYH 6nKl52Qi7W7s8WI7z5tPNke/TX8HUfbGbn2T2QVMdRA7iN3OEWkL4pDCsuIKcyQ= =JOD8 -END 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] [ceilometer][all] Scalable metering
We had a good discussion at the summit regarding ceilometer scaling. Julien has written up some of the items discussed in https://julien.danjou.info/blog/2015/openstack-summit-liberty-vancouver-ceilometer-gnocchi and there is work ongoing in the storage area for scalable storage of ceilometer data using gnocchi. I'd like community input on the other scalability concern raised during the event, namely the load on other services when ceilometer is enabled. From the blog, Ceilometer hits various endpoints in OpenStack that are poorly designed, and hitting those endpoints of Nova or other components triggers a lot of load on the platform.. I would welcome suggestions on how to identify the potential changes in the OpenStack projects and improve the operator experience when deploying metering. Tim __ 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] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
On 05/26/2015 01:12 PM, Salvatore Orlando wrote: From the bug Kevin reported it seems multiple dhcp agents per network have been completely broken by the fix for bug #1345947, so a revert of patch [1] (and stable backports) should probably be the first thing to do - if nothing else because the original bug has not nearly the same level of severity of the one it introduced. Before doing this however, I am wondering why the various instances of dnsmasq end up returning NAKs. I expect all instances to have the same hosts file, so they should be able to respond to DHCPDISCOVER/DHCPREQUEST correctly. Is the dnsmasq log telling us exactly why the authoritative setting is preventing us from doing so? (this is more of a curiosity in my side) [1] https://review.openstack.org/#/c/152080/ In the original case, the DHCPREQUEST is for a renew, which is different than for an initial request. If the server does not have a lease entry (which it won't after a restart), then it will NAK, which normally just causes the client to retry at INIT state. I had asked on the dnsmasq list about this [1], and the multiple server question was the wildcard, my testing didn't see the error described in the new bug though. I guess the first proposed fix of re-populating the lease information doesn't seem like such a bad idea any more, but I will reply to my original query with the tcpdump information since I'm confused as to why the second dhcp agent stepped-in with a NAK at all after originally offering the same address as the first dhcp agent [2]. I would agree the best thing to do is revert the stable backports while we work on fixing this in the master branch. -Brian [1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q1/009171.html [2] https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html On 26 May 2015 at 06:57, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/26/2015 04:35 AM, Kevin Benton wrote: Hi, A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2]. This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them. I have two fixes for this so far and a third alternative if we don't like those. The first is hacky, but it's only a few-line change.[3] It adds an iptables rule that just stops the DHCPNAKs from making it to the client. This is clean to back-port but it doesn't protect clients that have filtering disabled (e.g. bare metal). The second persists the DHCP leases to a database.[4] The downside to this was always that being rescheduled to another agent would mean no entries in the lease file. This approach adds a work-around to generate an initial fake lease file based on all of the ports in the network. A third approach that I don't have a patch pushed for yet is very similar to the second. When dnsmasq is in the leasefile-ro mode, it will call the script passed to --dhcp-script to get a list of leases to start with. This script would be built with the same logic as the second one. The only difference between the second approach is that dnsmasq wouldn't persist leases to a database. Actually, that approach was initially taken for bug 1345947, but then the patch was abandoned to be replaced with a simpler - --dhcp-authoritative approach that ended up with unexpected NAKs for multi agent setup. See: https://review.openstack.org/#/c/108272/12 Maybe we actually want to restore the work and merge it after conflicts are resolved and --dhcp-authoritative option is killed; the patch was almost merged when --dhcp-authoritative suggestion emerged, so most of nitpicking work should be complete now (though at the same time, I totally trust our community to find another pile of nits to work on for the next few weeks!) That was my thought as well. However, we should check whether that patch is ok to backport. For instance I see what it appears to be adding a script: [2] https://review.openstack.org/#/c/108272/12/bin/neutron-dhcp-agent-dnsmasq-lease-init === Speaking of regression testing... Are full stack tests already powerful enough for us to invoke multiple DHCP agents and test the scenario? Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8 Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w 7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS
[openstack-dev] [Neutron]: DVR Presentation slides from the Vancouver summit
Hi Folks, Unfortunately our presentation video is missing from the OpenStack Vancouver summit website. But there was a lot more request for the slides that we presented in the summit. Here is the link to the slides that we presented in the OpenStack Vancouver summit. https://drive.google.com/file/d/0B4kh-7VVPWlPYXNaQWxXd1NDdm8/view?usp=sharing Please let me know if you have any questions. thanks Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com __ 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] [Glance] [all] Liberty summit: Updates in Glance
Thank you Jesse for your valuable input (here and at the summit) as well as intent to clarify the discussion. Just trying to ensure people are aware about the EXPERIMENTAL nature of the v3 API and reasons behind it. Please find my responses in-line. However, I do want to ensure you all, that we will strive hard to move away from the EXPERIMENTAL nature and go with a rock solid implementation as and when interest grows in the code-base (that helps stabilize it). On 5/26/15 12:57 PM, Jesse Cook wrote: On 5/22/15, 4:28 PM, Nikhil Komawar nik.koma...@gmail.com mailto:nik.koma...@gmail.com wrote: Hi all, tl;dr; Artifacts IS staying in Glance. 1. We had a nice discussion at the contributors' meet-up at the Vancouver summit this morning. After weighing in many possibilities and evolution of the Glance program, we have decided to go ahead with the Artifacts implementation within Glance program under the EXPERIMENTAL v3 API. Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. That is to say, Artifacts is the technical implementation of the v3 API. This also means the v3 API is an objects API vs just an images API. Generic data assets' API would be a nice term along the lines of the mission statement. Artifacts seemed fitting as that was the focus of discussion at various sessions. We also had some hallway talk about putting the v1 and v2 APIs on top of the v3 API. This forces faster adoption, verifies supportability via v1 and v2 tests, increases supportability of v1 and v2 APIs, and pushes out the need to kill v1 API. Let's discuss more as time and development progresses on that possibility. v3 API should stay EXPERIMENTAL for now as that would help us understand use-cases across programs as it gets adopted by various code-bases. Putting v1/v2 on top of v3 would be tricky for now as we may have breaking changes with code being relatively-less stable due to narrow review domain. 1. 2. The effort would primarily be conducted as a sub-team-like structure within the program and the co-coordinators and drivers of the necessary Artifacts features would be given core-reviewer status temporarily with an informal agreement to merge code that is only related to Artifacts. 3. The entire Glance team would give reviews as time and priorities permit. The approval (+A/+WorkFlow) of any code within the program would need to come from core-reviewers who are not temporarily authorized. The list of such individuals and updated time-line would be documented in phases during the course of Liberty cycle. 4. We will continue to evaluate update the governance, maturity of the code and future plans for the v1, v2 and v3 Glance APIs as time progresses. However, for now we are aiming to integrate all of Glance (specifically Images) as Artifacts in the v3 API. As I understand it, that is to say that v3 requests in the first “micro-version” that specify the object type as image would get a not implemented or similar error. The next next “micro-version” would likely contain the support for images along with possibly implementing the v1 and v2 APIs on top of v3. As we will have EXPERIMENTAL v3 API, we should try to avoid micro-versions. However, we should soon consider this as a possibility once things seem to stabilize. 1. Special thanks to Flavio for providing DefCore and TC perspective as well as initializing this discussion. Also, thanks to Stuart McLaren and Brian Rosmaita for giving us thoughtful veteran feedback. The entire team did a great job at putting all their questions and concerns amicably on the table and came to a good understanding of the plan and level of commitment. All the best to the Project SearchLight team who have decided to start ElasticSearch based development for search functionality in OpenStack as a separate program and would be porting respective code out of Glance. Glance team would help co-ordinate this porting effort in order to avoid destabilizing Images and MetaDefs code-bases. This also means we will re-evaluate some of the existing spec proposals and most likely not ask people for radical changes in their approach. This first phase of the Liberty cycle would focus on seeing the Experimental Artifacts API through. We will also focus on stability aspects of the Images (v1 v2) related features. The second phase priorities would be decided at the mid-cycle meet-up (details to come out soon). Feel free to ask me questions on IRC or via email. Cheers, Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [CI] gate wedged by tox = 2.0
On 5/14/2015 9:50 AM, Brant Knudson wrote: On Thu, May 14, 2015 at 9:41 AM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: On 5/14/2015 5:46 AM, Sean Dague wrote: On 05/14/2015 04:16 AM, Robert Collins wrote: Tox 2.0 just came out, and it isolates environment variables - which is good, except if you use them (which we do). So everything is broken. https://review.openstack.org/182966 Should fix it until projects have had time to fix up their local tox.ini's to let through the needed variables. As an aside it might be nice to get this specifier from global-requirements, so that its managed in the same place as all our other specifiers. This will only apply to tempest jobs, and I see lots of tempest jobs passing without it. Do we have a bug with some failures linked because of it? If this is impacting unit tests, that has to be directly fixed there. -Sean python-novaclient, neutron and python-manilaclient are being tracked against bug https://bugs.launchpad.net/neutron/+bug/1455102. Heat is being tracked against bug https://bugs.launchpad.net/heat/+bug/1455065. -- Thanks, Matt Riedemann Here's the fix in keystoneclient if you need an example: https://review.openstack.org/#/c/182900/ It just added passenv =OS_* If you're seeing jobs pass without the workaround then those jobs are probably not running with tox=2.0. - Brant __ 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 There is a similar issue with horizon: https://bugs.launchpad.net/horizon/+bug/1458928 It's specifically busted on stable/kilo. I think it's not hitting on master because the jshint stuff has been cleaned up a bit on master and it's less strict in the run, which .jshintrc was handling before and why it fails on stable/kilo. I'll be pushing a change soon. We might think about capping tox2.0 on stable branches though... -- Thanks, Matt Riedemann __ 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] [Openstack] PCI pass-through SRIOV
- Original Message -
From: Moshe Levi mosh...@mellanox.com
To: RaghavendraChari Kamsali (Artesyn)
raghavendrachari.kams...@artesyn.com, OpenStack Development Mailing List
This is a different error
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] if ret == -1: raise libvirtError
('virDomainCreateWithFlags() failed', dom=self)
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] libvirtError: internal error: process
exited while connecting to monitor: 2015-05-26T04:34:07.980897Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed
to open /dev/vfio/vfio: Operation not permitted
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980951Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed
to setup container for group 49
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980970Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed
to get group 49
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980995Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: Device
initialization failed.
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.981019Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: Device
'vfio-pci' could not be initialized
You are using intel card therefore I think you should contact them and ask if
this card is supported.
In addition there are a number of Intel cards for which ACS quirks had to be
added to the kernel, this was done fairly recently in patches like this one:
http://www.spinics.net/lists/kernel/msg1951202.html
You may want to check whether a) your card is one of those impacted and b) your
kernel has these patches, though your output does not appear to be an exact
match for what we were seeing in
https://bugzilla.redhat.com/show_bug.cgi?id=1141399
Thanks,
--
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform
__
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] [Nova] Using depends-on for patches which require an approved spec
On Fri, May 22, 2015 at 02:57:23PM -0700, Michael Still wrote: Hey, it would be cool if devs posting changes for nova which depend on us approving their spec could use Depends-On to make sure their code doesn't land until the spec does. Does it actually bring any benefit ? Any change for which there is a spec is already supposed to be tagged with 'Blueprint: foo-bar-wiz' and nova core devs are supposed to check the blueprint is approved before +A'ing it. So also adding a Depends-on just feels redundant to me, and so is one more hurdle for contributors to remember to add. If we're concerned people forget the Blueprint tag, or forget to check blueprint approval, then we'll just have same problem with depends-on - people will forget to add it, and cores will forget to check the dependant change. So this just feels like extra rules for no gain and extra pain. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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] [designate] and [lbaas] - GSLB API and backend support
Hi, I would also like to participate. Friday is a non-working day in Israel (same as Saturday for most of you). So Monday- Thursday works best for me. -Sam. From: Doug Wiegley [mailto:doug...@parksidesoftware.com] Sent: Saturday, May 23, 2015 8:45 AM To: OpenStack Development Mailing List (not for usage questions) Cc: kunalhgan...@gmail.com; v.jain...@gmail.com; do...@a10networks.com Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend support Of those two options, Friday would work better for me. Thanks, doug On May 22, 2015, at 9:33 PM, ki...@macinnes.iemailto:ki...@macinnes.ie wrote: Hi Kunal, Thursday/Friday works for me - early morning PT works best, as I'm based in Ireland. I'll find some specific times the Designate folks are available over the next day or two and provide some options.. Thanks, Kiall On 22 May 2015 7:24 pm, Gandhi, Kunal kunalhgan...@gmail.commailto:kunalhgan...@gmail.com wrote: Hi All I wanted to start a discussion about adding support for GSLB to neutron-lbaas and designate. To be brief for folks who are new to GLB, GLB stands for Global Load Balancing and we use it for load balancing traffic across various geographical regions. A more detail description of GLB can be found at my talk at the summit this week herehttps://www.youtube.com/watch?v=fNR0SW3vj_s. To my understanding, there are two sides to a GSLB - DNS side and LB side. DNS side Most of the GSLB’s provided by various vendors are DNS servers and are authoritative for the GLB domains. The global fqdn’s that belong the GLB domains resolve to multiple public VIP’s across various regions based on various configurations on the global fqdn on the GLB. LBaaS side A few of the common functionalities provided by a standard GSLB provides are health monitoring on the public VIP’s and the local LB’s on which these public VIP’s sit on. Some additional features that a GSLB can provide are configuring admin status and weights on your public VIP’s. Based on these configurations and settings, the GLB returns the appropriate number of public VIP’s to any DNS resolve queries for the global fqdn’s. I would like to have the designate and lbaas to start a discussion on GSLB and discuss the following topics: * What parts of GSLB belongs to Designate and LBaaS ? * Once we have an understanding of the above, my team at eBay/PayPal would like work with the community on submitting a blueprint for this. To kick start this conversation, I would like to schedule an irc meeting regarding this with folks from designate and neutron-lbaas. Please let me know a time and day that works for you guys. I am available on Thursday and Friday next week. Regards Kunal __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] dashboard-app split in horizon
On Mon, May 25, 2015 at 5:35 PM, Richard Jones r1chardj0...@gmail.com wrote: As a follow-up to this [in the misguided hope that anyone will actually read this conversation with myself ;-)] I've started looking at the base.html split. At the summit last week, we agreed to: 1. move base.html over from the framework to the dashboard, and 2. move the _conf.html and _scripts.html over as well, since they configure the application (dashboard). Upon starting the work it occurs to me that all of the other files referenced by base.html should also move. So, here's the complete list of base.html components and whether they should move over in my opinion: - horizon/_custom_meta.html Yep, is an empty file in horizon, intended as an extension point in dashboard. The empty file (plus an added comment) should move. - horizon/_stylesheets.html Is just a dummy in horizon anyway, should move. - horizon/_conf.html Yep, should move. - horizon/client_side/_script_loader.html Looks to be a framework component not intended for override, so we should leave it there. - horizon/_custom_head_js.html Yep, is an empty file in horizon, intended as an extension point in dashboard. Move, with a comment added. - horizon/_header.html There is a basic implementation in framework but the real (used) implementation is in dashboard, so should move. - horizon/_messages.html This is a framework component, so I think should stay there. I'm not sure whether anyone would ever wish to override this. Also the bulk of it is probably going to be replaced by the toast implementation anyway... hmm... - horizon/common/_sidebar.html This is an overridable component that I think should move. - horizon/common/_page_header.html This is an overridable component that I think should move. - horizon/_scripts.html Yep, should move. Thoughts, anyone who has read this far? Richard On Sat, 23 May 2015 at 11:46 Richard Jones r1chardj0...@gmail.com wrote: As part of the ongoing Horizon project code reorganisation, we today agreed to clean up the Horizon-the-Framework and OpenStack Dashboard separation issue by doing a couple of things: 1. nuke (the recently-created) horizon dashboard-app by moving the angular app over to dashboard and the other contents to appropriate places (mostly under the heading of tech-debt :) 2. move base.html, _conf.html and _scripts.html from horizon over to dashboard. Thanks to Cindy, Sean and Thai for the pair (er triple?) programming keeping me honest today. The first step is done and captured in several linked patches based off your leaf patch ngReorg - Create dashboard-app https://review.openstack.org/#/c/184597/ (yes, I am nuking the thing created by your patch). I've not done the second step, but might find some time since I have 6 hours to waste in LAX tomorrow. Richard __ 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 This all sounds reasonable to me. We have better extension mechanisms than in the past so direct reuse of the horizon toolkit part is not necessary and we have little interest in maintaining the horizon toolkit as a generally reusable toolkit now. Moving the application pieces into openstack_dashboard (the actual application) makes sense. David __ 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] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions
We are considering adding network classes “rules” to LBaaS. In this case, such network classes could als be used to white/black list traffic. From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Friday, May 22, 2015 12:46 AM To: openstack-dev@lists.openstack.org; maishsk+openst...@maishsk.com Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions Right now its all or nothing as far as tcp ports go. It currently does not have the functionality of white/black listinging traffic originating from a specific network. From: Maish Saidel-Keesing mais...@maishsk.commailto:mais...@maishsk.com Sent: Thursday, May 21, 2015 7:45 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions Thanks Brandon On 05/20/15 22:58, Brandon Logan wrote: Just to add a few things, Barbican is not yet implemented in Octavia, though the code is there, we just need to spend a few hours hooking it all up and testing it out. Also, the security groups are used by octavia right now so that only the ports on the listener are accessible. Basically if a loadbalancer has listeners on ports 80 and 443, the vip ports will only allow traffic on those ports. It shouldn't allow other traffic. That is great to hear. I assume that if we are using security groups we will also be able to define rules regarding which networks the listeners are allowed to accept traffic from? Is that assumption correct? Thanks, Brandon From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Sent: Thursday, May 21, 2015 12:49 AM To: maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com; OpenStack Development Mailing List (not for usage questions); Maish Saidel-Keesing Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions Hi Maish, Thanks for the feedback, some answers below. Please also be aware of the lbaas use cases session tomorrow at 9am (yuck, I know), https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing mais...@maishsk.commailto:mais...@maishsk.com wrote: Hello all, Going over today's presentation Load Balancing as a Service, Kilo and Beyond[1] (great presentation!!) - there are a few questions I have regarding the future release: For Octavia 1.0: 1. Can someone explain to me how the flow would work for spinning up a a new Amphora with regards to interaction between Neutron, LBaaS and Barbican? Same question as well regarding how the standby is created and its relationship with Barbican. The lbaas API runs inside neutron-server. The general flow is: - User interacts with neutron CLI/API or horizon (in liberty), and creates an LB. - Lbaas plugin in neutron creates logical models, fetches cert data from barbican, and calls the backend lbaas driver. - The backend driver does what it needs to to instantiate the LB. Today this is a synchronous call that waits for the nova boot, but by Liberty, it will likely be an async call to the octavia controller to finish the job. Once Octavia has control, it is doing: - Get REST calls for objects, - Talk to nova, spin up an amphora image, - Talk to neutron, plumb in the networks, - Send the amphora its config. 2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is released or only further down the line? If not what would you suggest be the way to orchestrate LBaaS until this is ready? We need to talk to the Heat folks and coordinate this, which we are planning to do soon. 3. Is there some kind of hook into Security groups also planned for the Amphora to also protect the Load Balancer? Not at present, but I recorded this in the feature list on the etherpad above. I think that based on the answers to these questions above - additional questions will follow. Thanks [1] https://www.youtube.com/watch?v=-eAKur8lErU -- Best Regards, Maish Saidel-Keesing __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards, Maish Saidel-Keesing __ 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] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions
Hi Dani, Can you please explain further the 3rd use case (Multiple FIPs….)? Regards, -Sam. From: Daniel Comnea [mailto:comnea.d...@gmail.com] Sent: Friday, May 22, 2015 10:09 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions My $0.2 cents: I echo what Maish said with regards to functionality: - integration with HEAT is a must from Day -1 (if there is anything like this :) ) otherwise will be hard to gain operators traction. Look it as the entry point for everyone trying to move from Neutron LB - white/ black listing traffic based on source port/ network/IP - multiple FIPs associated with 1 LB, the use case is: say i have 1 LB open for port tcp 80 udp 88 listening on 2 FIPs (even registered into a DNS) and 2 different set of clients consuming this interfaces - frontend and backend Dani Dani On Thu, May 21, 2015 at 10:45 PM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: Right now its all or nothing as far as tcp ports go. It currently does not have the functionality of white/black listinging traffic originating from a specific network. From: Maish Saidel-Keesing mais...@maishsk.commailto:mais...@maishsk.com Sent: Thursday, May 21, 2015 7:45 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions Thanks Brandon On 05/20/15 22:58, Brandon Logan wrote: Just to add a few things, Barbican is not yet implemented in Octavia, though the code is there, we just need to spend a few hours hooking it all up and testing it out. Also, the security groups are used by octavia right now so that only the ports on the listener are accessible. Basically if a loadbalancer has listeners on ports 80 and 443, the vip ports will only allow traffic on those ports. It shouldn't allow other traffic. That is great to hear. I assume that if we are using security groups we will also be able to define rules regarding which networks the listeners are allowed to accept traffic from? Is that assumption correct? Thanks, Brandon From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Sent: Thursday, May 21, 2015 12:49 AM To: maishsk+openst...@maishsk.commailto:maishsk+openst...@maishsk.com; OpenStack Development Mailing List (not for usage questions); Maish Saidel-Keesing Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions Hi Maish, Thanks for the feedback, some answers below. Please also be aware of the lbaas use cases session tomorrow at 9am (yuck, I know), https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing mais...@maishsk.commailto:mais...@maishsk.com wrote: Hello all, Going over today's presentation Load Balancing as a Service, Kilo and Beyond[1] (great presentation!!) - there are a few questions I have regarding the future release: For Octavia 1.0: 1. Can someone explain to me how the flow would work for spinning up a a new Amphora with regards to interaction between Neutron, LBaaS and Barbican? Same question as well regarding how the standby is created and its relationship with Barbican. The lbaas API runs inside neutron-server. The general flow is: - User interacts with neutron CLI/API or horizon (in liberty), and creates an LB. - Lbaas plugin in neutron creates logical models, fetches cert data from barbican, and calls the backend lbaas driver. - The backend driver does what it needs to to instantiate the LB. Today this is a synchronous call that waits for the nova boot, but by Liberty, it will likely be an async call to the octavia controller to finish the job. Once Octavia has control, it is doing: - Get REST calls for objects, - Talk to nova, spin up an amphora image, - Talk to neutron, plumb in the networks, - Send the amphora its config. 2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is released or only further down the line? If not what would you suggest be the way to orchestrate LBaaS until this is ready? We need to talk to the Heat folks and coordinate this, which we are planning to do soon. 3. Is there some kind of hook into Security groups also planned for the Amphora to also protect the Load Balancer? Not at present, but I recorded this in the feature list on the etherpad above. I think that based on the answers to these questions above - additional questions will follow. Thanks [1] https://www.youtube.com/watch?v=-eAKur8lErU -- Best Regards, Maish Saidel-Keesing __ OpenStack
Re: [openstack-dev] [Horizon] dashboard-app split in horizon
Looks/sounds good, I started down this path a while ago and it never gained traction, so glad to see that it is finally moving along.-Richard Jones r1chardj0...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Richard Jones r1chardj0...@gmail.comDate: 05/25/2015 05:38PMCc: "Johanson, Tyr H" t...@hp.comSubject: Re: [openstack-dev] [Horizon] dashboard-app split in horizonAs a follow-up to this [in the misguided hope that anyone will actually read this conversation with myself ;-)] I've started looking at the base.html split. At the summit last week, we agreed to:1. move base.html over from the framework to the dashboard, and2. move the _conf.html and _scripts.html over as well, since they configure the application (dashboard).Upon starting the work it occurs to me that all of the other files referenced by base.html should also move. So, here's the complete list of base.html components and whether they should move over in my opinion:- horizon/_custom_meta.html Yep, is an empty file in horizon, intended as an extension point in dashboard. The empty file (plus an added comment) should move. - horizon/_stylesheets.html Is just a dummy in horizon anyway, should move.- horizon/_conf.html Yep, should move.- horizon/client_side/_script_loader.html Looks to be a framework component not intended for override, so we should leave it there.- horizon/_custom_head_js.html Yep, is an empty file in horizon, intended as an extension point in dashboard. Move, with a comment added.- horizon/_header.html There is a basic implementation in framework but the real (used) implementation is in dashboard, so should move.- horizon/_messages.html This is a framework component, so I think should stay there. I'm not sure whether anyone would ever wish to override this. Also the bulk of it is probably going to be replaced by the toast implementation anyway... hmm...- horizon/common/_sidebar.html This is an overridable component that I think should move.-horizon/common/_page_header.html This is an overridable component that I think should move.-horizon/_scripts.html Yep, should move.Thoughts, anyone who has read this far? RichardOn Sat, 23 May 2015 at 11:46 Richard Jones r1chardj0...@gmail.com wrote:As part of the ongoing Horizon project code reorganisation, we today agreed to clean up the Horizon-the-Framework and OpenStack Dashboard separation issue by doing a couple of things:1. nuke (the recently-created) horizon dashboard-app by moving the angular app over to dashboard and the other contents to appropriate places (mostly under the heading of "tech-debt" :)2. move base.html, _conf.html and _scripts.html from horizon over to dashboard.Thanks to Cindy, Sean and Thai for the pair (er triple?) programming keeping me honest today.The first step is done and captured in several linked patches based off your leaf patch "ngReorg - Create dashboard-app" https://review.openstack.org/#/c/184597/ (yes, I am nuking the thing created by your patch).I've not done the second step, but might find some time since I have 6 hours to waste in LAX tomorrow. Richard __OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging][zeromq] Next step
Alec, Here are the slides: http://www.slideshare.net/davanum/oslomessaging-new-0mq-driver-proposal All the 0mq patches to date should be either already merged in trunk or waiting for review on trunk. Oleksii, Li Ma, Can you please address the other questions? thanks, Dims On Tue, May 26, 2015 at 11:43 AM, Alec Hothan (ahothan) ahot...@cisco.com wrote: Looking at what is the next step following the design summit meeting on 0MQ as the etherpad does not provide too much information. Few questions: - would it be possible to have the slides presented (showing the proposed changes in the 0MQ driver design) to be available somewhere? - is there a particular branch in the oslo messaging repo that contains 0MQ related patches - I'm more particularly interested by James Page's patch to pool the 0MQ connections but there might be other - question for Li Ma, are you deploying with the straight upstream 0MQ driver or with some additional patches? The per node proxy process (which is itself some form of broker) needs to be removed completely if the new solution is to be made really broker-less. This will also eliminate the only single point of failure in the path and reduce the number of 0MQ sockets (and hops per message) by half. I think it was proposed that we go on with the first draft of the new driver (which still keeps the proxy server but reduces the number of sockets) before eventually tackling the removal of the proxy server? Thanks Alec __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [ceilometer][all] Scalable metering
Hi Tim, Maybe you should consider Monasca[1], Monitoring At Scale solution for OpenStack, or, at least, a few concepts of it. [1] https://wiki.openstack.org/wiki/Monasca []s Henrique Truta Em ter, 26 de mai de 2015 às 14:49, Tim Bell tim.b...@cern.ch escreveu: We had a good discussion at the summit regarding ceilometer scaling. Julien has written up some of the items discussed in https://julien.danjou.info/blog/2015/openstack-summit-liberty-vancouver-ceilometer-gnocchi and there is work ongoing in the storage area for scalable storage of ceilometer data using gnocchi. I’d like community input on the other scalability concern raised during the event, namely the load on other services when ceilometer is enabled. From the blog, “Ceilometer hits various endpoints in OpenStack that are poorly designed, and hitting those endpoints of Nova or other components triggers a lot of load on the platform.”. I would welcome suggestions on how to identify the potential changes in the OpenStack projects and improve the operator experience when deploying metering. Tim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstackclient] Use and practices of --format shell for defining individual variables
I came across the following neutron client specific syntax and decided to
see if I could reproduce using the openstack client and it's flexible
formatting capabilities
$ NIC_ID1=$(neutron net-show public | awk '/ id /{print $4}')
$ echo $NIC_ID1
210d976e-16a3-42dc-ac31-f01810dbd297
...
The show commands for neutron client and OSC have a format 'value' option
that may help:
$ os network show -c id -f value netty
00d7e1af-8749-411f-96da-3bda20601cb3
$ NETTY_ID=$(os network show -c id -f value netty)
$ echo $NETTY_ID
00d7e1af-8749-411f-96da-3bda20601cb3
__
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] [cinder] Some Changes to Cinder Core
Well deserved. Congrat! -Original Message- From: yang, xing [mailto:xing.y...@emc.com] Sent: Friday, May 22, 2015 8:52 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [cinder] Some Changes to Cinder Core Definitely +1! Thanks, Xing -Original Message- From: Mike Perez [mailto:thin...@gmail.com] Sent: Friday, May 22, 2015 7:34 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [cinder] Some Changes to Cinder Core This is long overdue, but it gives me great pleasure to nominate Sean McGinnis for Cinder core. Reviews: https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z Contributions: https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z 30/90 day review stats: http://stackalytics.com/report/contribution/cinder-group/30 http://stackalytics.com/report/contribution/cinder-group/90 As new contributors step up to help in the project, some move onto other things. I would like to recognize Avishay Traeger for his contributions, and now unfortunately departure from the Cinder core team. Cinder core, please reply with a +1 for approval. This will be left open until May 29th. Assuming there are no objections, this will go forward after voting is closed. -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
On Tue, May 26, 2015 at 11:05 AM, Brian Haley brian.ha...@hp.com wrote: On 05/26/2015 01:12 PM, Salvatore Orlando wrote: From the bug Kevin reported it seems multiple dhcp agents per network have been completely broken by the fix for bug #1345947, so a revert of patch [1] (and stable backports) should probably be the first thing to do - if nothing else because the original bug has not nearly the same level of severity of the one it introduced. As long as we confirm that the severity of this bug is accurately represented in the bug report, then this is the first thing we should do. However, see below. We tried this and did not encounter the error in at least one experiment. Are we sure that this is broken everywhere multiple servers is used? I'm checking internally to confirm that we have run this successfully. Before doing this however, I am wondering why the various instances of dnsmasq end up returning NAKs. I expect all instances to have the same hosts file, so they should be able to respond to DHCPDISCOVER/DHCPREQUEST correctly. Is the dnsmasq log telling us exactly why the authoritative setting is preventing us from doing so? (this is more of a curiosity in my side) [1] https://review.openstack.org/#/c/152080/ I also think we should understand more about this problem. I think that understanding more specifics around the bug will help. The details are a bit unclear to me. In the original case, the DHCPREQUEST is for a renew, which is different than for an initial request. If the server does not have a lease entry (which it won't after a restart), then it will NAK, which normally just causes the client to retry at INIT state. I had asked on the dnsmasq list about this [1], and the multiple server question was the wildcard, my testing didn't see the error described in the new bug though. I guess the first proposed fix of re-populating the lease information doesn't seem like such a bad idea any more, but I will reply to my original query with the tcpdump information since I'm confused as to why the second dhcp agent stepped-in with a NAK at all after originally offering the same address as the first dhcp agent [2]. I remember being concerned about the multiple dnsmasq case. I also remember having tried it and thought that it was working as expected. I would agree the best thing to do is revert the stable backports while we work on fixing this in the master branch. I think we can propose the reverts but until we confirm the severity of this bug, I don't want them to merge. Carl __ 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] [cinder] Some Changes to Cinder Core
+1 for Sean. He's done a great job doing reviews and getting involved in core Cinder features. Walt On 05/22/2015 04:34 PM, Mike Perez wrote: This is long overdue, but it gives me great pleasure to nominate Sean McGinnis for Cinder core. Reviews: https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z Contributions: https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z 30/90 day review stats: http://stackalytics.com/report/contribution/cinder-group/30 http://stackalytics.com/report/contribution/cinder-group/90 As new contributors step up to help in the project, some move onto other things. I would like to recognize Avishay Traeger for his contributions, and now unfortunately departure from the Cinder core team. Cinder core, please reply with a +1 for approval. This will be left open until May 29th. Assuming there are no objections, this will go forward after voting is closed. -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev . __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] oslo.log release 1.2.0 (liberty)
We are thrilled to announce the release of: oslo.log 1.2.0: oslo.log library With source available at: http://git.openstack.org/cgit/openstack/oslo.log For more details, please see the git log history below and: http://launchpad.net/oslo.log/+milestone/1.2.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.log Changes in oslo.log 1.1.0..1.2.0 7730773 Use proper deprecation for use-syslog-rfc-format option 33f5c6f Replace RFCSysLogHandler by a syslog() based one 36c925e Make remove_in=0 (no removal) use a better syntax 37166ac Remove is_compatible from versionutils e9a11f4 Add versionutils options to list_opts 3a4dc52 Add versionutils to API documentation cc713ab Advertise support for Python3.4 / Remove support for Python 3.3 39da8f9 Updated from global requirements 00036e7 Updated from global requirements 187881e Remove run_cross_tests.sh dbae3bf Deprecate WritableLogger - used for eventlet logging b457dae Log deprecation message when catching deprecated exceptions 27f7fe5 Change misleading TRACE to ERROR 6472777 Provide an API to let tempest control the log file 07d2641 fix pep8 errors c750167 Add pypi download + version badges 494074b Update to latest hacking 6a53053 move versionutils into place e10dccf Add liberty release name to versionutils Diffstat (except docs and test files) - README.rst | 15 +- openstack-common.conf| 5 +- openstack/common/versionutils.py | 260 - oslo_log/_options.py | 12 +- oslo_log/handlers.py | 43 - oslo_log/log.py | 71 --- oslo_log/loggers.py | 7 +- oslo_log/versionutils.py | 250 requirements.txt | 5 +- setup.cfg| 2 +- test-requirements.txt| 2 +- tox.ini | 2 +- 20 files changed, 741 insertions(+), 711 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index f38fc04..3bfd17a 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -9 +9 @@ iso8601=0.1.9 -oslo.config=1.9.3 # Apache-2.0 +oslo.config=1.11.0 # Apache-2.0 @@ -13,0 +14 @@ oslo.serialization=1.4.0 # Apache-2.0 +debtcollector=0.3.0 # Apache-2.0 diff --git a/test-requirements.txt b/test-requirements.txt index b551d65..7f335ce 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -5 +5 @@ -hacking=0.9.1,0.10 +hacking=0.10.0,0.11 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [cinder] Some Changes to Cinder Core
On Fri, May 22, 2015 at 5:34 PM, Mike Perez thin...@gmail.com wrote: This is long overdue, but it gives me great pleasure to nominate Sean McGinnis for Cinder core. Reviews: https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z Contributions: https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z 30/90 day review stats: http://stackalytics.com/report/contribution/cinder-group/30 http://stackalytics.com/report/contribution/cinder-group/90 As new contributors step up to help in the project, some move onto other things. I would like to recognize Avishay Traeger for his contributions, and now unfortunately departure from the Cinder core team. Cinder core, please reply with a +1 for approval. This will be left open until May 29th. Assuming there are no objections, this will go forward after voting is closed. -- Mike Perez __ 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 +1 __ 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] Functional gate expansion
(Trying to summarize discussions from earlier on IRC) On Mon, May 25, 2015 at 06:54:43PM +, Steven Dake (stdake) wrote: Hey fellow Kolla devs, With Sam’s recent change to add build from source as an option and build from Debuntian binaries as an option, we will end up in a situation where our gate will take 4+ hours to build all of the images and run the functional tests. I would like to separate each major distro and source type with a separate functional gate, for example: centos-rdo fedora-rdo ubuntu-binary debian-bianry centos-source fedora-source debian-source ubuntu-source I propose separating each of these as a separate non-voting check job. What needs to happen in our image building scripts, our functional tests, and the project-config repo to make this happen? Sam said he was working on a patch the allowed CLI args to be passed in to set the prefix. Then it appears that tox supports passing arguments to underlying tests, so a new argument could be passed to test_images.py, and that file be modified to pass the different prefix to build-all-docker-images. (The project-config repo would be nearly identical, just with new jobs executing tox with the different argument.) I really wish we were somehow using caching, though there is one downside. If caching were used and a network resource goes down that was cached, the build would succeed, which could be confusing. Then again that very con could be considered a pro as being more robust to third party failures. Today on IRC it was mentioned that pushing images would take hours, so I think we should leverage Docker's trusted builds and not even bother trying to push images from our test run (another potential solution). The flow would look something like: submitted to gerrit approved gating performed commit permitted to land in repo github commit hook triggers trusted build trusted build updated to latest and available for all to download from docker registry Looking into this further, we'd need infrastructure help to get permissions on github to create the webhooks. Once we get to this point we should be able to do image pulls of trusted builds, greatly accelerating the build process. However, if this is deemed too risky, the trusted builds would at least allow community users to stay up to date easily without any long build times. I’d like to make our current functional gate voting asap, but don’t want to block build from source to make that happen. ASAP? I thought we discussed leaving the job to run for a while before making it voting. But if voting is to be turned on in the near term, obviously we'd start without caching and just using the centos images for now. As far as I can tell, the review is ready: https://review.openstack.org/#/c/183417/ Thoughts? __ 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.vmware release 0.13.0 (liberty)
On 5/26/2015 9:53 AM, Davanum Srinivas wrote: We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 There is now a blocking vmware unit tests bug in nova due to the oslo.vmware 0.13.0 release: https://bugs.launchpad.net/nova/+bug/1459021 Since the vmware driver unit test code in nova likes to stub out external APIs there is probably a bug in the nova unit tests rather than an issue in oslo.vmware, but I'm not very familiar so I can't really say. -- Thanks, Matt Riedemann __ 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] [openstack-operators][chef] OpenStack+Chef is part of the big tent
Hey everyone! I’d like to just drop a note to the list saying thank you and congratulations to our general community. As of 2015-05-26 we’ve been merged into the “big tent”[1] sanctioning us as an official OpenStack project. This is amazing news, and lets keep up the great work! If you have an questions or thoughts please don’t hesitate to reach out. [1]: https://review.openstack.org/#/c/175000/ https://review.openstack.org/#/c/175000/ Best Regards, JJ Asghar c: 512.619.0722 t: @jjasghar__ 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] [cinder] Some Changes to Cinder Core
+1, Welcome to the team, Sean. Regards, Ivan Kolodyazhny On Wed, May 27, 2015 at 12:07 AM, John Griffith john.griffi...@gmail.com wrote: On Fri, May 22, 2015 at 5:34 PM, Mike Perez thin...@gmail.com wrote: This is long overdue, but it gives me great pleasure to nominate Sean McGinnis for Cinder core. Reviews: https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z Contributions: https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z 30/90 day review stats: http://stackalytics.com/report/contribution/cinder-group/30 http://stackalytics.com/report/contribution/cinder-group/90 As new contributors step up to help in the project, some move onto other things. I would like to recognize Avishay Traeger for his contributions, and now unfortunately departure from the Cinder core team. Cinder core, please reply with a +1 for approval. This will be left open until May 29th. Assuming there are no objections, this will go forward after voting is closed. -- Mike Perez __ 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 +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty)
On 5/26/2015 4:19 PM, Matt Riedemann wrote: On 5/26/2015 9:53 AM, Davanum Srinivas wrote: We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 There is now a blocking vmware unit tests bug in nova due to the oslo.vmware 0.13.0 release: https://bugs.launchpad.net/nova/+bug/1459021 Since the vmware driver unit test code in nova likes to stub out external APIs there is probably a bug in the nova unit tests rather than an issue in oslo.vmware, but I'm not very familiar so I can't really say. I have a revert for oslo.vmware here: https://review.openstack.org/#/c/185744/ And a block on the 0.13.0 version in global-requirements here: https://review.openstack.org/#/c/185748/ -- Thanks, Matt Riedemann __ 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] [openstack-operators][chef] OpenStack+Chef is part of the big tent
Yay :) On 26 May 2015, at 23:36, JJ Asghar jasg...@chef.io wrote: Hey everyone! I’d like to just drop a note to the list saying thank you and congratulations to our general community. As of 2015-05-26 we’ve been merged into the “big tent”[1] sanctioning us as an official OpenStack project. This is amazing news, and lets keep up the great work! If you have an questions or thoughts please don’t hesitate to reach out. [1]: https://review.openstack.org/#/c/175000/ Best Regards, JJ Asghar c: 512.619.0722 t: @jjasghar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty)
Vipin, Gary, Can you please accept the revert or figure out the best way to handle this? thanks, dims On Tue, May 26, 2015 at 5:41 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 5/26/2015 4:19 PM, Matt Riedemann wrote: On 5/26/2015 9:53 AM, Davanum Srinivas wrote: We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 There is now a blocking vmware unit tests bug in nova due to the oslo.vmware 0.13.0 release: https://bugs.launchpad.net/nova/+bug/1459021 Since the vmware driver unit test code in nova likes to stub out external APIs there is probably a bug in the nova unit tests rather than an issue in oslo.vmware, but I'm not very familiar so I can't really say. I have a revert for oslo.vmware here: https://review.openstack.org/#/c/185744/ And a block on the 0.13.0 version in global-requirements here: https://review.openstack.org/#/c/185748/ -- Thanks, Matt Riedemann __ 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
Actually, that approach was initially taken for bug 1345947, but then the patch was abandoned to be replaced with a simpler - --dhcp-authoritative approach that ended up with unexpected NAKs for multi agent setup. See: https://review.openstack.org/#/c/108272/12 So I had seen that patch but it's quite different from the approach I was taking. That one requires a new script in the 'bin' directory, a new entry in setup.cfg, an a new dhcp filter entry for rootwrap. Is that something you would be comfortable back-porting all of the way back to Icehouse? The approach I was using was to generate the script at runtime in the data directory for each instance to just return the addresses directly. That way there are no setup changes or new entries in bin. Personally, I felt it was easier to understand since it simply generated a big echo statement, but I might be biased because I wrote it. :) It's really up to what you think is cleaner to back-port. On Tue, May 26, 2015 at 6:57 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/26/2015 04:35 AM, Kevin Benton wrote: Hi, A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2]. This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them. I have two fixes for this so far and a third alternative if we don't like those. The first is hacky, but it's only a few-line change.[3] It adds an iptables rule that just stops the DHCPNAKs from making it to the client. This is clean to back-port but it doesn't protect clients that have filtering disabled (e.g. bare metal). The second persists the DHCP leases to a database.[4] The downside to this was always that being rescheduled to another agent would mean no entries in the lease file. This approach adds a work-around to generate an initial fake lease file based on all of the ports in the network. A third approach that I don't have a patch pushed for yet is very similar to the second. When dnsmasq is in the leasefile-ro mode, it will call the script passed to --dhcp-script to get a list of leases to start with. This script would be built with the same logic as the second one. The only difference between the second approach is that dnsmasq wouldn't persist leases to a database. Actually, that approach was initially taken for bug 1345947, but then the patch was abandoned to be replaced with a simpler - --dhcp-authoritative approach that ended up with unexpected NAKs for multi agent setup. See: https://review.openstack.org/#/c/108272/12 Maybe we actually want to restore the work and merge it after conflicts are resolved and --dhcp-authoritative option is killed; the patch was almost merged when --dhcp-authoritative suggestion emerged, so most of nitpicking work should be complete now (though at the same time, I totally trust our community to find another pile of nits to work on for the next few weeks!) === Speaking of regression testing... Are full stack tests already powerful enough for us to invoke multiple DHCP agents and test the scenario? Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8 Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w 7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS 67lryFh1DTMwI77LjDEanXzWIdMhb3t0YZw7ewpBBLl6P/Lh7xobIOGX2GeOyJ0= =xivW -END 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 -- Kevin Benton __ 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] [Neutron][DB] neutron DB migration scripts
On 5/25/15 10:35 PM, Armando M. wrote: On 25 May 2015 at 09:46, Mike Bayer mba...@redhat.com mailto:mba...@redhat.com wrote: On 5/25/15 12:34 PM, Armando M. wrote: One thing I would like to point out is that in this cycle we'll be working extensively in this area to make the very task you are working on easier to deal with, and better documented. This will fall under the umbrella of the blueprint [1]. HTH Armando [1] https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition took a look at https://review.openstack.org/#/c/134680/17, can I have some clarification on what currently alembic requires extra work to support multiple db migration paths onto a single database? Want to make sure you're aware that Alembic supports this fully (and my job has been to try to get Openstack projects to notice); see http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases. The wording might be confusing, my bad. What I intended there was that neutron's logic to handle alembic migrations required some work in order to simplify the support of out-of-tree DB migrations. Past experiences, like the one that triggered this thread, have shown that we can improve neutron's tooling (neutron-db-manage), as well as documentation. I wonder if there is some way that out-of-tree migrations can still take place within the migration stream as a whole. As those external trees can be built assuming the central Neutron migration series as a dependency, if their directories are added to the version_locations collection before the alembic command line runner invokes the migration, they will form part of the total migration setup for the database. This was one use case I had in mind when building out this feature. The command line runner is extensible so a runtime extension to configuration is feasible. __ 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.vmware release 0.13.0 (liberty)
We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/26/2015 04:35 AM, Kevin Benton wrote: Hi, A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2]. This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them. I have two fixes for this so far and a third alternative if we don't like those. The first is hacky, but it's only a few-line change.[3] It adds an iptables rule that just stops the DHCPNAKs from making it to the client. This is clean to back-port but it doesn't protect clients that have filtering disabled (e.g. bare metal). The second persists the DHCP leases to a database.[4] The downside to this was always that being rescheduled to another agent would mean no entries in the lease file. This approach adds a work-around to generate an initial fake lease file based on all of the ports in the network. A third approach that I don't have a patch pushed for yet is very similar to the second. When dnsmasq is in the leasefile-ro mode, it will call the script passed to --dhcp-script to get a list of leases to start with. This script would be built with the same logic as the second one. The only difference between the second approach is that dnsmasq wouldn't persist leases to a database. Actually, that approach was initially taken for bug 1345947, but then the patch was abandoned to be replaced with a simpler - --dhcp-authoritative approach that ended up with unexpected NAKs for multi agent setup. See: https://review.openstack.org/#/c/108272/12 Maybe we actually want to restore the work and merge it after conflicts are resolved and --dhcp-authoritative option is killed; the patch was almost merged when --dhcp-authoritative suggestion emerged, so most of nitpicking work should be complete now (though at the same time, I totally trust our community to find another pile of nits to work on for the next few weeks!) === Speaking of regression testing... Are full stack tests already powerful enough for us to invoke multiple DHCP agents and test the scenario? Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8 Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w 7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS 67lryFh1DTMwI77LjDEanXzWIdMhb3t0YZw7ewpBBLl6P/Lh7xobIOGX2GeOyJ0= =xivW -END 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] Add core approver Sam Yaple
On Mon, May 25, 2015 at 06:59:15PM +, Steven Dake (stdake) wrote: Hi folks, I propose Sam Yaple for core approver for the Kolla team. Sam has a lot of great ideas and has done some really cool work lately. Sam is active in IRC and is starting to pick up more reviews. Of particular interest to me his his idea of merging the work he has done on YAODU into Kolla. This would be fantastic for Kolla and allow us to deliver on our goals of providing high availability which depends on multi-node deployment in our container architecture. Some really complex and nice improvements to the codebase: https://review.openstack.org/#q,Ifc7bac0d827470f506c8b5c004a833da9ce13b90,n,z https://review.openstack.org/#q,Ic0ff96bb8119ddfab15b99e9f1e21cfe8d321dab,n,z https://review.openstack.org/#q,I95101136dad56e9331d8b92cd394495f7bd0576a,n,z Sam's stats for Liberty and Kilo: http://stackalytics.com/?project_type=alluser_id=s8mmodule=kollarelease=all Count my proposal as a +1. Since our core team is only 5 people presently, I think it makes sense to only require one additional +1. Typically projects require 3 +1 votes but have larger core teams, so we will use that in the future. -1 = veto, so vote wisely. Folks often abstain if they are not certain how their vote should go – so don’t feel compelled to vote. +1, don't even need to look at the above links __ 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] [openstackclient] Use and practices of --format shell for defining individual variables
On Tue, May 26, 2015 at 10:18 AM, Ronald Bradford m...@ronaldbradford.com wrote: I came across the following neutron client specific syntax and decided to see if I could reproduce using the openstack client and it's flexible formatting capabilities I'll just say off the top it is unlikely as there are only two resources implemented using the Network API. The remaining networking functions use the Compute API for nova-net. We have not really mapped the requried commands to OSC form yet, that is going to be the hardest part of implementing them. They need to be consistent with the rest of OSC. Some of what you mentioned is common to all OSC commands, like the output formatting is all done with cliff. I don't know how much of that would be common to neutronclient too since it also uses cliff, but sometimes in a different way. dt -- Dean Troyer dtro...@gmail.com __ 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] PCI pass-through SRIOV
This is a different error
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] if ret == -1: raise libvirtError
('virDomainCreateWithFlags() failed', dom=self)
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] libvirtError: internal error: process
exited while connecting to monitor: 2015-05-26T04:34:07.980897Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed to
open /dev/vfio/vfio: Operation not permitted
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980951Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed to
setup container for group 49
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980970Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: vfio: failed to
get group 49
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.980995Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: Device
initialization failed.
2015-05-26 13:34:08.081 TRACE nova.compute.manager [instance:
101776a0-cd2e-47b9-bdc4-1097782201c6] 2015-05-26T04:34:07.981019Z qemu-kvm:
-device vfio-pci,host=81:02.3,id=hostdev0,bus=pci.0,addr=0x4: Device 'vfio-pci'
could not be initialized
You are using intel card therefore I think you should contact them and ask if
this card is supported.
From: Kamsali, RaghavendraChari (Artesyn)
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Tuesday, May 26, 2015 4:49 PM
To: Kamsali, RaghavendraChari (Artesyn); Moshe Levi; OpenStack Development
Mailing List (not for usage questions); openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV
Please find the attachment for the logs when changed in ml2_conf_sriov.ini
From: Kamsali, RaghavendraChari (Artesyn)
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Tuesday, May 26, 2015 1:36 PM
To: Moshe Levi; OpenStack Development Mailing List (not for usage questions);
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: Re: [Openstack] [openstack-dev] PCI pass-through SRIOV
Hi,
Yes I changed it on what you mentioned in ml2_conf_sriov.ini ,but same issue
occurs.
Thanks and Regards,
Raghavendrachari kamsali,
Embedded Computing and Power,
Hyderabad, AndhraPradesh , India
From: Moshe Levi [mailto:mosh...@mellanox.com]
Sent: Tuesday, May 26, 2015 12:58 PM
To: Kamsali, RaghavendraChari [ENGINEERING/IN]; OpenStack Development Mailing
List (not for usage questions);
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV
Hi Kamsali,
This is the error:
Refusing to bind due to unsupported vnic_type: direct
Please add the following to you ml2_conf.ini
supported_pci_vendor_devs = 8086:154c
Thanks,
Moshe Levi
From: Kamsali, RaghavendraChari (Artesyn)
[mailto:raghavendrachari.kams...@artesyn.com]
Sent: Monday, May 25, 2015 2:31 PM
To: Moshe Levi; OpenStack Development Mailing List (not for usage questions);
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: RE: [openstack-dev] PCI pass-through SRIOV
FYI,
Neutron-server logs,
Ml2 config file on compute and controller
Nova.conf file
From: Moshe Levi [mailto:mosh...@mellanox.com]
Sent: Saturday, May 23, 2015 7:53 PM
To: OpenStack Development Mailing List (not for usage questions);
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: Re: [Openstack] [openstack-dev] PCI pass-through SRIOV
Hi Kamsali,
According to the logs you got binding failed error, which mean neutron failed
to bind the port.
Can you send the neutron server log and the your neutron ml2 conf file?
Thank,
Moshe Levi
From: Kamsali, RaghavendraChari
(Artesyn)mailto:raghavendrachari.kams...@artesyn.com
Sent: Saturday, May 23, 2015 6:38 AM
To: OpenStack Development Mailing List (not for usage
questions)mailto:openstack-dev@lists.openstack.org,
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Hi,
Am deploying controller-compute openstack setup , in controller I configured
openvswitch bridges and in computed node I configured PCI nic supported SRIOV
capability and while am spawning VM am getting following error as in attached
file:
I followed the link for setting up the sriov
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking and
http://www.qlogic.com/solutions/Documents/UsersGuide_OpenStack_SR-IOV.pdf
Could any one help me regarding this issue
Thanks and Regards,
Raghavendrachari kamsali,
Embedded Computing and Power,
Hyderabad, AndhraPradesh , India
__
OpenStack Development Mailing
[openstack-dev] [openstackclient] Use and practices of --format shell for defining individual variables
Hi list,
I came across the following neutron client specific syntax and decided to
see if I could reproduce using the openstack client and it's flexible
formatting capabilities
$ NIC_ID1=$(neutron net-show public | awk '/ id /{print $4}')
$ echo $NIC_ID1
210d976e-16a3-42dc-ac31-f01810dbd297
I can get similar syntax (unfortunately lowercase variable name only) with:
NOTE: It may be nice to be able to pass an option to UPPERCASE all shell
variables names.
$ openstack network show public -c id --format shell --prefix nic_
nic_id=210d976e-16a3-42dc-ac31-f01810dbd297
However to use this I effectively have to place in a file and source that
file to expose this variable to my current running shell.
Reproducing the same syntax does not work obviously.
$ NIC_ID2=$(openstack network show public -c id --format shell)
$ echo $NIC_ID2
id=210d976e-16a3-42dc-ac31-f01810dbd297
And even stripping out the name= portion still results in a quoted
response.
$ NIC_ID3=$(openstack network show public -c id --format shell | cut -d=
-f2)
$ echo $NIC_ID3
210d976e-16a3-42dc-ac31-f01810dbd297
So in order to accurately reproduce I need the following which seems more
long winded then the original.
$ NIC_ID4=$(openstack network show public -c id --format shell | cut -d=
-f2 | tr -d '')
$ echo $NIC_ID4
210d976e-16a3-42dc-ac31-f01810dbd297
While I presume the intended use to create a file to source variables is
there any merit it supporting per variable definition as in this example?
Any thoughts appreciated.
Regards
Ronald
__
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] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
As long as we confirm that the severity of this bug is accurately represented in the bug report, then this is the first thing we should do. However, see below. We tried this and did not encounter the error in at least one experiment. Are we sure that this is broken everywhere multiple servers is used? I'm checking internally to confirm that we have run this successfully. Outside of the reported bug, I had another person report this behavior to me from Big Switch Networks as well. Additionally, I was just informed today that it was encountered internally here at Mirantis testing the latest stable/juno code. On Tue, May 26, 2015 at 12:37 PM, Carl Baldwin c...@ecbaldwin.net wrote: On Tue, May 26, 2015 at 11:05 AM, Brian Haley brian.ha...@hp.com wrote: On 05/26/2015 01:12 PM, Salvatore Orlando wrote: From the bug Kevin reported it seems multiple dhcp agents per network have been completely broken by the fix for bug #1345947, so a revert of patch [1] (and stable backports) should probably be the first thing to do - if nothing else because the original bug has not nearly the same level of severity of the one it introduced. As long as we confirm that the severity of this bug is accurately represented in the bug report, then this is the first thing we should do. However, see below. We tried this and did not encounter the error in at least one experiment. Are we sure that this is broken everywhere multiple servers is used? I'm checking internally to confirm that we have run this successfully. Before doing this however, I am wondering why the various instances of dnsmasq end up returning NAKs. I expect all instances to have the same hosts file, so they should be able to respond to DHCPDISCOVER/DHCPREQUEST correctly. Is the dnsmasq log telling us exactly why the authoritative setting is preventing us from doing so? (this is more of a curiosity in my side) [1] https://review.openstack.org/#/c/152080/ I also think we should understand more about this problem. I think that understanding more specifics around the bug will help. The details are a bit unclear to me. In the original case, the DHCPREQUEST is for a renew, which is different than for an initial request. If the server does not have a lease entry (which it won't after a restart), then it will NAK, which normally just causes the client to retry at INIT state. I had asked on the dnsmasq list about this [1], and the multiple server question was the wildcard, my testing didn't see the error described in the new bug though. I guess the first proposed fix of re-populating the lease information doesn't seem like such a bad idea any more, but I will reply to my original query with the tcpdump information since I'm confused as to why the second dhcp agent stepped-in with a NAK at all after originally offering the same address as the first dhcp agent [2]. I remember being concerned about the multiple dnsmasq case. I also remember having tried it and thought that it was working as expected. I would agree the best thing to do is revert the stable backports while we work on fixing this in the master branch. I think we can propose the reverts but until we confirm the severity of this bug, I don't want them to merge. Carl __ 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 -- Kevin Benton __ 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] [ceilometer] Vancouver summit roundup
hi folks it was great seeing/meeting all those who could make it to the Vancouver summit. i hope everyone had a productive summit and also enjoyed Vancouver (go Canucks!). for those who couldn't make it or for those interested, here are some of the items we talked about and will be tracking in the upcoming cycle.[1] (the following is a brain dump and does not reflect any prioritisation) -- componentisation -- [2] Ceilometer consists of several discrete services: polling, notification handling, storage, and alarming. for the most part, packaging is done to match these functionalities but the code itself is contained all in a single repo. this has lead to some confusion as to how Ceilometer can be used/deployed and a generic 'ceilometer' term to define any part of the functionality. the idea for separating the code is to: enable easier consumption for new developers, allow easier/precise classification of issues, to get a better sense of what parts of Ceilometer are more important so resources can be prioritised better, in addition to other potential wins. the first step will be to separate the alarming functionality and we will re-evaluate from there. -- alarming on events -- [3] in Kilo, we added a more complete functionality for capturing events in OpenStack. in Liberty, we aim to provide alarming functionality to events. the idea is again to start small and to enable immediate alarming when a change in status is detected and also when specific actions pass timing thresholds. from there, we will see how we can expand it's scope. -- polling agent load -- [4] a complaint regarding Ceilometer has been the load it places on the apis of services. while there are small workaround such as creating a dedicated api for just Ceilometer so that it does not affect general OpenStack processes, further enhancements are being looked at. -- declarative meters -- [5] when adding a meter to Ceilometer, you need to write code. the code is often just a process of copying existing meter, pasting code into a new section, and editing a variable or two. this is extremely inflexible and even more unnecessary. the new proposal is to define meters in a yaml file which defines what values of a notification become meters. this allows for better ease of use and the ability for users to easily define their own meters. -- graceful pipeline reconfiguration -- [6] for this item, the basic premise is to allow the modification of pipelines and have the agents update to accommodate new pipeline configuration without having to do a hard restart of service -- gnocchi -- [7][8][9] there's this thing called gnocchi. it's a new time-series driven storage backend. -- documentation -- there's a lot of confusion as to how to use and deploy Ceilometer[10]. there was a talk to highlight some items but we'll be publishing a bit more help to enable operators. -- other -- initial trial of oslo.versionobjects, in-tree functional testing, bugs, etc... so there's the long summary. for those interested in helping out, feel free to reach out. for those with ideas we haven't discussed, feel free to reach out. as always irc:#openstack-ceilometer and [ceilometer]. [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Ceilometer [2] https://review.openstack.org/#/c/184307/ [3] https://review.openstack.org/#/c/172893/ [4] https://review.openstack.org/#/c/185084/ [5] https://review.openstack.org/#/c/178399/ [6] https://review.openstack.org/#/c/171826/ [7] https://julien.danjou.info/blog/2015/openstack-gnocchi-first-release [8] www.slideshare.net/EoghanGlynn/rdo-hangout-on-gnocchi [9] http://blog.sileht.net/autoscaling-with-heat-ceilometer-and-gnocchi.html [10] www.openstack.org/summit/vancouver-2015/summit-videos/presentation/stabilizing-the-jenga-tower-scaling-out-ceilometer cheers, gord ** crosses fingers on formatting ** __ 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] [openstackclient] [magnum] Review of object and actions for magnumclient implementation
For reference, the current list of objects and actions used by commands in the OSC repo are at http://docs.openstack.org/developer/python-openstackclient/commands.html. Also note that while the OSC team may have multiple opinions on what fits well and does not in plugins, the plugins are owned by the project teams and not the OSC team and we do not rigidly enforce our structure on external plugins. Inconsistencies in command structure work against the entire spirit of why OSC was built to begin with. For external plugins, however, we will rely on community feedback to encourage projects to stay consistent as much as possible. On Mon, May 25, 2015 at 9:52 AM, Ronald Bradford m...@ronaldbradford.com wrote: 2. execute or exec This is clearly a new type of action that requires OSC to provide recommended guidance on. I am 50/50 here. To add a new action I think you need to be clear for the user what it does and hopefully in a way that is not unique to this command. Many of the actions in the docs are specific to servers because they only appear in server commands. These can/should be generalized where possible in favor of adding new actions. I don't see anything that fits what I would expect an 'execute' action to do, but then I also don't quite know what this is intended to do. In the context of the container command example above, there is execute, start and stop. start and stop seem to be create and delete equivalents to the server commands. If you choose to deviate from that, you should explain exactly why and how so the user can figure out the difference. I don't know what execute does in that context. Is a container created in a paused/suspended state? Also, I'm not a fan of adding yet another set of running state action pairs (create/delete, pause/unpause, suspend/resume). 3. set or update While I consider the word set to be more an attribute specific term, update implies a change of multiple attributes. If I just looked at the usage I would say update. However, looking at the actual usage openstack client set syntax uses named parameters to set multiple parameters. Most people's update is OSC's set. There is also unset for removing an attribute rather than setting it to a null value. Set is generally very similar to create command-wise. Looking into the help syntax of a Magnum update option, I find it supports add, replace and remove operations. This complicates matters We already have the concept of adding and removing resources from other containing resources. Look at security groups for the best example. This is also one of the only places we use more than one positional parameter, the rationale being you have two resources in the command itself, both can be referenced in the args implicitly. 4. service is already used by Identity. See http://docs.openstack.org/developer/python-openstackclient/command-objects/service.html 5. container is already used by Swift. See http://docs.openstack.org/developer/python-openstackclient/command-objects/container.html We need to go to multiple word objects here then. Backward compatibility gives the bare object name to the existing commands, although I would suggest we add a qualified object name also: 'service' might become 'catalog service' as an alas. We document those and ride out a really long deprecation for something so fundamental. I have no suggestions on 4. and 5. Given these last 2 entanglements the OSC will quickly become unusable as more clients which it integrate. Yup, this is a problem. We need to anmespace things somehow, be it by putting the commands into a namespace like congressclient did (all commands start with 'congress', I'd have suggested not using the project name), or we namespace the objects as I suggested earlier by using longer and more specific names. Or we don't attempt to put the entire big tent client commands into a single CLI. There is nothing that says we can't have multiple top-level commands. OSC today doesn't easily do that and leverage the existing code structure, but it probably could if this becomes a popular option. The 'openstack' command for the usual and common stuff, and a (pulling names out of my hat here): 'os-tent' for big-tent-related commands (I'm taking this part literally) and 'os-jewel' for the sparkly, shiny commands that make brides happy: os-tent ring create --type elephant dumbo os-jewel ring create --type wedding sparkle In the end, the principle of 'least surprise' is important to consider. And that I still maintain the 'C' in OSC stands for 'Consistent'. dt -- Dean Troyer dtro...@gmail.com __ 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] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
Hi Salvatore, The problem isn't that dnsmasq doesn't have an entry for the client. The issue is that the client is sending to a server address that is not dnsmasq. This is the logic that is causing the issue.[1] 1. https://github.com/kevinbenton/dnsmasq/blob/master/src/rfc2131.c#L1103 On Tue, May 26, 2015 at 10:12 AM, Salvatore Orlando sorla...@nicira.com wrote: From the bug Kevin reported it seems multiple dhcp agents per network have been completely broken by the fix for bug #1345947, so a revert of patch [1] (and stable backports) should probably be the first thing to do - if nothing else because the original bug has not nearly the same level of severity of the one it introduced. Before doing this however, I am wondering why the various instances of dnsmasq end up returning NAKs. I expect all instances to have the same hosts file, so they should be able to respond to DHCPDISCOVER/DHCPREQUEST correctly. Is the dnsmasq log telling us exactly why the authoritative setting is preventing us from doing so? (this is more of a curiosity in my side) [1] https://review.openstack.org/#/c/152080/ On 26 May 2015 at 06:57, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/26/2015 04:35 AM, Kevin Benton wrote: Hi, A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2]. This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them. I have two fixes for this so far and a third alternative if we don't like those. The first is hacky, but it's only a few-line change.[3] It adds an iptables rule that just stops the DHCPNAKs from making it to the client. This is clean to back-port but it doesn't protect clients that have filtering disabled (e.g. bare metal). The second persists the DHCP leases to a database.[4] The downside to this was always that being rescheduled to another agent would mean no entries in the lease file. This approach adds a work-around to generate an initial fake lease file based on all of the ports in the network. A third approach that I don't have a patch pushed for yet is very similar to the second. When dnsmasq is in the leasefile-ro mode, it will call the script passed to --dhcp-script to get a list of leases to start with. This script would be built with the same logic as the second one. The only difference between the second approach is that dnsmasq wouldn't persist leases to a database. Actually, that approach was initially taken for bug 1345947, but then the patch was abandoned to be replaced with a simpler - --dhcp-authoritative approach that ended up with unexpected NAKs for multi agent setup. See: https://review.openstack.org/#/c/108272/12 Maybe we actually want to restore the work and merge it after conflicts are resolved and --dhcp-authoritative option is killed; the patch was almost merged when --dhcp-authoritative suggestion emerged, so most of nitpicking work should be complete now (though at the same time, I totally trust our community to find another pile of nits to work on for the next few weeks!) That was my thought as well. However, we should check whether that patch is ok to backport. For instance I see what it appears to be adding a script: [2] https://review.openstack.org/#/c/108272/12/bin/neutron-dhcp-agent-dnsmasq-lease-init === Speaking of regression testing... Are full stack tests already powerful enough for us to invoke multiple DHCP agents and test the scenario? Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8 Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w 7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS 67lryFh1DTMwI77LjDEanXzWIdMhb3t0YZw7ewpBBLl6P/Lh7xobIOGX2GeOyJ0= =xivW -END 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 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 -- Kevin Benton __ 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] [horizon] No meeting this week
There are no items on the agenda and with the summit just completing, I'm canceling the horizon IRC meeting for May 27. We will resume next week on June 3 at 20:00 UTC. David __ 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] [Openstack-operators] [openstack-operators][chef] OpenStack+Chef is part of the big tent
Congrats and welcome! On May 26, 2015 5:35 PM, JJ Asghar jasg...@chef.io wrote: Hey everyone! I’d like to just drop a note to the list saying thank you and congratulations to our general community. As of 2015-05-26 we’ve been merged into the “big tent”[1] sanctioning us as an official OpenStack project. This is amazing news, and lets keep up the great work! If you have an questions or thoughts please don’t hesitate to reach out. [1]: https://review.openstack.org/#/c/175000/ Best Regards, JJ Asghar c: 512.619.0722 t: @jjasghar ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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] [keystone] Abandoning open spec reviews for previous cycles
At the end of this week, I will be administratively abandoning all specs with open reviews that are not targeting Liberty or Backlog. Each of these specs has been open for a while with a -2 on them. A given spec can be reproposed against a current target if desired down the line. Cheers, --Morgan __ 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] [glance] [kolla] [magnum] [nova] [neutron] Vancouver Summit Operations Containers Session
Flavio Percoco wrote: There's work going on on something called Artifacts[0], which - in a poorly worded definition - is an enhancement of the current image model in Glance. It'll take some time for the full migration to happen but that should solve your requirement. [0] http://specs.openstack.org/openstack/glance-specs/specs/kilo/artifact-repository.html Thank you for bringing that to my attention, this looks like it solves the issue we outlined - very exciting. =] __ 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] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
From the bug Kevin reported it seems multiple dhcp agents per network have been completely broken by the fix for bug #1345947, so a revert of patch [1] (and stable backports) should probably be the first thing to do - if nothing else because the original bug has not nearly the same level of severity of the one it introduced. Before doing this however, I am wondering why the various instances of dnsmasq end up returning NAKs. I expect all instances to have the same hosts file, so they should be able to respond to DHCPDISCOVER/DHCPREQUEST correctly. Is the dnsmasq log telling us exactly why the authoritative setting is preventing us from doing so? (this is more of a curiosity in my side) [1] https://review.openstack.org/#/c/152080/ On 26 May 2015 at 06:57, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/26/2015 04:35 AM, Kevin Benton wrote: Hi, A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2]. This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them. I have two fixes for this so far and a third alternative if we don't like those. The first is hacky, but it's only a few-line change.[3] It adds an iptables rule that just stops the DHCPNAKs from making it to the client. This is clean to back-port but it doesn't protect clients that have filtering disabled (e.g. bare metal). The second persists the DHCP leases to a database.[4] The downside to this was always that being rescheduled to another agent would mean no entries in the lease file. This approach adds a work-around to generate an initial fake lease file based on all of the ports in the network. A third approach that I don't have a patch pushed for yet is very similar to the second. When dnsmasq is in the leasefile-ro mode, it will call the script passed to --dhcp-script to get a list of leases to start with. This script would be built with the same logic as the second one. The only difference between the second approach is that dnsmasq wouldn't persist leases to a database. Actually, that approach was initially taken for bug 1345947, but then the patch was abandoned to be replaced with a simpler - --dhcp-authoritative approach that ended up with unexpected NAKs for multi agent setup. See: https://review.openstack.org/#/c/108272/12 Maybe we actually want to restore the work and merge it after conflicts are resolved and --dhcp-authoritative option is killed; the patch was almost merged when --dhcp-authoritative suggestion emerged, so most of nitpicking work should be complete now (though at the same time, I totally trust our community to find another pile of nits to work on for the next few weeks!) That was my thought as well. However, we should check whether that patch is ok to backport. For instance I see what it appears to be adding a script: [2] https://review.openstack.org/#/c/108272/12/bin/neutron-dhcp-agent-dnsmasq-lease-init === Speaking of regression testing... Are full stack tests already powerful enough for us to invoke multiple DHCP agents and test the scenario? Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8 Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w 7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS 67lryFh1DTMwI77LjDEanXzWIdMhb3t0YZw7ewpBBLl6P/Lh7xobIOGX2GeOyJ0= =xivW -END 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 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] [Nova] [Ironic] Using depends-on for patches which require an approved spec
On 22 May 2015 at 21:38, Morgan Fainberg morgan.fainb...@gmail.com wrote: This seems like a good idea for a pattern in general to use gong forward. --Morgan Sent via mobile On May 22, 2015, at 14:57, Michael Still mi...@stillhq.com wrote: Hey, it would be cool if devs posting changes for nova which depend on us approving their spec could use Depends-On to make sure their code doesn't land until the spec does. On that note, In Ironic, some of us have been talking about how to make -2 better. Right now, we -2 any patches that depend on a spec needing approval. Some downsides are that 1) someone needs to notice to -2 it; 2) the person that puts the -2 has to remove it later (or I guess someone in infra can do that?); and 3) some developers don't like getting the -2 (even though we message it by saying that it can still be reviewed etc but cannot be approved until the spec is approved). For Nova, is the Depends-On a replacement for the -2 process? (I think Nova does/did a similar thing as Ironic.) I was thinking that using Depends-On should work as a replacement for the -2 method. Some of the downsides might be that 1) someone will have to notice/remind developers to add this; 2) doesn't work in the case where a patch is approved and the spec changes after the patch is approved, the spec is approved, and then the patch lands (without subsequent changes). The pluses are that yay, I get quick access to the spec (instead of via the blueprint) and I don't have to get into a conversation with someone about why their patch has been -2'd. --ruby __ 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] [Glance] [all] Liberty summit: Updates in Glance
On 5/22/15, 4:28 PM, Nikhil Komawar nik.koma...@gmail.commailto:nik.koma...@gmail.com wrote: Hi all, tl;dr; Artifacts IS staying in Glance. 1. We had a nice discussion at the contributors' meet-up at the Vancouver summit this morning. After weighing in many possibilities and evolution of the Glance program, we have decided to go ahead with the Artifacts implementation within Glance program under the EXPERIMENTAL v3 API. Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. That is to say, Artifacts is the technical implementation of the v3 API. This also means the v3 API is an objects API vs just an images API. We also had some hallway talk about putting the v1 and v2 APIs on top of the v3 API. This forces faster adoption, verifies supportability via v1 and v2 tests, increases supportability of v1 and v2 APIs, and pushes out the need to kill v1 API. 1. 2. The effort would primarily be conducted as a sub-team-like structure within the program and the co-coordinators and drivers of the necessary Artifacts features would be given core-reviewer status temporarily with an informal agreement to merge code that is only related to Artifacts. 3. The entire Glance team would give reviews as time and priorities permit. The approval (+A/+WorkFlow) of any code within the program would need to come from core-reviewers who are not temporarily authorized. The list of such individuals and updated time-line would be documented in phases during the course of Liberty cycle. 4. We will continue to evaluate update the governance, maturity of the code and future plans for the v1, v2 and v3 Glance APIs as time progresses. However, for now we are aiming to integrate all of Glance (specifically Images) as Artifacts in the v3 API. As I understand it, that is to say that v3 requests in the first micro-version that specify the object type as image would get a not implemented or similar error. The next next micro-version would likely contain the support for images along with possibly implementing the v1 and v2 APIs on top of v3. 1. Special thanks to Flavio for providing DefCore and TC perspective as well as initializing this discussion. Also, thanks to Stuart McLaren and Brian Rosmaita for giving us thoughtful veteran feedback. The entire team did a great job at putting all their questions and concerns amicably on the table and came to a good understanding of the plan and level of commitment. All the best to the Project SearchLight team who have decided to start ElasticSearch based development for search functionality in OpenStack as a separate program and would be porting respective code out of Glance. Glance team would help co-ordinate this porting effort in order to avoid destabilizing Images and MetaDefs code-bases. This also means we will re-evaluate some of the existing spec proposals and most likely not ask people for radical changes in their approach. This first phase of the Liberty cycle would focus on seeing the Experimental Artifacts API through. We will also focus on stability aspects of the Images (v1 v2) related features. The second phase priorities would be decided at the mid-cycle meet-up (details to come out soon). Feel free to ask me questions on IRC or via email. Cheers, Nikhil __ 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] [Glance] Liberty Priorities
I created an etherpad with priorities the RAX team I work on will be focusing on based on our talks at the summit: https://etherpad.openstack.org/p/liberty-priorities-rax. Input, guidance, feedback, and collaboration is not just welcome, it is encouraged and appreciated. Thanks, Jesse __ 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] [openstackclient] Use and practices of --format shell for defining individual variables
Excerpts from Ronald Bradford's message of 2015-05-26 11:18:09 -0400:
Hi list,
I came across the following neutron client specific syntax and decided to
see if I could reproduce using the openstack client and it's flexible
formatting capabilities
$ NIC_ID1=$(neutron net-show public | awk '/ id /{print $4}')
$ echo $NIC_ID1
210d976e-16a3-42dc-ac31-f01810dbd297
I can get similar syntax (unfortunately lowercase variable name only) with:
NOTE: It may be nice to be able to pass an option to UPPERCASE all shell
variables names.
$ openstack network show public -c id --format shell --prefix nic_
nic_id=210d976e-16a3-42dc-ac31-f01810dbd297
However to use this I effectively have to place in a file and source that
file to expose this variable to my current running shell.
Reproducing the same syntax does not work obviously.
It's actually meant to be used with an eval statement:
$ eval $(openstack network show public -c id --format shell --prefix nic_)
$ echo $nic_id
Doug
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] oslo.messaging release 1.11.0 (liberty)
We are jubilant to announce the release of: oslo.messaging 1.11.0: Oslo Messaging API With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.11.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messaging Changes in oslo.messaging 1.10.0..1.11.0 f3d4ba7 rabbit: smart timeout on missing exchange 708d9d8 rabbit: Fix message ttl not work ccbe866 rabbit: remove publisher classes 77f952a rabbit: Set timeout on the underlying socket 8af6b2f Remove stale copy of context.py cc4ca1f Add one more functional test for MessagingTimeout 3d483fd Fix list_opts test to not check all deps 1da2231 make it possible to import amqp driver without dependencies 65fecf2 Remove outdated release notes 1ba55c0 rabbit: smarter declaration of the notif. queue 415db68 rabbit: redeclare consumers when ack/requeue fail 0c954cf Bump kombu and amqp requirements 48eb5e1 Updated from global requirements 3c2e965 rabbit: fix exception path in queue redeclaration 2c3c8a3 rabbit: fix consumers declaration b737a92 rabbit: remove unused consumer interfaces 2d81577 rabbit: remove unused code cca84f6 rabbit: Remove unused stuffs from publisher 6abfdd5 Remove support for Python 3.3 ef58534 Updated from global requirements e888daa Add RequestContextSerializer b46e52f Updated from global requirements 54ecb3b rabbit: fixes a logging issue 6c91066 rabbit/qpid: simplify the consumer loop 5b9fb69 Updated from global requirements 0941982 Imported Translations from Transifex 60624a6 Fix missing space in help text de015d5 zmq: Add support for ZmqClient pooling 50204ee Enable eventlet dependency on Python 3 e3fa3ca Add JsonPayloadSerializer serializer 6aff6c3 Fix test_matchmaker_redis on Python 3 287a4f5 Disable and mark heartbeat as experimental 45ca27a Port ZMQ driver to Python 3 Diffstat (except docs and test files) - .../locale/de/LC_MESSAGES/oslo.messaging.po| 46 +- .../en_GB/LC_MESSAGES/oslo.messaging-log-error.po | 1 - .../locale/en_GB/LC_MESSAGES/oslo.messaging.po | 31 +- .../fr/LC_MESSAGES/oslo.messaging-log-error.po | 1 - .../locale/fr/LC_MESSAGES/oslo.messaging.po| 43 +- oslo_messaging/_drivers/amqp.py| 6 - oslo_messaging/_drivers/amqpdriver.py | 4 +- oslo_messaging/_drivers/base.py| 7 + oslo_messaging/_drivers/impl_qpid.py | 22 +- oslo_messaging/_drivers/impl_rabbit.py | 727 + oslo_messaging/_drivers/impl_zmq.py| 254 +-- oslo_messaging/_drivers/protocols/amqp/driver.py | 86 +-- .../_drivers/protocols/amqp/drivertasks.py | 90 +++ oslo_messaging/notify/notifier.py | 4 +- oslo_messaging/openstack/common/context.py | 126 oslo_messaging/opts.py | 2 + oslo_messaging/serializer.py | 33 +- requirements-py3.txt | 29 +- requirements.txt | 14 +- test-requirements-py3.txt | 3 + tox.ini| 6 +- 31 files changed, 986 insertions(+), 1203 deletions(-) Requirements updates diff --git a/requirements-py3.txt b/requirements-py3.txt index a37a824..32739db 100644 --- a/requirements-py3.txt +++ b/requirements-py3.txt @@ -5 +5 @@ -oslo.config=1.9.3 # Apache-2.0 +oslo.config=1.11.0 # Apache-2.0 @@ -14,0 +15,5 @@ six=1.9.0 +# FIXME(markmc): remove this when the drivers no longer +# import eventlet + +eventlet=0.17.3 + @@ -19 +24,3 @@ PyYAML=3.1.0 -kombu=2.5.0 +# we set the amqp version to ensure heartbeat works +amqp=1.4.0 +kombu=3.0.7 @@ -22 +29,17 @@ kombu=2.5.0 -oslo.middleware=1.0.0 # Apache-2.0 +oslo.middleware=1.2.0 # Apache-2.0 + +# FIXME: concurrent.futures is part of the Python stdlib since Python 3.2, +# but the requirements is still needed because of a bug in tox: +# https://bitbucket.org/hpk42/tox/issue/236/tox-must-create-the-source-distribution +# +# Tox builds a source distribution with python setup.py sdist which uses +# requirements.txt even if tox wants to build the py34 virtual environment. +# As a consequence, oslo.messaging.egg_info/requires.txt contains futures +# and oslo_messaging.tests.test_opts.OptsTestCase.test_entry_point fails. +# +# for the futures based executor +futures=3.0 + +# needed by the aioeventlet executor +aioeventlet=0.4 +trollius=1.0 diff --git a/requirements.txt b/requirements.txt index aaf7390..a6373a4 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -7 +7 @@ pbr=0.6,!=0.7,1.0 -oslo.config=1.9.3 # Apache-2.0 +oslo.config=1.11.0 # Apache-2.0 @@ -20 +20 @@ six=1.9.0
[openstack-dev] [oslo.messaging][zeromq] Next step
Looking at what is the next step following the design summit meeting on 0MQ as the etherpad does not provide too much information. Few questions: - would it be possible to have the slides presented (showing the proposed changes in the 0MQ driver design) to be available somewhere? - is there a particular branch in the oslo messaging repo that contains 0MQ related patches - I'm more particularly interested by James Page's patch to pool the 0MQ connections but there might be other - question for Li Ma, are you deploying with the straight upstream 0MQ driver or with some additional patches? The per node proxy process (which is itself some form of broker) needs to be removed completely if the new solution is to be made really broker-less. This will also eliminate the only single point of failure in the path and reduce the number of 0MQ sockets (and hops per message) by half. I think it was proposed that we go on with the first draft of the new driver (which still keeps the proxy server but reduces the number of sockets) before eventually tackling the removal of the proxy server? Thanks Alec __ 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
