Re: [openstack-dev] [stable-maint] acceptable changes for stable/icehouse
John Griffith wrote: On Mon, Jan 5, 2015 at 4:39 PM, Jay S. Bryant jsbry...@electronicjungle.net wrote: All, We have been getting a number of non-security patches proposed to stable/icehouse for Cinder. The cores were discussing what was ok to put into icehouse at this point in time and couldn't agree as to whether we were at the point of only accepting security changes. Appreciate advice on this topic. Hey Jay, Thanks for raising this, my understanding was that we were in fact security only mode now for Icehouse. That being said I completely forgot that it's been that long already and I let some reviews slip myself just today in fact. Thanks for pointing it out. Icehouse is now 9-month old, so it is in phase II support (only critical bugfixes and security patches are acceptable). Reference: https://wiki.openstack.org/wiki/StableBranch#Support_phases In case of doubt, you can ask stable-maint-core people for advice: https://review.openstack.org/#/admin/groups/530,members -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon switching to the normal .ini format
On 05/01/15 19:27, Matthew Farina wrote: Switching to an ini format would likely be painful to impossible. Horizon is built on django which is where the settings.py format comes from. It's part of a django app. For more info see the django docs. The settings information is at https://docs.djangoproject.com/en/1.6/topics/settings/ Sorry, I fail to see, how this should be impossible, esp. if you look at the linked patch; the rest of the stack uses such an .ini format, too. Matthias On Thu, Dec 25, 2014 at 1:25 PM, Timur Sufiev tsuf...@mirantis.com mailto:tsuf...@mirantis.com wrote: Thomas, I could only point you to the Radomir's patch https://review.openstack.org/#/c/100521/ It's still a work in progress, so you may ask him for more details. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 06/01/15 01:39, Tripp, Travis S wrote: What Radomir proposes looks like it would greatly ease the process I am still going through to get the latest angular available to Horizon for current development. At the time of writing this, I’m still trying to get the updated library through. I hit a rather difficult workflow: 1. Packaged the latest into Xstatic-Angular-1.3.7 2. Submitted patch which deprecated the separate older xstatic-angular-cookies and xstatic-angular-mock packages 3. Reviewed and approved (after correcting an initial mis-repackaging) 4. Radomir released to Pypi This was pretty easy and not too hard. Not too much to complain about. However, now, to get Horizon to use it, I have to get that into global requirements. Since I’m deprecating old packages I got stuck in a sort of ugly dependency path. I couldn’t remove the cookies and mock libraries from the global requirements patch that added the new 1.3.7 package because of horizon still referencing the deprecated packages. And, when I did it anyway, the integration tests failed due to horizon being dependent on something not in global requirements. So, now, as far as I can tell we have to jump through the following hoops: 1. Global requirements patch to add angular 1.3.7 * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and cookies packages * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 3. Global requirements patch to remove deprecated mock and cookies * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun Don’t get me wrong, I really do think the gate is brilliant and am all for a review / approval process, but this does seem excessive for a UI library that should only be used by Horizon. Is there some other reason that this should have to go through global requirements? You can do it much easier, since the current version of Angular already packages what is in the deprecated modules. So just: 1. Patch Horizon to remove the xstatic dependencies to the mock and cookies packages. 2. Patch global-requirements to remove them, and add newer Angular. 3. Patch Horizon to use the newer Angular. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova]nova not work with eventlet 0.16.0
hi all , I set up nova environment with latest upstream code. nova-compute can not boot up due to failed to load libvirt driver. by further debugging. found that eventlet (0.16.0) remove util which is referenced by libvirt driver. after I downgrade to (0.15.2) it works. *0.15.2* In [3]: print eventlet.__version__ 0.15.2 In [5]: import eventlet.util In [6]: - *0.16.0** * In [1]: import eventlet.util --- ImportError Traceback (most recent call last) ipython-input-1-a23626d6f273 in module() 1 import eventlet.util ImportError: No module named util In [3]: import eventlet In [4]: print eventlet.__version__ 0.16.0 In [5]: In [1]: import nova.virt.libvirt.LibvirtDriver --- ImportError Traceback (most recent call last) ipython-input-1-2bdce28fc3dd in module() 1 import nova.virt.libvirt.LibvirtDriver /opt/stack/nova/nova/virt/libvirt/__init__.py in module() 13 #under the License. 14 --- 15 from nova.virt.libvirt import driver 16 17 LibvirtDriver = driver.LibvirtDriver /opt/stack/nova/nova/virt/libvirt/driver.py in module() 96 from nova.virt.libvirt import dmcrypt 97 from nova.virt.libvirt import firewall as libvirt_firewall --- 98 from nova.virt.libvirt import host 99 from nova.virt.libvirt import imagebackend 100 from nova.virt.libvirt import imagecache /opt/stack/nova/nova/virt/libvirt/host.py in module() 37 from eventlet import patcher 38 from eventlet import tpool --- 39 from eventlet import util as eventlet_util 40 41 from nova import exception ImportError: cannot import name util In [2]: import eventlet In [3]: from eventlet import util --- ImportError Traceback (most recent call last) ipython-input-3-f6f91e4749eb in module() 1 from eventlet import util ImportError: cannot import name util In [4]: -- Thanks, Eli (Li Yong) Qiao ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] IRC logging
On 05/01/15 08:57 -0800, Morgan Fainberg wrote: On Jan 5, 2015, at 08:07, Nikhil Komawar nikhil.koma...@rackspace.com wrote: Based on the feedback received, we would like to avoid logging on the project channel. My take from the discussion was that it gives many a folks a feeling of informal platform to express their ideas freely in contrast to the meeting channels. However, at the same time I would like to point out that using foul language in the open freenode channels is a bad practice. There are no admins monitoring our project channels however, those channels that are monitored have people kicked out on misbehavior. The point being, no logging means freedom of thought for only the creative purposes; please do not take me any other way. Thanks, -Nikhil I just want to point out that keystone has logging enabled for our channel and I do not see it as a hamper to creative discussion / open discussion. The logging is definitely of value. Also a lot of people will locally log a given irc channel, which largely nets the same result. It is still not an official meeting, and we have heated debates at times, the logging let's us check back on things discussed outside of the official meetings. I do admit it is used less frequently than the meeting logs. Fully agree... I don't see how enable logging should be a limitation for freedom of thought. We've used it in Zaqar since day 0 and it's bee of great help for all of us. The logging does not remove the need of meetings where decisions and more relevant/important topics are discussed. From: Anita Kuno [ante...@anteaya.info] Sent: Monday, January 05, 2015 10:42 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Glance] IRC logging On 01/05/2015 06:42 AM, Cindy Pallares wrote: Hi all, I would like to re-open the discussion on IRC logging for the glance channel. It was discussed on a meeting back in November[1], but it didn't seem to have a lot of input from the community and it was not discussed in the mailing list. A lot of information is exchanged through the channel and it isn't accessible for people who occasionally come into our channel from other projects, new contributors, and people who don't want to be reached off-hours or don't have bouncers. Logging our channel would increase our community's transparency and make our development discussions publicly accessible to contributors in all time-zones and from other projects. It is very useful to look back on the logs for previous discussions or as well as to refer people to discussions or questions previously answered. +2 Thanks for bringing this up :) Flavio -- @flaper87 Flavio Percoco pgpq0Ec4GfNbo.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Devstack][Neutron]Neutron with External DHCP server
Dear All, Is it possible to configure neutron to take VM ip from external DHCP server? I am having All In One openstack env deployed using devstack icehouse. I am looking for an option to integrate it with external DHCP server. -- Thanks Regards E-Mail: thefossg...@gmail.com IRC: neophy Blog : http://lmohanphy.livejournal.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Cross-Project meeting, Tue January 6th, 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: * State of nova-network to neutron migration * Discuss openstack-spec: log guidelines [1] * Discuss openstack-spec: OSProfiler [2] * Open discussion announcements [1] https://review.openstack.org/#/c/132552/ [2] https://review.openstack.org/#/c/134839/ See you there ! For more details on this meeting, please see: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] microversion and backward incompatible changes on v2.1
Hi https://review.openstack.org/#/c/144995/ introduced a backward incompatible change with mirco version support and I think it's the microversion's purpose to enable v2.1 (v3) API to make those changes The question is whether we should make bp for each change for the API change? should we make a simple bp or go through the nova-spec process? Thanks a lot Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion
Based on nova-specs api-microversions.rst we support following function definition format, but it violate the hacking rule pep8 F811 because duplicate function definition we should use #noqa for them , but considering microversion may live for long time , keep adding #noqa may be a little bit ugly, can anyone suggest a good solution for it ? thanks @api_version(min_version='2.1') def _version_specific_func(self, req, arg1): pass @api_version(min_version='2.5') def _version_specific_func(self, req, arg1): pass Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
Thanks Eli, please do file a bug on Launchpad with your information below. Best, -jay On 01/06/2015 04:18 AM, Eli Qiao wrote: hi all , I set up nova environment with latest upstream code. nova-compute can not boot up due to failed to load libvirt driver. by further debugging. found that eventlet (0.16.0) remove util which is referenced by libvirt driver. after I downgrade to (0.15.2) it works. *0.15.2* In [3]: print eventlet.__version__ 0.15.2 In [5]: import eventlet.util In [6]: - *0.16.0** * In [1]: import eventlet.util --- ImportError Traceback (most recent call last) ipython-input-1-a23626d6f273 in module() 1 import eventlet.util ImportError: No module named util In [3]: import eventlet In [4]: print eventlet.__version__ 0.16.0 In [5]: In [1]: import nova.virt.libvirt.LibvirtDriver --- ImportError Traceback (most recent call last) ipython-input-1-2bdce28fc3dd in module() 1 import nova.virt.libvirt.LibvirtDriver /opt/stack/nova/nova/virt/libvirt/__init__.py in module() 13 #under the License. 14 --- 15 from nova.virt.libvirt import driver 16 17 LibvirtDriver = driver.LibvirtDriver /opt/stack/nova/nova/virt/libvirt/driver.py in module() 96 from nova.virt.libvirt import dmcrypt 97 from nova.virt.libvirt import firewall as libvirt_firewall --- 98 from nova.virt.libvirt import host 99 from nova.virt.libvirt import imagebackend 100 from nova.virt.libvirt import imagecache /opt/stack/nova/nova/virt/libvirt/host.py in module() 37 from eventlet import patcher 38 from eventlet import tpool --- 39 from eventlet import util as eventlet_util 40 41 from nova import exception ImportError: cannot import name util In [2]: import eventlet In [3]: from eventlet import util --- ImportError Traceback (most recent call last) ipython-input-3-f6f91e4749eb in module() 1 from eventlet import util ImportError: cannot import name util In [4]: -- Thanks, Eli (Li Yong) Qiao ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Support for Amazon VPC APIs in OpenStack
On 01/06/2015 12:44 AM, Saju M wrote: Hi, I seen a blueprint which implement Amazon VPC APIs and Status is Abandoned https://review.openstack.org/#/c/40071/ Have any plans to get it done in Kilo release ? How can I change the Abandoned status ?. Have any dependencies ? Please let me know, So I can rebase it. Hi Saju, We'd need to see a nova-specs submission for this work, first. You could take much of the content from https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support for the content of the nova-spec submission, though you will want to change references to Quantum to Neutron :) The nova-specs submission is covered here: https://wiki.openstack.org/wiki/Blueprints#Nova Note that due to it being late in the cycle, it will be unlikely to get a newly-submitted spec approved, but that does not mean you cannot work on code that implements the spec. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][oslo] heat unit tests mocking private parts of oslo.messaging
On 01/05/2015 06:03 PM, Doug Hellmann wrote: As part of updating oslo.messaging to move it out of the oslo namespace package I ran into some issues with heat. While debugging, I tried running the heat unit tests using the modified version of oslo.messaging and ran into test failures because the tests are mocking private parts of the library that are moving to have new names. It's just never polite to mock someone's private parts. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Problem installing devstack
Thanks for the responses RECLONE=yes worked for me. On Tue, Jan 6, 2015 at 11:14 AM, Dr. Jens Rosenboom j.rosenb...@x-ion.de wrote: Am 06/01/15 um 04:40 schrieb Rajdeep Dua: Getting this error while running stack.sh in devstack Could not find a version that satisfies the requirement SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from keystone==2014.2.dev114) (from versions: 0.4.2p3, 0.4.7p1, 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9, 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6, 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3, 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7, 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5, 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5, 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 0.9.6, 0.9.7, 0.9.8) No distributions matching the version for SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from keystone==2014.2.dev114) I saw a couple of bugs filed and patches going in. Please clarify if this is fixed and how to get the latest changes in. I would assume that you are trying to reuse an older devstack installation, as this bug should have been fixed a couple of weeks ago. However, running stack.sh by default does not update the source repos once they exist, so you can either add RECLONE=yes to your config or go manually through the repos in /opt/stack and update them. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FUEL] Zabbix in HA mode
On 01/05/2015 04:05 PM, Andrew Woodward wrote: snip Secondly running monitoring on the cluster may also result in the monitoring going offline if the cluster does, from my own experience, not being able to see your monitoring is nearly worse than having everything down and leads to lost precious moments of downtime SLA. Yep, this is exactly my experience as well. Excellent point. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion
2015-01-06 20:31 GMT+08:00 Jay Pipes jaypi...@gmail.com: On 01/06/2015 06:25 AM, Chen CH Ji wrote: Based on nova-specs api-microversions.rst we support following function definition format, but it violate the hacking rule pep8 F811 because duplicate function definition we should use #noqa for them , but considering microversion may live for long time , keep adding #noqa may be a little bit ugly, can anyone suggest a good solution for it ? thanks @api_version(min_version='2.1') def _version_specific_func(self, req, arg1): pass @api_version(min_version='2.5') def _version_specific_func(self, req, arg1): pass Hey Kevin, This was actually one of my reservations about the proposed microversioning implementation -- i.e. having functions that are named exactly the same, only decorated with the microversioning notation. It kinda reminds me of the hell of debugging C++ code that uses STL: how does one easily know which method one is in when inside a debugger? That said, the only other technique we could try to use would be to not use a decorator and instead have a top-level dispatch function that would inspect the API microversion (only when the API version makes a difference to the output or input of that function) and then dispatch the call to a helper method that had the version in its name. So, for instance, let's say you are calling the controller's GET /$tenant/os-hosts method, which happens to get routed to the nova.api.openstack.compute.contrib.hosts.HostController.index() method. If you wanted to modify the result of that method and the API microversion is at 2.5, you might do something like: def index(self, req): req_api_ver = utils.get_max_requested_api_version(req) if req_api_ver == (2, 5): return self.index_2_5(req) return self.index_2_1(req) def index_2_5(self, req): results = self.index_2_1(req) # Replaces 'host' with 'host_name' for result in results: result['host_name'] = result['host'] del result['host'] return results def index_2_1(self, req): # Would be a rename of the existing index() method on # the controller Another option would be to use something like JSON-patch to determine the difference between two output schemas and automatically translate one to another... but that would be a huge effort. Just JSON-patch only can resolve multiple-version of request/response, we need handle semantic change also. But I still think we need something like JSON-patch, it can avoid add new method only for small request/response changing, like this patch https://review.openstack.org/#/c/144995/3 I have propose before, we can try mapping the request/response into nova object by json-schema automatically, the nova object will handle the change. When the request/response changed, nothing will change in REST API code. I wrote the POC before https://github.com/soulxu/nova-v3-api-doc/commits/micro_ver_with_obj_auto_mapping This is more easy to maintenance than JSON-patch(thinking about the case of 3.3 patch based on 3.2 patch based on 3.1 patch.) That's the only other way I can think of besides disabling F811, which I really would not recommend, since it's a valuable safeguard against duplicate function names (especially duplicated test methods). Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion
On 01/06/2015 06:25 AM, Chen CH Ji wrote: Based on nova-specs api-microversions.rst we support following function definition format, but it violate the hacking rule pep8 F811 because duplicate function definition we should use #noqa for them , but considering microversion may live for long time , keep adding #noqa may be a little bit ugly, can anyone suggest a good solution for it ? thanks @api_version(min_version='2.1') def _version_specific_func(self, req, arg1): pass @api_version(min_version='2.5') def _version_specific_func(self, req, arg1): pass Hey Kevin, This was actually one of my reservations about the proposed microversioning implementation -- i.e. having functions that are named exactly the same, only decorated with the microversioning notation. It kinda reminds me of the hell of debugging C++ code that uses STL: how does one easily know which method one is in when inside a debugger? That said, the only other technique we could try to use would be to not use a decorator and instead have a top-level dispatch function that would inspect the API microversion (only when the API version makes a difference to the output or input of that function) and then dispatch the call to a helper method that had the version in its name. So, for instance, let's say you are calling the controller's GET /$tenant/os-hosts method, which happens to get routed to the nova.api.openstack.compute.contrib.hosts.HostController.index() method. If you wanted to modify the result of that method and the API microversion is at 2.5, you might do something like: def index(self, req): req_api_ver = utils.get_max_requested_api_version(req) if req_api_ver == (2, 5): return self.index_2_5(req) return self.index_2_1(req) def index_2_5(self, req): results = self.index_2_1(req) # Replaces 'host' with 'host_name' for result in results: result['host_name'] = result['host'] del result['host'] return results def index_2_1(self, req): # Would be a rename of the existing index() method on # the controller Another option would be to use something like JSON-patch to determine the difference between two output schemas and automatically translate one to another... but that would be a huge effort. That's the only other way I can think of besides disabling F811, which I really would not recommend, since it's a valuable safeguard against duplicate function names (especially duplicated test methods). Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion
On Tue, Jan 06, 2015 at 07:31:19AM -0500, Jay Pipes wrote: On 01/06/2015 06:25 AM, Chen CH Ji wrote: Based on nova-specs api-microversions.rst we support following function definition format, but it violate the hacking rule pep8 F811 because duplicate function definition we should use #noqa for them , but considering microversion may live for long time , keep adding #noqa may be a little bit ugly, can anyone suggest a good solution for it ? thanks @api_version(min_version='2.1') def _version_specific_func(self, req, arg1): pass @api_version(min_version='2.5') def _version_specific_func(self, req, arg1): pass Hey Kevin, This was actually one of my reservations about the proposed microversioning implementation -- i.e. having functions that are named exactly the same, only decorated with the microversioning notation. It kinda reminds me of the hell of debugging C++ code that uses STL: how does one easily know which method one is in when inside a debugger? That said, the only other technique we could try to use would be to not use a decorator and instead have a top-level dispatch function that would inspect the API microversion (only when the API version makes a difference to the output or input of that function) and then dispatch the call to a helper method that had the version in its name. So, for instance, let's say you are calling the controller's GET /$tenant/os-hosts method, which happens to get routed to the nova.api.openstack.compute.contrib.hosts.HostController.index() method. If you wanted to modify the result of that method and the API microversion is at 2.5, you might do something like: def index(self, req): req_api_ver = utils.get_max_requested_api_version(req) if req_api_ver == (2, 5): return self.index_2_5(req) return self.index_2_1(req) def index_2_5(self, req): results = self.index_2_1(req) # Replaces 'host' with 'host_name' for result in results: result['host_name'] = result['host'] del result['host'] return results def index_2_1(self, req): # Would be a rename of the existing index() method on # the controller Yes, I'd much prefer to see us use version numbers in the method names like this and not have identically named methods. With some cleverness we could perhaps avoid the need for the repetative 'index' impl and just auto-detect the versioned method names when needed. 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-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Questions on pep8 F811 hacking check for microversion
On 01/06/2015 06:25 AM, Chen CH Ji wrote: Based on nova-specs api-microversions.rst we support following function definition format, but it violate the hacking rule pep8 F811 because duplicate function definition we should use #noqa for them , but considering microversion may live for long time , keep adding #noqa may be a little bit ugly, can anyone suggest a good solution for it ? thanks @api_version(min_version='2.1') def _version_specific_func(self, req, arg1): pass @api_version(min_version='2.5') def _version_specific_func(self, req, arg1): pass Can you show the patch in question? (this is the only one I see - https://review.openstack.org/#/c/144995/3/nova/api/openstack/compute/plugins/v3/hosts.py,cm) We knew this was going to be an evolution. I think it was only ever envisioned that @api_version would be used at the top level dispatch, not 5 levels of private methods deep. The patch above does something extremely unexpected, and not what I wanted to see out of this for sure. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pip 6.0.6 breaking py2* jobs - bug 1407736
On 01/06/2015 03:09 AM, Matt Riedemann wrote: On 1/5/2015 2:16 PM, Doug Hellmann wrote: On Jan 5, 2015, at 12:22 PM, Doug Hellmann d...@doughellmann.com wrote: On Jan 5, 2015, at 12:00 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: There is a deprecation warning in pip 6.0.6 which is making the py26 (on stable branches) and py27 jobs hit subunit log sizes of over 50 MB which makes the job fail. A logstash query shows this started happening around 1/3 which is when pip 6.0.6 was released. In Nova alone there are nearly 18 million hits of the deprecation warning. Should we temporarily block so that pip 6.0.6? https://bugs.launchpad.net/nova/+bug/1407736 I think this is actually a change in pkg_resources (in the setuptools dist) [1], being triggered by stevedore using require=False to avoid checking dependencies when plugins are loaded. Doug [1] https://bitbucket.org/pypa/setuptools/commits/b1c7a311fb8e167d026126f557f849450b859502 After some discussion with Jason Coombs and dstufft, a version of setuptools with a split API to replace the deprecated option was released. I have a patch up to teach stevedore about the new methods[1]. Doug [1] https://review.openstack.org/#/c/145042/1 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The stevedore patch was merged. Do we need a release of stevedore and a global-requirements update to then get the deprecation warnings fixed in nova (on master and stable/juno)? I guess so. Also, Icehouse is affected too. I've checked Nova requirements.txt for Icehouse, and we don't cap steverore version, so a new release will be automatically propagated to all new jobs. /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable] Stable check of openstack/keystone failed
Both of these build failures should be fixed by: https://review.openstack.org/#/c/144182/ (Thanks, Alan!) On Tue, Jan 6, 2015 at 12:28 AM, A mailing list for the OpenStack Stable Branch test reports. openstack-stable-ma...@lists.openstack.org wrote: Build failed. - periodic-keystone-docs-icehouse http://logs.openstack.org/periodic-stableperiodic-keystone-docs-icehouse/ac7970c/ : FAILURE in 27s - periodic-keystone-python26-icehouse http://logs.openstack.org/periodic-stableperiodic-keystone-python26-icehouse/6f7ec11/ : SUCCESS in 23m 03s - periodic-keystone-python27-icehouse http://logs.openstack.org/periodic-stableperiodic-keystone-python27-icehouse/527351e/ : FAILURE in 41s - periodic-keystone-docs-juno http://logs.openstack.org/periodic-stableperiodic-keystone-docs-juno/6d4d68b/ : SUCCESS in 5m 59s - periodic-keystone-python26-juno http://logs.openstack.org/periodic-stableperiodic-keystone-python26-juno/7517d87/ : SUCCESS in 8m 24s - periodic-keystone-python27-juno http://logs.openstack.org/periodic-stableperiodic-keystone-python27-juno/727a389/ : SUCCESS in 9m 40s ___ Openstack-stable-maint mailing list openstack-stable-ma...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] [nova] [glance] Consistency in client side sorting
I've got no strong preferences on which we go for, but agree they should be consistent. The internal python library options should also be consistent. On 5 January 2015 at 20:52, Mike Perez thin...@gmail.com wrote: On 09:13 Mon 05 Jan , Steven Kaufer wrote: Giving that each of these 3 clients will be supporting client-side sorting in kilo, it seems that we should get this implemented in a consistent manner. It seems that the 2 options are either: --sort-key key1 --sort-dir desc --sort-key key2 --sort-dir asc --sort key1:asc,key2:desc Personally, I favor option 2 but IMO it is more important that these are made consistent. I like option 2 better. -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with External DHCP server
Hi, As far as I know, there is a spec and feature for external dhcp server configuration but *just for ironic project* (bare metal installation). Btw, I have not tested it yet. http://specs.openstack.org/openstack/ironic-specs/specs/juno/support-external-dhcp.html Erhan, On Tue, Jan 6, 2015 at 1:04 PM, foss geek thefossg...@gmail.com wrote: Dear All, Is it possible to configure neutron to take VM ip from external DHCP server? I am having All In One openstack env deployed using devstack icehouse. I am looking for an option to integrate it with external DHCP server. -- Thanks Regards E-Mail: thefossg...@gmail.com IRC: neophy Blog : http://lmohanphy.livejournal.com/ ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack][Neutron]Neutron with External DHCP server
On 01/06/2015 12:04 PM, foss geek wrote: Dear All, Is it possible to configure neutron to take VM ip from external DHCP server? I am having All In One openstack env deployed using devstack icehouse. I am looking for an option to integrate it with external DHCP server. At the moment, there is no way to achieve this, though the option was discussed as part of Pluggable IPAM effort that was approved for Kilo: http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/kilo/neutron-ipam.rst Quoting the spec: Out-of-Scope Items [...] Pluggable DHCP would require a separate effort, or must be addressed within the individual drivers. /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] stevedore 1.2.0 released
The Oslo team is pleased to announce the release of stevedore 1.2.0: Manage dynamic plugins for Python applications This release includes an update to eliminate excessive deprecation warnings generated by pkg_resources when plugins are loaded. For more details, please see the git log history below and https://launchpad.net/python-stevedore/+milestone/1.2.0 Please report issues through launchpad: https://bugs.launchpad.net/python-stevedore Changes in openstack/stevedore 1.1.0..1.2.0 37c94cd Use pkg_resources resolve() and require() instead of load() 9324bf0 Fix the README.rst file format for pypi 6027ff6 Workflow documentation is now in infra-manual bbafbe9 Implement a __contains__ override for extension manager f33adbe Update link to docs in README a322d61 Bring doc build up to standard diffstat (except docs and test files): CONTRIBUTING.rst | 2 +- README.rst| 12 +- setup.cfg | 4 +- stevedore/extension.py| 14 +- test-requirements.txt | 1 + 54 files changed, 1792 insertions(+), 1734 deletions(-) Requirements updates: diff --git a/test-requirements.txt b/test-requirements.txt index 7f1e798..6075428 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -11,0 +12 @@ oslotest=1.2.0 # Apache-2.0 +oslosphinx=2.2.0 # Apache-2.0 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] oslo.i18n 1.2.0 release
The Oslo team is pleased to announce the release of oslo.i18n 1.2.0: oslo.i18n library The primary reason for this release is to move the code out of the oslo namespace package as part of https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages For more details, please see the git log history below and http://launchpad.net/oslo.i18n/+milestone/1.2.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.i18n Changes in openstack/oslo.i18n 1.1.0..1.2.0 582c718 Correct the translation domain for loading messages ba05e9a Move out of the oslo namespace package c86629e Workflow documentation is now in infra-manual 53635ea Force code sample to be treated as python diffstat (except docs and test files): CONTRIBUTING.rst| 7 +- oslo/i18n/__init__.py | 23 +- oslo/i18n/_factory.py | 110 -- oslo/i18n/_gettextutils.py | 90 - oslo/i18n/_i18n.py | 25 -- oslo/i18n/_lazy.py | 38 -- oslo/i18n/_locale.py| 25 -- oslo/i18n/_message.py | 167 - oslo/i18n/_translate.py | 73 oslo/i18n/fixture.py| 54 +-- oslo/i18n/log.py| 86 + oslo_i18n/__init__.py | 16 + oslo_i18n/_factory.py | 110 ++ oslo_i18n/_gettextutils.py | 90 + oslo_i18n/_i18n.py | 25 ++ oslo_i18n/_lazy.py | 38 ++ oslo_i18n/_locale.py| 25 ++ oslo_i18n/_message.py | 167 + oslo_i18n/_translate.py | 73 oslo_i18n/fixture.py| 65 oslo_i18n/log.py| 97 ++ setup.cfg | 2 +- tests/fakes.py | 59 tests/test_factory.py | 91 - tests/test_fixture.py | 2 +- tests/test_gettextutils.py | 128 --- tests/test_handler.py | 4 +- tests/test_lazy.py | 40 --- tests/test_locale_dir_variable.py | 32 -- tests/test_logging.py | 42 --- tests/test_message.py | 518 tests/test_public_api.py| 2 +- tests/test_translate.py | 44 --- tests/test_warning.py | 61 tests/utils.py | 42 --- tox.ini | 2 +- 52 files changed, 2004 insertions(+), 1699 deletions(-) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross-Project meeting, Tue January 6th, 21:00 UTC
On 01/06/2015 06:14 AM, Thierry Carrez wrote: 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: * State of nova-network to neutron migration * Discuss openstack-spec: log guidelines [1] * Discuss openstack-spec: OSProfiler [2] * Open discussion announcements [1] https://review.openstack.org/#/c/132552/ [2] https://review.openstack.org/#/c/134839/ I took another spin on [1] this morning attempting to clear up the confusing parts and dumping the security section for now (as it was kind of a mismatch in structure for this document). Hopefully it's good enough to go at this point. -Sean See you there ! For more details on this meeting, please see: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] update existing plugin and add new ones
Hello, Actually there is two different fuel plugins git repositories. One in stackforge and the other in mirantis: https://github.com/stackforge/fuel-plugins https://github.com/Mirantis/fuel-plugins it is a little bit confusing. Why needing two different repositories? which one should be used in order to: -add new plugin -update/correct exisiting one (for example adding 7-mode and e-series support to cinder netapp plugin according to https://bugs.launchpad.net/fuel/+bug/1405186) How are going to be manage version? There is a stable/6.0 branch from stackforge repo but not mirantis one Regards, Samuel Bartel Orange _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] mid-cycle details
Devananda van der Veen wrote: Dates: Feb 3 - 5 (Tue - Thu) with a half day for those sticking around on Friday, Feb 6th. Location: Hewlett Packard Centre de Compétences 5 Avenue Raymond Chanas 38320 Eybens Grenoble, France Could you please reference it on: https://wiki.openstack.org/wiki/Sprints Thanks! -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting
On Tue, 2015-01-06 at 12:19 -0600, Anne Gentle wrote: I'm all for consistency. Sounds like a great case for the API Working Group to document. You can propose a patch describing the way we want sorting to work. See https://review.openstack.org/#/q/project:openstack/api-wg,n,z I really think that the API WG should be responsible for the REST API only, TBH, and maybe for the Pythonic APIs. Once we start talking about CLI options, I think that's outside the API WG's perview, and we probably should have that be up to CLI authors. My thinking is that a REST API and a Python API are both used by developers, where we have one set of conventions; but when you start talking about CLI, you're really talking about UX, and the rules there can be vastly different. Now, my personal preference on the CLI side is that --sort key[:dir] is the way to go, but I helped hash that out in the novaclient implementation as a reviewer. I also had suggestions about how it should be transmitted in the REST API, but that had already been settled at the blueprint phase; that may be something the API WG will want to take up and review and provide guidance on now, though… -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] update existing plugin and add new ones
Ah, bad paste, sorry. All the details around developing and certifying a plug-in can be found here: http://docs.mirantis.com/openstack/fuel/fuel-6.0/plugin-dev.html -Christopher ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] LDAP Assignment Backend Use Survey
The Keystone team is evaluating the support of the LDAP Assignment backend within OpenStack and how it is used in deployments. The assignment backend covers “Projects/Tenants”, “Roles/Grants”, and in the case of SQL “Domains”. There is a concern that the assignment backend implemented against LDAP is falling further and further behind the SQL implementation. To get a good read on the deployments and how the LDAP assignment backend is being used, the Keystone development team would appreciate feedback from the community. Please fill out the following form and let us know if you are using LDAP Assignment, what it provides you that the SQL assignment backend is not providing, and the release of OpenStack (specifically Keystone) you are using. http://goo.gl/forms/xz6xJQOQf5 http://goo.gl/forms/xz6xJQOQf5 This poll is only meant to get information on the use of the LDAP Assignment backend which only contains Projects/Tenants and Roles/Grants. Cheers, Morgan Fainberg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] Questions about the Octavia project
Ill answer inline what I can, others can chime in to clear up anything and answer the rest. On 1/6/15 10:38 AM, Andrew Hutchings and...@linuxjedi.co.uk wrote: Hi, I¹m looking into the Octavia project in relation to something my team are working on inside HP and I have a bunch of questions. I realise it is early days for the project and some of these could be too low level at this time. Some of these questions come from the fact that I could not get the documentation to compile and the docs site for Octavia is down. The v0.5-component-design.dot file crashes Graphviz 2.38 in every OS I tried and unfortunately all my dev machines have that version or 2.36 which is too low to render it correctly. It also requires at least 5 extra dependencies (Sphinx modules) to build the docs but doesn¹t try to install them. I¹ll guess I¹ll start from the most obvious question: 1. Octavia looks a lot like Libra but with integration into Neutron and Barbican (both were planned for Libra) as well as few other changes. So the most obvious question is: why not just develop Libra for integration with Neutron? There was many discussions with many contributors that included HP, Rackspace, Bluebox A10 etc.. In regards to this decision. In the docs we should have links to the reasonings behind some of these. Amphorae stuff: 2. I see a lot of building blocks for the controller and Amphorae but not a lot about communication. What protocol / method is to be used to communicate to the Amphorae instances? In the docs/specs the communication protocols are defined. 3. How are Amphorae instances to be spun up on-demand? I see a reference to Heat but not sure if that is why it is there The specs define how this is to happen 4. There is mention of Docker in some of the deploy scripts. Is this for multi-tenancy or just separation of the Amphorae processes? 5. I take it Amphorae is designed to be single-AZ for now? Load Balancing: 6. It seems like you are going to have SSL termination support and are going to use HAProxy, which means that you will have unencrypted data between the LB and web servers. How do you plan to work around this problem? Not sure what the 'problem' is, ultimately its up to the user, but a private network can be configured between the LB and Web server Security: 7. Someone in the specification there is talk of a 1 minute cache of security certificates. How are you going to ensure that the cache will actually erase that cache after the 1 minute? Also why cache them at all? It seems to me to be a potential security risk API: 8. More a comment than a question. There is talk of using Pecan+WSME. Libra had a 5K patch on top of WSME just to make it behave correctly with Pecan and correct JSON specifications in certain situations, judging by the planned API you will also hit those same situations. I admit I¹ve not looked at WSME for a year and there was an effort to strip it out of Libra completely at one point. So that one is mainly my 2c :) Many thanks for your time. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] update existing plugin and add new ones
On Tue, Jan 6, 2015 at 7:00 AM, samuel.bar...@orange.com wrote: Actually there is two different fuel plugins git repositories. One in stackforge and the other in mirantis: https://github.com/stackforge/fuel-plugins Stackforge plug-ins - used for plug-ins developed by Fuel Core team. https://github.com/Mirantis/fuel-plugins Mirantis plug-ins - used for plug-ins developed by Partner Integrations and MOS teams. it is a little bit confusing. Why needing two different repositories? Samuel, I agree, it is confusing. From what I see the repo on stackforge is the one that matters from the perspective of someone building a new plugin. For those just looking to download and use a plug-in, the directory of certified and non-certified plug-ins for Fuel will live here: https://software.mirantis.com/download-mirantis-openstack-fuel-plug-ins/ All the details around developing and certifying a plug-in can be found here: https://software.mirantis.com/download-mirantis-openstack-fuel-plug-ins/ Feedback on improving the docs is greatly appreciated! How are going to be manage version? There is a stable/6.0 branch from stackforge repo but not mirantis one Since plugins are developed and built outside Fuel, the plugins have their own versions (see metadata.yaml file). I expect we will make things a little clearer in the weeks to come, but please share your feedback and thoughts on how to make this work better. Thanks! -Christopher ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday January 7th @ 2200 UTC in #openstack-meeting
Hi all, Just a reminder that the OpenStack Telco Working Group [1] will be meeting @ 2200 UTC in #openstack-meeting on Wednesday January 7th. Draft agenda is available here: https://etherpad.openstack.org/p/nfv-meeting-agenda Please feel free to add items that you wish to discuss at the meeting. Thanks, Steve [1] https://wiki.openstack.org/wiki/TelcoWorkingGroup ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
Am 06/01/15 um 18:01 schrieb Daniel P. Berrange: On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote: On 01/06/2015 05:33 PM, Daniel P. Berrange wrote: On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote: Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is still in the libvirt host module, but this isn't blowing up in the Jenkins runs, so what's different? There isn't a version cap on eventlet in global-requirements either. When I pip install it in my dev env it still pulls in 0.15.2. Likewise looking at a jenkins log from today it pulls in 0.15.2 http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log But the pypi page refers to 0.16.0 https://pypi.python.org/pypi/eventlet/ ?!?!? Maybe some external dependency pulls in older version? Ah, it seems my devpi/wheel caching setup was not seeing the new version. When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate has a similar cache refresh issue As I noted in https://bugs.launchpad.net/nova/+bug/1407685/comments/3 the pypi version of eventlet 0.16.0 does still include the old code, so you are only going to see this issue if you install eventlet from source. In particular most devstack issues will not see this issue until the pypi package is fixed. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support
Miguel, Thanks again for taking this on. I went looking for the rootwrap daemon code today in gerrit and found it here [1]. I can allocate some review cycles to help get this merged early in the cycle. Please keep us posted on your progress refreshing the code. Carl [1] https://review.openstack.org/#/c/84667/ On Mon, Nov 10, 2014 at 2:05 AM, Miguel Angel Ajo Pelayo majop...@redhat.com wrote: Thank you very much Armando, I updated the spec (which is missing the dev impact now) and I must rebase all the patches. That may happen during tomorrow if I'm not missing anything. I will ping you back when it's ready. Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Armando M. [arma...@gmail.com] Received: Saturday, 08 Nov 2014, 11:25 To: OpenStack Development Mailing List (not for usage questions) [openstack-dev@lists.openstack.org] Subject: Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support Hi Miguel, Thanks for picking this up. Pull me in and I'd be happy to help! Cheers, Armando On 7 November 2014 10:05, Miguel Ángel Ajo majop...@redhat.com wrote: Hi Yorik, I was talking with Mark Mcclain a minute ago here at the summit about this. And he told me that now at the start of the cycle looks like a good moment to merge the spec the root wrap daemon bits, so we have a lot of headroom for testing during the next months. We need to upgrade the spec [1] to the new Kilo format. Do you have some time to do it?, I can allocate some time and do it right away. [1] https://review.openstack.org/#/c/93889/ -- Miguel Ángel Ajo Sent with Sparrow On Thursday, 24 de July de 2014 at 01:42, Miguel Angel Ajo Pelayo wrote: +1 Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Yuriy Taraday [yorik@gmail.com] Received: Thursday, 24 Jul 2014, 0:42 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support Hello. I'd like to propose making a spec freeze exception for rootwrap-daemon-mode spec [1]. Its goal is to save agents' execution time by using daemon mode for rootwrap and thus avoiding python interpreter startup time as well as sudo overhead for each call. Preliminary benchmark shows 10x+ speedup of the rootwrap interaction itself. This spec have a number of supporters from Neutron team (Carl and Miguel gave it their +2 and +1) and have all code waiting for review [2], [3], [4]. The only thing that has been blocking its progress is Mark's -2 left when oslo.rootwrap spec hasn't been merged yet. Now that's not the case and code in oslo.rootwrap is steadily getting approved [5]. [1] https://review.openstack.org/93889 [2] https://review.openstack.org/82787 [3] https://review.openstack.org/84667 [4] https://review.openstack.org/107386 [5] https://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
On 01/06/2015 09:56 PM, victor stinner wrote: Hi, I set up nova environment with latest upstream code. nova-compute can not boot up due to failed to load libvirt driver. by further debugging. found that eventlet (0.16.0) remove util which is referenced by libvirt driver. after I downgrade to (0.15.2) it works. Can you please try my following change? https://review.openstack.org/#/c/145335/ It changes the libvirt driver to stop using the deprecated (and now removed) eventlet.util module. Victor Victor, Could you also backport this to Juno? Cheers, Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] unit test migration failure specific to MySQL/MariaDB - 'uuid': used in a foreign key constraint 'block_device_mapping_instance_uuid_fkey'
Hello -
Victor Sergeyev and I are both observing the following test failure which
occurs with all the tests underneath
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.This is against
master with a brand new tox environment and everything at the default.
It does not seem to be occurring on gates that run these tests and
interestingly the tests seem to complete very quickly (under seven seconds) on
the gate as well; the failures here take between 50-100 seconds to occur, not
fully deterministically, and only on the MySQL backend; the Postgresql and
SQLite versions of these tests pass. I’m running against MariaDB server
10.0.14 with Python 2.7.8 on Fedora 21.
Below is the test just for test_walk_versions, but the warnings (not
necessarily the failures themselves) here also occur for test_migration_267 as
well as test_innodb_tables.
I’m still looking into what the cause of this is, I’d imagine it’s something
related to newer MySQL versions or perhaps MariaDB vs. MySQL, I’m just putting
it up here in case someone already knows what this is or has some clue to save
me some time figuring it out. I apologize if I’m just doing something dumb,
I’ve only recently begun to run Nova’s test suite in full against all backends,
so I haven’t yet put intelligent thought into this nor have I tried to yet look
at the migration in question causing the problem. Will do that next.
[mbayer@thinkpad nova]$ tox -e py27 --
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_walk_versions
py27 develop-inst-noop: /home/mbayer/dev/openstack/nova
py27 runtests: PYTHONHASHSEED='0'
py27 runtests: commands[0] | find . -type f -name *.pyc -delete
py27 runtests: commands[1] | bash tools/pretty_tox.sh
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_walk_versions
running testr
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./nova/tests}
--list
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./nova/tests}
--load-list /tmp/tmpw7zqhE
2015-01-06 18:28:12.913 32435 WARNING oslo.db.sqlalchemy.session
[req-5cc6731f-00ef-43df-8aec-4914a44d12c5 ] MySQL SQL mode is '', consider
enabling TRADITIONAL or STRICT_ALL_TABLES
{0}
nova.tests.unit.db.test_migrations.TestNovaMigrationsMySQL.test_walk_versions
[51.553131s] ... FAILED
Captured traceback:
~~~
Traceback (most recent call last):
File nova/tests/unit/db/test_migrations.py, line 151, in
test_walk_versions
self.walk_versions(self.snake_walk, self.downgrade)
File
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/oslo/db/sqlalchemy/test_migrations.py,
line 193, in walk_versions
self.migrate_up(version, with_data=True)
File nova/tests/unit/db/test_migrations.py, line 148, in migrate_up
super(NovaMigrationsCheckers, self).migrate_up(version, with_data)
File
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/oslo/db/sqlalchemy/test_migrations.py,
line 263, in migrate_up
self.REPOSITORY, version)
File
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/api.py,
line 186, in upgrade
return _migrate(url, repository, version, upgrade=True, err=err, **opts)
File string, line 2, in _migrate
File
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/util/__init__.py,
line 160, in with_engine
return f(*a, **kw)
File
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/api.py,
line 366, in _migrate
schema.runchange(ver, change, changeset.step)
File
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/schema.py,
line 93, in runchange
change.run(self.engine, step)
File
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/versioning/script/py.py,
line 148, in run
script_func(engine)
File
/home/mbayer/dev/openstack/nova/nova/db/sqlalchemy/migrate_repo/versions/267_instance_uuid_non_nullable.py,
line 103, in upgrade
process_null_records(meta, scan=False)
File
/home/mbayer/dev/openstack/nova/nova/db/sqlalchemy/migrate_repo/versions/267_instance_uuid_non_nullable.py,
line 89, in process_null_records
table.columns.uuid.alter(nullable=False)
File
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/changeset/schema.py,
line 534, in alter
return alter_column(self, *p, **k)
File
/home/mbayer/dev/openstack/nova/.tox/py27/lib/python2.7/site-packages/migrate/changeset/schema.py,
line 141, in
[openstack-dev] [Nova] Etherpad for the Nova midcycle meetup
Heya, https://etherpad.openstack.org/p/kilo-nova-midcycle is the etherpad for the Nova midcycle meetup. I'd like to start collecting topics we'd like to cover, and we'll sort them by priority later once we've collected a few. Thanks, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] taskflow 0.6.1 released
The Oslo team is pleased to announce the release of: taskflow 0.6.1: Taskflow structured state management library. For more details, please see the git log history below and: http://launchpad.net/taskflow/+milestone/0.6.1 Please report issues through launchpad: http://bugs.launchpad.net/taskflow/ Changes in taskflow 0.6.0..0.6.1 --- 69449ae Remove need to inherit/adjust netutils split b52db18 Allow specifying the engine 'executor' as a string 2ed1ad9 Disallowing starting the executor when worker running 50c5441 Use a single shared queue for an executors lifecycle 49ac8ec Avoid creating a temporary list(s) for tree type 05518ca Update statement around stopwatch thread safety d498fdb Register with 'ANY' in the cloned process fce7afb Remove less than useful action_engine __str__ f897008 Ensure manager started/shutdown/joined and reset f862775 Return the same namedtuple that the future module returns 6cb9a0c Add a simplistic hello world example e841b5a Get event/notification sending working correctly a170f4b Move the engine scoping test to its engines test folder 2a8fde1 Get the basics of a process executor working dbc890f Correctly trigger 'on_exit' of starting/initial state 2b959da Add an example which shows how to send events out from tasks Diffstat (except docs and test files) - taskflow/engines/action_engine/engine.py | 113 +- taskflow/engines/action_engine/executor.py | 429 - taskflow/engines/worker_based/engine.py| 34 +- taskflow/engines/worker_based/executor.py | 18 +- taskflow/examples/alphabet_soup.py | 101 + taskflow/examples/hello_world.py | 110 ++ taskflow/examples/wbe_event_sender.py | 148 +++ taskflow/types/fsm.py | 7 +- taskflow/types/timing.py | 5 +- taskflow/types/tree.py | 9 +- taskflow/utils/async_utils.py | 33 +- taskflow/utils/lock_utils.py | 9 +- taskflow/utils/misc.py | 24 +- taskflow/utils/threading_utils.py | 7 + 26 files changed, 1517 insertions(+), 479 deletions(-) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Progress of the port to Python 3
On 01/06/2015 05:51 PM, victor stinner wrote: Hi, I'm still working on porting OpenStack to Python 3. I'm fixing Python 3 issues in eventlet and I'm trying to replace eventlet with trollius in OpenStack. Two different and complementary ways to port OpenStack to Python 3. Hi Victor, Will you also work on moving away from python-memcache (eg: memcached) and using pymemcache instead? I believe I shouted enough about this being a major issue for the support of Python 3, but nothing is happening here. I fixed some eventlet issues related to Python 3 and monkey-patching. My changes are part of eventlet 0.16 which was released the 2014-12-30. I tried this version with Oslo Messaging: with another fix in eventlet (threading.Condition) and a change in the zmq driver, only 3 tests are now failing (which is a great success for me). Super cool! :) Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable] Proposal to add Flavio Percoco to stable-maint-core
Hiya- Flavio has been actively involved in stable branch maintenance for as long as I can remember, but it looks like his +2 abilities were removed after the organizational changes made to the stable maintenance teams. He has expressed interest in continuing on with general stable maintenance and I think his proven understanding of branch policies make him a valuable contributor. I propose we add him to the stable-maint-core team. Cheers, Adam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Proposal to add Flavio Percoco to stable-maint-core
+1 Flavio has always been a good gate keeper of stable across the board. Sent via mobile On Jan 6, 2015, at 11:32, Adam Gandelman ad...@ubuntu.com wrote: Hiya- Flavio has been actively involved in stable branch maintenance for as long as I can remember, but it looks like his +2 abilities were removed after the organizational changes made to the stable maintenance teams. He has expressed interest in continuing on with general stable maintenance and I think his proven understanding of branch policies make him a valuable contributor. I propose we add him to the stable-maint-core team. Cheers, Adam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] client noauth deprecation
The option to disable keystone authentication in the neutron client was marked for deprecation in August as part of a Keystone support upgrade.[1] What was the reason for this? As far as I can tell, Neutron works fine in the 'noauth' mode and there isn't a lot of code that tightly couples neutron to Keystone that I can think of. 1. https://github.com/openstack/python-neutronclient/commit/2203b013fb66808ef280eff0285318ce21d9bc67#diff-ba2e4fad85e66d9aabb6193f222fcc4cR438 -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cross Project][Log][Profiler] Specs are in review and need constructive feedback soonest
The Cross Project team meeting discussed the following specs today: * Discuss openstack-spec: log guidelines [1] * Discuss openstack-spec: OSProfiler [2] * Open discussion announcements [1] https://review.openstack.org/#/c/132552/ [2] https://review.openstack.org/#/c/134839/ For [1], the log guidelines spec is likely to reach approval for merge by the next meeting on 1/13. The spec has not been discussed on any mailing list for a while, so might be flying a bit under the radar. This log guidelines spec is high level and states a number of best practices for developers when writing the logging chunks of their project code. It also codifies the set of log levels: Error; Warning; Info; etc. and removes the AUDIT level. Operators and others who hold an interest in this: *PLEASE REVIEW [1] AND COMMENT ON THE REVIEW BY 1/13* Lack of comments, as always, implies approval. If there is only light discussion of the spec, it will be approved. If there is lively discussion, the discussion will move towards consensus before final approval. The spec will then be used to expand the code review checklist so that its contents are enforced. For [2], the OSProfiler spec is not as far along, but if you as an Ops (or interested developer) sees an issue or has a suggestion for improvement, you should also comment on this review. The profiler already has code in use and is considered useful by a number of developers and some DevOps, which is why this spec and its review is being highlighted for this audience. Ops, if you've never commented on a review before, don't let that hurdle stop you. Check out this page: http://docs.openstack.org/infra/manual/developers.html#code-review It tells you how to post a review. It doesn't tell you that you need get an account on Launchpad.net, but that info is here: http://docs.openstack.org/infra/manual/developers.html#account-setup . I'm not sure if you have to be a member of OpenStack for commenting, but I'm sure folks will chime in if you do;-) If working through these docs is hard for you, go out to IRC and folks will help get you started so you *can* comment on the reviews. Also, if there is a section of the spec that you feel needs broader attention, start a discussion of it on the mailing list. Please reference the review and the part of the spec you want to discuss, but put it out there on the mailing list so the issues/suggestions you have get addressed. --Rocky ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
在 2015年01月07日 04:56, victor stinner 写道: Hi, I set up nova environment with latest upstream code. nova-compute can not boot up due to failed to load libvirt driver. by further debugging. found that eventlet (0.16.0) remove util which is referenced by libvirt driver. after I downgrade to (0.15.2) it works. Can you please try my following change? https://review.openstack.org/#/c/145335/ It changes the libvirt driver to stop using the deprecated (and now removed) eventlet.util module. Victor thanks victor, you response so quick, appreciate, I will get some time to verify it ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Eli (Li Yong) Qiao ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][api]do we need to have a spec for all api related changes?
hi all: I have a patch [1], just did slight changes on api, do I need to write a spec(kinds of wasting time to get approved)? since api-microversion[2] is almost done, can we just feel free to add changes as micro-version api? like bump version , write down changes in rest_api_version_history.rst [1] https://review.openstack.org/#/c/144914/ [2] https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/api-microversions,n,z -- Thanks, Eli (Li Yong) Qiao ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting
On Jan 6, 2015, at 12:46 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Tue, 2015-01-06 at 12:19 -0600, Anne Gentle wrote: I'm all for consistency. Sounds like a great case for the API Working Group to document. You can propose a patch describing the way we want sorting to work. See https://review.openstack.org/#/q/project:openstack/api-wg,n,z I really think that the API WG should be responsible for the REST API only, TBH, and maybe for the Pythonic APIs. Once we start talking about CLI options, I think that's outside the API WG's perview, and we probably should have that be up to CLI authors. My thinking is that a REST API and a Python API are both used by developers, where we have one set of conventions; but when you start talking about CLI, you're really talking about UX, and the rules there can be vastly different. Agreed. The scope [1] of the API WG is the HTTP (REST) API. We won’t be touching any language SDKs (one of which is referred to as Pythonic APIs above) or any CLIs. Thanks, Everett [1] https://wiki.openstack.org/wiki/API_Working_Group#Scope ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] Etherpad for the Keystone midcycle meetup
Howdy, https://etherpad.openstack.org/p/kilo-keystone-midcycle is the etherpad for the Keystone midcycle meetup. Similar to the Nova team, we should start collecting topics to cover, and sort them by priority later once we've collected a few. Steve___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Refstack] Refstack mid cycle meet up in Santa Clara, CA Jan 12-14 2015
Refstack is having its midcycle F2F meetup January 12-14, 2015 in Santa Clara, CA Etherpad is: https://etherpad.openstack.org/p/refstack-january-2015-midcycle Everyone is welcome to join in, but please add your list to the etherpad if you will be attending in person. We are hoping to do a sprint on getting the Refstack website back up and running, and are inviting local infra folks to suggest a session time and date for possibly doing this F2F, too. We hope we can quickly identify what infra needs to make this happen, and get the site up and action items for what else is needed during the session. The Refstack team is flexible in shifting sessions to accommodate the Infra team. We also will be working on the test UUID and would love any local QA team members to join for a session or two. And, just to round this out, are there any Docs folks who might want to help for a session. We promise at least one Refstack member dedicated to your needs;-) There will be group dinners for those interested... --Rocky ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with External DHCP server
We have a spec for implementing a DHCP relay agent [1], which would enable this. We have implemented this, but it's not upstream (yet!). You would have to download our adapter [2] and dissect it to get the code from there, which may be pretty painful, because the package includes lots of changes related to our integration rather than just the relay. The adapter uses ISC dhcrelay, but we had to patch it to add the link selection option. That code is also included with the adapter package, along with a build script for it. [1] https://blueprints.launchpad.net/neutron/+spec/dhcp-relay [2] https://www.infoblox.com/products/private-hybrid-cloud/openstack-adapter From: Erhan Ekici erhan.ek...@gmail.commailto:erhan.ek...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, January 6, 2015 at 9:00 AM To: foss geek thefossg...@gmail.commailto:thefossg...@gmail.com Cc: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, openstack openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Subject: Re: [openstack-dev] [Openstack] [Devstack][Neutron]Neutron with External DHCP server Hi, As far as I know, there is a spec and feature for external dhcp server configuration but just for ironic project (bare metal installation). Btw, I have not tested it yet. http://specs.openstack.org/openstack/ironic-specs/specs/juno/support-external-dhcp.html Erhan, On Tue, Jan 6, 2015 at 1:04 PM, foss geek thefossg...@gmail.commailto:thefossg...@gmail.com wrote: Dear All, Is it possible to configure neutron to take VM ip from external DHCP server? I am having All In One openstack env deployed using devstack icehouse. I am looking for an option to integrate it with external DHCP server. -- Thanks Regards E-Mail: thefossg...@gmail.commailto:thefossg...@gmail.com IRC: neophy Blog : http://lmohanphy.livejournal.com/ ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [kolla][tripleo] Announcing Kolla Milestone #2
I'm pleased to announce the release of Kolla Milestone #2 available for immediate download from https://github.com/stackforge/kolla/archive/version-m2.tar.gz. Kolla is an effort to bring container deployment of OpenStack to TripleO. This milestone brings several new features: * Integrated Neutron container * Integrated Ceilometer container * Integrated Horizon container * Integrated Zaqar container * Integrated Mongodb container As can be seen from our list of updates, most of the work has been focused on updating the services we support to more fully deploy OpenStack. Our huge feature this release is Neutron, which we would love people to test and use. Instructions for running Kolla can be found with the software release in addition to our previous milestone #1 release at: http://lists.openstack.org/pipermail/openstack-dev/2014-October/048970.html Our milestone #3 and beyond will likely focus around tighter integration with TripleO. For more details see: https://review.openstack.org/#/c/144199/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder bug commit] How to commit a bug which depends on another bug that have not been merged?
Hi all, * I have commit a bug and it is not yet merged. Now I want to commit another bug but this bug is depends on the previousapp:ds:previous one which have not been merged? * So how should I do? Should I commit the latterapp:ds:latter bug directly or wait the previousapp:ds:previous bug to be merged? Any input will be appreciated, thanks! liu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][api]do we need to have a spec for all api related changes?
2015-01-07 11:43 GMT+08:00 Eli Qiao ta...@linux.vnet.ibm.com: hi all: I have a patch [1], just did slight changes on api, do I need to write a spec(kinds of wasting time to get approved)? since api-microversion[2] is almost done, can we just feel free to add changes as micro-version api? We definitely can't 'feel free' to change API even we have micro-version, special for back-incompatibility change. The spec is for avoid we break the API accidentally. like bump version , write down changes in rest_api_version_history.rst [1] https://review.openstack.org/#/c/144914/ [2] https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/api-microversions,n,z -- Thanks, Eli (Li Yong) Qiao ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] Is anyone working on the following patch?
https://review.openstack.org/#/c/113586/ Two of my patches depend on this patch. https://review.openstack.org/#/c/113277/ https://review.openstack.org/#/c/110575/ Cheers, Ajaya ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting
Steven, This sounds like a perfect place for a cross project spec. It wouldn't have to be a big one, but all the projects would have a chance to review and the TC would oversee to ensure it gets proper review. TCms, am I on point here? --Rocky From: Jay S. Bryant [mailto:jsbry...@electronicjungle.net] Sent: Tuesday, January 06, 2015 10:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting Steven, Thank you for continuing to pursue this. Adding this functionality and having it consistent will be a good thing. The plan for Cinder looks good to me and is consistent with Mike and Duncan's input. I look forward to seeing patches for Cinder. Jay On 01/06/2015 10:03 AM, Steven Kaufer wrote: This is a follow up thread to [1] In order to have consistency across clients, I am proposing that the client side sorting has the following syntax: --sort key[:direction] Where the --sort parameter is comma-separated and is used to specify one or more sort keys and directions. The direction defaults to 'desc' for each sort key and the user can supply 'asc' to override. For example: nova list --sort display_name nova list --sort display_name,vm_state nova list --sort display_name:asc,vm_state:asc If approved, then the following changes are needed for glance and cinder (note that nova already uses this syntax): Cinder: Deprecate --sort_key and --sort_dir and add support for --sort Glance: Modify [2] to this new syntax I have not verified how all other projects handle sorting, there may be other projects that would also need to be changed. Thoughts? Objections? Also, if there is a more formal way to propose/review this standard please let me know. [1] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html [2] https://review.openstack.org/#/c/120777/ Thanks, Steven Kaufer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Manila]Rename driver mode
Hi list, After study https://wiki.openstack.org/wiki/Manila/Kilo_Network_Spec I’d like to change my proposal. Since driver mode is actually decide by its network situation, how about: static_network_mode ⇨ No share server ⇨ import share server from other place dynamic_network_mode ⇨ flat network ⇨ segmented network o share server at the same subnet of share network o share server connect to tenant subnet using router The usecase would like this: enabled_backends=generic1,generic2,glusterfs1 [generic1] driver=manila.share.drivers.generic.GenericShareDriver mode=dynamic_network_mode network=network1 [generic2] driver=manila.share.drivers.generic.GenericShareDriver mode=static_network_mode enable_share_server=True share_server=server1 [glusterfs1] share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver glusterfs_target = manila:/manila-volume0 mode=static_network_mode enable_share_server=False [network1] plugin=manila.network.Neutron network_type=flat network=192.168.10.0 netmask=255.255.255.0 gateway=192.168.10.1 ip_range=192.168.10.50-192.168.10.99 [server1] server_type=nova is_deletable=False id=x From: Li, Chen [mailto:chen...@intel.com] Sent: Tuesday, December 30, 2014 5:27 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Manila]Rename driver mode Hi list, There are two driver modes in manila currently, “multi_svm_mode” and “single_svm_mode”. multi_svm_mode means usage of share-networks that contain network information for dynamic creation of share-servers (SVMs). single_svm_mode means usage of predefined some endpoint, without need to provide share-network and without creation of share-servers (SVMs). Currently, the name of driver mode describes how many servers the driver can handle. For multi, it says that share driver can handle more than one server. And, if someone share server is just already exist from share driver, but it uses some server anyway with host address, username, password, NFS daemon, etc... are defined as works in single_svm mode too. But, as a new user to manila, these names make me really confusing. Because I thought the driver mode names describe how drivers works with share-servers. I thought “multi-” and “single-” indicate the number of share-servers would been created when we create a share, if we are using the driver. Obviously, my understanding is wrong. When we’re working under driver generic, one share-server would be created for one share-network. When we’re working under driver glusterfs, no share-server would be created at all. I believe I would not be the only one who is making this mistake. To make code more readable, I’d like to suggest to rename driver mode names. Name them based on behavior but not ability. I think three driver modes are needed: - dynamic_svm_mode : Usage of share-networks that contain network information for dynamic creation of share-servers (SVMs). This is how current generic driver works. Under this mode, driver manages share servers itself, and share-server would be created and deleted with related shares. - static_svm_mode: Using pre-create share servers. The case as https://review.openstack.org/#/c/144342/ Under this mode, driver do not manage share servers, but work with them. - no_svm_mode: the case as driver glusterfs working currently, no share-server would be created. Thanks. -chen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without stopping sevices
Itsuro,
It would be desirable to be able to be hide an agent from scheduling
but no one has stepped up to make this happen. Come to think of it,
I'm not sure that a bug or blueprint has been filed yet to address it
though it is something that I've wanted for a little while now.
Carl
On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA o...@valinux.co.jp wrote:
Neutron experts,
I want to stop scheduling to a specific {dhcp|l3}_agent without
stopping router/dhcp services on it.
I expected setting admin_state_up of the agent to False is met
this demand. But this operation stops all services on the agent
in actuality. (Is this behavior intended ? It seems there is no
document for agent API.)
I think admin_state_up of agents should affect only scheduling.
If it is accepted I will submit a bug report and make a fix.
Or should I propose a blueprint for adding function to stop
agent's scheduling without stopping services on it ?
I'd like to hear neutron experts' suggestions.
Thanks.
Itsuro Oda
--
Itsuro ODA o...@valinux.co.jp
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting
On Tue, Jan 6, 2015 at 10:03 AM, Steven Kaufer kau...@us.ibm.com wrote: This is a follow up thread to [1] In order to have consistency across clients, I am proposing that the client side sorting has the following syntax: --sort key[:direction] Where the --sort parameter is comma-separated and is used to specify one or more sort keys and directions. The direction defaults to 'desc' for each sort key and the user can supply 'asc' to override. For example: nova list --sort display_name nova list --sort display_name,vm_state nova list --sort display_name:asc,vm_state:asc If approved, then the following changes are needed for glance and cinder (note that nova already uses this syntax): Cinder: Deprecate --sort_key and --sort_dir and add support for --sort Glance: Modify [2] to this new syntax I have not verified how all other projects handle sorting, there may be other projects that would also need to be changed. Thoughts? Objections? Also, if there is a more formal way to propose/review this standard please let me know. I'm all for consistency. Sounds like a great case for the API Working Group to document. You can propose a patch describing the way we want sorting to work. See https://review.openstack.org/#/q/project:openstack/api-wg,n,z Anne [1] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html [2] https://review.openstack.org/#/c/120777/ Thanks, Steven Kaufer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][all] nova not work with eventlet 0.16.0
Maybe we should ask for cap eventlet to 0.15.2 in global-requirements ? Adding the [all] tag as I think it's cross-project. -Sylvain Le 06/01/2015 18:01, Daniel P. Berrange a écrit : On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote: On 01/06/2015 05:33 PM, Daniel P. Berrange wrote: On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote: Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is still in the libvirt host module, but this isn't blowing up in the Jenkins runs, so what's different? There isn't a version cap on eventlet in global-requirements either. When I pip install it in my dev env it still pulls in 0.15.2. Likewise looking at a jenkins log from today it pulls in 0.15.2 http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log But the pypi page refers to 0.16.0 https://pypi.python.org/pypi/eventlet/ ?!?!? Maybe some external dependency pulls in older version? Ah, it seems my devpi/wheel caching setup was not seeing the new version. When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate has a similar cache refresh issue Regards, Daniel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
On 1/6/2015 6:33 AM, Jay Pipes wrote: Thanks Eli, please do file a bug on Launchpad with your information below. Best, -jay On 01/06/2015 04:18 AM, Eli Qiao wrote: hi all , I set up nova environment with latest upstream code. nova-compute can not boot up due to failed to load libvirt driver. by further debugging. found that eventlet (0.16.0) remove util which is referenced by libvirt driver. after I downgrade to (0.15.2) it works. *0.15.2* In [3]: print eventlet.__version__ 0.15.2 In [5]: import eventlet.util In [6]: - *0.16.0** * In [1]: import eventlet.util --- ImportError Traceback (most recent call last) ipython-input-1-a23626d6f273 in module() 1 import eventlet.util ImportError: No module named util In [3]: import eventlet In [4]: print eventlet.__version__ 0.16.0 In [5]: In [1]: import nova.virt.libvirt.LibvirtDriver --- ImportError Traceback (most recent call last) ipython-input-1-2bdce28fc3dd in module() 1 import nova.virt.libvirt.LibvirtDriver /opt/stack/nova/nova/virt/libvirt/__init__.py in module() 13 #under the License. 14 --- 15 from nova.virt.libvirt import driver 16 17 LibvirtDriver = driver.LibvirtDriver /opt/stack/nova/nova/virt/libvirt/driver.py in module() 96 from nova.virt.libvirt import dmcrypt 97 from nova.virt.libvirt import firewall as libvirt_firewall --- 98 from nova.virt.libvirt import host 99 from nova.virt.libvirt import imagebackend 100 from nova.virt.libvirt import imagecache /opt/stack/nova/nova/virt/libvirt/host.py in module() 37 from eventlet import patcher 38 from eventlet import tpool --- 39 from eventlet import util as eventlet_util 40 41 from nova import exception ImportError: cannot import name util In [2]: import eventlet In [3]: from eventlet import util --- ImportError Traceback (most recent call last) ipython-input-3-f6f91e4749eb in module() 1 from eventlet import util ImportError: cannot import name util In [4]: -- Thanks, Eli (Li Yong) Qiao ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is still in the libvirt host module, but this isn't blowing up in the Jenkins runs, so what's different? There isn't a version cap on eventlet in global-requirements either. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Telco] [NFV] Service function chaining
Hi all, as discussed per last IRC meeting we prepared first thoughts on the requirements on Service Function Chaining (SFC) and relevant use-case. We have an etherpad for initial draft ideas. Later on we should move it to wiki. All comments are very welcome. https://etherpad.openstack.org/p/kKIqu2ipN6 Best, Yuriy Deutsche Telekom ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] local and gate pep8 check comparsion
I got following error in patch https://review.openstack.org/#/c/137009/ from Jenkins 2015-01-06 12:24:20.445 | ./nova/compute/manager.py:5325:13: N331 Use LOG.warning due to compatibility with py3 2015-01-06 12:24:20.445 | ./nova/compute/manager.py:5726:13: N331 Use LOG.warning due to compatibility with py3 2015-01-06 12:24:20.916 | ERROR: InvocationError: '/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8' but I didn't get it either by ./run_test.sh -8 or tox -e pep8 in my local test env, I am pretty sure I have the latest nova code so I think I should get same result ? Thanks a lot Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pip 6.0.6 breaking py2* jobs - bug 1407736
On 1/6/2015 7:27 AM, Ihar Hrachyshka wrote: On 01/06/2015 03:09 AM, Matt Riedemann wrote: On 1/5/2015 2:16 PM, Doug Hellmann wrote: On Jan 5, 2015, at 12:22 PM, Doug Hellmann d...@doughellmann.com wrote: On Jan 5, 2015, at 12:00 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: There is a deprecation warning in pip 6.0.6 which is making the py26 (on stable branches) and py27 jobs hit subunit log sizes of over 50 MB which makes the job fail. A logstash query shows this started happening around 1/3 which is when pip 6.0.6 was released. In Nova alone there are nearly 18 million hits of the deprecation warning. Should we temporarily block so that pip 6.0.6? https://bugs.launchpad.net/nova/+bug/1407736 I think this is actually a change in pkg_resources (in the setuptools dist) [1], being triggered by stevedore using require=False to avoid checking dependencies when plugins are loaded. Doug [1] https://bitbucket.org/pypa/setuptools/commits/b1c7a311fb8e167d026126f557f849450b859502 After some discussion with Jason Coombs and dstufft, a version of setuptools with a split API to replace the deprecated option was released. I have a patch up to teach stevedore about the new methods[1]. Doug [1] https://review.openstack.org/#/c/145042/1 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The stevedore patch was merged. Do we need a release of stevedore and a global-requirements update to then get the deprecation warnings fixed in nova (on master and stable/juno)? I guess so. Also, Icehouse is affected too. I've checked Nova requirements.txt for Icehouse, and we don't cap steverore version, so a new release will be automatically propagated to all new jobs. /Ihar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I've closed the nova bug as a duplicate of the stevedore bug since the latest release of stevedore fixed the problem for my nova change on stable/juno, thanks Doug! -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][all] nova not work with eventlet 0.16.0
Le 06/01/2015 19:25, Sylvain Bauza a écrit : Maybe we should ask for cap eventlet to 0.15.2 in global-requirements ? My bad, there is already a change https://review.openstack.org/#/c/145023/ -S Adding the [all] tag as I think it's cross-project. -Sylvain Le 06/01/2015 18:01, Daniel P. Berrange a écrit : On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote: On 01/06/2015 05:33 PM, Daniel P. Berrange wrote: On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote: Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is still in the libvirt host module, but this isn't blowing up in the Jenkins runs, so what's different? There isn't a version cap on eventlet in global-requirements either. When I pip install it in my dev env it still pulls in 0.15.2. Likewise looking at a jenkins log from today it pulls in 0.15.2 http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log But the pypi page refers to 0.16.0 https://pypi.python.org/pypi/eventlet/ ?!?!? Maybe some external dependency pulls in older version? Ah, it seems my devpi/wheel caching setup was not seeing the new version. When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate has a similar cache refresh issue Regards, Daniel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting
Steven, Thank you for continuing to pursue this. Adding this functionality and having it consistent will be a good thing. The plan for Cinder looks good to me and is consistent with Mike and Duncan's input. I look forward to seeing patches for Cinder. Jay On 01/06/2015 10:03 AM, Steven Kaufer wrote: This is a follow up thread to [1] In order to have consistency across clients, I am proposing that the client side sorting has the following syntax: --sort key[:direction] Where the --sort parameter is comma-separated and is used to specify one or more sort keys and directions. The direction defaults to 'desc' for each sort key and the user can supply 'asc' to override. For example: nova list --sort display_name nova list --sort display_name,vm_state nova list --sort display_name:asc,vm_state:asc If approved, then the following changes are needed for glance and cinder (note that nova already uses this syntax): Cinder: Deprecate --sort_key and --sort_dir and add support for --sort Glance: Modify [2] to this new syntax I have not verified how all other projects handle sorting, there may be other projects that would also need to be changed. Thoughts? Objections? Also, if there is a more formal way to propose/review this standard please let me know. [1] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html [2] https://review.openstack.org/#/c/120777/ Thanks, Steven Kaufer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Octavia] Questions about the Octavia project
Hi, I’m looking into the Octavia project in relation to something my team are working on inside HP and I have a bunch of questions. I realise it is early days for the project and some of these could be too low level at this time. Some of these questions come from the fact that I could not get the documentation to compile and the docs site for Octavia is down. The v0.5-component-design.dot file crashes Graphviz 2.38 in every OS I tried and unfortunately all my dev machines have that version or 2.36 which is too low to render it correctly. It also requires at least 5 extra dependencies (Sphinx modules) to build the docs but doesn’t try to install them. I’ll guess I’ll start from the most obvious question: 1. Octavia looks a lot like Libra but with integration into Neutron and Barbican (both were planned for Libra) as well as few other changes. So the most obvious question is: why not just develop Libra for integration with Neutron? Amphorae stuff: 2. I see a lot of building blocks for the controller and Amphorae but not a lot about communication. What protocol / method is to be used to communicate to the Amphorae instances? 3. How are Amphorae instances to be spun up on-demand? I see a reference to Heat but not sure if that is why it is there 4. There is mention of Docker in some of the deploy scripts. Is this for multi-tenancy or just separation of the Amphorae processes? 5. I take it Amphorae is designed to be single-AZ for now? Load Balancing: 6. It seems like you are going to have SSL termination support and are going to use HAProxy, which means that you will have unencrypted data between the LB and web servers. How do you plan to work around this problem? Security: 7. Someone in the specification there is talk of a 1 minute cache of security certificates. How are you going to ensure that the cache will actually erase that cache after the 1 minute? Also why cache them at all? It seems to me to be a potential security risk API: 8. More a comment than a question. There is talk of using Pecan+WSME. Libra had a 5K patch on top of WSME just to make it behave correctly with Pecan and correct JSON specifications in certain situations, judging by the planned API you will also hit those same situations. I admit I’ve not looked at WSME for a year and there was an effort to strip it out of Libra completely at one point. So that one is mainly my 2c :) Many thanks for your time. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo] Progress of the port to Python 3
Hi, I'm still working on porting OpenStack to Python 3. I'm fixing Python 3 issues in eventlet and I'm trying to replace eventlet with trollius in OpenStack. Two different and complementary ways to port OpenStack to Python 3. I fixed some eventlet issues related to Python 3 and monkey-patching. My changes are part of eventlet 0.16 which was released the 2014-12-30. I tried this version with Oslo Messaging: with another fix in eventlet (threading.Condition) and a change in the zmq driver, only 3 tests are now failing (which is a great success for me). See my Oslo Messaging change for more information: https://review.openstack.org/#/c/145241/ It looks like eventlet 0.16 works much better with Python 3 and monkey-patching. You should try it on your own project! Tell me if you need help to fix issues. -- About asyncio, I renamed my aiogreen project to aioeventlet (to make it more explicit that it is specific to eventlet). With the release 0.4, the API is now considered as stable. http://aioeventlet.readthedocs.org/ Mehdi Abaakouk voted +2 on my Oslo Messaging patches to support trollius coroutines using aioeventlet project, but it looks that he's alone to review Oslo Messaging patches :-/ Anyway to approve my changes? * Add an optional executor callback to dispatcher https://review.openstack.org/136652 * Add a new aioeventlet executor https://review.openstack.org/136653 By the way, my review to add aioeventlet dependency also waits for a review: * Add aioeventlet dependency https://review.openstack.org/138750 Victor Stinner ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [api] [sdk] Proposal to achieve consistency in client side sorting
This is a follow up thread to [1] In order to have consistency across clients, I am proposing that the client side sorting has the following syntax: --sort key[:direction] Where the --sort parameter is comma-separated and is used to specify one or more sort keys and directions. The direction defaults to 'desc' for each sort key and the user can supply 'asc' to override. For example: nova list --sort display_name nova list --sort display_name,vm_state nova list --sort display_name:asc,vm_state:asc If approved, then the following changes are needed for glance and cinder (note that nova already uses this syntax): Cinder: Deprecate --sort_key and --sort_dir and add support for --sort Glance: Modify [2] to this new syntax I have not verified how all other projects handle sorting, there may be other projects that would also need to be changed. Thoughts? Objections? Also, if there is a more formal way to propose/review this standard please let me know. [1] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg42854.html [2] https://review.openstack.org/#/c/120777/ Thanks, Steven Kaufer___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] local and gate pep8 check comparsion
On 1/6/2015 10:21 AM, Chen CH Ji wrote: I got following error in patch https://review.openstack.org/#/c/137009/ from Jenkins _2015-01-06 12:24:20.445_ http://logs.openstack.org/09/137009/2/check/gate-nova-pep8/b868ad8/console.html#_2015-01-06_12_24_20_445 | ./nova/compute/manager.py:5325:13: N331 Use LOG.warning due to compatibility with py3 _2015-01-06 12:24:20.445_ http://logs.openstack.org/09/137009/2/check/gate-nova-pep8/b868ad8/console.html#_2015-01-06_12_24_20_445 | ./nova/compute/manager.py:5726:13: N331 Use LOG.warning due to compatibility with py3 _2015-01-06 12:24:20.916_ http://logs.openstack.org/09/137009/2/check/gate-nova-pep8/b868ad8/console.html#_2015-01-06_12_24_20_916 | ERROR: InvocationError: '/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/bin/flake8' but I didn't get it either by ./run_test.sh -8 or tox -e pep8 in my local test env, I am pretty sure I have the latest nova code so I think I should get same result ? Thanks a lot Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Stale venv? Try tox -r -e pep8. -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
On 01/06/2015 05:33 PM, Daniel P. Berrange wrote: On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote: Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is still in the libvirt host module, but this isn't blowing up in the Jenkins runs, so what's different? There isn't a version cap on eventlet in global-requirements either. When I pip install it in my dev env it still pulls in 0.15.2. Likewise looking at a jenkins log from today it pulls in 0.15.2 http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log But the pypi page refers to 0.16.0 https://pypi.python.org/pypi/eventlet/ ?!?!? Regards, Daniel Maybe some external dependency pulls in older version? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] IRC logging
On Tue, Jan 6, 2015 at 2:49 AM, Flavio Percoco fla...@redhat.com wrote: Fully agree... I don't see how enable logging should be a limitation for freedom of thought. We've used it in Zaqar since day 0 and it's bee of great help for all of us. The logging does not remove the need of meetings where decisions and more relevant/important topics are discussed. Wanted to second this as well. I'm strongly in favor of logging - looking through backlogs of chats on other channels has been very helpful to me in the past, and it sure to help others in the future. I don't think there is danger of anyone pointing to a logged IRC conversation in this context as some statement of record. -Christopher ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote: Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is still in the libvirt host module, but this isn't blowing up in the Jenkins runs, so what's different? There isn't a version cap on eventlet in global-requirements either. When I pip install it in my dev env it still pulls in 0.15.2. Likewise looking at a jenkins log from today it pulls in 0.15.2 http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log But the pypi page refers to 0.16.0 https://pypi.python.org/pypi/eventlet/ ?!?!? 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-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0
On Tue, Jan 06, 2015 at 05:36:38PM +0100, Ihar Hrachyshka wrote: On 01/06/2015 05:33 PM, Daniel P. Berrange wrote: On Tue, Jan 06, 2015 at 10:21:10AM -0600, Matt Riedemann wrote: Odd...eventlet 0.16.0 was released on 12/30 and the eventlet.util import is still in the libvirt host module, but this isn't blowing up in the Jenkins runs, so what's different? There isn't a version cap on eventlet in global-requirements either. When I pip install it in my dev env it still pulls in 0.15.2. Likewise looking at a jenkins log from today it pulls in 0.15.2 http://logs.openstack.org/89/140089/3/check/gate-nova-python27/55b24ee/tox/py27-1.log But the pypi page refers to 0.16.0 https://pypi.python.org/pypi/eventlet/ ?!?!? Maybe some external dependency pulls in older version? Ah, it seems my devpi/wheel caching setup was not seeing the new version. When I forced a refresh in that, it pulled down 0.16.0 Wonder if the gate has a similar cache refresh issue 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-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
Radomir, The current version of Angular were using in Horizon still does not have cookie and mock packages: https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data We still need to do it the long way: 1. Update the Angular version in global-requirements 2. Wait till it gets merge and propagate to horizon requirements 3. Remove references loading of mock and cookie packages in horizon and horizon requirement 4. Remove mock and cookie from global-requirements. -Lin On Tue, Jan 6, 2015 at 1:00 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 06/01/15 01:39, Tripp, Travis S wrote: What Radomir proposes looks like it would greatly ease the process I am still going through to get the latest angular available to Horizon for current development. At the time of writing this, I’m still trying to get the updated library through. I hit a rather difficult workflow: 1. Packaged the latest into Xstatic-Angular-1.3.7 2. Submitted patch which deprecated the separate older xstatic-angular-cookies and xstatic-angular-mock packages 3. Reviewed and approved (after correcting an initial mis-repackaging) 4. Radomir released to Pypi This was pretty easy and not too hard. Not too much to complain about. However, now, to get Horizon to use it, I have to get that into global requirements. Since I’m deprecating old packages I got stuck in a sort of ugly dependency path. I couldn’t remove the cookies and mock libraries from the global requirements patch that added the new 1.3.7 package because of horizon still referencing the deprecated packages. And, when I did it anyway, the integration tests failed due to horizon being dependent on something not in global requirements. So, now, as far as I can tell we have to jump through the following hoops: 1. Global requirements patch to add angular 1.3.7 * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and cookies packages * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 3. Global requirements patch to remove deprecated mock and cookies * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun Don’t get me wrong, I really do think the gate is brilliant and am all for a review / approval process, but this does seem excessive for a UI library that should only be used by Horizon. Is there some other reason that this should have to go through global requirements? You can do it much easier, since the current version of Angular already packages what is in the deprecated modules. So just: 1. Patch Horizon to remove the xstatic dependencies to the mock and cookies packages. 2. Patch global-requirements to remove them, and add newer Angular. 3. Patch Horizon to use the newer Angular. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
Thanks, Radomir. I originally started a patch on Horizon and was going to do that, but was guided to update global requirements first. I¹ll go ahead and redo that patch on Horizon. -Travis On 1/6/15, 2:00 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 06/01/15 01:39, Tripp, Travis S wrote: What Radomir proposes looks like it would greatly ease the process I am still going through to get the latest angular available to Horizon for current development. At the time of writing this, I¹m still trying to get the updated library through. I hit a rather difficult workflow: 1. Packaged the latest into Xstatic-Angular-1.3.7 2. Submitted patch which deprecated the separate older xstatic-angular-cookies and xstatic-angular-mock packages 3. Reviewed and approved (after correcting an initial mis-repackaging) 4. Radomir released to Pypi This was pretty easy and not too hard. Not too much to complain about. However, now, to get Horizon to use it, I have to get that into global requirements. Since I¹m deprecating old packages I got stuck in a sort of ugly dependency path. I couldn¹t remove the cookies and mock libraries from the global requirements patch that added the new 1.3.7 package because of horizon still referencing the deprecated packages. And, when I did it anyway, the integration tests failed due to horizon being dependent on something not in global requirements. So, now, as far as I can tell we have to jump through the following hoops: 1. Global requirements patch to add angular 1.3.7 * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and cookies packages * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun 3. Global requirements patch to remove deprecated mock and cookies * Verify check / recheck fun * Reviewed and approved * Gate check / recheck fun Don¹t get me wrong, I really do think the gate is brilliant and am all for a review / approval process, but this does seem excessive for a UI library that should only be used by Horizon. Is there some other reason that this should have to go through global requirements? You can do it much easier, since the current version of Angular already packages what is in the deprecated modules. So just: 1. Patch Horizon to remove the xstatic dependencies to the mock and cookies packages. 2. Patch global-requirements to remove them, and add newer Angular. 3. Patch Horizon to use the newer Angular. -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.i18n 1.2.0 release
This release is causing problems with some of Heat’s WSGI code that accesses private classes in oslo.i18n. We’re working on a fix: https://review.openstack.org/#/c/145257 On Jan 6, 2015, at 10:15 AM, Doug Hellmann d...@doughellmann.com wrote: The Oslo team is pleased to announce the release of oslo.i18n 1.2.0: oslo.i18n library The primary reason for this release is to move the code out of the oslo namespace package as part of https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages For more details, please see the git log history below and http://launchpad.net/oslo.i18n/+milestone/1.2.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.i18n Changes in openstack/oslo.i18n 1.1.0..1.2.0 582c718 Correct the translation domain for loading messages ba05e9a Move out of the oslo namespace package c86629e Workflow documentation is now in infra-manual 53635ea Force code sample to be treated as python diffstat (except docs and test files): CONTRIBUTING.rst| 7 +- oslo/i18n/__init__.py | 23 +- oslo/i18n/_factory.py | 110 -- oslo/i18n/_gettextutils.py | 90 - oslo/i18n/_i18n.py | 25 -- oslo/i18n/_lazy.py | 38 -- oslo/i18n/_locale.py| 25 -- oslo/i18n/_message.py | 167 - oslo/i18n/_translate.py | 73 oslo/i18n/fixture.py| 54 +-- oslo/i18n/log.py| 86 + oslo_i18n/__init__.py | 16 + oslo_i18n/_factory.py | 110 ++ oslo_i18n/_gettextutils.py | 90 + oslo_i18n/_i18n.py | 25 ++ oslo_i18n/_lazy.py | 38 ++ oslo_i18n/_locale.py| 25 ++ oslo_i18n/_message.py | 167 + oslo_i18n/_translate.py | 73 oslo_i18n/fixture.py| 65 oslo_i18n/log.py| 97 ++ setup.cfg | 2 +- tests/fakes.py | 59 tests/test_factory.py | 91 - tests/test_fixture.py | 2 +- tests/test_gettextutils.py | 128 --- tests/test_handler.py | 4 +- tests/test_lazy.py | 40 --- tests/test_locale_dir_variable.py | 32 -- tests/test_logging.py | 42 --- tests/test_message.py | 518 tests/test_public_api.py| 2 +- tests/test_translate.py | 44 --- tests/test_warning.py | 61 tests/utils.py | 42 --- tox.ini | 2 +- 52 files changed, 2004 insertions(+), 1699 deletions(-) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Progress of the port to Python 3
Hi Victor. Thanks for your effort. Did you read the ML thread [nova]nova not work with eventlet 0.16.0 ? It looks important. Jordan On Tue, Jan 6, 2015 at 5:51 PM, victor stinner victor.stin...@enovance.com wrote: Hi, I'm still working on porting OpenStack to Python 3. I'm fixing Python 3 issues in eventlet and I'm trying to replace eventlet with trollius in OpenStack. Two different and complementary ways to port OpenStack to Python 3. I fixed some eventlet issues related to Python 3 and monkey-patching. My changes are part of eventlet 0.16 which was released the 2014-12-30. I tried this version with Oslo Messaging: with another fix in eventlet (threading.Condition) and a change in the zmq driver, only 3 tests are now failing (which is a great success for me). See my Oslo Messaging change for more information: https://review.openstack.org/#/c/145241/ It looks like eventlet 0.16 works much better with Python 3 and monkey-patching. You should try it on your own project! Tell me if you need help to fix issues. -- About asyncio, I renamed my aiogreen project to aioeventlet (to make it more explicit that it is specific to eventlet). With the release 0.4, the API is now considered as stable. http://aioeventlet.readthedocs.org/ Mehdi Abaakouk voted +2 on my Oslo Messaging patches to support trollius coroutines using aioeventlet project, but it looks that he's alone to review Oslo Messaging patches :-/ Anyway to approve my changes? * Add an optional executor callback to dispatcher https://review.openstack.org/136652 * Add a new aioeventlet executor https://review.openstack.org/136653 By the way, my review to add aioeventlet dependency also waits for a review: * Add aioeventlet dependency https://review.openstack.org/138750 Victor Stinner ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
