[openstack-dev] Messaging queue is not cleaned when cinder volume-type is destroyed
Hi, I was intrigued when a cinder volume-type is destroyed completely its queue still exists until the messaging service is restarted. In my case its rabbitmq, not sure if it is valid behavior. Kindly let me know. -- Thanks, IK ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Help in writing new neutron plugin
I am considering to contribute to Neutron but was struggling to find good documents, thanks for sharing links. Thanks, Shiva On Fri, Jun 20, 2014 at 3:24 AM, Anita Kuno ante...@anteaya.info wrote: On 06/19/2014 05:47 PM, Mohammad Banikazemi wrote: Have you looked at https://wiki.openstack.org/wiki/NeutronDevelopment In particular, this section may be useful to you: Developing a Neutron Plugin You may also want to look at the following presentation/talk and look for more such presentations from OpenStack Summits: http://www.slideshare.net/mestery/modular-layer-2-in-openstack-neutron https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/openstack-neutron-modular-layer-2-plugin-deep-dive Hope this helps, Mohammad From: shiva m anjane...@gmail.com To: openstack-dev@lists.openstack.org, Date: 06/19/2014 07:22 AM Subject: [openstack-dev] Help in writing new neutron plugin HI, I am looking at documents to understand how to write a new neutron plugin. I working with devstack with ryu setup from last 4 months. I am trying to write some test plugin to get hands-on. Can any one please help where to start looking neutron code, where to embed new code. Also I am looking for beginner kind of documentation to write ML2 type driver and mechanism drivers, Thanks Shiva___ 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 Have you considered contributing to Neutron? Perhaps working on addressing some bugs, participating in meetings and in channel, writing some tests? Helping address some of the current issues the community is facing would be a great way to learn about the Neutron code. I would recommend considering this direction. Thanks, Anita. ___ 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] [hacking] rules for removal
On 06/20/2014 09:26 PM, Clint Byrum wrote: Excerpts from Sean Dague's message of 2014-06-20 11:07:39 -0700: After seeing a bunch of code changes to enforce new hacking rules, I'd like to propose dropping some of the rules we have. The overall patch series is here - https://review.openstack.org/#/q/status:open+project:openstack-dev/hacking+branch:master+topic:be_less_silly,n,z H402 - 1 line doc strings should end in punctuation. The real statement is this should be a summary sentence. A sentence is not just a set of words that end in a period. Squirel fast bob. It's something deeper. This rule thus isn't really semantically useful, especially when you are talking about at 69 character maximum (79 - 4 space indent - 6 quote characters). Yes. I despise this one. H803 - First line of a commit message must *not* end in a period. This was mostly a response to an unreasonable core reviewer that was -1ing people for not having periods. I think any core reviewer that -1s for this either way should be thrown off the island, or at least made fun of, a lot. Again, the clarity of a commit message is not made or lost by the lack or existence of a period at the end of the first line. Perhaps we can make a bot that writes disparaging remarks on any -1's that mention period in the line after the short commit message. :) H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty, our tree. This biggest issue here is it's built in a world where there was only 1 viable python version, 2.7. Python's stdlib is actually pretty dynamic and grows over time. As we embrace more python 3, and as distros start to make python3 be front and center, what does this even mean? The current enforcement can't pass on both python2 and python3 at the same time in many cases because of that. I think we should find a way to make this work. Like it or not, this will garner -1's by people for stylistic reasons and I'd rather it be the bots than the humans do it. The algorithm is something like this pseudo python: for block in import_blocks: if is_this_set_in_a_known_lib_collection(block): continue if is_this_set_entirely_local(block): continue if is_this_set_entirely_installed_libs(block): continue raise AnError(block) And just make the python2 and python3 stdlibs both be a match. Basically I'm saying, let's just be more forgiving but keep the check so we can avoid most of the -1 please group libs and stdlibs separately patches. You can avoid that by yelling at reviewers if that's the *only* feedback they are giving. Pedantic reviewers that are reviewing for this kind of thing only should be scorned. I realistically like the idea markmc came up with - https://twitter.com/markmc_/status/480073387600269312 I no longer buy the theory that something like this is saving time. What it's actually doing is training a new generation of reviewers that the right thing to do it review for nits. That's not actually what we want, we want people reviewing for how this could go wrong. It's really instructive to realize that we've definitely gone beyond shared culture with what's in hacking. Look at how much of it is turned off in projects. It's pretty high. If this project is going to remain useful at all it really needs to prune back to what's actually shared culture. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hacking] rules for removal
On Sat, Jun 21, 2014 at 6:08 AM, Sean Dague s...@dague.net wrote: https://twitter.com/markmc_/status/480073387600269312 Don't think it needs to be said, but I'm TOTALLY on board with all of the items Sean pointed out. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hacking] rules for removal
Excerpts from Sean Dague's message of 2014-06-21 05:08:01 -0700: On 06/20/2014 09:26 PM, Clint Byrum wrote: Excerpts from Sean Dague's message of 2014-06-20 11:07:39 -0700: H803 - First line of a commit message must *not* end in a period. This was mostly a response to an unreasonable core reviewer that was -1ing people for not having periods. I think any core reviewer that -1s for this either way should be thrown off the island, or at least made fun of, a lot. Again, the clarity of a commit message is not made or lost by the lack or existence of a period at the end of the first line. Perhaps we can make a bot that writes disparaging remarks on any -1's that mention period in the line after the short commit message. :) [For the reader: read the comments below, and then come back to this] Note that I'm not at all unaware of the irony I created by making the statement above and then the statements below. I feel like I'm a Fox News reporter being called out on the daily show actually. ;) H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty, our tree. This biggest issue here is it's built in a world where there was only 1 viable python version, 2.7. Python's stdlib is actually pretty dynamic and grows over time. As we embrace more python 3, and as distros start to make python3 be front and center, what does this even mean? The current enforcement can't pass on both python2 and python3 at the same time in many cases because of that. I think we should find a way to make this work. Like it or not, this will garner -1's by people for stylistic reasons and I'd rather it be the bots than the humans do it. The algorithm is something like this pseudo python: for block in import_blocks: if is_this_set_in_a_known_lib_collection(block): continue if is_this_set_entirely_local(block): continue if is_this_set_entirely_installed_libs(block): continue raise AnError(block) And just make the python2 and python3 stdlibs both be a match. Basically I'm saying, let's just be more forgiving but keep the check so we can avoid most of the -1 please group libs and stdlibs separately patches. You can avoid that by yelling at reviewers if that's the *only* feedback they are giving. I totally agree we can do that. Pedantic reviewers that are reviewing for this kind of thing only should be scorned. I realistically like the idea markmc came up with - https://twitter.com/markmc_/status/480073387600269312 I also agree it is really fun to think about shaming those annoying actions. It is also not fun _at all_ to be publicly shamed. In fact I'd say it is at least an order of magnitude less fun. There is an old saying, praise in public, punish in private. It is one reason the -1 comments I give always include praise for whatever is right for new contributors. Not everyone is a grizzled veteran. It is far more interesting to me to solve the grouping problem in a way that works for us long term (python 2 and 3) than it is to develop a culture that builds any of its core activities on negative emotional feedback. That's not to say we can't say hey you're doing it wrong. I mean to say that direct feedback like that belongs in private IRC messages or email, not in public everyone can see that reviews. Give people a chance to save face. Meanwhile, the less we have to have one on one negative feedback, the easier the job of reviewers is. The last thing we want to do is have more reasons for people to NOT do reviews. I no longer buy the theory that something like this is saving time. What it's actually doing is training a new generation of reviewers that the right thing to do it review for nits. That's not actually what we want, we want people reviewing for how this could go wrong. I'm not sure how hacking is training reviewers. I feel like hacking is training developers. Reviewers don't even need to look at it until the pep8 tox job passes. It's really instructive to realize that we've definitely gone beyond shared culture with what's in hacking. Look at how much of it is turned off in projects. It's pretty high. If this project is going to remain useful at all it really needs to prune back to what's actually shared culture. I think having things turned off at the project level is o-k. The more strict a project's automated style rules, the less they have to quibble and train new reviewers on the fact that we don't do that here. However, I don't think rules being turned off is evidence that rules are unhelpful. It most likely means that those rules didn't exist when the code base was created and they turned them off because of incubation or a new set of rules arrived and they didn't have time to land the new patches. That is a per-project choice and should remain so, but I don't think that choice means that those rules wouldn't have a long term positive effect of stopping
Re: [openstack-dev] [nova] Set compute_node:hypervisor_nodename as unique and not null
As we knew, Nova db has the table “compute_nodes” for modelling the hypervisors and its using the “hypervisor_hostname” field to represent the hypervisor name. This value is having significant value in os-hypervisor extension api which is using this field to uniquely identify the hypervisor. Consider the case where a given environment is having more than one hypervisors (KVM, EXS, Xen, etc) with same hostname and os-hypervisor and thereby Horizon Hypervisor panel and nova hypervisors-servers command will fail. There is a defect ( https://bugs.launchpad.net/nova/+bug/1329261 ) already filed on VMware VC driver to address this issue to make sure that, a unique value is generated for the VC driver’s hypervisor. But its good to fix at the model level as well by making “hypervisor_hostname” field as unique always. And a bug https://bugs.launchpad.net/nova/+bug/1329299 is filed for the same. Hi Kanagaraj, Thanks for filing these bugs. For the VMware driver we can use a combination of the vCenter uuid and the id of the cluster which is managed by Nova. I have already posted some comments on your patch for this: https://review.openstack.org/#/c/99623/ I am also +1 for adding an unique constraint for the hypervisor_hostname column. Thanks, Rado ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
Horizon in icehouse is now 100% failing [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: / [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last): [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py, line 112, in get_response [Sat Jun 21 16:17:35 2014] [error] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/views/decorators/vary.py, line 36, in inner_func [Sat Jun 21 16:17:35 2014] [error] response = func(*args, **kwargs) [Sat Jun 21 16:17:35 2014] [error] File /opt/stack/old/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/views.py, line 35, in splash [Sat Jun 21 16:17:35 2014] [error] form = views.Login(request) [Sat Jun 21 16:17:35 2014] [error] AttributeError: 'module' object has no attribute 'Login' This suspiciously times with django_openstack_auth 1.1.6 being released. http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnbW9kdWxlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnTG9naW4nXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDMzNjk0MjQ4NjR9 Because this breaks smoke tests on icehouse, it means that any project with upgrade testing fails. Would be great if horizon folks code make this a top priority. Also, in future, releasing new library versions on a saturday maybe best avoided. :) -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
On Sat, Jun 21, 2014 at 10:53 AM, Sean Dague s...@dague.net wrote: Horizon in icehouse is now 100% failing [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: / [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last): [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py, line 112, in get_response [Sat Jun 21 16:17:35 2014] [error] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/views/decorators/vary.py, line 36, in inner_func [Sat Jun 21 16:17:35 2014] [error] response = func(*args, **kwargs) [Sat Jun 21 16:17:35 2014] [error] File /opt/stack/old/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/views.py, line 35, in splash [Sat Jun 21 16:17:35 2014] [error] form = views.Login(request) [Sat Jun 21 16:17:35 2014] [error] AttributeError: 'module' object has no attribute 'Login' This suspiciously times with django_openstack_auth 1.1.6 being released. http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnbW9kdWxlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnTG9naW4nXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDMzNjk0MjQ4NjR9 Because this breaks smoke tests on icehouse, it means that any project with upgrade testing fails. Would be great if horizon folks code make this a top priority. Also, in future, releasing new library versions on a saturday maybe best avoided. :) -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 Don't know if this flies or not but: https://review.openstack.org/#/c/101711/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
Since Friday I have been getting this misbehavior: enter username and password, hit login, and it shows you the login page again. Sean Dague --- [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches --- |--+--| |Fr|Sean Dague s...@dague.net | |om| | |: | | |--+--| |To|openstack-dev openstack-dev@lists.openstack.org | |--+--| |Da|Sat, Jun 21, 2014 12:54 | |te| | |: | | |--+--| |Su|[openstack-dev] horizon failing on icehouse 100%, currently blocking | |bj|all patches | |ec| | |t | | |--+--| Horizon in icehouse is now 100% failing [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: / [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last): [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py, line 112, in get_response [Sat Jun 21 16:17:35 2014] [error] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/views/decorators/vary.py, line 36, in inner_func [Sat Jun 21 16:17:35 2014] [error] response = func(*args, **kwargs) [Sat Jun 21 16:17:35 2014] [error] File /opt/stack/old/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/views.py, line 35, in splash [Sat Jun 21 16:17:35 2014] [error] form = views.Login(request) [Sat Jun 21 16:17:35 2014] [error] AttributeError: 'module' object has no attribute 'Login' This suspiciously times with django_openstack_auth 1.1.6 being released. http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnbW9kdWxlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnTG9naW4nXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDMzNjk0MjQ4NjR9 Because this breaks smoke tests on icehouse, it means that any project with upgrade testing fails. Would be great if horizon folks code make this a top priority. Also, in future, releasing new library versions on a saturday maybe best avoided. :) -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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
The issue with the login page simply refreshing was due to a change in Keystone that updated the type of Token issued by default from PKI to PKIZ (compressed PKI/ASN1). The update to the django auth module was intended to correct that specific issue with Keystone and Horizon (Juno). The bug fix (not sure if another review is to blame with the django_openstack_auth module tha t is currently happening) that addressed your specific issue is: https://bugs.launchpad.net/horizon/+bug/1331406 I have proposed a fix for Keystone that would revert the PKIZ default: https://review.openstack.org/#/c/101714/ Depending on the fixes upcoming for the django_openstack_auth module, it may make sense to temporarily revert the PKIZ provider default until we can solve the issues with the django auth module and horizon when PKIZ is enabled. If this review is not needed based on how the horizon issues are corrected, it will be abandoned. I think this is also showing some gaps in our testing, notably that the django_openstack_auth module isn't being exercised on the integration tests. I'll aim to hit up Horizon team and work with them and the QA folks to make sure we cover this gap in the future. --Morgan On Saturday, June 21, 2014, Mike Spreitzer mspre...@us.ibm.com wrote: Since Friday I have been getting this misbehavior: enter username and password, hit login, and it shows you the login page again. Sean Dague --- [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches --- From:Sean Dague s...@dague.net Toopenstack-dev openstack-dev@lists.openstack.org Date:Sat, Jun 21, 2014 12:54 Subject[openstack-dev] horizon failing on icehouse 100%, currently blocking all patches -- Horizon in icehouse is now 100% failing [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: / [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last): [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py, line 112, in get_response [Sat Jun 21 16:17:35 2014] [error] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/views/decorators/vary.py, line 36, in inner_func [Sat Jun 21 16:17:35 2014] [error] response = func(*args, **kwargs) [Sat Jun 21 16:17:35 2014] [error] File /opt/stack/old/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/views.py, line 35, in splash [Sat Jun 21 16:17:35 2014] [error] form = views.Login(request) [Sat Jun 21 16:17:35 2014] [error] AttributeError: 'module' object has no attribute 'Login' This suspiciously times with django_openstack_auth 1.1.6 being released. http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnbW9kdWxlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnTG9naW4nXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDMzNjk0MjQ4NjR9 Because this breaks smoke tests on icehouse, it means that any project with upgrade testing fails. Would be great if horizon folks code make this a top priority. Also, in future, releasing new library versions on a saturday maybe best avoided. :) -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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Periodic Security Checks
Hello! We have blueprints here: https://blueprints.launchpad.net/horizon/+spec/periodic-security-checks and here: https://blueprints.launchpad.net/nova/+spec/periodic-security-checks/ And we already have some code. Is it necessary to approve the blueprint before contributing the code? In any case, could someone review the aforementioned blueprints? Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
I released django_openstack_auth 1.1.6 on Friday to fix the login issue with PKIZ. Part of that release contained a pep8 cleanup that broke Horizon, ultimately because we were doing something stupid in Horizon. We added a fix to Horizon to correct the issue on trunk https://github.com/openstack/horizon/commit/0bd4350cb308d57b6afc69daee4a782 3055be5a9. However, to allow older versions of Horizon to work with newer django_openstack_auth versions, I currently have a patch up to restore the strange import in openstack_auth https://review.openstack.org/#/c/101715/ once that merges I will release django_openstack_auth 1.1.7 and all gates should work again. David From: Morgan Fainberg morgan.fainb...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Saturday, June 21, 2014 at 12:27 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches The issue with the login page simply refreshing was due to a change in Keystone that updated the type of Token issued by default from PKI to PKIZ (compressed PKI/ASN1). The update to the django auth module was intended to correct that specific issue with Keystone and Horizon (Juno). The bug fix (not sure if another review is to blame with the django_openstack_auth module tha t is currently happening) that addressed your specific issue is: https://bugs.launchpad.net/horizon/+bug/1331406 I have proposed a fix for Keystone that would revert the PKIZ default: https://review.openstack.org/#/c/101714/ https://review.openstack.org/#/c/101714/ Depending on the fixes upcoming for the django_openstack_auth module, it may make sense to temporarily revert the PKIZ provider default until we can solve the issues with the django auth module and horizon when PKIZ is enabled. If this review is not needed based on how the horizon issues are corrected, it will be abandoned. I think this is also showing some gaps in our testing, notably that the django_openstack_auth module isn't being exercised on the integration tests. I'll aim to hit up Horizon team and work with them and the QA folks to make sure we cover this gap in the future. --Morgan On Saturday, June 21, 2014, Mike Spreitzer mspre...@us.ibm.com wrote: Since Friday I have been getting this misbehavior: enter username and password, hit login, and it shows you the login page again. Sean Dague --- [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches --- From:Sean Dague s...@dague.netToopenstack-dev openstack-dev@lists.openstack.orgDate:Sat, Jun 21, 2014 12:54Subject[openstack-dev] horizon failing on icehouse 100%, currently blocking all patches Horizon in icehouse is now 100% failing [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: / [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last): [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py, line 112, in get_response [Sat Jun 21 16:17:35 2014] [error] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/views/decorators/vary.py, line 36, in inner_func [Sat Jun 21 16:17:35 2014] [error] response = func(*args, **kwargs) [Sat Jun 21 16:17:35 2014] [error] File /opt/stack/old/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/ views.py, line 35, in splash [Sat Jun 21 16:17:35 2014] [error] form = views.Login(request) [Sat Jun 21 16:17:35 2014] [error] AttributeError: 'module' object has no attribute 'Login' This suspiciously times with django_openstack_auth 1.1.6 being released. http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnbW9k dWxlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnTG9naW4nXCIiLCJmaWVsZHMiOltdLCJvZmZ zZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6ey J1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDMzNjk0MjQ4NjR9 Because this breaks smoke tests on icehouse, it means that any project with upgrade testing fails. Would be great if horizon folks code make this a top priority. Also, in future, releasing new library versions on a saturday maybe best avoided. :) -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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
Great. This looks like your fix will not require reverting the PKIZ change. Thanks! --Morgan On Saturday, June 21, 2014, Lyle, David david.l...@hp.com wrote: I released django_openstack_auth 1.1.6 on Friday to fix the login issue with PKIZ. Part of that release contained a pep8 cleanup that broke Horizon, ultimately because we were doing something stupid in Horizon. We added a fix to Horizon to correct the issue on trunk https://github.com/openstack/horizon/commit/0bd4350cb308d57b6afc69daee4a782 3055be5a9. However, to allow older versions of Horizon to work with newer django_openstack_auth versions, I currently have a patch up to restore the strange import in openstack_auth https://review.openstack.org/#/c/101715/ once that merges I will release django_openstack_auth 1.1.7 and all gates should work again. David From: Morgan Fainberg morgan.fainb...@gmail.com javascript:; Reply-To: OpenStack List openstack-dev@lists.openstack.org javascript:; Date: Saturday, June 21, 2014 at 12:27 PM To: OpenStack List openstack-dev@lists.openstack.org javascript:; Subject: Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches The issue with the login page simply refreshing was due to a change in Keystone that updated the type of Token issued by default from PKI to PKIZ (compressed PKI/ASN1). The update to the django auth module was intended to correct that specific issue with Keystone and Horizon (Juno). The bug fix (not sure if another review is to blame with the django_openstack_auth module tha t is currently happening) that addressed your specific issue is: https://bugs.launchpad.net/horizon/+bug/1331406 I have proposed a fix for Keystone that would revert the PKIZ default: https://review.openstack.org/#/c/101714/ https://review.openstack.org/#/c/101714/ Depending on the fixes upcoming for the django_openstack_auth module, it may make sense to temporarily revert the PKIZ provider default until we can solve the issues with the django auth module and horizon when PKIZ is enabled. If this review is not needed based on how the horizon issues are corrected, it will be abandoned. I think this is also showing some gaps in our testing, notably that the django_openstack_auth module isn't being exercised on the integration tests. I'll aim to hit up Horizon team and work with them and the QA folks to make sure we cover this gap in the future. --Morgan On Saturday, June 21, 2014, Mike Spreitzer mspre...@us.ibm.com javascript:; wrote: Since Friday I have been getting this misbehavior: enter username and password, hit login, and it shows you the login page again. Sean Dague --- [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches --- From:Sean Dague s...@dague.net javascript:;Toopenstack-dev openstack-dev@lists.openstack.org javascript:;Date:Sat, Jun 21, 2014 12:54Subject[openstack-dev] horizon failing on icehouse 100%, currently blocking all patches Horizon in icehouse is now 100% failing [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: / [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last): [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py, line 112, in get_response [Sat Jun 21 16:17:35 2014] [error] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/views/decorators/vary.py, line 36, in inner_func [Sat Jun 21 16:17:35 2014] [error] response = func(*args, **kwargs) [Sat Jun 21 16:17:35 2014] [error] File /opt/stack/old/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/ views.py, line 35, in splash [Sat Jun 21 16:17:35 2014] [error] form = views.Login(request) [Sat Jun 21 16:17:35 2014] [error] AttributeError: 'module' object has no attribute 'Login' This suspiciously times with django_openstack_auth 1.1.6 being released. http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnbW9k dWxlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnTG9naW4nXCIiLCJmaWVsZHMiOltdLCJvZmZ zZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6ey J1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDMzNjk0MjQ4NjR9 Because this breaks smoke tests on icehouse, it means that any project with upgrade testing fails. Would be great if horizon folks code make this a top priority. Also, in future, releasing new library versions on a saturday maybe best avoided. :) -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:;
Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
On Sat, Jun 21, 2014 at 2:27 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote: The issue with the login page simply refreshing was due to a change in Keystone that updated the type of Token issued by default from PKI to PKIZ (compressed PKI/ASN1). The update to the django auth module was intended to correct that specific issue with Keystone and Horizon (Juno). The bug fix (not sure if another review is to blame with the django_openstack_auth module tha t is currently happening) that addressed your specific issue is: https://bugs.launchpad.net/horizon/+bug/1331406 I have proposed a fix for Keystone that would revert the PKIZ default: https://review.openstack.org/#/c/101714/ Depending on the fixes upcoming for the django_openstack_auth module, it may make sense to temporarily revert the PKIZ provider default until we can solve the issues with the django auth module and horizon when PKIZ is enabled. If this review is not needed based on how the horizon issues are corrected, it will be abandoned. I think this is also showing some gaps in our testing, notably that the django_openstack_auth module isn't being exercised on the integration tests. I'll aim to hit up Horizon team and work with them and the QA folks to make sure we cover this gap in the future. We may also want to consider adding it to the list of libraries we have in the cross-project unit test matrix (https://review.openstack.org/#/c/95885/ ). Doug --Morgan On Saturday, June 21, 2014, Mike Spreitzer mspre...@us.ibm.com wrote: Since Friday I have been getting this misbehavior: enter username and password, hit login, and it shows you the login page again. Sean Dague --- [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches --- From:Sean Dague s...@dague.net Toopenstack-dev openstack-dev@lists.openstack.org Date:Sat, Jun 21, 2014 12:54 Subject[openstack-dev] horizon failing on icehouse 100%, currently blocking all patches -- Horizon in icehouse is now 100% failing [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: / [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last): [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py, line 112, in get_response [Sat Jun 21 16:17:35 2014] [error] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/views/decorators/vary.py, line 36, in inner_func [Sat Jun 21 16:17:35 2014] [error] response = func(*args, **kwargs) [Sat Jun 21 16:17:35 2014] [error] File /opt/stack/old/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/views.py, line 35, in splash [Sat Jun 21 16:17:35 2014] [error] form = views.Login(request) [Sat Jun 21 16:17:35 2014] [error] AttributeError: 'module' object has no attribute 'Login' This suspiciously times with django_openstack_auth 1.1.6 being released. http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnbW9kdWxlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnTG9naW4nXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDMzNjk0MjQ4NjR9 Because this breaks smoke tests on icehouse, it means that any project with upgrade testing fails. Would be great if horizon folks code make this a top priority. Also, in future, releasing new library versions on a saturday maybe best avoided. :) -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 ___ 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] [Neutron][L3] BGP Dynamic Routing Proposal
Hi Thomas, This is interesting. I have some of the basic question about deployment model of using this BaGPipe BGP in virtual cloud network. 1. We want MPLS to start right from compute node as part Tennant traffic ? 2. We want L3 VRF separation right on Compute nodes (or NN Node) ? Tenant = VRF ? Tenant span can be across multiple CN nodes, then have BGP to Full mesh with in CN ? 3. How to have E-VPN connectivity mapping at NN/CN nodes ? Is there an L2 VPN psuedowire thinking from CN nodes itself ? 4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ? Help me understand the deployment model for this . -Original Message- From: Thomas Morin [mailto:thomas.mo...@orange.com] Sent: Thursday, June 19, 2014 9:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal Hi everyone, Sorry, I couldn't make it in time for the IRC meeting. Just saw in the logs: 15:19:12 yamamoto are orange folks here? they might want to introduce their bgp speaker. The best intro to BaGPipe BGP is the README on github: https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md Beyond just speaking the BGP protocol on the wire, BaGPipe is a an implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding part. It can be run as a service exposing a REST API, or a library inside an agent; it handles the lifecylcle of VRFs and port attached/detached from them and appropriately circulates event to/from BGP peers based on VRF import/export rules and RTC publish/subscribe semantics. It's complete enough to let us build neutron virtual networks with IP VPNs, and interconnect them with external VPNs; the parts for Opentsack integration are not on this github, I'm just mentioning this for the sake of illustrating the relative maturity. Although it does not address plain IP, this would I believe by a really easy addition to make. I'll do my best to attend next week IRC meeting, but until this, feel free to ask. We can also do a QA session on IRC if that sounds convenient. Best, -Thomas 2014-06-13, YAMAMOTO Takashi: an update after today's l3 meeting: here's a new version of ryu bgp api patch. http://sourceforge.net/p/ryu/mailman/message/32453021/ it has been merged to the ryu master. https://github.com/osrg/ryu.git here's formatted documentation: http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html YAMAMOTO Takashi YAMAMOTO Takashi I have seen the Ryu team is involved and responsive to the community. That goes a long way to support it as the reference implementation for BPG speaking in Neutron. Thank you for your support. I'll look forward to the API and documentation refinement Let's be sure to document any work that needs to be done so that it will support the features we need. We can use the comparison page for now [1] to gather that information (or links). If Ryu is lacking in any area, it will be good to understand the timeline on which the features can be delivered and stable before we make a formal decision on the reference implementation. Carl [1] https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison On Thu, Jun 5, 2014 at 10:36 AM, Jaume Devesa devv...@gmail.com wrote: After watch the documentation and the code of exabgp and Ryu, I find the Ryu speaker much more easy to integrate and pythonic than exabgp. I will use it as well as reference implementation in the Dynamic Routing bp. Regards, On 5 June 2014 18:23, Nachi Ueno na...@ntti3.com wrote: Yamamoto Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. Yong Ya, we have already decided to have the driver architecture. IMO, this discussion is for reference impl. 2014-06-05 0:24 GMT-07:00 Yongsheng Gong gong...@unitedstack.com: I think maybe we can device a kind of framework so that we can plugin different BGP speakers. On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi yamam...@valinux.co.jp wrote: hi, ExaBgp was our first choice because we thought that run something in library mode would be much more easy to deal with (especially the exceptions and corner cases) and the code would be much cleaner. But seems that Ryu BGP also can fit in this requirement. And having the help from a Ryu developer like you turns it into a promising candidate! I'll start working now in a proof of concept to run the agent with these implementations and see if we need more requirements to compare between the speakers. we (ryu team) love to hear any suggestions and/or requests. we are currently working on our bgp api refinement and documentation. hopefully they will be available early next week. for both of bgp blueprints, it would be possible, and might be desirable, to create reference
Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
I'm afraid we have to revert the PKIZ change since devstack is not support django_openstack_auth now and all patches blocked including David's fix. 发自我的 iPhone 在 Jun 22, 2014，5:39，Morgan Fainberg morgan.fainb...@gmail.com 写道： Great. This looks like your fix will not require reverting the PKIZ change. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
I don't think we can revert the change without David's fix. The blocked up gate isn't because of PKIZ in this case (it isn't tested from the horizon part) the blocked up gate is because of the broken django_openstack_auth module. Could we just tag a new release based upon the commit of the old release? Then once everything is fixed we tag the real fixed release of django_openstack_auth. It is a little crummy, but would solve it. Alternatively, we temporarily pin the version of django_openstack_auth to the lower version. --Morgan On Saturday, June 21, 2014, Zhenguo Niu niu.zgli...@gmail.com wrote: I'm afraid we have to revert the PKIZ change since devstack is not support django_openstack_auth now and all patches blocked including David's fix. 发自我的 iPhone 在 Jun 22, 2014，5:39，Morgan Fainberg morgan.fainb...@gmail.com javascript:; 写道： Great. This looks like your fix will not require reverting the PKIZ change. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; 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 failing on icehouse 100%, currently blocking all patches
Agreed, we can temporarily pin the version of django_openstack_auth to the lower version. 发自我的 iPhone 在 Jun 22, 2014，11:09，Morgan Fainberg morgan.fainb...@gmail.com 写道： I don't think we can revert the change without David's fix. The blocked up gate isn't because of PKIZ in this case (it isn't tested from the horizon part) the blocked up gate is because of the broken django_openstack_auth module. Could we just tag a new release based upon the commit of the old release? Then once everything is fixed we tag the real fixed release of django_openstack_auth. It is a little crummy, but would solve it. Alternatively, we temporarily pin the version of django_openstack_auth to the lower version. --Morgan On Saturday, June 21, 2014, Zhenguo Niu niu.zgli...@gmail.com wrote: I'm afraid we have to revert the PKIZ change since devstack is not support django_openstack_auth now and all patches blocked including David's fix. 发自我的 iPhone 在 Jun 22, 2014，5:39，Morgan Fainberg morgan.fainb...@gmail.com 写道： Great. This looks like your fix will not require reverting the PKIZ change. ___ 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] [Cinder][Driver] Delete snapshot
This is what I thought of as well. In the rbd driver, if a request to delete a volume comes in, where the volume object on the backend has other objects that depend on it, it simply renames it: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/rbd.py#L657 There is also code to clean up those renamed objects. The point is, Cinder has an API which should be consistent no matter what storage is being used. The driver must do whatever necessary to implement the API rather than allowing quirks of the specific storage to show through to the user. Thanks, Avishay On Thu, Jun 19, 2014 at 8:13 PM, Duncan Thomas duncan.tho...@gmail.com wrote: So these are all features that various other backends manage to implement successfully. Your best point of reference might be the ceph code - I believe it deals with very similar issues in various ways. On 19 June 2014 18:01, Amit Das amit@cloudbyte.com wrote: Hi All, Thanks for clarifying the Cinder behavior w.r.t a snapshot its clones which seems to be independent/decoupled. The current volume its snapshot based validations in Cinder holds true for snapshot its clones w.r.t my storage requirements. Our storage is built on top of ZFS filesystem. The volume - snapshot - clone that I am referring to in turn points to a ZFS dataset - ZFS snapshot - ZFS clone. The best part of ZFS based snapshots clones are : these are almost instantaneous ( i.e. copy-on-write based copies) these will not consume any additional (initially) a clone initially shares all its disk space with the original snapshot, its used property is initially zero. As changes are made to the clone, it uses more space. The used property of the original snapshot does not consider the disk space consumed by the clone. Further optimizations i.e. cool feature: While creating VM clones, a hypervisor driver can delegate part of its cloning process to storage driver hence, the overall VM cloning will be very very fast. Regards, Amit CloudByte Inc. On Thu, Jun 19, 2014 at 9:16 PM, John Griffith john.griff...@solidfire.com wrote: On Tue, Jun 17, 2014 at 10:50 PM, Amit Das amit@cloudbyte.com wrote: Hi Stackers, I have been implementing a Cinder driver for our storage solution facing issues with below scenario. Scenario - When a user/admin tries to delete a snapshot that has associated clone(s), an error message/log should be shown to the user stating that 'There are clones associated to this snapshot. Hence, snapshot cannot be deleted'. What's the use model of clones associated with the snapshot? What are these clones from a Cinder perspective. Easy answer is: don't create them, but I realize you probably have a cool feature or optimization that you're trying to leverage here. Implementation issues - If Cinder driver throws an Exception the snapshot will have error_deleting status will not be usable. If Cinder driver logs the error silently then Openstack will probably mark the snapshot as deleted. So as others point out, from a Cinder perspective this is what I/we would expect. Scott made some really good points, but the point is we do not want to behave differently for every single driver. The agreed upon mission for Cinder is to actually provide a consistent API and set of behaviors to end users regardless of what backend device they're using (in other words that should remain pretty much invisible to the end-user). What do you use the Clones of the Snapshot for? Maybe we can come up with another approach that works and keeps consistency in the API. What is the appropriate procedure that needs to be followed for above usecase. Regards, Amit CloudByte Inc. ___ 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 -- Duncan Thomas ___ 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
