Re: [openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email
So, we can work around this in devstack, but it seems like there is a more fundamental bug here that setup project isn't following dependencies. Dep chain was: testtools (from zake=0.1-tooz=0.12,=0.3-ceilometer==2014.2.3.dev2) Unneeded _runtime_ dependency on testtools was removed in https://github.com/yahoo/Zake/commit/215620ca51c3c883279ba62ccc860a274219ecc1 Is this just another 'pip is drunk' issue in it not actually satisfying requirements? Seems that pip is drunk by design, clarkb explained that pip only updates deps if you pass the --upgrade flag. Cheers, Alan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [sahara] team meeting Mar 12 1400 UTC
Hi sahara folks, We'll be having the Sahara team meeting tomorrow at #openstack-meeting-3 channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150312T14 P.S. I'll be unavailable at this time unfortunately, so, Andrew Lazarev will chair the meeting. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [sahara] team meeting Mar 12 1400 UTC
Correction, Michael McCune (elmiko) will chair the meeting. On Wed, Mar 11, 2015 at 3:57 PM, Sergey Lukjanov slukja...@mirantis.com wrote: Hi sahara folks, We'll be having the Sahara team meeting tomorrow at #openstack-meeting-3 channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20150312T14 P.S. I'll be unavailable at this time unfortunately, so, Andrew Lazarev will chair the meeting. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging] extending notification MessagingDriver
Regarding bug 1426046 (see below) -- Is this just a matter of making the classes public or are you thinking the driver interface needs more thought + solidifying before making something extendable? Perhaps I can donate a cycle to 2 to help get this in. On 2/26/15 10:33 AM, Doug Hellmann wrote: Yes, I don't recommend relying on anything in private modules. It looks like even the base class for the notification drivers is private, right now. We should probably change that, so I filed https://bugs.launchpad.net/oslo.messaging/+bug/1426046. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable] Freeze exception for Correct initialization order for logging to use eventlet locks
Hello, I would like to get a freeze exception for patch Correct initialization order for logging to use eventlet locks, [0]. https://review.openstack.org/#/c/163387/ The bug fixed by the changeset is known to affect Keystone deployed with eventlet. I am aware of a customer who hit this bug in his cloud. There is no known workaround for the bug. -- Best regards, Boris Bobrov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Recent issues with our review workflow
I'll keep it in mind not to create unnecessary backports, although I really find it more convenient to do them once I submit changes to master for review. I apologize for [4], it indeed was wrong and it won't happen again. Regards, Bartłomiej On Wed, Mar 11, 2015 at 12:36 AM, Ryan Moe r...@mirantis.com wrote: Here are some examples of proposing changes prior to being merged in master [0][1][2][3][4]. [0] is a perfect example of why this isn't a good process. A change was proposed to stable/6.0 before master was merged, and now the change to master needs to be reworked based on review feedback. Premature backporting just creates unnecessary additional work. I'd also like to give a friendly reminder to make sure we maintain the Change-Id and author of any change we backport. The wiki [5] has also been updated to make this explicit. [0] https://review.openstack.org/#/q/Ief8186006386af8ae7e40cffeeaeef5a5c0f3c70,n,z [1] https://review.openstack.org/#/q/I4c94bb03501f4238ead2378cf504485b7d67b236,n,z [2] https://review.openstack.org/#/q/Ic15a3bfb6238e4281b06aae0a3f9fe4abf96590d,n,z [3] https://review.openstack.org/#/q/I7ab6dc2341821c3b82ef3d3ac63b64a5a9958fa9,n,z [4] https://review.openstack.org/#/q/Iff947f0053577f19441c04101e5a35a7820e40a0,n,z [5] https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Backport_bugfixes_to_stable_release_series Thanks, Ryan On Tue, Mar 10, 2015 at 4:20 AM, Tomasz Napierala tnapier...@mirantis.com wrote: On 09 Mar 2015, at 18:21, Ryan Moe r...@mirantis.com wrote: Hi All, I've noticed a few times recently where reviews have been abandoned by people who were not the original authors. These reviews were only days old and there was no prior notice or discussion. This is both rude and discouraging to contributors. Reasons for abandoning should be discussed on the review and/or in email before any action is taken. Hi Ryan, I was trying to find any examples, and the only one I see is: https://review.openstack.org/#/c/152674/ I spoke to Bogdan and he agreed it was not proper way to do it, but they were in a rush - I know, it does not explain anything really. Do you have any other examples? I’d like to clarify them Regards, -- Tomasz 'Zen' Napierala Sr. OpenStack Engineer tnapier...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Kilo FeatureFreeze is March 19th, FeatureProposalFreeze has happened
Hi, Just a quick update on where we are at with the release: https://wiki.openstack.org/wiki/Kilo_Release_Schedule Please help review all the code we want to merge before FeatureFreeze: https://etherpad.openstack.org/p/kilo-nova-priorities-tracking https://launchpad.net/nova/+milestone/kilo-3 Please note, 19th March is: kilo-3 release, General FeatureFreeze, StringFreeze, DepFreeze (that includes all high priority items) Generally patches that don't look likely to merge by 19th March are likely to get deferred around 17th March, to make sure we get kilo-3 out the door. As ever, there may be exceptions, if we really need them, but they will have to be reviewed by ttx for their impact on the overall integrated release of kilo. More details will be shared nearer the time. A big ask at this time, is to highlight any release critical bugs that we need to fixe before we can release kilo (and that involves testing things). We are likely to use the kilo-rc-potential tag to track those bugs, more details on that soon. Any questions, please do ask (here or on IRC). Thanks, johnthetubaguy PS Just a reminder you are now free to submit specs for liberty. Specs where there is no clear agreement will be the best candidates for a discussion slot at the summit. Again more on that later. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Driver documentation for Kilo [cinder] [neutron] [nova] [trove]
Ok, thanks Anne! On Tue, Mar 10, 2015 at 6:10 PM, Anne Gentle annegen...@justwriteclick.com wrote: On Tue, Mar 10, 2015 at 3:35 PM, Erlon Cruz sombra...@gmail.com wrote: Hi Anne, Thanks for the quick answer. One thing that still not clear for me is about the documentation that is currently there. Will it be removed (converted to the resumed version) in Kilo? If so what are the milestones for that? All deadlines revolve around the release of Kilo and time for reviews. I don't know if we are planning on a purge with all the migration work still to be done, so please just work on best effort by April 9th so the doc team can work with you. Thanks, Anne Erlon On Tue, Mar 10, 2015 at 10:48 AM, Anne Gentle annegen...@justwriteclick.com wrote: On Tue, Mar 10, 2015 at 8:28 AM, Erlon Cruz sombra...@gmail.com wrote: Hi Anne, How about driver documentation that is in the old format? Will it be removed in Kilo? Hi Erlon, The spec doesn't have a specific person assigned for removal, and the only drivers the docs team signed up for through the blueprint are these: - For cinder: volume drivers: document LVM and NFS; backup drivers: document swift - For glance: Document local storage, cinder, and swift as backends - For neutron: document ML2 plug-in with the mechanisms drivers OpenVSwitch and LinuxBridge - For nova: document KVM (mostly), send Xen open source call for help - For sahara: apache hadoop - For trove: document all supported Open Source database engines like MySQL. The wiki says: Bring all driver sections that are currently just ‘bare bones’ up to the standard mentioned. Will this be performed by core team? Andreas has done some of that work, for example here: https://review.openstack.org/#/c/157086/ We can use more hands of course, just coordinate the work here on the list. And Andreas, if there aren't any more to do, let us know. :) Thanks, Anne Thanks, Erlon On Fri, Mar 6, 2015 at 4:58 PM, Anne Gentle annegen...@justwriteclick.com wrote: Hi all, We have been working on streamlining driver documentation for Kilo through a specification, on the mailing lists, and in my weekly What's Up Doc updates. Thanks for the reviews while we worked out the solutions. Here's the final spec: http://specs.openstack.org/openstack/docs-specs/specs/kilo/move-driver-docs.html Driver documentation caretakers, please note the following summary: - At a minimum, driver docs are published in the Configuration Reference at with tables automatically generated from the code. There's a nice set of examples in this patch: https://review.openstack.org/#/c/157086/ - If you want full driver docs on docs.openstack.org, please add a contact person's name and email to this wiki page: https://wiki.openstack.org/wiki/Documentation/VendorDrivers - To be included in the April 30 release of the Configuration Reference, driver docs are due by April 9th. Thanks all for your collaboration and attention. Anne -- Anne Gentle annegen...@justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Anne Gentle annegen...@justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Anne Gentle annegen...@justwriteclick.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Icehouse 2014.1.4 freeze exceptions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2015 12:21 PM, Alan Pevec wrote: Hi, next Icehouse stable point release 2014.1.4 has been slipping last few weeks due to various gate issues, see Recently closed section in https://etherpad.openstack.org/p/stable-tracker for details. Branch looks good enough now to push the release tomorrow (Thursdays are traditional release days) and I've put freeze -2s on the open reviews. I'm sorry about the short freeze period but branch was effectively frozen last two weeks due to gate issues and further delay doesn't make sense. Attached is the output from the stable_freeze script for thawing after tags are pushed. At the same time I'd like to propose following freeze exceptions for the review by stable-maint-core: * https://review.openstack.org/144714 - Eventlet green threads not released back to pool Justification: while not OSSA fix, it does have SecurityImpact tag * https://review.openstack.org/163035 - [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Justification: pending merge on master and juno +2 to both exceptions, especially the OSSA one. All distributions will be interested in including the patch in their packages, so it's better to do it once in upstream. Cheers, Alan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVACsoAAoJEC5aWaUY1u57bYgH/0D1PSy0lJ5yyfkWWKDCDsz7 2Uk6jMOiH6g0nS3o+mJHiukBTbCCpsx4mnVKTtejyAJN8Fc8vW3UaWNWxsZDJykn MplR+l6dO2jVmn3RZYH3FudeP9BtTOohUZahzTsXcnZ2+S9WvFiTX8NRmqzgWPgY J7GioQ3XcGk2Q22LEBWhhJFCNm7mLsdKjVQds4glyZPMbuH5gNw4fKwU2xFikWOr RRBPplSL+DJOfNjqPc2w4CCbXyWuN+j398/GGHEi4QRnKf97fSn99x95uyiLM5EY S/qg7MbWcNFWzjsVtzQyAp6DaQRH4/YK6/Rt8oQpGPtfyFAPb0/3Z50yZ128bxg= =WBlx -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Freeze exception for Correct initialization order for logging to use eventlet locks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2015 12:51 PM, Boris Bobrov wrote: Hello, I would like to get a freeze exception for patch Correct initialization order for logging to use eventlet locks, [0]. https://review.openstack.org/#/c/163387/ The bug fixed by the changeset is known to affect Keystone deployed with eventlet. I am aware of a customer who hit this bug in his cloud. There is no known workaround for the bug. Seems reasonable to me. Eventlet mode was not even deprecated in Icehouse, so should be properly supported. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVAC4KAAoJEC5aWaUY1u57mckH/AhxxtzoqylsuQymgtPGQaW+ 20nuI4620/rOJeb+6uvbmU+r35yTbgwD+vleq7MEtqMkaZ4i01z4XydfKtKUhmT6 umYRZgz92O8uPL2n7RvnZk7glAKvXQcCLGn/GyD7QypmPisBoJFDpz4F/zdLWHGq fM/UgJBk78usGXc3ff8xUZI72uFSCHcsQdaiZG6qOWwyTufED3U4Hpmd1BTCGOjm JM2P2qBD7nznrjd/MXhtQta2hgadb8iSEdDJHznGzuVgKhKaWbR+OWIox8qZZXIX qPNguSWrJqRVJlDAIa0rpPLRT0c+FFnKVMp8aObXNlKoKCXz0wwFQYKe/vLNsmI= =g4a1 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Issue when upgrading from Juno to Kilo due to agent report_state RPC namespace patch
- Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Should we target it for Kilo? It does not seem right to allow it slipping into the next release while we know there are operators relying on the feature. Of course, this will be fixed for Kilo. This is the immediate fix, which should be merged right away: https://review.openstack.org/#/c/163676/ I pushed a patch to support servers with multiple namespaces to Oslo messaging: https://review.openstack.org/#/c/163673/ Once that gains momentum I'll send a patch to Neutron that re-enables namespaces for RPC servers (Along with the null namespace) and enable fallbacks for clients. On 03/11/2015 08:42 PM, Assaf Muller wrote: I've filed a bug here: https://bugs.launchpad.net/neutron/+bug/1430984 I've outlined the path I'd like to take in the bug description. - Original Message - +1 on avoiding changes that break rolling upgrade. Rolling upgrade has been working so far (at least from my perspective), and as openstack adoption spreads, it will be important for more and more users. How do we make rolling upgrade a supported part of Neutron? Finding a sane way to test it would be a start. I'm still looking... - Jack -Original Message- From: Assaf Muller [mailto:amul...@redhat.com] Sent: Thursday, March 05, 2015 11:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Issue when upgrading from Juno to Kilo due to agent report_state RPC namespace patch - Original Message - To turn this stuff off, you don't need to revert. I'd suggest just setting the namespace contants to None, and that will result in the same thing. http://git.openstack.org/cgit/openstack/neutron/tree/neutron/common/constants.py# n152 It's definitely a non-backwards compatible change. That was a conscious choice as the interfaces are a bit of a tangled mess, IMO. The non-backwards compatible changes were simpler so I went that route, because as far as I could tell, rolling upgrades were not supported. If they do work, it's due to luck. There's multiple things including the lack of testing this scenario to lack of data versioning that make it a pretty shaky area. However, if it worked for some people, I totally get the argument against breaking it intentionally. As mentioned before, a quick fix if needed is to just set the namespace constants to None. If someone wants to do something to make it backwards compatible, that's even better. I sent out an email to the operators list to get some feedback: http://lists.openstack.org/pipermail/openstack-operators/2015-March/006429.html And at least one operator reported that he performed a rolling Neutron upgrade from I to J successfully. So, I'm agreeing with you agreeing with me that we probably don't want to mess this up knowingly, even though there is no testing to make sure that it keeps working. I'll follow up on IRC with you to figure out who's doing what. -- Russell Bryant On 03/04/2015 11:50 AM, Salvatore Orlando wrote: To put in another way I think we might say that change 154670 broke backward compatibility on the RPC interface. To be fair this probably happened because RPC interfaces were organised in a way such that this kind of breakage was unavoidable. I think the strategy proposed by Assaf is a viable one. The point about being able to do rolling upgrades only from version N to N+1 is a sensible one, but it has more to do with general backward compability rules for RPC interfaces. In the meanwhile this is breaking a typical upgrade scenario. If a fix allowing agent state updates both namespaced and not is available today or tomorrow, that's fine. Otherwise I'd revert just to be safe. By the way, we were supposed to have already removed all server rpc callbacks in the appropriate package... did we forget out this one or is there a reason for which it's still in neutron.db? Salvatore On 4 March 2015 at 17:23, Miguel Ángel Ajo majop...@redhat.com mailto:majop...@redhat.com wrote: I agree with Assaf, this is an issue across updates, and we may want (if that’s technically possible) to provide access to those functions with/without namespace. Or otherwise think about reverting for now until we find a migration strategy https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:m aster+topic:bp/rpc-docs-and-namespaces,n,z Best regards, Miguel Ángel Ajo On Wednesday, 4 de March de 2015 at 17:00, Assaf Muller wrote: Hello everyone, I'd like to highlight an issue with: https://review.openstack.org/#/c/154670/ According to my understanding, most deployments upgrade the controllers first and compute/network nodes later. During
Re: [openstack-dev] [Glance] Nitpicking in code reviews
+1 to what John said (overall). However, I think I know where Erno is coming from. We're very close to the FF and people are trying hard to get green on the check as well as ensure thoroughness of the feature; this might lead to bunch of these errors. Pointing them out and expecting to complete the remnant in a follow up patch sounds like a better solution to me rather than holding something important back that may miss the FF. Thanks, -Nikhil From: John Bresnahan j...@bresnahan.me Sent: Wednesday, March 11, 2015 9:06 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Glance] Nitpicking in code reviews FWIW I agree with #3 and #4 but not #1 and #2. Spelling is an easy enough thing to get right and speaks to the quality standard to which the product is held even in commit messages and comments (consider the 'broken window theory'). Of course everyone makes mistakes (I am a terrible speller) but correcting a spelling error should be a trivial matter. If a reviewer notices a spelling error I would expect them to point it. On 3/11/15 2:22 PM, Kuvaja, Erno wrote: Hi all, Following the code reviews lately I’ve noticed that we (the fan club seems to be growing on weekly basis) have been growing culture of nitpicking [1] and bikeshedding [2][3] over almost every single change. Seriously my dear friends, following things are not worth of “-1” vote if even a comment: 1)Minor spelling errors on commit messages (as long as the message comes through and flags are not misspelled). 2)Minor spelling errors on comments (docstrings and documentation is there and there, but comments, come-on). 3)Used syntax that is functional, readable and does not break consistency but does not please your poem bowel. 4)Other things you “just did not realize to check if they were there”. After you have gone through the whole change go and look your comments again and think twice if your concern/question/whatsoever was addressed somewhere else than where your first intuition would have dropped it. We have relatively high volume for glance at the moment and this nitpicking and bikeshedding does not help anyone. At best it just tightens nerves and breaks our group. Obviously if there is “you had ONE job” kind of situations or there is relatively high amount of errors combined with something serious it’s reasonable to ask fix the typos on the way as well. The reason being need to increase your statistics, personal perfectionist nature or actually I do not care what; just stop or go and do it somewhere else. Love and pink ponies, -Erno [1] www.urbandictionary.com/define.php?term=nitpicking http://www.urbandictionary.com/define.php?term=nitpicking [2] http://bikeshed.com [3] http://en.wiktionary.org/wiki/bikeshedding __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [metadata] metadata service when NOT using name space
When use_namespaces is True, there will be a namespace metadata proxy launched for either dhcp or router namespace, this proxy will accept metada service request , and then proxy the request to metadata server via metadata agent. But when use_namespaces is False, there is no namespace metadata proxy running, how is the request from vm going to get to matadata server then? I also checked that there is no NAT rule in the iptables. So do we support metadata service with no namespace? If we do , how is it supposed to work? This is Juno. Regards! Wanjing Xu__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Avoiding regression in project governance
On 11 March 2015 at 05:29, Russell Bryant rbry...@redhat.com wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved *any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. I think this is kindof missing the point of the new governance system: the bar for entry has been replaced with a bar for getting certain tags - holding back entrants because we don't have enough tags to answer all the questions we could before doesn't make anything better - we know we weren't really answering the questions folk cared about before (thats why we've revamped the governance system at all). If I understand your particular concern, its that if more projects are added folk will be more confused about what is safe or sane to deploy : I think that is a risk, but not a big one, because what was safe or sane to deploy before was already quite fuzzy. See e.g. Neutron only a couple of releases back :). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] readout from Philly Operators Meetup
It sounds like we're diverging a bit from the original topic, but... whatever. Yeah! We should totally work towards a quota service - that's what we said back in 2011 This is a topic that comes back regularly like the Halley's comet. With the only difference that it happens every 6 months, not 75 years. We explored options for a quota library or service in a few recent email threads and at the Paris summit. It was concluded that since quota enforcement requires database support, and quota management needs to hook into some RESTful APIs, an oslo library was not the appropriate path forward. Further options were explored, but the thing which is closest to what we'd need, from a conceptual point of view is Boson [1]. As you can see, the development there has been stalled for a while. It was then considered how to move forward with boson, and how to integrate it in the current Openstack infrastructure. The most recent update on the mailing list is [2]. As you can see, there has not been any activity for a while there too. I am still interested in resuming that work, and I am planning to come back to it after the Kilo-3 deadline. I am obviously still trying to look at building a group of developers interested in it. Salvatore [1] https://github.com/klmitch/boson [2] http://lists.openstack.org/pipermail/openstack-dev/2015-January/054510.html On 11 March 2015 at 23:49, Robert Collins robe...@robertcollins.net wrote: On 12 March 2015 at 12:07, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2015 07:48 PM, Joe Gordon wrote: Out of sync Quotas -- https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63 The quotas code is quite racey (this is kind of a known if you look at the bug tracker). It was actually marked as a top soft spot during last fall's bug triage - http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html There is an operator proposed spec for an approach here - https://review.openstack.org/#/c/161782/ Action: we should make a solution here a top priority for enhanced testing and fixing in Liberty. Addressing this would remove a lot of pain from ops. To help us better track quota bugs I created a quotas tag: https://bugs.launchpad.net/nova/+bugs?field.tag=quotas Next step is re-triage those bugs: mark fixed bugs as fixed, deduplicate bugs etc. (Being quite far from nova code, so ignore if not applicable) I would like to note that other services experience races in quota management too. Neutron has a spec approved to land in Kilo-3 that is designed to introduce a new quota enforcement mechanism that is expected to avoid (some of those) races: https://github.com/openstack/neutron-specs/blob/master/specs/kilo/better-quotas.rst I thought you may be interested in looking into it to apply similar ideas to nova. Seems to me that there is enough complexity around quotas that a dedicated quota REST service could be a good way to abstract that out - then in consuming code you can reserve, consume and free appropriately, and the service can take care of being super diligent about races, correctness, and we'd have one place both in code and deployments to tune for speed. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Avoiding regression in project governance
On 11/03/15 19:06 +, Tim Bell wrote: -Original Message- From: Stefano Maffulli [mailto:stef...@openstack.org] Sent: 11 March 2015 03:16 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Avoiding regression in project governance On Tue, 2015-03-10 at 15:23 -0700, James E. Blair wrote: The holy grail of this system would be the suitable for production deployment tag, but no one has figured out how to define it yet. Are crazy ideas welcome in this phase? I start with 2 below: Preface: an idea circulates about visually displaying in a web page the projects.yaml file and the tags in there. Visitors would be able to browse the list of projects and sort, pick, search and find what they need from a nice representation of the 'big tent'. 1) how about we pull the popularity of OpenStack projects as reported in the User Survey and display such number on the page where we list the projects? What if, together with the objective tags managed by TC and community at large, we show also the number of known deployment as guidance? I think we can make this work. Assuming more than N (to my mind 5 or so) deployments report they are using project X, we can say that this is used in production/POC/... and the number of nodes/hypervisors/etc. This makes it concrete and anonymous to avoid the fishing queries. It also allows our community to enter what they are doing in one place rather than answering multiple surveys. I am keen to avoid generic queries such as How many hypervisors are installed for public clouds using Xen but if we have an agreement that 5 avoids company identification, I feel this is feasible. It does help address the maturity question concretely. If it's in prod in 200 deployments, I would consider this to be reasonably mature. If there is only 1, I would worry. I'm not convinced this is a fair metric. What if I tell you, there's just 1 large deployment? or that there's just 1 deployment that has been running the service for quite a bit? It's true that the more deployments there are, the easier it is to trust a project's maturity but I'd be worry about people considering that the only metric and not giving new projects a chance. Flavio [snip] -- @flaper87 Flavio Percoco pgp9Nma0N2AXF.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Avoiding regression in project governance
-Original Message- From: Stefano Maffulli [mailto:stef...@openstack.org] Sent: 12 March 2015 00:26 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Avoiding regression in project governance On Wed, 2015-03-11 at 17:59 -0500, Ed Leafe wrote: The longer we try to be both sides of this process, the longer we will continue to have these back-and-forths about stability vs. innovation. If I understand correctly your model, it works only for users/operators who decide to rely on a vendor to consume OpenStack. There are quite large enterprises out there who consume directly the code as it's shipped from git.openstack.org, some from trunk others from the stable release .tgz: these guys can't count on companies A, B, C or D to put resources to fix their problems, because they don't talk to those companies. One thing I like of your proposal though, when you say: So what is production-ready? And how would you trust any such designation? I think that it should be the responsibility of groups outside of OpenStack development to make that call. This problem has been bugging the European authorities for a long time and they've invested quite a lot of money to find tools that would help IT managers of the public (and private) sector estimate the quality of open source code. It's a big deal in fact when on one hand you have Microsoft and IBM sales folks selling your IT managers overpriced stuff that just works and on the other hand you have this Linux thing that nobody has heard of, it's gratis and I can find it on the web and many say it just works, too... crazy, right? Well, at the time it was and to some extent, it still is. So the EU has funded lots of research in this area. One group of researcher that I happen to be familiar with, recently has received another bag of Euros and released code/methodologies to evaluate and compare open source projects[1]. The principles they use to evaluate software are not that hard to find and are quite objective. For example: is there a book published about this project? If there is, chances are this project is popular enough for a publisher to sell copies. Is the project's documentation translated in multiple languages? Then we can assume the project is popular. How long has the code been around? How large is the pool of contributors? Are there training programs offered? You get the gist. Following up on my previous crazy ideas (did I hear someone yell keep 'em coming?), probably a set of tags like: book-exists (or book-chapter-exists) specific-training-offered translated-in-1-language (and its bigger brothers translated-in-5, translated-in-10+languages) contributor-size-high (or low, and we can set a rule as we do for the diversity metric used in incubation/graduation) codebase-age-baby, -young and -mature, (in classes, like less than 1, 1-3, 3+ years old) would help a user understand that Nova or Neutron are different from (say) Barbican or Zaqar. These are just statements of facts, not a qualitative assessment of any of the projects mentioned. At the same time, I have the impression these facts would help our users make up their mind. Thoughts? Just one, is it too late to change the name, tag is pretty overloaded and I rather like the sound of badge. I would be nice to see project working towards different new badges and carrying them proudly after earning them. Oh another one, I'm not convinced that 3+ years is still mature project. I think there is room to look bit out of our own sandbox and think where we are in 2, 3 or 5 years time. Perhaps we need to change the governance again, perhaps this could be something that is flexible all the way there, but I would hate to call Nova, Swift, Glance etc. ancient or granny just because they have been around double/triple the mature time. - Erno [1] http://www.ict-prose.eu/2014/12/09/osseval-prose-open-source- evaluation-methodology-and-tool/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [metadata] metadata service when NOT using name space
Can you explain why are you not using namespaces? (I'm really curious). I've been thinking of proposing to deprecate that option only for the simple truth that it's not tested and we have no idea if it works anymore, or if anyone actually uses it. - Original Message - When use_namespaces is True, there will be a namespace metadata proxy launched for either dhcp or router namespace, this proxy will accept metada service request , and then proxy the request to metadata server via metadata agent. But when use_namespaces is False, there is no namespace metadata proxy running, how is the request from vm going to get to matadata server then? I also checked that there is no NAT rule in the iptables. So do we support metadata service with no namespace? If we do , how is it supposed to work? This is Juno. Regards! Wanjing Xu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Ryu/ofagent CI outage
hi,
sorry for keep forgetting and thank you for reminder.
YAMAMOTO Takashi
Hi-
Regarding the CI offline mails, I previously received an email from Anita.
Please find the summary below.
Please set your account listing to down on this page:
https://wiki.openstack.org/wiki/ThirdPartySystems
Following these instructions: If your system is going down or having
problems, change the entry to {{ThirdPartySystemTableEntryDown|your
ci system name}} which are found on the
https://wiki.openstack.org/wiki/ThirdPartySystems page.
Leave the details of your system status on this page:
https://wiki.openstack.org/wiki/ThirdPartySystems/Ryu_CI
This is the expected workflow of offline systems communication.
Posting to this mailing list is not part of the communication.
Hope this helps when you further communicate the CI status.
--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048
-Original Message-
From: YAMAMOTO Takashi [mailto:yamam...@valinux.co.jp]
Sent: Wednesday, March 11, 2015 12:33 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Ryu/ofagent CI outage
hi,
Ryu/ofagent CI will be offline during the next weekend for a scheduled
maintenance. sorry for inconvenience.
YAMAMOTO Takashi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Avoiding regression in project governance
On 2015-03-10 23:00:16 + (+), Devananda van der Veen wrote: Many of those requirements were subjective (well tested, well documented, etc) and had to be evaluated by the TC. Are these the sort of tags you're referring to? If so, and if the TC delegated responsibility to manage the application of those tags (say, QA team manages the 'well-tested' tag), would that be sufficient? [...] Yep, that's exactly what I'm hoping for. But without those in place yet I worry that we'll end up turning away lots of new requests for help from projects coming forward thinking they're suddenly entitled by virtue of being OpenStack and not really have any common criteria to point them at so that they can work toward getting more priority. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.
On Wed, Mar 11, 2015 at 02:25:26PM +, Ian Cordasco wrote: I have no opinions on the matter. Either 1400 or 1500 work for me. I think there are a lot of people asking for it to be at 1500 instead though. Would anyone object to changing it to 1500 instead (as long as it is one consistent time for the meeting)? I have no problem with that. I'm +1 on a consistent time, but don't mind when it is. signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] readout from Philly Operators Meetup
On Wed, 11 Mar 2015, Matt Riedemann wrote: Thanks for writing this up. Etherpads are usually a mess for those not involved in creating them so it's always useful to have some summary and digestion after the fact. +trillion for summaries. Going to look at an etherpad is pretty much useless pretty much most of the time. (off-topic: Whatever happened to trimming messages?) -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email
On Wed, 11 Mar 2015, Alan Pevec wrote: So, we can work around this in devstack, but it seems like there is a more fundamental bug here that setup project isn't following dependencies. Dep chain was: testtools (from zake=0.1-tooz=0.12,=0.3-ceilometer==2014.2.3.dev2) Unneeded _runtime_ dependency on testtools was removed in https://github.com/yahoo/Zake/commit/215620ca51c3c883279ba62ccc860a274219ecc1 Is this just another 'pip is drunk' issue in it not actually satisfying requirements? Seems that pip is drunk by design, clarkb explained that pip only updates deps if you pass the --upgrade flag. That's why I did this for devstack: https://review.openstack.org/#/c/161195/ Presumably it might be useful other places? -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Ryu/ofagent CI outage
hi, Ryu/ofagent CI will be offline during the next weekend for a scheduled maintenance. sorry for inconvenience. YAMAMOTO Takashi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] will instance action deprecate in feature
Hi all will instance action deprecate in feature since we have notify mechanism now? Currently, nova have instance action and instance event action to record specify actions performed on a instances. For some enterprise user, they may need to compute the latency when they perform an action on an instance. I check instance action only record the start time but no finish time. Instance action event have start time and finish time. But for 1 instance action , there may be several instance action event, so there is no necessary to check all instance action event, we only care about the action time itself, so a finished time is necessary to added into instance action. I made a patch to add finish time of instance action in [1](but need to fix unit test issue), I wonder if it is worthy to Spend time on debug unit test issue? Since I remember that instance action will be deprecated soon. [1] https://review.openstack.org/162910 Best Regards, Eli(Li Yong) Qiao. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.
I have no opinions on the matter. Either 1400 or 1500 work for me. I think there are a lot of people asking for it to be at 1500 instead though. Would anyone object to changing it to 1500 instead (as long as it is one consistent time for the meeting)? On 3/11/15, 01:53, Inessa Vasilevskaya ivasilevsk...@mirantis.com wrote: +1 On Mon, Mar 9, 2015 at 2:43 AM, Alexander Tivelkov ativel...@mirantis.com wrote: Works for me, but the previous one worked as well. So, consider my vote as +1 unless the majority is against this :) -- Regards, Alexander Tivelkov On Mon, Mar 9, 2015 at 12:36 AM, Fei Long Wang feil...@catalyst.net.nz wrote: Oh, it means 3:00AM for me :-( On 09/03/15 09:07, Nikhil Komawar wrote: Hi all, Currently, we've alternating time for Glance meetings. Now, with the Daylight savings being implemented in some parts of the world, we're thinking of moving the meeting time to just one slot i.e. earlier in the day(night). This solves the original conflicting times issue that a subset of the individuals had; to add to that the schedule is less confusing and unified. So, the new proposal is: Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on #openstack-meeting-4 This would be implemented on Mar 19th, given there are no major objections. Please vote with +1/-1 here. [1] https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting [2] http://www.timeanddate.com/worldclock/fixedtime.html?hour=14min=0sec=0 http://www.timeanddate.com/worldclock/fixedtime.html?hour=14min=0sec=0 Thanks, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists. openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cheers Best regards, Fei Long Wang (王飞龙) -- Senior Cloud Software Engineer Tel: +64-48032246 tel:%2B64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] readout from Philly Operators Meetup
On 3/11/2015 7:59 AM, Sean Dague wrote: The last couple of days I was at the Operators Meetup acting as Nova rep for the meeting. All the sessions were quite nicely recorded to etherpads here - https://etherpad.openstack.org/p/PHL-ops-meetup There was both a specific Nova session - https://etherpad.openstack.org/p/PHL-ops-nova-feedback as well as a bunch of relevant pieces of information in other sessions. This is an attempt for some summary here, anyone else that was in attendance please feel free to correct if I'm interpreting something incorrectly. There was a lot of content there, so this is in no way comprehensive list, just the highlights that I think make the most sense for the Nova team. = Nova Network - Neutron = This remains listed as the #1 issue from the Operator Community on their burning issues list (https://etherpad.openstack.org/p/PHL-ops-burning-issues L18). During the tags conversation we straw polled the audience (https://etherpad.openstack.org/p/PHL-ops-tags L45) and about 75% of attendees were over on neutron already. However those on Nova Network we disproportionally the largest clusters and longest standing OpenStack users. Of those on nova-network about 1/2 had no interest in being on Neutron (https://etherpad.openstack.org/p/PHL-ops-nova-feedback L24). Some of the primary reasons were the following: - Complexity concerns - neutron has a lot more moving parts - Performance concerns - nova multihost means there is very little between guests and the fabric, which is really important for the HPC workload use case for OpenStack. - Don't want OVS - ovs adds additional complexity, and performance concerns. Many large sites are moving off ovs back to linux bridge with neutron because they are hitting OVS scaling limits (especially if on UDP) - (https://etherpad.openstack.org/p/PHL-ops-OVS L142) The biggest disconnect in the model seems to be that Neutron assumes you want self service networking. Most of these deploys don't. Or even more importantly, they live in an organization where that is never going to be an option. Neutron provider networks is close, except it doesn't provide for floating IP / NAT. Going forward: I think the gap analysis probably needs to be revisited with some of the vocal large deployers. I think we assumed the functional parity gap was closed with DVR, but it's not clear in it's current format it actually meets the n-net multihost users needs. === EC2 going forward === Having a sustaninable EC2 is of high interest to the operator community. Many large deploys have some users that were using AWS prior to using OpenStack, or currently are using both. They have preexisting tooling for that. There didn't seem to be any objection to the approach of an external proxy service for this function - (https://etherpad.openstack.org/p/PHL-ops-nova-feedback L111). Mostly the question is timing, and the fact that no one has validated the stackforge project. The fact that we landed everything people need to run this in Kilo is good, as these production deploys will be able to test it for their users when they upgrade. Burning Nova Features/Bugs Hierarchical Projects Quotas Hugely desired feature by the operator community (https://etherpad.openstack.org/p/PHL-ops-nova-feedback L116). Missed Kilo. This made everyone sad. Action: we should queue this up as early Liberty priority item. Out of sync Quotas -- https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63 The quotas code is quite racey (this is kind of a known if you look at the bug tracker). It was actually marked as a top soft spot during last fall's bug triage - http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html There is an operator proposed spec for an approach here - https://review.openstack.org/#/c/161782/ Action: we should make a solution here a top priority for enhanced testing and fixing in Liberty. Addressing this would remove a lot of pain from ops. Reporting on Scheduler Fails Apparently, some time recently, we stopped logging scheduler fails above DEBUG, and that behavior also snuck back into Juno as well (https://etherpad.openstack.org/p/PHL-ops-nova-feedback L78). This has made tracking down root cause of failures far more difficult. Action: this should hopefully be a quick fix we can get in for Kilo and backport. = Additional Interesting Bits = Rabbit -- There was a whole session on Rabbit - https://etherpad.openstack.org/p/PHL-ops-rabbit-queue Rabbit is a top operational concern for most large sites. Almost all sites have a restart everything that talks to rabbit script because during rabbit ha opperations queues tend to blackhole. All other queue systems
[openstack-dev] Fwd: PCI passthrough of 40G ethernet interface
-- Forwarded message -- From: jacob jacob opstk...@gmail.com Date: Tue, Mar 10, 2015 at 6:00 PM Subject: PCI passthrough of 40G ethernet interface To: openst...@lists.openstack.org Hi, I'm interested in finding out if anyone has successfully tested PCI passthrough functionality for 40G interfaces in Openstack(KVM hypervisor). I am trying this out on a Fedora 21 host with Fedora 21 VM image.(3.18.7-200.fc21.x86_64) Was able to successfully test PCI passthrough of 10 G interfaces: Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) With 40G interface testing, the PCI device is passed through to the VM but data transfer is failing. 0a:00.1 Ethernet controller: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (rev 01) Tried this with both the i40e driver and latest dpdk driver but no luck so far. With the i40e driver, the data transfer fails. Relevant dmesg output: [ 11.544088] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None [ 11.689178] i40e :00:06.0 eth2: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None [ 16.704071] [ cut here ] [ 16.705053] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x23e/0x250() [ 16.705053] NETDEV WATCHDOG: eth1 (i40e): transmit queue 1 timed out [ 16.705053] Modules linked in: cirrus ttm drm_kms_helper i40e drm ppdev serio_raw i2c_piix4 virtio_net parport_pc ptp virtio_balloon crct10dif_pclmul pps_core parport pvpanic crc32_pclmul ghash_clmulni_intel virtio_blk crc32c_intel virtio_pci virtio_ring virtio ata_generic pata_acpi [ 16.705053] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.18.7-200.fc21.x86_64 #1 [ 16.705053] Hardware name: Fedora Project OpenStack Nova, BIOS 1.7.5-20140709_153950- 04/01/2014 [ 16.705053] 2e5932b294d0c473 88043fc83d48 8175e686 [ 16.705053] 88043fc83da0 88043fc83d88 810991d1 [ 16.705053] 88042958f5c0 0001 88042865f000 0001 [ 16.705053] Call Trace: [ 16.705053] IRQ [8175e686] dump_stack+0x46/0x58 [ 16.705053] [810991d1] warn_slowpath_common+0x81/0xa0 [ 16.705053] [81099245] warn_slowpath_fmt+0x55/0x70 [ 16.705053] [8166e62e] dev_watchdog+0x23e/0x250 [ 16.705053] [8166e3f0] ? dev_graft_qdisc+0x80/0x80 [ 16.705053] [810fd52a] call_timer_fn+0x3a/0x120 [ 16.705053] [8166e3f0] ? dev_graft_qdisc+0x80/0x80 [ 16.705053] [810ff692] run_timer_softirq+0x212/0x2f0 [ 16.705053] [8109d7a4] __do_softirq+0x124/0x2d0 [ 16.705053] [8109db75] irq_exit+0x125/0x130 [ 16.705053] [817681d8] smp_apic_timer_interrupt+0x48/0x60 [ 16.705053] [817662bd] apic_timer_interrupt+0x6d/0x80 [ 16.705053] EOI [811005c8] ? hrtimer_start+0x18/0x20 [ 16.705053] [8105ca96] ? native_safe_halt+0x6/0x10 [ 16.705053] [810f81d3] ? rcu_eqs_enter+0xa3/0xb0 [ 16.705053] [8101ec7f] default_idle+0x1f/0xc0 [ 16.705053] [8101f64f] arch_cpu_idle+0xf/0x20 [ 16.705053] [810dad35] cpu_startup_entry+0x3c5/0x410 [ 16.705053] [8104a2af] start_secondary+0x1af/0x1f0 [ 16.705053] ---[ end trace 7bda53aeda558267 ]--- [ 16.705053] i40e :00:05.0 eth1: tx_timeout recovery level 1 [ 16.705053] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 519 Tx ring 0 disable timeout [ 16.744198] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 520 Tx ring 64 disable timeout [ 16.779322] i40e :00:05.0: i40e_ptp_init: added PHC on eth1 [ 16.791819] i40e :00:05.0: PF 40 attempted to control timestamp mode on port 1, which is owned by PF 1 [ 16.933869] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None [ 18.853624] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs [ 22.720083] i40e :00:05.0 eth1: tx_timeout recovery level 2 [ 22.826993] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 519 Tx ring 0 disable timeout [ 22.935288] i40e :00:05.0: i40e_vsi_control_tx: VSI seid 520 Tx ring 64 disable timeout [ 23.669555] i40e :00:05.0: i40e_ptp_init: added PHC on eth1 [ 23.682067] i40e :00:05.0: PF 40 attempted to control timestamp mode on port 1, which is owned by PF 1 [ 23.722423] i40e :00:05.0 eth1: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None [ 23.800206] i40e :00:06.0: i40e_ptp_init: added PHC on eth2 [ 23.813804] i40e :00:06.0: PF 48 attempted to control timestamp mode on port 0, which is owned by PF 0 [ 23.855275] i40e :00:06.0 eth2: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None [ 38.720091] i40e :00:05.0 eth1: tx_timeout recovery level 3 [ 38.725844] random: nonblocking pool is initialized [ 38.729874] i40e :00:06.0: HMC error interrupt [ 38.733425] i40e :00:06.0: i40e_vsi_control_tx: VSI
Re: [openstack-dev] [cinder]difference between spec merged and BP approval
Hi Stefano, Thanks so much for your detailed answer, I finally know the reason why those patches are not reviewed in this cycle. Actually, this BP (https://blueprints.launchpad.net/python-cinderclient/+spec/support-modify-volume-image-metadata) is created very early around Nov. 2014, and there is BP even earlier before that (https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata) which is created around May 2014. Maybe they just believe this is not such important and not worth to take time to review. Hope those patches could be reviewed in 'L'. Best Regards, Dave Chen -Original Message- From: Stefano Maffulli [mailto:stef...@openstack.org] Sent: Tuesday, March 10, 2015 10:14 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [cinder]difference between spec merged and BP approval Hi David, On Sat, 2015-03-07 at 02:22 +, Chen, Wei D wrote: I thought the feature should be approved as long as the SPEC[1] is merged, but it seems I am wrong from the beginning[2], both of them (SPEC merged and BP approval[4][5]) is necessary and mandatory for getting some effective reviews, right? anyone can help to confirm with that? Since Cinder uses BP+spec, the process is described on the wiki page: https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle If it helps, I'd consider the spec and the blueprint as one element made of two pieces. The spec needs to be approved and its corresponding blueprint needs to be approved and have a priority, deadline/milestone assigned. If any of these attributes is missing, the feature is not going to be reviewed. Blueprints and their attributes 'priority' and 'milestone' are used to track the status of the release. The reviewers use BPs to identify the code that they need to review. For example, https://launchpad.net/cinder/+milestone/kilo-3 I've tried to piece the history of your experience from the links you provided: - you submitted the spec in November 2014 - the spec was approved on Jan 6, 2015 (from https://review.openstack.org/#/c/136253/) - the spec references two blueprints, one for Cinder, one of Cinder-client; both BPs were created at the end of February - none of the BP have a milestone set - you submitted code related to the approved spec between Jan 6 and today I have the impression that you may have missed a step in the BP+spec process. I have tried to find the documentation for this process myself and I had a hard time, too. Besides, who is eligible to define/modify the priority in the list[3], only PTL or any core? I am trying to understand the acceptable procedure for the coming 'L'. The project team leaders (PTL) are ultimately responsible to set the priorities, although the decision is always a consensual decision of the core teams. Have you considered joining OpenStack Upstream Training? https://www.openstack.org/blog/2015/02/openstack-upstream-training-in-vancouver/ Cheers, stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon
is there anyone tryed this and successfully?
On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang zhang.lei@gmail.com wrote:
Hi guys,
I am setting up the keytone v3 api. Now I meet a issue about the
`cloud_admin` policy.
Base on the
http://www.florentflament.com/blog/setting-keystone-v3-domains.html
article, I modify the cloud_admin policy to
```
cloud_admin: rule:admin_required and
domain_id:ef0d30167f744401a0cbfcc938ea7d63,
```
But the cloud_admin don't work as expected. I failed to open all the
identity panel ( like http://host/horizon/identity/domains/)
Horizon tell me Error: Unable to retrieve project list.
And keystone log warning:
```
2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-]
enforce identity:list_user_projects: {'is_delegated_auth': False,
'access_token_id': None, 'user_id': u'6433222efd78459bb70ad9adbcfac418',
'roles': [u'_member_', u'admin'], 'trustee_id': None, 'trustor_id': None,
'consumer_id': None, 'token': KeystoneToken
(audit_id=DWsSa6yYSWi0ht9E7q4uhw, audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) at
0x7f4503fab3c8, 'project_id': u'4d170baaa89b4e46b239249eb5ec6b00',
'trust_id': None}, enforce
/usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are not
authorized to perform the requested action: identity:list_projects (Disable
debug mode to suppress these details.)
```
I make some debug and found that, the root cause is that the `context`
variable in keystone has no `domain_id` field( like the above keystone
log). So the `cloud_admin` rule failed. if i change the `cloud_admin` to
following. It works as expected.
```
cloud_admin: rule:admin_required and user_id:
6433222efd78459bb70ad9adbcfac418,
```
I found that in the keystone code[0], the domain_id only exist when it is
a domain scope. But i believe that the horizon login token is a project
one( I am not very sure this)
```
if token.project_scoped:
auth_context['project_id'] = token.project_id
elif token.domain_scoped:
auth_context['domain_id'] = token.domain_id
else:
LOG.debug('RBAC: Proceeding without project or domain scope')
```
Is it a bug? or some wrong configuration?
Following is my configuration.
```
# /etc/keystone/keystone.conf
[DEFAULT]
debug=true
verbose=true
log_dir=/var/log/keystone
[assignment]
driver = keystone.assignment.backends.sql.Assignment
[database]
connection=mysql://:@controller/keystone
[identity]
driver=keystone.identity.backends.sql.Identity
[memcache]
servers=controller1:11211,controller2:11211,controller3:1121
[token]
provider=keystone.token.providers.uuid.Provider
```
```
# /etc/openstack-dashboard/local_settings.py ( partly )
POLICY_FILES_PATH = /etc/openstack-dashboard/
POLICY_FILES = {
'identity': 'keystone_policy.json',
}
OPENSTACK_HOST = 127.0.0.1
OPENSTACK_KEYSTONE_URL = http://%s:5000/v3; % OPENSTACK_HOST
OPENSTACK_KEYSTONE_DEFAULT_ROLE = _member_
OPENSTACK_API_VERSIONS = {
data_processing: 1.1,
identity: 3,
volume: 2
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
```
[0]
https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58
--
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l
--
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email
On 12 March 2015 at 13:18, Ian Wienand iwien...@redhat.com wrote: On 03/12/2015 10:37 AM, Ian Wienand wrote: File /tmp/easy_install-mV2rSm/unittest2-1.0.0/unittest2/case.py, line 16, in module ImportError: cannot import name range Complete output from command python setup.py egg_info: OK, so this suggests the version of six is wrong. unittest2 does have an uncapped dependency [1] looking at six, range was added between 1.3.0 1.4.0 ... but it hadn't got there yet. Filed [2]. I think the wheel works because pip gets to it after six has been upgraded. Even then, I'm not sure that would fix it. I've had similar issues before; I still don't fully understand why but pip install a b does *not* install a then b, apparently by design [2]. This deep in I'm not sure how the dependencies will order. Thanks for digging up the release of six. I've added the versioned dep and released unittest2 1.0.1 which has that and only that fix in it. Hopefully that will prevent the issue. The late version object shim is fragile though, so its likely not to work in many places - wheels will always be a better path forward for installing it until I get around to some proper magic to fix the version lookup stuff. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] about the image size
On Mar 12, 2015, at 04:08, Steven Dake (stdake) std...@cisco.com wrote: On 3/10/15, 12:22 AM, Bohai (ricky) bo...@huawei.com wrote: Hi, stackers I try to use the Kolla Images and pull them down from docker hub. I found the size of the image is bigger than what I thought(for example, the images of docker conductor service is about 1.4GB). Is it possible to get a more smaller images. Do we have the plan to minimize the images. Best regards to you. Ricky The images are quite large mainly because the base Fedora 20 image is very large. There are centos images available for download which average bout 750MB/per. It is worth noting that the image size is less problematic when all your images are using on the same base image. Then only the delta is downloaded, and not the whole 1.4GB. As far as I know there is no immediate plan to reduce the base image size. Steve will correct me if I’m wrong. I am myself experimenting with a different approach to build docker images based on tripleo image elements, and I get smaller images, for example for a Fedora 20 based keystone image that is 1.325 GB in kollaglue registry, I’m down to 1.049 GB, and I’m even down to 465 MB for the same image based on Debian unstable. Regards, Martin Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev PLEASE NOTE: This email, and any attachments hereto, are intended only for use by the specified addressee(s) and may contain legally privileged and/or confidential and/or proprietary information of KVH Co., Ltd. and/or its affiliates (including personal information). If you are not the intended recipient of this email, please immediately notify the sender by email, and please permanently delete the original, any print out and any copies of the foregoing. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Thinking about our python client UX
Oh, sure - switching to the spec is fine, I didn't realise there was one, given the list thread had gone quiet :) -Rob On 12 March 2015 at 12:24, Ruby Loo rlooya...@gmail.com wrote: On 11 March 2015 at 18:21, Robert Collins robe...@robertcollins.net wrote: ... Since there was no debate on the compat thing, I've thrown up an etherpad to start the discussion. https://etherpad.openstack.org/p/ironic-client-ux Thanks Rob. Michael Davies has a spec [1] that discusses how a client interacts with Ironic (pre-microversion and post-microversion). Maybe we can move our discussion to that spec? I was hoping we'd be able to decide and implement *something* for the kilo release, but maybe I am being overly optimistic. --ruby [1] https://review.openstack.org/#/c/161110/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] readout from Philly Operators Meetup
On 12 March 2015 at 13:05, Salvatore Orlando sorla...@nicira.com wrote: It sounds like we're diverging a bit from the original topic, but... whatever. Yeah! We should totally work towards a quota service - that's what we said back in 2011 :). This is a topic that comes back regularly like the Halley's comet. With the only difference that it happens every 6 months, not 75 years. We explored options for a quota library or service in a few recent email threads and at the Paris summit. It was concluded that since quota enforcement requires database support, and quota management needs to hook into some RESTful APIs, an oslo library was not the appropriate path forward. Ok, I misread that the first time. So the conclusion was yes, a service? I'll reply more about boson in the boson thread. -Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder]difference between spec merged and BP approval
On Wed, Mar 11, 2015 at 8:17 PM, Chen, Wei D wei.d.c...@intel.com wrote: Hi Stefano, Thanks so much for your detailed answer, I finally know the reason why those patches are not reviewed in this cycle. Actually, this BP ( https://blueprints.launchpad.net/python-cinderclient/+spec/support-modify-volume-image-metadata) is created very early around Nov. 2014, and there is BP even earlier before that ( https://blueprints.launchpad.net/python-cinderclient/+spec/support-volume-image-metadata) which is created around May 2014. Maybe they just believe this is not such important and not worth to take time to review. Hope those patches could be reviewed in 'L'. Best Regards, Dave Chen -Original Message- From: Stefano Maffulli [mailto:stef...@openstack.org] Sent: Tuesday, March 10, 2015 10:14 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [cinder]difference between spec merged and BP approval Hi David, On Sat, 2015-03-07 at 02:22 +, Chen, Wei D wrote: I thought the feature should be approved as long as the SPEC[1] is merged, but it seems I am wrong from the beginning[2], both of them (SPEC merged and BP approval[4][5]) is necessary and mandatory for getting some effective reviews, right? anyone can help to confirm with that? Since Cinder uses BP+spec, the process is described on the wiki page: https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle If it helps, I'd consider the spec and the blueprint as one element made of two pieces. The spec needs to be approved and its corresponding blueprint needs to be approved and have a priority, deadline/milestone assigned. If any of these attributes is missing, the feature is not going to be reviewed. Blueprints and their attributes 'priority' and 'milestone' are used to track the status of the release. The reviewers use BPs to identify the code that they need to review. For example, https://launchpad.net/cinder/+milestone/kilo-3 I've tried to piece the history of your experience from the links you provided: - you submitted the spec in November 2014 - the spec was approved on Jan 6, 2015 (from https://review.openstack.org/#/c/136253/) - the spec references two blueprints, one for Cinder, one of Cinder-client; both BPs were created at the end of February - none of the BP have a milestone set - you submitted code related to the approved spec between Jan 6 and today I have the impression that you may have missed a step in the BP+spec process. I have tried to find the documentation for this process myself and I had a hard time, too. Besides, who is eligible to define/modify the priority in the list[3], only PTL or any core? I am trying to understand the acceptable procedure for the coming 'L'. The project team leaders (PTL) are ultimately responsible to set the priorities, although the decision is always a consensual decision of the core teams. Have you considered joining OpenStack Upstream Training? https://www.openstack.org/blog/2015/02/openstack-upstream-training-in-vancouver/ Cheers, stef __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev First I'd like to thank Stef for the clear explanation; second I'd like to apologize Dave if you're feeling like nobody cares or don't feel your patch is that important. That's really not the case, it's just a matter of scheduling and priorities and honestly sometimes there's just more in the pipeline than we're able to actually process. I did notice that the bulk of your bp did in fact merge so that's good. Things like the cinderclient are a special case and don't have the same deadlines or prioritization. I'll take a look at what you have submitted again tomorrow, in the meantime you might want to jump on IRC at #openstack-cinder and look up myself or even better thingee who is the PTL for the Cinder project. There's plenty of core folks who should be willing and able to talk through some of the process stuff with you and discuss your patch. Also keep in mind that we have a weekly meeting on IRC that is intended to provide a forum for topics exactly like this and help us from letting things slip through the cracks. Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
