Re: [openstack-dev] [rally] Parallel scenarios
Ajay, to be more precise, we also already had a feature request https://github.com/stackforge/rally/blob/master/doc/feature_request/multi_scenarios_load_gen.rst for implementing load generation from multiple scenarios, which seems to be exactly what you proposed. So we are working on this. Best regards, Mikhail Dubov Community Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Sat, Sep 6, 2014 at 2:35 AM, Mikhail Dubov mdu...@mirantis.com wrote: Hi Ajay, Rally as of now does not support launching different scenarios in parallel; implementing this functionality is, however, one of the major points in our roadmap (see this blueprint https://blueprints.launchpad.net/rally/+spec/benchmark-runners-at-large-scale), since being able to produce e.g. parallel load from different servers is really important for benchmarking at scale. Best regards, Mikhail Dubov Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Fri, Sep 5, 2014 at 10:09 PM, Ajay Kalambur (akalambu) akala...@cisco.com wrote: Hi In Rally is there a way to run parallel scenarios? I know the scenario can support concurrency but I am talking about running multiple such scenarios themselves in parallel Ajay ___ 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] python-neutronclient, launchpad, and milestones
On 8/29/2014 1:53 PM, Kyle Mestery wrote: On Fri, Aug 29, 2014 at 1:40 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 7/29/2014 4:12 PM, Kyle Mestery wrote: On Tue, Jul 29, 2014 at 3:50 PM, Nader Lahouti nader.laho...@gmail.com wrote: Hi Kyle, I have a BP listed in https://blueprints.launchpad.net/python-neutronclient and looks like it is targeted for 3.0 (it is needed fro juno-3) The code is ready and in the review. Can it be a included for 2.3.7 release? Yes, you can target it there. We'll see about including it in that release, pending review. Thanks! Kyle Thanks, Nader. On Tue, Jul 29, 2014 at 12:28 PM, Kyle Mestery mest...@mestery.com wrote: All: I spent some time today cleaning up python-neutronclient in LP. I created a 2.3 series, and created milestones for the 2.3.5 (June 26) and 2.3.6 (today) releases. I also targeted bugs which were released in those milestones to the appropriate places. My next step is to remove the 3.0 series, as I don't believe this is necessary anymore. One other note: I've tentatively created a 2.3.7 milestone in LP, so we can start targeting client bugs which merge there for the next client release. If you have any questions, please let me know. Thanks, Kyle ___ 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 What are the thoughts on when a 2.3.7 release is going to happen? I'm specifically interested in getting the keystone v3 support [1] into a released version of the library. 9/4 and feature freeze seems like a decent target date. I can make that happen. I'll take a pass through the existing client reviews to see what's there, and roll another release which would include the keystone v3 work which is already merged. Thanks, Kyle [1] https://review.openstack.org/#/c/92390/ -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think we're at or near dependency freeze so wondering what the plan is for cutting the final release of python-neutronclient before Juno release candidates start building (which I think is too late for a dep update). Are there any Neutron FFEs that touch the client that people need to wait for? -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?
On Aug 22, 2014 12:48 AM, Steve Kowalik ste...@wedontsleep.org wrote: On 22/08/14 17:35, Chris Jones wrote: Hi When register-nodes blows up, is the error we get from Ironic sufficiently unique that we can just consume it and move on? You should get a clear error when attempting to add a port with a preexisting MAC. However, at this point, a new node has already been created (this won't fail since it includes no unique info). When catching the duplicate MAC error, you should delete the just-created node. I'm all for making the API more powerful wrt inspecting the current setup, but I also like idempotency :) If the master nodes list changes, because say you add a second NIC, and up the amount of RAM for a few of your nodes, we then want to update those details in the baremetal service, rather than skipping those nodes since they are already registered. If you want to update information about a node, you must have that nodes UUID, whether cached or retrieved on-demand. You can retrieve this by searching for a port with a known MAC to determine which node is associated with that port. You will have a problem updating the existing NIC(s) if you don't cache the UUID, as MAC address is currently the only other uniquely identifying data point for a node. -Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] List of granted FFEs
Michael Still wrote: I've built this handy dandy list of granted FFEs, because searching email to find out what is approved is horrible. It would be good if people with approved FFEs could check their thing is listed here: https://etherpad.openstack.org/p/juno-nova-approved-ffes It would also be great if the contents of that list matched the Launchpad milestone page we use to track progress on them: https://launchpad.net/nova/+milestone/juno-rc1 Cheers, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Ironic] Unique way to get a registered machine?
Woops, meant to respond to this in the email I just sent... On Aug 21, 2014 11:35 PM, Steve Kowalik ste...@wedontsleep.org wrote: For other drivers, we think that the pm_address for each machine will be unique. Would it be possible add some advice to that effect to Ironic's driver API? pm_address is cruft on the old nova API, and was replaced with driver_info in ironic. Node driver_info is presumably also unique, but the format varies between drivers; uniqueness is not enforced, nor is it searchable in the REST API. In some cases, there are half a dozen data points contained in driver_info (eg, for double bridged IPMI in the case of moonshot) which collectively inform the driver how to connect to and manage that node. -Devananda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Feature freeze + Juno-3 milestone candidates available
In that precise case, given how early it is in the freeze, I think giving a quick heads-up to the -i18n team/list should be enough :) Also /adding/ a string is not as disruptive to their work as modifying a potentially-already-translated one. Joe Cropper wrote: +1 to what Jay said. I’m not sure whether the string freeze applies to bugs, but the defect that Matt mentioned (for which I authored the fix) adds a string, albeit to fix a bug. Hoping it’s more desirable to have an untranslated correct message than a translated incorrect message. :-) - Joe On Sep 5, 2014, at 3:41 PM, Jay Bryant jsbry...@electronicjungle.net mailto:jsbry...@electronicjungle.net wrote: Matt, I don't think that is the right solution. If the string changes I think the only problem is it won't be translated if it is thrown. That is better than breaking the coding standard imho. Jay On Sep 5, 2014 3:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: On 9/5/2014 5:10 AM, Thierry Carrez wrote: Hi everyone, We just hit feature freeze[1], so please do not approve changes that add features or new configuration options unless those have been granted a feature freeze exception. This is also string freeze[2], so you should avoid changing translatable strings. If you have to modify a translatable string, you should give a heads-up to the I18N team. Finally, this is also DepFreeze[3], so you should avoid adding new dependencies (bumping oslo or openstack client libraries is OK until RC1). If you have a new dependency to add, raise a thread on openstack-dev about it. The juno-3 development milestone was tagged, it contains more than 135 features and 760 bugfixes added since the juno-2 milestone 6 weeks ago (not even counting the Oslo libraries in the mix). You can find the full list of new features and fixed bugs, as well as tarball downloads, at: https://launchpad.net/__keystone/juno/juno-3 https://launchpad.net/keystone/juno/juno-3 https://launchpad.net/glance/__juno/juno-3 https://launchpad.net/glance/juno/juno-3 https://launchpad.net/nova/__juno/juno-3 https://launchpad.net/nova/juno/juno-3 https://launchpad.net/horizon/__juno/juno-3 https://launchpad.net/horizon/juno/juno-3 https://launchpad.net/neutron/__juno/juno-3 https://launchpad.net/neutron/juno/juno-3 https://launchpad.net/cinder/__juno/juno-3 https://launchpad.net/cinder/juno/juno-3 https://launchpad.net/__ceilometer/juno/juno-3 https://launchpad.net/ceilometer/juno/juno-3 https://launchpad.net/heat/__juno/juno-3 https://launchpad.net/heat/juno/juno-3 https://launchpad.net/trove/__juno/juno-3 https://launchpad.net/trove/juno/juno-3 https://launchpad.net/sahara/__juno/juno-3 https://launchpad.net/sahara/juno/juno-3 Many thanks to all the PTLs and release management liaisons who made us reach this important milestone in the Juno development cycle. Thanks in particular to John Garbutt, who keeps on doing an amazing job at the impossible task of keeping the Nova ship straight in troubled waters while we head toward the Juno release port. Regards, [1] https://wiki.openstack.org/__wiki/FeatureFreeze https://wiki.openstack.org/wiki/FeatureFreeze [2] https://wiki.openstack.org/__wiki/StringFreeze https://wiki.openstack.org/wiki/StringFreeze [3] https://wiki.openstack.org/__wiki/DepFreeze https://wiki.openstack.org/wiki/DepFreeze I should probably know this, but at least I'm asking first. :) Here is an example of a new translatable user-facing error message [1]. From the StringFreeze wiki, I'm not sure if this is small or large. Would a compromise to get this in be to drop the _() so it's just a string and not a message? Maybe I should just shut-up and email the openstack-i18n mailing list [2]. [1] https://review.openstack.org/#__/c/118535/ https://review.openstack.org/#/c/118535/ [2] http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-i18n http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n -- Thanks, Matt Riedemann _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][Cinder] Coraid CI system
Mykola, thanks for update! Few additional notes on this. For now, we have to inject two patches to make it work. The first patch is a simple bugfix for the Coraid driver itself: https://review.openstack.org/#/c/119022/ The second one is for Tempest to allow specification of custom volume type keys that are required for the Coraid driver to operate properly: https://review.openstack.org/#/c/118619/ On Fri, Sep 5, 2014 at 6:09 PM, Mykola Grygoriev mgrygor...@mirantis.com wrote: Hi, My name is Mykola Grygoriev and I'm engineer who currently working on deploying 3d party CI for Сoraid Сinder driver. Following instructions on http://ci.openstack.org/third_party.html#requesting-a-service-account asking for adding gerrit CI account (coraid-ci) to the Voting Third-Party CI Gerrit group https://review.openstack.org/#/admin/groups/91,members. We have already added description of Coraid CI system to wiki page - https://wiki.openstack.org/wiki/ThirdPartySystems/Coraid_CI We used openstack-dev/sandbox project to test current CI infrastructure with OpenStack Gerrit system. Please find our history there. Please have a look to results of Coraid CI system. it currently takes updates from openstack/cinder project: http://38.111.159.9:8080/job/Coraid_CI/32/ http://38.111.159.9:8080/job/Coraid_CI/33/ Thank you in advance. -- Best regards, Mykola Grygoriev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] default allow security group
Hi, Monty, Thanks for bringing this topic up. I think the blueprint that Miguel mentioned will address the issue you're sufffering from, but maybe there are not many people interested in this feature, so unfortunately, the bp will not be landed in Juno release. But I will continue the bp when the Kilo dev cycle get started, since I believe this feature will benefit people like you. 2014-09-06 0:17 GMT+08:00 Dean Troyer dtro...@gmail.com: On Fri, Sep 5, 2014 at 10:27 AM, Monty Taylor mord...@inaugust.com wrote: I've decided that as I have problems with OpenStack while using it in the service of Infra, I'm going to just start spamming the list. User CLI/API feedback! neutron security-group-create default --allow-every-damn-thing You mean like this? https://review.openstack.org/#/c/119407/ dt *Disclaimer: For demonstration purposes on nova-network only; the views expressed here may not be those of the OpenStack Foundation, it's member companies or lackeys; in case of duplicates, ties will be awarded; your mileage may vary; allow 4 to 6 weeks for delivery; any resemblance to functional code, living or dead, is unintentional and purely coincidental; representations of this code may be freely reused without the express written consent of the Commissioner of the National Football League. -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][policy] Group-based Policy next steps
Good discussion. Based on this I think we should get started on the stackforge right away. Sumit - It would be great if you get started on the StackForge soon. We have a few changes that needs to be submitted and have been holding up. On Fri, Sep 5, 2014 at 8:08 AM, Mohammad Banikazemi m...@us.ibm.com wrote: I can only see the use of a separate project for Group Policy as a tactical and temporary solution. In my opinion, it does not make sense to have the Group Policy as a separate project outside Neutron (unless the new project is aiming to replace Neutron and I do not think anybody is suggesting that). In this regard, Group Policy is not similar to Advanced Services such as FW and LB. So, using StackForge to get things moving again is fine but let us keep in mind (and see if we can agree on) that we want to have the Group Policy abstractions as part of OpenStack Networking (when/if it proves to be a valuable extension to what we currently have). I do not want to see our decision to make things moving quickly right now prevent us from achieving that goal. That is why I think the other two approaches (from the little I know about the incubator option, and even littler I know about the feature branch option) may be better options in the long run. If I understand it correctly some members of the community are actively working on these options (that is, the incubator and the Neutron feature branch options) . In order to make a better judgement as to how to proceed, it would be very helpful if we get a bit more information on these two options and their status here on this mailing list. Mohammad [image: Inactive hide details for Kevin Benton ---09/05/2014 04:31:05 AM---Tl;dr - Neutron incubator is only a wiki page with many unce]Kevin Benton ---09/05/2014 04:31:05 AM---Tl;dr - Neutron incubator is only a wiki page with many uncertainties. Use StackForge to make progre From: Kevin Benton blak...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 09/05/2014 04:31 AM Subject: Re: [openstack-dev] [neutron][policy] Group-based Policy next steps -- Tl;dr - Neutron incubator is only a wiki page with many uncertainties. Use StackForge to make progress and re-evaluate when the incubator exists. I also agree that starting out in StackForge as a separate repo is a better first step. In addition to the uncertainty around packaging and other processes brought up by Mandeep, I really doubt the Neutron incubator is going to have the review velocity desired by the group policy contributors. I believe this will be the case based on the Neutron incubator patch approval policy in conjunction with the nature of the projects it will attract. Due to the requirement for two core +2's in the Neutron incubator, moving group policy there is hardly going to do anything to reduce the load on the Neutron cores who are in a similar overloaded position as the Nova cores.[1] Consequently, I wouldn't be surprised if patches to the Neutron incubator receive even less core attention than the main repo simply because their location outside of openstack/neutron will be a good reason to treat them with a lower priority. If you combine that with the fact that the incubator is designed to house all of the proposed experimental features to Neutron, there will be a very high volume of patches constantly being proposed to add new features, make changes to features, and maybe even fix bugs in those features. This new demand for reviewers will not be met by the existing core reviewers because they will be busy with refactoring, fixing, and enhancing the core Neutron code. Even ignoring the review velocity issues, I see very little benefit to GBP starting inside of the Neutron incubator. It doesn't guarantee any packaging with Neutron and Neutron code cannot reference any incubator code. It's effectively a separate repo without the advantage of being able to commit code quickly. There is one potential downside to not immediately using the Neutron incubator. If the Neutron cores decide that all features must live in the incubator for at least 2 cycles regardless of quality or usage in deployments, starting outside in a StackForge project would delay the start of the timer until GBP makes it into the incubator. However, this can be considered once the incubator actually exists and starts accepting submissions. In summary, I think GBP should move to a StackForge project as soon as possible so development can progress. A transition to the Neutron incubator can be evaluated once it actually becomes something more than a wiki page. 1. *http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html* http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html -- Kevin Benton On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami
Re: [openstack-dev] [Nova] List of granted FFEs
Hi Michael, I see that ephemeral storage encryption is not on the list of granted FFEs but I sent an email to John Garbutt yesterday listing the 3 core sponsors for the FFE. Why was the FFE denied? Dan From: Michael Still mi...@stillhq.com Sent: Friday, September 5, 2014 5:23 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Nova] List of granted FFEs Hi, I've built this handy dandy list of granted FFEs, because searching email to find out what is approved is horrible. It would be good if people with approved FFEs could check their thing is listed here: https://etherpad.openstack.org/p/juno-nova-approved-ffes Michael -- Rackspace Australia ___ 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] Feature freeze + Juno-3 milestone candidates available
Thanks, ttx. If there’s anyone that can do a final review on https://review.openstack.org/#/c/118535/ — would be much appreciated and I’m happy to llet the i18n folks know once it merges. - Joe On Sep 6, 2014, at 9:36 AM, Thierry Carrez thie...@openstack.org wrote: In that precise case, given how early it is in the freeze, I think giving a quick heads-up to the -i18n team/list should be enough :) Also /adding/ a string is not as disruptive to their work as modifying a potentially-already-translated one. Joe Cropper wrote: +1 to what Jay said. I’m not sure whether the string freeze applies to bugs, but the defect that Matt mentioned (for which I authored the fix) adds a string, albeit to fix a bug. Hoping it’s more desirable to have an untranslated correct message than a translated incorrect message. :-) - Joe On Sep 5, 2014, at 3:41 PM, Jay Bryant jsbry...@electronicjungle.net mailto:jsbry...@electronicjungle.net wrote: Matt, I don't think that is the right solution. If the string changes I think the only problem is it won't be translated if it is thrown. That is better than breaking the coding standard imho. Jay On Sep 5, 2014 3:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: On 9/5/2014 5:10 AM, Thierry Carrez wrote: Hi everyone, We just hit feature freeze[1], so please do not approve changes that add features or new configuration options unless those have been granted a feature freeze exception. This is also string freeze[2], so you should avoid changing translatable strings. If you have to modify a translatable string, you should give a heads-up to the I18N team. Finally, this is also DepFreeze[3], so you should avoid adding new dependencies (bumping oslo or openstack client libraries is OK until RC1). If you have a new dependency to add, raise a thread on openstack-dev about it. The juno-3 development milestone was tagged, it contains more than 135 features and 760 bugfixes added since the juno-2 milestone 6 weeks ago (not even counting the Oslo libraries in the mix). You can find the full list of new features and fixed bugs, as well as tarball downloads, at: https://launchpad.net/__keystone/juno/juno-3 https://launchpad.net/keystone/juno/juno-3 https://launchpad.net/glance/__juno/juno-3 https://launchpad.net/glance/juno/juno-3 https://launchpad.net/nova/__juno/juno-3 https://launchpad.net/nova/juno/juno-3 https://launchpad.net/horizon/__juno/juno-3 https://launchpad.net/horizon/juno/juno-3 https://launchpad.net/neutron/__juno/juno-3 https://launchpad.net/neutron/juno/juno-3 https://launchpad.net/cinder/__juno/juno-3 https://launchpad.net/cinder/juno/juno-3 https://launchpad.net/__ceilometer/juno/juno-3 https://launchpad.net/ceilometer/juno/juno-3 https://launchpad.net/heat/__juno/juno-3 https://launchpad.net/heat/juno/juno-3 https://launchpad.net/trove/__juno/juno-3 https://launchpad.net/trove/juno/juno-3 https://launchpad.net/sahara/__juno/juno-3 https://launchpad.net/sahara/juno/juno-3 Many thanks to all the PTLs and release management liaisons who made us reach this important milestone in the Juno development cycle. Thanks in particular to John Garbutt, who keeps on doing an amazing job at the impossible task of keeping the Nova ship straight in troubled waters while we head toward the Juno release port. Regards, [1] https://wiki.openstack.org/__wiki/FeatureFreeze https://wiki.openstack.org/wiki/FeatureFreeze [2] https://wiki.openstack.org/__wiki/StringFreeze https://wiki.openstack.org/wiki/StringFreeze [3] https://wiki.openstack.org/__wiki/DepFreeze https://wiki.openstack.org/wiki/DepFreeze I should probably know this, but at least I'm asking first. :) Here is an example of a new translatable user-facing error message [1]. From the StringFreeze wiki, I'm not sure if this is small or large. Would a compromise to get this in be to drop the _() so it's just a string and not a message? Maybe I should just shut-up and email the openstack-i18n mailing list [2]. [1] https://review.openstack.org/#__/c/118535/ https://review.openstack.org/#/c/118535/ [2] http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-i18n http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n -- Thanks, Matt Riedemann _ OpenStack-dev mailing list
Re: [openstack-dev] [nova][neutron] default allow security group
While it's good that somebody is addressing this specific issue, perhaps punctual solutions - eg: hey I have a patch for that, are not addressing the general issues, which is that Neutron has very granular primitives that force users to do multiple API requests for operations they regard as atomic. What we need, in my opinion, is a set of macros which will provide some basic orchestration over the primitives exposed by the Neutron API. For instance another macro which has been requested several times is the ability to create a port and associate it with a floating IP (well actually the request I think is to boot a server with a public IP). I think such macros are better placed on the server side rather than the CLI, mostly because not all API clients use the CLI and failure management is easier if done on th server side. On the other hand I see those macros better implemented as by addition on top of the current API rather than by modifying resources and actions available in the current API. I think it will be a good idea to compile a list of all the macros we want to implement for Kilo, and then implement all of them within this mini-framework, rather than as many disjoint blueprints. On another note, I think the teams working on the group policy API have asserted several times that the new abstractions proposed will automatically simplify the user interface. Everybody will be super happy when that happens, but in the meanwhile we should provide solutions targeting the current Neutron API. Salvatore On 6 September 2014 18:00, Lingxian Kong anlin.k...@gmail.com wrote: Hi, Monty, Thanks for bringing this topic up. I think the blueprint that Miguel mentioned will address the issue you're sufffering from, but maybe there are not many people interested in this feature, so unfortunately, the bp will not be landed in Juno release. But I will continue the bp when the Kilo dev cycle get started, since I believe this feature will benefit people like you. 2014-09-06 0:17 GMT+08:00 Dean Troyer dtro...@gmail.com: On Fri, Sep 5, 2014 at 10:27 AM, Monty Taylor mord...@inaugust.com wrote: I've decided that as I have problems with OpenStack while using it in the service of Infra, I'm going to just start spamming the list. User CLI/API feedback! neutron security-group-create default --allow-every-damn-thing You mean like this? https://review.openstack.org/#/c/119407/ dt *Disclaimer: For demonstration purposes on nova-network only; the views expressed here may not be those of the OpenStack Foundation, it's member companies or lackeys; in case of duplicates, ties will be awarded; your mileage may vary; allow 4 to 6 weeks for delivery; any resemblance to functional code, living or dead, is unintentional and purely coincidental; representations of this code may be freely reused without the express written consent of the Commissioner of the National Football League. -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards! --- Lingxian Kong ___ 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] Feature freeze + Juno-3 milestone candidates available
Thierry, Thanks! I agree. Jay On Sep 6, 2014 9:37 AM, Thierry Carrez thie...@openstack.org wrote: In that precise case, given how early it is in the freeze, I think giving a quick heads-up to the -i18n team/list should be enough :) Also /adding/ a string is not as disruptive to their work as modifying a potentially-already-translated one. Joe Cropper wrote: +1 to what Jay said. I’m not sure whether the string freeze applies to bugs, but the defect that Matt mentioned (for which I authored the fix) adds a string, albeit to fix a bug. Hoping it’s more desirable to have an untranslated correct message than a translated incorrect message. :-) - Joe On Sep 5, 2014, at 3:41 PM, Jay Bryant jsbry...@electronicjungle.net mailto:jsbry...@electronicjungle.net wrote: Matt, I don't think that is the right solution. If the string changes I think the only problem is it won't be translated if it is thrown. That is better than breaking the coding standard imho. Jay On Sep 5, 2014 3:30 PM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: On 9/5/2014 5:10 AM, Thierry Carrez wrote: Hi everyone, We just hit feature freeze[1], so please do not approve changes that add features or new configuration options unless those have been granted a feature freeze exception. This is also string freeze[2], so you should avoid changing translatable strings. If you have to modify a translatable string, you should give a heads-up to the I18N team. Finally, this is also DepFreeze[3], so you should avoid adding new dependencies (bumping oslo or openstack client libraries is OK until RC1). If you have a new dependency to add, raise a thread on openstack-dev about it. The juno-3 development milestone was tagged, it contains more than 135 features and 760 bugfixes added since the juno-2 milestone 6 weeks ago (not even counting the Oslo libraries in the mix). You can find the full list of new features and fixed bugs, as well as tarball downloads, at: https://launchpad.net/__keystone/juno/juno-3 https://launchpad.net/keystone/juno/juno-3 https://launchpad.net/glance/__juno/juno-3 https://launchpad.net/glance/juno/juno-3 https://launchpad.net/nova/__juno/juno-3 https://launchpad.net/nova/juno/juno-3 https://launchpad.net/horizon/__juno/juno-3 https://launchpad.net/horizon/juno/juno-3 https://launchpad.net/neutron/__juno/juno-3 https://launchpad.net/neutron/juno/juno-3 https://launchpad.net/cinder/__juno/juno-3 https://launchpad.net/cinder/juno/juno-3 https://launchpad.net/__ceilometer/juno/juno-3 https://launchpad.net/ceilometer/juno/juno-3 https://launchpad.net/heat/__juno/juno-3 https://launchpad.net/heat/juno/juno-3 https://launchpad.net/trove/__juno/juno-3 https://launchpad.net/trove/juno/juno-3 https://launchpad.net/sahara/__juno/juno-3 https://launchpad.net/sahara/juno/juno-3 Many thanks to all the PTLs and release management liaisons who made us reach this important milestone in the Juno development cycle. Thanks in particular to John Garbutt, who keeps on doing an amazing job at the impossible task of keeping the Nova ship straight in troubled waters while we head toward the Juno release port. Regards, [1] https://wiki.openstack.org/__wiki/FeatureFreeze https://wiki.openstack.org/wiki/FeatureFreeze [2] https://wiki.openstack.org/__wiki/StringFreeze https://wiki.openstack.org/wiki/StringFreeze [3] https://wiki.openstack.org/__wiki/DepFreeze https://wiki.openstack.org/wiki/DepFreeze I should probably know this, but at least I'm asking first. :) Here is an example of a new translatable user-facing error message [1]. From the StringFreeze wiki, I'm not sure if this is small or large. Would a compromise to get this in be to drop the _() so it's just a string and not a message? Maybe I should just shut-up and email the openstack-i18n mailing list [2]. [1] https://review.openstack.org/#__/c/118535/ https://review.openstack.org/#/c/118535/ [2] http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-i18n http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n -- Thanks, Matt Riedemann _ OpenStack-dev mailing list
Re: [openstack-dev] [Nova] List of granted FFEs
That's something I'll work on today. Michael On Sun, Sep 7, 2014 at 12:32 AM, Thierry Carrez thie...@openstack.org wrote: Michael Still wrote: I've built this handy dandy list of granted FFEs, because searching email to find out what is approved is horrible. It would be good if people with approved FFEs could check their thing is listed here: https://etherpad.openstack.org/p/juno-nova-approved-ffes It would also be great if the contents of that list matched the Launchpad milestone page we use to track progress on them: https://launchpad.net/nova/+milestone/juno-rc1 Cheers, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] List of granted FFEs
The process for requesting a FFE is to email openstack-dev and for the core sponsors to signup there. I've obviously missed the email thread... What is the subject line? Michael On Sun, Sep 7, 2014 at 3:03 AM, Genin, Daniel I. daniel.ge...@jhuapl.edu wrote: Hi Michael, I see that ephemeral storage encryption is not on the list of granted FFEs but I sent an email to John Garbutt yesterday listing the 3 core sponsors for the FFE. Why was the FFE denied? Dan From: Michael Still mi...@stillhq.com Sent: Friday, September 5, 2014 5:23 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [Nova] List of granted FFEs Hi, I've built this handy dandy list of granted FFEs, because searching email to find out what is approved is horrible. It would be good if people with approved FFEs could check their thing is listed here: https://etherpad.openstack.org/p/juno-nova-approved-ffes Michael -- Rackspace Australia ___ 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 -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Infra][Cinder] Coraid CI system
Not sure if https://review.openstack.org/#/c/118619/ is necessary. See if this solves your issue [1], simple update to your devstack localrc/local.conf to create the type keys. It is merged to master. Otherwise, consider creating a cinder backend file[1]. Ramy [1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/043274.html [2] https://github.com/openstack-dev/devstack/tree/master/lib/cinder_backends From: Roman Bogorodskiy [mailto:rbogorods...@mirantis.com] Sent: Saturday, September 06, 2014 8:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Infra][Cinder] Coraid CI system Mykola, thanks for update! Few additional notes on this. For now, we have to inject two patches to make it work. The first patch is a simple bugfix for the Coraid driver itself: https://review.openstack.org/#/c/119022/ The second one is for Tempest to allow specification of custom volume type keys that are required for the Coraid driver to operate properly: https://review.openstack.org/#/c/118619/ On Fri, Sep 5, 2014 at 6:09 PM, Mykola Grygoriev mgrygor...@mirantis.commailto:mgrygor...@mirantis.com wrote: Hi, My name is Mykola Grygoriev and I'm engineer who currently working on deploying 3d party CI for Сoraid Сinder driver. Following instructions on http://ci.openstack.org/third_party.html#requesting-a-service-account asking for adding gerrit CI account (coraid-ci) to the Voting Third-Party CI Gerrit grouphttps://review.openstack.org/#/admin/groups/91,members. We have already added description of Coraid CI system to wiki page - https://wiki.openstack.org/wiki/ThirdPartySystems/Coraid_CI We used openstack-dev/sandbox project to test current CI infrastructure with OpenStack Gerrit system. Please find our history there. Please have a look to results of Coraid CI system. it currently takes updates from openstack/cinder project: http://38.111.159.9:8080/job/Coraid_CI/32/ http://38.111.159.9:8080/job/Coraid_CI/33/ Thank you in advance. -- Best regards, Mykola Grygoriev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] how to provide tests environments for python things that require C extensions
There was a review once that tried to move the evzookeeper to using kazoo, perhaps that can get reprioritzed?? https://review.openstack.org/#/c/28951/ Sent from my really tiny device... On Sep 5, 2014, at 6:36 AM, Sean Dague s...@dague.net wrote: While reviewing this zookeeper service group fix in Nova - https://review.openstack.org/#/c/102639/ it was exposed that the zookeeper tests aren't running in infra. The crux of the issue is that zookeeper python modules are C extensions. So you have to either install from packages (which we don't do in unit tests) or install from pip, which means forcing zookeeper dev packages locally. Realistically this is the same issue we end up with for mysql and pg, but given their wider usage we just forced that pain on developers. But it seems like a bad stand off between testing upstream and testing normal path locally. Big picture it would be nice to not require a ton of dev libraries locally for optional components, but still test them upstream. So that in the base case I'm not running zookeeper locally, but if it fails upstream because I broke something in zookeeper, it's easy enough to spin up that dev env that has it. Which feels like we need some decoupling on our requirements vs. tox targets to get there. CC to Monty and Clark as our super awesome tox hackers to help figure out if there is a path forward here that makes sense. -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] [neutron] python-neutronclient, launchpad, and milestones
On Sat, Sep 6, 2014 at 8:43 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 8/29/2014 1:53 PM, Kyle Mestery wrote: On Fri, Aug 29, 2014 at 1:40 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 7/29/2014 4:12 PM, Kyle Mestery wrote: On Tue, Jul 29, 2014 at 3:50 PM, Nader Lahouti nader.laho...@gmail.com wrote: Hi Kyle, I have a BP listed in https://blueprints.launchpad.net/python-neutronclient and looks like it is targeted for 3.0 (it is needed fro juno-3) The code is ready and in the review. Can it be a included for 2.3.7 release? Yes, you can target it there. We'll see about including it in that release, pending review. Thanks! Kyle Thanks, Nader. On Tue, Jul 29, 2014 at 12:28 PM, Kyle Mestery mest...@mestery.com wrote: All: I spent some time today cleaning up python-neutronclient in LP. I created a 2.3 series, and created milestones for the 2.3.5 (June 26) and 2.3.6 (today) releases. I also targeted bugs which were released in those milestones to the appropriate places. My next step is to remove the 3.0 series, as I don't believe this is necessary anymore. One other note: I've tentatively created a 2.3.7 milestone in LP, so we can start targeting client bugs which merge there for the next client release. If you have any questions, please let me know. Thanks, Kyle ___ 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 What are the thoughts on when a 2.3.7 release is going to happen? I'm specifically interested in getting the keystone v3 support [1] into a released version of the library. 9/4 and feature freeze seems like a decent target date. I can make that happen. I'll take a pass through the existing client reviews to see what's there, and roll another release which would include the keystone v3 work which is already merged. Thanks, Kyle [1] https://review.openstack.org/#/c/92390/ -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I think we're at or near dependency freeze so wondering what the plan is for cutting the final release of python-neutronclient before Juno release candidates start building (which I think is too late for a dep update). Are there any Neutron FFEs that touch the client that people need to wait for? There are none at this point. I'll cut a client release either tomorrow (Sunday, 9-7) or Monday morning early Central time. Thanks, Kyle -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] Question about where to render haproxy configurations
Hi Steven, Thanks for taking the time to lay out the components clearly. I think we are pretty much on the same page ☺ Driver vs, Driver-less I strongly believe that REST is a cleaner interface/integration point – but if even Brandon believes that drivers are the better approach (having suffered through the LBaaS v1 driver world which is not an advertisement for this approach) I will concede on that front. Let’s hope nobody makes an asynchronous driver and/or writes straight to the DB ☺ That said I still believe that adding the driver interface now will lead to some more complexity and I am not sure we will get the interface right in the first version: so let’s agree to develop with a driver in mind but don’t allow third party drivers before the interface has matured. I think that is something we already sort of agreed to, but I just want to make that explicit. Multiple drivers/version for the same Controller This is a really contentious point for us at HP: If we allow say drivers or even different versions of the same driver, e.g. A, B, C to run in parallel, testing will involve to test all the possible (version) combination to avoid potential side effects. That can get extensive really quick. So HP is proposing, given that we will have 100s of controllers any way, to limit the number of drivers per controller to 1 to aide testing. We can revisit that at a future time when our testing capabilities have improved but for now I believe we should choose that to speed things up. I personally don’t see the need for multiple drivers per controller – in an operator grade environment we likely don’t need to “save” on the number of controllers ;-) The only reason we might need two drivers on the same controller is if an Amphora for whatever reason needs to be talked to by two drivers. (e.g. you install nginx and haproxy and have a driver for each). This use case scares me so we should not allow it. We also see some operational simplifications from supporting only one driver per controller: If we have an update for driver A we don’t need to touch any controller running Driver B. Furthermore we can keep the old version running but make sure no new Amphora gets scheduled there to let it wind down with attrition and then stop that controller when it doesn’t have any more Amphora to serve. Lastly, I interpreted the word “VM driver” in the spec along the lines what we have in libra: A driver interface on the Amphora agent that abstracts starting/stopping the haproxy if we end up on some different and abstracts writing the haproxy file. But that is for the agent on the Amphora. I am sorry I got confused that way when reading the 0.5 spec and I am therefore happy we can have that discussion to make things more clear. German From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Friday, September 05, 2014 6:26 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Octavia] Question about where to render haproxy configurations Hi German, Responses in-line: On Fri, Sep 5, 2014 at 2:31 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi Stephen, I think this is a good discussion to have and will make it more clear why we chose a specific design. I also believe by having this discussion we will make the design stronger. I am still a little bit confused what the driver/controller/amphora agent roles are. In my driver-less design we don’t have to worry about the driver which most likely in haproxy’s case will be split to some degree between controller and amphora device. Yep, I agree that a good technical debate like this can help both to get many people's points of view and can help determine the technical merit of one design over another. I appreciate your vigorous participation in this process. :) So, the purpose of the controller / driver / amphora and the responsibilities they have are somewhat laid out in the Octavia v0.5 component design document, but it's also possible that there weren't enough specifics in that document to answer the concerns brought up in this thread. So, to that end in my mind, I see things like the following: The controller: * Is responsible for concerns of the Octavia system as a whole, including the intelligence around interfacing with the networking, virtualization, and other layers necessary to set up the amphorae on the network and getting them configured. * Will rarely, if ever, talk directly to the end-systems or -services (like Neutron, Nova, etc.). Instead it goes through a clean driver interface for each of these. * The controller has direct access to the database where state is stored. * Must load at least one driver, may load several drivers and choose between them based on configuration logic (ex. flavors, config file, etc.) The driver: * Handles all communication to or from the amphorae * Is loaded by the controller (ie. its interface
