Re: [openstack-dev] [Neutron] Service VM: irc discussion?
https://wiki.openstack.org/wiki/Meetings Now we're scheduling. On Mon, Feb 10, 2014 at 07:43:09AM +, Wangyang (Alex) alex.wangy...@huawei.com wrote: Hi everyone, Is there anyone can kindly tell me how to join your conference? ^^ -?始?原件- ??件人: balaj...@freescale.com [mailto:balaj...@freescale.com] ??送?奔?: 2014年2月10日 15:11 收件人: Isaku Yamahata; OpenStack Development Mailing List (not for usage questions) 主??: Re: [openstack-dev] [Neutron] Service VM: irc discussion? Hi Isaku Yamahata, We are at UTC+5.30.[IST] Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 12:36 PM To: P Balaji-B37839; OpenStack Development Mailing List (not for usage questions) Cc: Isaku Yamahata Subject: Re: [openstack-dev] [Neutron] Service VM: irc discussion? What's your timezone? 18.00UTC doesn't work for me because my timezone is UTC+9 and it's 3:00AM. thanks, On Mon, Feb 10, 2014 at 06:43:05AM +, balaj...@freescale.com balaj...@freescale.com wrote: Hi Isaku Yamahata, Is it possible to move the below time slot a little earlier like 18.00UTC? Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 11:42 AM To: openstack-dev@lists.openstack.org Cc: isaku.yamah...@gmail.com Subject: [Neutron] Service VM: irc discussion? As the first patch for service vm framework is ready for review[1][2], it would be a good idea to have IRC meeting. Anyone interested in it? How about schedule? Schedule candidate Monday 22:00UTC-, 23:00UTC- Tuesday 22:00UTC-, 23:00UTC- (Although the slot of servanced service vm[3] can be resuled, it doesn't work for me because my timezone is UTC+9.) topics for - discussion/review on the patch - next steps - other open issues? [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms [2] https://review.openstack.org/#/c/56892/ [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this week
Hi, I saw that one of the days there will be talk about Gantt. Would it be possible that people not at the local meet up can join this discussion? Thanks Gary From: Dugger, Donald D donald.d.dug...@intel.commailto:donald.d.dug...@intel.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, February 10, 2014 6:54 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this week Let’s cancel the meeting this week, some of us (me for sure) will be tied up at the Icehouse mid-cycle meetup. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Openstack] [KEYSTONE] Keystone federation
Dear all, I would provide both PaaS and IaaS (Openstack) services, with two keystone services: one for the PaaS (Keystone PaaS) and the other one for the IaaS (Keystone IaaS). In particular, I would Openstack system appear as a PaaS service towards PaaS's users, so that an user that authenticates against Keystone PaaS can use Openstack services too. So, I was thinking of using Keystones federation, so that: 1- PaaS's user authenticates against Keystone PaaS and receives a scoped token. 2- PaaS's user invokes openstack services by using the scoped token received from Keystone PaaS; 3- Openstack services validate the token against Keystone IaaS; 4- Keystone IaaS validate against Keystone PaaS Do you think this scenario is possible? I would be appreciate any further solutions you think I might implement. Best regards, Giuseppe ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Service VM: irc discussion?
Many thanks! : ) -Original Message- From: Isaku Yamahata [mailto:isaku.yamah...@gmail.com] Sent: Monday, February 10, 2014 5:47 PM To: Wangyang (Alex) Cc: OpenStack Development Mailing List (not for usage questions); Isaku Yamahata Subject: Re: [openstack-dev] [Neutron] Service VM: irc discussion? https://wiki.openstack.org/wiki/Meetings Now we're scheduling. On Mon, Feb 10, 2014 at 07:43:09AM +, Wangyang (Alex) alex.wangy...@huawei.com wrote: Hi everyone, Is there anyone can kindly tell me how to join your conference? ^^ -?始?原件- ??件人: balaj...@freescale.com [mailto:balaj...@freescale.com] ??送?奔?: 2014年2月10日 15:11 收件人: Isaku Yamahata; OpenStack Development Mailing List (not for usage questions) 主??: Re: [openstack-dev] [Neutron] Service VM: irc discussion? Hi Isaku Yamahata, We are at UTC+5.30.[IST] Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 12:36 PM To: P Balaji-B37839; OpenStack Development Mailing List (not for usage questions) Cc: Isaku Yamahata Subject: Re: [openstack-dev] [Neutron] Service VM: irc discussion? What's your timezone? 18.00UTC doesn't work for me because my timezone is UTC+9 and it's 3:00AM. thanks, On Mon, Feb 10, 2014 at 06:43:05AM +, balaj...@freescale.com balaj...@freescale.com wrote: Hi Isaku Yamahata, Is it possible to move the below time slot a little earlier like 18.00UTC? Regards, Balaji.P -Original Message- From: i y [mailto:yamahat...@gmail.com] On Behalf Of Isaku Yamahata Sent: Monday, February 10, 2014 11:42 AM To: openstack-dev@lists.openstack.org Cc: isaku.yamah...@gmail.com Subject: [Neutron] Service VM: irc discussion? As the first patch for service vm framework is ready for review[1][2], it would be a good idea to have IRC meeting. Anyone interested in it? How about schedule? Schedule candidate Monday 22:00UTC-, 23:00UTC- Tuesday 22:00UTC-, 23:00UTC- (Although the slot of servanced service vm[3] can be resuled, it doesn't work for me because my timezone is UTC+9.) topics for - discussion/review on the patch - next steps - other open issues? [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-v ms [2] https://review.openstack.org/#/c/56892/ [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] delayed delete and user credentials
Hi Pete, See the comments in patch set 5 for scrubber.py and also this documentation: https://review.openstack.org/#/c/59471/ -Stuart Message: 2 Date: Thu, 6 Feb 2014 11:56:28 -0700 From: Pete Zaitcev zait...@redhat.com To: OpenStack Dev OpenStack-dev@lists.openstack.org Subject: [openstack-dev] [Glance] delayed delete and user credentials Message-ID: 20140206115628.345bf...@guren.zaitcev.lan Content-Type: text/plain; charset=US-ASCII Hi, guys: I looked briefly at a bug/fix, which looks exceedingly strange to me: https://review.openstack.org/59689 As much as I can tell, the problem (lp:1238604) is that pending delete fails because by the time the delete actually occurs, Glance API does not have proper permissions to talk to Glance Registry. So far so good, but the solution that we accepted is to forward the user credentials to Registry... but only if configured to do so. Does it make any sense to anyone? Why configure something that must always work? How can sysadmin select the correct value? -- Pete ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Maintaining support for the Tail-f NCS mech driver in Icehouse
I think testing with sandbox repo is really useful during setting up third party CI. Not so many people know sandbox repo. When neutron folks were setting up third party CI, we created test reviews in openstack/neutron, but if we knew it it would be great. It is worth documented in Third Party Testing web page [1]. I will add it if nobody adds it. [1] http://ci.openstack.org/third_party.html Akihiro (2014/02/10 12:13), Anita Kuno wrote: On 02/06/2014 09:52 AM, Luke Gorrie wrote: Howdy! My name is Luke and I'm helping my friends at Tail-f Systems to support Neutron with their NCS [1] product. This went really smoothly for us on the Havana cycle, but lately we're having a harder time with Icehouse. In particular, our attempt to fulfill the 3rd party testing requirements has caused a lot of frustration for the #openstack-infra team around New Year. So I'm writing now to look for a good solution. Our goal for Icehouse is to keep our mechanism driver officially supported. The code already works, and has unit tests to keep it working. The risk we want to avoid is going on the dreaded deprecated list for some other reason, which would confuse our customers. For background, our mechanism driver is about 150 lines of code. It translates each network/port/subnet API call into a REST/JSON notification to an external system. That external system returns HTTP 200 OK. That's about all. It's a pretty trivial program. In December I sat down with Tobbe Tornqvist and we tried to setup Jenkins 3rd party testing. We created a Vagrantfile that spins up an Ubuntu VM, installs Neutron and NCS, and performs integration tests with them connected together. We hooked this into Jenkins with a service account. This went fine to start with, but after Christmas our tests started failing due to random setup issues with 'tox', and the script started making -1 votes. Those -1's created major headaches for the infrastructure team and others upstream, I am sorry to say, and ended up requiring a messy process of manual cleanup, and a public flogging for us on IRC. Bad feeling all around ... The part to keep in mind is that random issues crop up all the time. For us in -infra they are a weekly event, and some weeks they are a daily event. The part that was the most difficult was the lack of responsiveness to our efforts to communicate, to get an acknowledgement from the maintainers that this account was experiencing some issues. Then to get the issues addressed. In the end we failed and had to resort to revoking verify voting permissions for this account. It has become evident through an IRC conversation with Tobbe Tornqvist [0] that the human resources required to stay available to maintain this testing system is an issue. While understanding of the need of different sized companies to make decisions to provide value for their customers, in -infra, we can not lose sight of the fact that our customers are our developers and we need to be responsive to their requirements. We are moving to be able to merge 200 patches a day with our system, by making a commitment to that rate of development as our target, we have to ensure any dependencies for testing also are able to move at a similar pace or at least be responsive to ours. Third-party CI [1] service accounts can still place comments on open reviews even if they lack the ability to set a verify vote (-1/+1), and this can be used to show whether the backend is reliably representing the changes it tests in an effort to build community trust in its results. Your account, Tail-f, can vote on our sandbox repo [2] as a way of testing voting for the system. Thank you, Anita. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2014-01-10.log timestamp ~ 2014-01-10T14:48:01 [1] https://review.openstack.org/#/admin/groups/270,members [2] http://git.openstack.org/cgit/openstack-dev/sandbox/ And that's where we are today. Now, reviewing the situation, I would love to find a solution that doesn't make us deprecated _and_ doesn't require us to be so deeply hooked into the OpenStack Jenkins infrastructure. Could we, for example, write an accurate emulator for the external system so that the MD code can be tested on OpenStack's own servers? That would suit us very well. It seems like a reasonable request to make given the simplicity of our driver code. Hoping for a simple solution... Cheers, -Luke friends at Tail-f [1] http://blog.ipspace.net/2013/05/tail-f-network-control-system-first.html ___ 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] [Ceilometer] Policy Issue
On Mon, Feb 10 2014, ZhiQiang Fan wrote: So, is this loose policy limit designed purposely, or it just a simple implementation for policy? It's just nobody stepped up to implement a more complete one, indeed. So, is there any opportunity to implement more strict policy check, for i.e. a normal user can read resources created by other users (to be stricter, may disable this too), but read+write for his own? I'd like to get some help or advise before create a blueprint Yep, go ahead and create a blueprint. :) If you need help, just ask on this list or on IRC. -- Julien Danjou -- Free Software hacker - independent consultant -- http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] several oslo library repositories have moved
Doug Hellmann wrote: The Oslo program has adopted cliff, pycadf, stevedore, and taskflow, promoting them from stackforge, so we can establish symmetric gating with the rest of OpenStack. In order to do that, the git repositories were moved from stackforge/* to openstack/* Doug, If you adopted those projects you should also push the corresponding change to the governance repo (projects.yaml). All projects under openstack*/ must be accounted for. Thanks, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Port binding information, transactions, and concurrency
Hi, one other comment inline : On Wed, Feb 5, 2014 at 5:01 PM, Robert Kukura rkuk...@redhat.com wrote: On 02/05/2014 09:10 AM, Henry Gessau wrote: Bob, this is fantastic, I really appreciate all the detail. A couple of questions ... On Wed, Feb 05, at 2:16 am, Robert Kukura rkuk...@redhat.com wrote: A couple of interrelated issues with the ML2 plugin's port binding have been discussed over the past several months in the weekly ML2 meetings. These effect drivers being implemented for icehouse, and therefore need to be addressed in icehouse: * MechanismDrivers need detailed information about all binding changes, including unbinding on port deletion (https://bugs.launchpad.net/neutron/+bug/1276395) * MechanismDrivers' bind_port() methods are currently called inside transactions, but in some cases need to make remote calls to controllers or devices (https://bugs.launchpad.net/neutron/+bug/1276391) * Semantics of concurrent port binding need to be defined if binding is moved outside the triggering transaction. I've taken the action of writing up a unified proposal for resolving these issues, which follows... 1) An original_bound_segment property will be added to PortContext. When the MechanismDriver update_port_precommit() and update_port_postcommit() methods are called and a binding previously existed (whether its being torn down or not), this property will provide access to the network segment used by the old binding. In these same cases, the portbinding extension attributes (such as binding:vif_type) for the old binding will be available via the PortContext.original property. It may be helpful to also add bound_driver and original_bound_driver properties to PortContext that behave similarly to bound_segment and original_bound_segment. 2) The MechanismDriver.bind_port() method will no longer be called from within a transaction. This will allow drivers to make remote calls on controllers or devices from within this method without holding a DB transaction open during those calls. Drivers can manage their own transactions within bind_port() if needed, but need to be aware that these are independent from the transaction that triggered binding, and concurrent changes to the port could be occurring. 3) Binding will only occur after the transaction that triggers it has been completely processed and committed. That initial transaction will unbind the port if necessary. Four cases for the initial transaction are possible: 3a) In a port create operation, whether the binding:host_id is supplied or not, all drivers' port_create_precommit() methods will be called, the initial transaction will be committed, and all drivers' port_create_postcommit() methods will be called. The drivers will see this as creation of a new unbound port, with PortContext properties as shown. If a value for binding:host_id was supplied, binding will occur afterwards as described in 4 below. PortContext.original: None PortContext.original_bound_segment: None PortContext.original_bound_driver: None PortContext.current['binding:host_id']: supplied value or None PortContext.current['binding:vif_type']: 'unbound' PortContext.bound_segment: None PortContext.bound_driver: None 3b) Similarly, in a port update operation on a previously unbound port, all drivers' port_update_precommit() and port_update_postcommit() methods will be called, with PortContext properies as shown. If a value for binding:host_id was supplied, binding will occur afterwards as described in 4 below. PortContext.original['binding:host_id']: previous value or None PortContext.original['binding:vif_type']: 'unbound' or 'binding_failed' PortContext.original_bound_segment: None PortContext.original_bound_driver: None PortContext.current['binding:host_id']: current value or None PortContext.current['binding:vif_type']: 'unbound' PortContext.bound_segment: None PortContext.bound_driver: None 3c) In a port update operation on a previously bound port that does not trigger unbinding or rebinding, all drivers' update_port_precommit() and update_port_postcommit() methods will be called with PortContext properties reflecting unchanged binding states as shown. PortContext.original['binding:host_id']: previous value PortContext.original['binding:vif_type']: previous value PortContext.original_bound_segment: previous value PortContext.original_bound_driver: previous value PortContext.current['binding:host_id']: previous value PortContext.current['binding:vif_type']: previous value PortContext.bound_segment: previous value PortContext.bound_driver: previous value 3d) In a the port update operation on a previously bound port that does trigger unbinding or rebinding, all drivers' update_port_precommit() and update_port_postcommit() methods will be called with PortContext properties reflecting the previously bound and currently unbound binding states as shown. If a value for binding:host_id was supplied,
Re: [openstack-dev] [neutron][ml2] Maintaining support for the Tail-f NCS mech driver in Icehouse
Hi Akihiro, That would be nice like we are in the process of setting CI test setup and will be useful. Regards, Balaji.P -Original Message- From: Akihiro Motoki [mailto:mot...@da.jp.nec.com] Sent: Monday, February 10, 2014 3:53 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][ml2] Maintaining support for the Tail-f NCS mech driver in Icehouse I think testing with sandbox repo is really useful during setting up third party CI. Not so many people know sandbox repo. When neutron folks were setting up third party CI, we created test reviews in openstack/neutron, but if we knew it it would be great. It is worth documented in Third Party Testing web page [1]. I will add it if nobody adds it. [1] http://ci.openstack.org/third_party.html Akihiro (2014/02/10 12:13), Anita Kuno wrote: On 02/06/2014 09:52 AM, Luke Gorrie wrote: Howdy! My name is Luke and I'm helping my friends at Tail-f Systems to support Neutron with their NCS [1] product. This went really smoothly for us on the Havana cycle, but lately we're having a harder time with Icehouse. In particular, our attempt to fulfill the 3rd party testing requirements has caused a lot of frustration for the #openstack-infra team around New Year. So I'm writing now to look for a good solution. Our goal for Icehouse is to keep our mechanism driver officially supported. The code already works, and has unit tests to keep it working. The risk we want to avoid is going on the dreaded deprecated list for some other reason, which would confuse our customers. For background, our mechanism driver is about 150 lines of code. It translates each network/port/subnet API call into a REST/JSON notification to an external system. That external system returns HTTP 200 OK. That's about all. It's a pretty trivial program. In December I sat down with Tobbe Tornqvist and we tried to setup Jenkins 3rd party testing. We created a Vagrantfile that spins up an Ubuntu VM, installs Neutron and NCS, and performs integration tests with them connected together. We hooked this into Jenkins with a service account. This went fine to start with, but after Christmas our tests started failing due to random setup issues with 'tox', and the script started making -1 votes. Those -1's created major headaches for the infrastructure team and others upstream, I am sorry to say, and ended up requiring a messy process of manual cleanup, and a public flogging for us on IRC. Bad feeling all around ... The part to keep in mind is that random issues crop up all the time. For us in -infra they are a weekly event, and some weeks they are a daily event. The part that was the most difficult was the lack of responsiveness to our efforts to communicate, to get an acknowledgement from the maintainers that this account was experiencing some issues. Then to get the issues addressed. In the end we failed and had to resort to revoking verify voting permissions for this account. It has become evident through an IRC conversation with Tobbe Tornqvist [0] that the human resources required to stay available to maintain this testing system is an issue. While understanding of the need of different sized companies to make decisions to provide value for their customers, in -infra, we can not lose sight of the fact that our customers are our developers and we need to be responsive to their requirements. We are moving to be able to merge 200 patches a day with our system, by making a commitment to that rate of development as our target, we have to ensure any dependencies for testing also are able to move at a similar pace or at least be responsive to ours. Third-party CI [1] service accounts can still place comments on open reviews even if they lack the ability to set a verify vote (-1/+1), and this can be used to show whether the backend is reliably representing the changes it tests in an effort to build community trust in its results. Your account, Tail-f, can vote on our sandbox repo [2] as a way of testing voting for the system. Thank you, Anita. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack -infra.2014-01-10.log timestamp ~ 2014-01-10T14:48:01 [1] https://review.openstack.org/#/admin/groups/270,members [2] http://git.openstack.org/cgit/openstack-dev/sandbox/ And that's where we are today. Now, reviewing the situation, I would love to find a solution that doesn't make us deprecated _and_ doesn't require us to be so deeply hooked into the OpenStack Jenkins infrastructure. Could we, for example, write an accurate emulator for the external system so that the MD code can be tested on OpenStack's own servers? That would suit us very well. It seems like a reasonable request to make given the simplicity of our driver code. Hoping for a simple solution... Cheers,
[openstack-dev] [Mistral] Cancelling community meeting today on Feb 10
Hi guys, I would suggest we skip today’s community meeting since some folks from the team (including myself) won’t be able to participate. My apologies for the late notice.. Renat Akhmerov @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to write a new neutron L2 plugin using ML2 framework?
Hi, SRIOV is under implementation in nova and neutron. Did you have a look to : https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov On Mon, Feb 10, 2014 at 7:27 AM, Isaku Yamahata isaku.yamah...@gmail.com wrote: On Sat, Feb 08, 2014 at 03:49:46AM +, Yang, Yi Y yi.y.y...@intel.com wrote: Hi, All Hi. I want to write a new neutron L2 plugin using ML2 framework, I noticed openvswitch and linxubridge have been ported into ML2 framework, but it seems many code is removed compared to standalone L2 plugin, I guess some code has been written into a common library. Now I want to write a L2 plugin to enable switch for a SR-IOV 10g NIC, I think I need to write as follows: having such a feature would be awesome : did you fill a BP for that? 1. a new mechanism driver neutron/plugins/ml2/drivers/mech_XXX.py, but from source code, it seems nothing to do. You mean, you want to use AgentMechanismDriverBase directly? this is an abstract class du to check_segment_for_agent method. This requires to define how your plugin utilize network. If multi tenant network is wanted, what/how technology will be used. The common one is VLAN or tunneling(GRE, VXLAN). This depends on what feature your NIC supports. 2. a new agent neutron/plugins/XXX/ XXX_neutron_plugin.py I don't know if this would be mandatory. May be you can just add necessary informations with extend_port_dict while your MD bind the port, as proposed by this patch : https://review.openstack.org/#/c/69783/ Nova will then configure the port correctly. The only need for an agent would be to populate the agent DB with supported segment types, so that during bind_port, the MD find an appropriate segment (with check_segment_for_agent). After this, an issue it how to let neutron know it and load it by default or by configuration. Debugging is also an issue, nobody can write code correctly once :-), does neutron have any good debugging way for a newbie? LOG.debug and debug middle ware. If there are any other better way, I'd also like to know. thanks, I'm very eager to be able to get your help and sincerely thank you in advance. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ 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] How to write a new neutron L2 plugin using ML2 framework?
Hi, As stated below, we are already having this work both in nova and neuron. Please take a look at the following discussions: https://wiki.openstack.org/wiki/Meetings#PCI_Passthrough_Meeting For neutron part there are two different flavors that are coming as part of this effort: 1. Cisco SRIOV supporting 802.1QBH - no L2 agent 2. Mellanox Flavor - SRIOV embedded switch (HW_VEB) - with L2 agent. My guess is that second flavor of SRIOV embedded switch should work for Intel NICs as well. Please join the PCI pass-through meeting discussions to see that you do not do any redundant work or just follow-up on mailing list. BR, Irena -Original Message- From: Mathieu Rohon [mailto:mathieu.ro...@gmail.com] Sent: Monday, February 10, 2014 1:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] How to write a new neutron L2 plugin using ML2 framework? Hi, SRIOV is under implementation in nova and neutron. Did you have a look to : https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov On Mon, Feb 10, 2014 at 7:27 AM, Isaku Yamahata isaku.yamah...@gmail.com wrote: On Sat, Feb 08, 2014 at 03:49:46AM +, Yang, Yi Y yi.y.y...@intel.com wrote: Hi, All Hi. I want to write a new neutron L2 plugin using ML2 framework, I noticed openvswitch and linxubridge have been ported into ML2 framework, but it seems many code is removed compared to standalone L2 plugin, I guess some code has been written into a common library. Now I want to write a L2 plugin to enable switch for a SR-IOV 10g NIC, I think I need to write as follows: having such a feature would be awesome : did you fill a BP for that? 1. a new mechanism driver neutron/plugins/ml2/drivers/mech_XXX.py, but from source code, it seems nothing to do. You mean, you want to use AgentMechanismDriverBase directly? this is an abstract class du to check_segment_for_agent method. This requires to define how your plugin utilize network. If multi tenant network is wanted, what/how technology will be used. The common one is VLAN or tunneling(GRE, VXLAN). This depends on what feature your NIC supports. 2. a new agent neutron/plugins/XXX/ XXX_neutron_plugin.py I don't know if this would be mandatory. May be you can just add necessary informations with extend_port_dict while your MD bind the port, as proposed by this patch : https://review.openstack.org/#/c/69783/ Nova will then configure the port correctly. The only need for an agent would be to populate the agent DB with supported segment types, so that during bind_port, the MD find an appropriate segment (with check_segment_for_agent). After this, an issue it how to let neutron know it and load it by default or by configuration. Debugging is also an issue, nobody can write code correctly once :-), does neutron have any good debugging way for a newbie? LOG.debug and debug middle ware. If there are any other better way, I'd also like to know. thanks, I'm very eager to be able to get your help and sincerely thank you in advance. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] several oslo library repositories have moved
Thierry, They are listed in projects.yaml already: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/projects.yaml#L1760 I did push a review to add them to projects.txt in requirements repo: https://review.openstack.org/#/c/72330/ -- dims On Mon, Feb 10, 2014 at 5:44 AM, Thierry Carrez thie...@openstack.org wrote: Doug Hellmann wrote: The Oslo program has adopted cliff, pycadf, stevedore, and taskflow, promoting them from stackforge, so we can establish symmetric gating with the rest of OpenStack. In order to do that, the git repositories were moved from stackforge/* to openstack/* Doug, If you adopted those projects you should also push the corresponding change to the governance repo (projects.yaml). All projects under openstack*/ must be accounted for. Thanks, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] Murano Release 0.4.1 Announcement
Hi, everyone! Let me introduce you new Murano-0.4.1 release! This is the bug-fix release for a Murano-0.4 version: more than 40 bugs were resolved https://launchpad.net/murano/1.0/0.4.1 and all known issues from the previous release were fixed - now there is no any problems with deploying web-farm services. Moreover, some features were implemented: - Per-tenant isolation in Metadata Repository; - Floating IP and VIP auto-assignment; - Key-pair assinment for linux servicies; - Murano installation with devstack. Check out Murano-0.4.1 Release Noteshttps://wiki.openstack.org/wiki/Murano/ReleaseNotes_v0.4.1to see more information about new features! Other useful links: - MuranoWiki https://wiki.openstack.org/wiki/Murano - Murano Launchpad https://launchpad.net/murano Thanks everyone who helped with Murano 0.4.1! Best regards, Kate Fedorova. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] several oslo library repositories have moved
Davanum Srinivas wrote: They are listed in projects.yaml already: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/projects.yaml#L1760 I did push a review to add them to projects.txt in requirements repo: https://review.openstack.org/#/c/72330/ Oops. I meant: http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa][Nova] Update: Nova *V3* API List for Missing Tempest Tests
Hi, I have updated: Nova *V3* API List for Missing Tempest Tests. https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc#gid=6 The summary of this list: different count from Tested or not # of APIs ratio the last time --- Tested API 88 62.4% 0 Not Tested API[1]53 37.6% 0 --- Total[2]: 141 100.0% 0 [1] including some Doings [2] only v3 APIs Additional information: I made this API list with this nova's patch https://review.openstack.org/#/c/25882/ https://review.openstack.org/#/c/72277/ https://review.openstack.org/#/c/65615/ (Actually, I need to extract and summarize the data from its screen-n-api.txt.gz manually because of some reasons.) This information would be useful for creating Tempest tests. Any comments/questions/suggestions are welcome. And if you notice any mistakes on this list, feel free to correct/update it please. Best Regards, -- Masayuki Igawa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] several oslo library repositories have moved
Done. https://review.openstack.org/#/c/72335/ thanks for the pointer :) -- dims On Mon, Feb 10, 2014 at 7:49 AM, Thierry Carrez thie...@openstack.org wrote: Davanum Srinivas wrote: They are listed in projects.yaml already: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/projects.yaml#L1760 I did push a review to add them to projects.txt in requirements repo: https://review.openstack.org/#/c/72330/ Oops. I meant: http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] XenAPI / XCP going away from Debian Ubuntu
Hi, Just to make sure nobody misses the information. Due to a lack of upstream support from Citrix, and because XCP cannot be built in recent versions of Debian and Ubuntu, I asked for the removal of XCP from Debian Sid (it's already gone from Debian testing). A removal from Ubuntu has also been requested. This means that it will also be impossible to support XCP support in OpenStack, unfortunately (the support for XCP was removed a few months ago because that was blocking migration to Debian testing anyway). This is sad, but there was unfortunately no other way. I just hope Citrix will work on Debian support in xenserver-core. Cheers, Thomas Goirand (zigo) For reference, see http://bugs.debian.org/738322 and https://bugs.launchpad.net/bugs/1278352 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] XenAPI / XCP going away from Debian Ubuntu
Hi Thomas, This means that it will also be impossible to support XCP support in OpenStack, unfortunately (the support for XCP was removed a few months ago because that was blocking migration to Debian testing anyway). Just a quick note - there are two separate issues here which some might confuse into one issue. The first part of the issue is there have been XAPI XCP packages in Debian which were based on an old version of XenServer; effectively forked with CentOS-specific paths etc replaced with Debian-specific paths. This is what is not considered to be the long-term plan for the packages in Debian and Ubuntu. Citrix have recently been fixing the master branch of various modules such as XAPI to enable it to run on both environments, removing the distro-specific components. As you mentioned in the email, xenserver-core provides a way to build Debian packages from that environment and we are hoping that will make a return to Debian very soon (and Ubuntu after that). The second part is that XCP/XenServer support in OpenStack makes use of a VM which is where nova is run. Both Debian and Ubuntu can be used as those without any XAPI XCP packages, and only need the XenAPI.py API wrapper script. In this way Debian acts purely as a client to the remote XenAPI server. As such, there is no reason that XCP support in OpenStack should be removed from Debian, since such support does not depend on Debian being able to act as a XCP server. Bob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Possible Hyper-V false CI failures
Here’s the Zuul error for this specific patch from the logs. Looks like Zuul reports back the “please rebase” message independently from the error it encounters. Given that, we’re looking into how to improve resiliency and error reporting. Alessandro On 10 Feb 2014, at 12:45 , Gabriel Samfira gsamf...@cloudbasesolutions.com wrote: 2014-02-09 20:09:12,190 INFO zuul.Gerrit: Updating information for 72197,1 2014-02-09 20:09:19,551 ERROR zuul.Merger: Unable to reset repo zuul.merger.Repo object at 0x1617c10 Traceback (most recent call last): File /usr/local/lib/python2.7/dist-packages/zuul/merger.py, line 241, in mergeChanges repo.reset() File /usr/local/lib/python2.7/dist-packages/zuul/merger.py, line 71, in reset self.update() File /usr/local/lib/python2.7/dist-packages/zuul/merger.py, line 138, in update origin.update() File /usr/local/lib/python2.7/dist-packages/git/remote.py, line 510, in update self.repo.git.remote(update, self.name) File /usr/local/lib/python2.7/dist-packages/git/cmd.py, line 227, in lambda return lambda *args, **kwargs: self._call_process(name, *args, **kwargs) File /usr/local/lib/python2.7/dist-packages/git/cmd.py, line 456, in _call_process return self.execute(call, **_kwargs) File /usr/local/lib/python2.7/dist-packages/git/cmd.py, line 377, in execute raise GitCommandError(command, status, stderr_value) GitCommandError: 'git remote update origin' returned exit status 1: ssh: connect to host review.openstack.org port 29418: Network is unreachable fatal: The remote end hung up unexpectedly error: Could not fetch origin On 10 Feb 2014, at 04:21 , Alessandro Pilotti apilo...@cloudbasesolutions.com wrote: Hi guys, On 10 Feb 2014, at 03:59 , Jay Pipes jaypi...@gmail.com wrote: On Sun, 2014-02-09 at 18:17 -0700, Christopher Yeoh wrote: Hi, I think the hyper-v CI system is sometimes failing with this message incorrectly: This change was unable to be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset. I only mention it because its the second time I've seen it. An example here: https://review.openstack.org/#/c/72197/ The changeset was made off a very fresh git update and there doesn't appear to be any updates merged since then. The last time this error appeared for me the rebase had no conflicts and Jenkins did not have any trouble testing the same patchset that the Hyper-V one failed to merge. Yeah, it may not be a rebase issue at all. The problem may be that the failure-message setting on the Zuul pipeline that is being triggered or Jenkins Gerrit trigger plugin is set to the above message, regardless of whether the failure is indeed due to the failure of a rebase… Hi guys, looking into this. We had a similar issue some days ago due to a corrupted Nova local git repo, which clearly had nothing to do with a rebase. Checking out what’s going on this time. Octavius, is it possible to pastebin your Zuul layout.yaml? Here’s the zuul layout that we’re using: https://github.com/cloudbase/ci-overcloud-init-scripts/blob/master/zuul_layout.yaml Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Using Python-Neutronclient from
All dictionaries are not created equal; in some respects it's like we have a
medical dictionary and an automotive terms dictionary and on for each api. So,
we need to document our dictionaries, by which key names (and possibly sample
values) are required in the dictionary and which are optional (and when), for
that particular API (e.g. create_credential) to work as expected.
--
Message: 3
Date: Sat, 8 Feb 2014 19:20:02 +
From: Collins, Sean sean_colli...@cable.comcast.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Using Python-Neutronclient from
Python - docstrings needed?
Message-ID: 20140208192001.gb40...@hqsml-1081034.cable.comcast.com
Content-Type: text/plain; charset=utf-8
Hi,
I was writing a small script yesterday to parse a list of IP blocks and
create security groups and rules, by using python-neutronclient.
To be honest, it was very difficult - even though I have actually
written extensions to Python-Neutronclient for the QoS API.
For those that are trying to use the client from inside their code,
they end up getting zero help as to how to actually call any of the
functions, and what parameters they take.
neutron = client.Client('2.0', auth_url=os.environ['OS_AUTH_URL'],
... tenant_id=os.environ['OS_TENANT_ID'],
... username=os.environ['OS_USERNAME'],
... password=os.environ['OS_PASSWORD'])
help(neutron)
| create_credential = function with_params
|
| create_firewall = function with_params
|
| create_firewall_policy = function with_params
|
| create_firewall_rule = function with_params
|
| create_floatingip = function with_params
|
| create_health_monitor = function with_params
|
| create_ikepolicy = function with_params
|
| create_ipsec_site_connection = function with_params
|
| create_ipsecpolicy = function with_params
|
| create_member = function with_params
|
| create_metering_label = function with_params
Since there was nothing there, I decided to go check the source of
python-neutronclient and see if there are any examples.
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
If you read closely enough, you'll find out that the function takes a
dictionary, that looks very similar to the request/response examples
listed in the API documentation. So, I went over and checked it out.
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html
So from there, I was able to remember enough that each of these
functions takes a single argument, that is a dictionary, that mimics
the same structure that you see in the API documentation, so from there
it was just some experimentation to get the structure right.
Honestly it wasn't easy to remember all this stuff, since
it had been a couple months since I had worked with
python-neutronclient, and it had been from inside the library itself.
This was my first experience using it on the outside and it was pretty
tough - so I'm going to try and look into how we can improve the
docstrings for the client object, to make it a bit easier to figure out.
Thoughts?
--
Sean M. Collins
--
Message: 4
Date: Sat, 8 Feb 2014 14:22:24 -0800
From: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] non-trivial example - IBM
Connections [and Murano]
Message-ID:
CAG_6_o=22iR7HJKBSRpkJ6f3-3bLrHcaSC-mLU=6s3jnoel...@mail.gmail.com
Content-Type: text/plain; charset=iso-8859-1
Hi Mike,
Thank you for clarification. I like your approach with Ruby and I think
this is a right way to solve such tasks like DSL creation. In Murano we use
Yaml and python just to avoid introduction of a whole new language like
Ruby to OpenStack.
As for software configurations in heat, we are eager to have it available
for use. We use Heat in Murano and we want to pass as much as possible work
to Heat engine. Murano itself is intended to be an Application Catalog for
managing available application packages and focuses on UI and user
experience rather then on deployment details. We still use DSL for several
things, have something working while waiting for Heat implementations, and
to have imperative workflow engine which is useful when you need to
orchestrate complex workflows. The last part is very powerful when you need
to have an explicit control on deployment sequence with conditional
branches orchestration among several different instances. When Mistral will
be available we plan to use its workflow engine for task orchestration.
Again,
Re: [openstack-dev] oslo.config improvements
On Fri, Feb 7, 2014 at 11:35 AM, Shaun McCance sha...@gnome.org wrote: I've been working on the code that generates our configuration docs. A couple week ago, I rewrote most of it to address some major problems, most notably its inability to distinguish same-named options in different groups. I've tried to reuse bits from the oslo-incubator code to generate sample config files, but it's been tricky. Failing that, I've tried to write the docs generator in a way where its code could be moved somewhere and reused by multiple projects. oslo.config seems like a good home for that. I want to move the sample config generator there, too, so if we can share code between them and have 2 programs that generate different output formats that would probably be best. The way the config file generator in oslo-incubator works right now has some major problems, which I'd like to address: 1) Because of the way it iterates over modules, then over all options, it's considerably slower than it should be. The config file generator groups by defining module, so it needs that info. The config docs gnerator doesn't do anything with the defining module right now, but I wouldn't rule out the possibility in the future. 2) It locates options based on them being defined at the top level of a module (not in function or packed into some object), but it gets info by looking at cfg.CONF, which require registration. This fails if an option is defined by only registered when some function is called. This happens right now with the ip_lib_force_root option in Neutron. Both the config file generator and config docs generator currently crash on Neutron because of this. The option definition needs to be in a variable at the module top level, even if the registration call happens at run time. Can you file a bug against Neutron about that? 3) It's completely incapable of finding options that aren't defined or registered until some function is called or some object is instantiated. I don't have a general solution to this, although I do have special-case code that detects projects that use oslo.messaging and ensures those options get registered. I did some work to address this under https://blueprints.launchpad.net/oslo/+spec/improve-config-discovery-for-docsso that libraries can register entry points that declare configuration options. I think the only library using this feature so far is oslo.messaging, but the other oslo libraries will use it when they graduate from the incubator. To address these issues, I'd like to get oslo.config to know about the defining module for each option. It can get that using something like this in Opt.__init__: for frame in inspect.stack(): mod = inspect.getmodule(frame[0]) if mod == sys.modules[__name__]: continue self.module = mod.__name__ break I'm not sure we want deployers to have to worry about where the option is defined. How would you use the information in the documentation? I guess we include it in the sample config output? We'd also have to modify __eq__ and __ne__, because it's valid for an option to be defined in two different modules as long as all its parameters are the same. Checking vars() equality would trip up on the module. (There's the further issue that the defining module is non-deterministic in those cases.) It's valid for an option to be registered with the same definition more than once, but having the definition live in more than one place is just asking for maintenance trouble later. Do we actually have this situation now? Then I'd like to get both the config file generator and the config docs generator using something like the OptionsCache class I wrote for the config docs generator: http://git.openstack.org/cgit/openstack/openstack-doc-tools/tree/autogenerate_config_docs/common.py#n88 This could be simpler and faster and avoid the crash mentioned above with the module info attached to each option. Having 2 programs that discover options in 2 ways is a bad thing, so yes, let's combine them in oslo.config and let them share code. Doug Is any part of this feasible? Has anybody else worked on resolving these types of issues with the config file generator? -- Shaun ___ 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] [infra] Meeting Tuesday February 11th at 19:00 UTC
Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday February 11th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend. -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] universal wheel support
On Sat, Feb 8, 2014 at 7:08 PM, Monty Taylor mord...@inaugust.com wrote: Hey all! There are a bunch of patches adding: [wheel] universal = 1 to setup.cfg: https://review.openstack.org/#/q/status:open+topic:wheel-publish,n,z I wanted to follow up on what the deal is with them, and what I think we should do about them. universal means that a wheel can be made that can work with any python. That's awesome, and we want it - it makes the wheel publishing code easier. I don't think we want it turned on for any project that doesn't, in fact, support python3 - because we'd be producing a wheel that says it works in python3. To be fair - the wheel itself will work just fine in python3 - it's just the software that doesn't - and we upload tarballs right now which don't block attempts to use them in python3. SO - my pedantic side says: Let's only land universal = 1 into python3 supporting projects upon further reflection, I think my other side says: It's fine, let's land it everywhere, it doesn't hurt anything, and then we can stop worrying about it Thoughts? Do we have any non-library projects that support python 3? Doug Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] User Signup
Hi Soren, On 10 February 2014 08:27, Soren Hansen so...@linux2go.dk wrote: I've just taken a look at the feedback in the whiteboard. If it's ok, I'd like to take this discussion back to the mailing list. I find the whiteboards somewhat clumsy for discussions. Akihiro Motoki points out that all services should work without the dashboard. Keystone already exposes an API to create new users, so that requirement is already fulfilled, whether there's an intermediate service or not, so I don't really understand this objection. Kieran Spear argues in favour of a separate registration service that Horizon talks to over some sort of RPC interface. He argues that putting Keystone admin credentials on public facing webserver is a security risk. I agree that putting admin credentials on a public web server is a security risk, but I'm not sure why a set of restricted admin credentials that only allow you to create users and tenants is a bigger problem than the credentials for separate registration service that performs the exact same operations? The third (and most dangerous) operation here is the role grant. I don't think any Keystone policy could be specific enough to prevent arbitrary member role assignment in this case. How do you express the following as a set of policies in Keystone? Allow a user to create a new user and a new project and grant the member role for only that user on only that project. There may be other ways around this particular case, but in these situations I accept that mistakes are inevitable, and another layer of isolation helps to reduce the impact when things go wrong. Cheers, Kieran Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ 2014-02-01 18:24 GMT+01:00 Saju M sajup...@gmail.com: Hi folks, Could you please spend 5 minutes on the blueprint https://blueprints.launchpad.net/horizon/+spec/user-registration and add your suggestions in the white board. Thanks, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Can heat automatically create a flavor as part of stack creation?
On 09/02/14 03:09, Robert Collins wrote: In principle yes. You need: - to write a module to orchestrate the nova flavor API. https://wiki.openstack.org/wiki/Heat/Plugins - to configure your policy rules in the cloud in question to let the heat engine user create flavors Not quite. Heat does everything using the end-user's credentials. You should configure the cloud to allow the users you want to be able to create flavors to create them. (This makes sense if you think about it - if the heat-engine user did it you would have no granular control, and could only allow all users or no users to create flavors.) -Rob On 9 February 2014 20:49, ELISHA, Moshe (Moshe) moshe.eli...@alcatel-lucent.com wrote: Hello, I am wondering if instead of being obligated to use an existing flavor, I could declare a flavor (with its properties) inside Heat template and let Heat create the flavor automatically? Similar to the ability to create networks as part of the template. As Alex correctly points out in another reply, this is fairly unusual because normally you want the available flavors to be tightly controlled by the cloud operator. There is some precedent for this in Heat - a couple of Neutron resources have properties to tie virtual network components to physical routers that are only available to admins. TBH I'm not thrilled about their existence though, until such time as we have some way to filter resources and properties based on what the user is permitted given their roles. If you were to write a plugin as Rob described above then I think it would belong in /contrib, not in the main tree. In particular, this is not really something that is analogous to being able to creating (virtual) networks in the template, since that is something exposed to ordinary users via the Neutron API as a matter of course. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] XenAPI / XCP going away from Debian Ubuntu
On 02/10/2014 10:15 PM, Bob Ball wrote: The second part is that XCP/XenServer support in OpenStack makes use of a VM which is where nova is run. Both Debian and Ubuntu can be used as those without any XAPI XCP packages, and only need the XenAPI.py API wrapper script. In this way Debian acts purely as a client to the remote XenAPI server. As such, there is no reason that XCP support in OpenStack should be removed from Debian, since such support does not depend on Debian being able to act as a XCP server. Bob Hi bob, I don't agree with this view. If there's no XCP in Debian, I don't see the point in supporting it in OpenStack. (and no, adding support for the magical Citrix CentOS appliance blackbox isn't something I wish to do...) Also, there's the need of python-xenapi in OpenStack, which was provided by the xen-api sources. As I wrote, in Debian, I removed XCP support in OpenStack (in fact, in Nova) a long time ago, because xen-api was removed from testing, which therefore was blocking Nova to migrate to testing. So even if I wanted to support something which isn't in Debian, I wouldn't be able because of the lack of the XenAPI python module. Again, I'm unhappy about this situation, and hope it can be solved. I warmly welcome Citrix to work with me (again) to fix this quickly. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
On Mon, Feb 10, 2014 at 11:38:40AM +1300, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. +1, and thanks for sticking with the multi-engine work, I know it's been a tough challenge at times! :) Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler
I'm not sure what you mean by whatever it takes to finally create the instances, but that sounds like what I had assumed everybody meant by orchestration (until I heard that there is no widespread agreement) --- and I think we need to take a properly open approach to that. I think the proper API for cross-service whole-pattern scheduling should primarily focus on conveying the placement problem to the thing that will make the joint decision. After the joint decision is made comes the time to create the individual resources. I think we can NOT mandate one particular agent or language for that. We will have to allow general clients to make calls on Nova, Cinder, etc. to do the individual resource creations (with some sort of reference to the decision that was already made). My original position was that we could use Heat for this, but I think we have gotten push-back saying it is NOT OK to *require* that. For example, note that some people do not want to use Heat at all, they prefer to make individual calls on Nova, Cinder, etc. Of course, we definitely want to support, among others, the people who *do* use Heat. I do not think Heat would be appropriate, either. Heat does not have the detailed knowledges on the infrastructure and it uses Nova (Gantt) API to pass the command, so if Nova (Gantt) API does not support multiple instances provisioning, Heat will not get the joint decision for all VMs as a whole. Heat may orchestrate the provisioning process, but eventually the instances will be passed to Nova-scheduler (Gantt) as separated commands, which is exactly the problem Solver Scheduler wants to correct. Therefore the Instance Group API is needed, wherever it is used (nova-scheduler/Gantt). I think Gantt should be the cross-service joint decision point. Heat still keeps orchestrating processes like it always does, but the provisioning decision has to be made all together as one atomic step in Heat's whole process. Here's a more detailed description of our thoughts on how such a protocol might look: https://wiki.openstack.org/wiki/Nova/PlacementAdvisorAndEngine We've concentrated on the Nova scheduler; Would be interesting to see if this protocol aligns with Yathiraj's thoughts on a global scheduler addressing compute+storage+network. Feedback is most welcome. Thank you for the link, I will give it a try. Best regards, Toan - Original Message - From: Mike Spreitzer mspre...@us.ibm.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Tuesday, February 4, 2014 9:05:22 AM Subject: Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler From: Khanh-Toan Tran khanh-toan.t...@cloudwatt.com ... There is an unexpected line break in the middle of the link, so I post it again: https://docs.google.com/document/d/1RfP7jRsw1mXMjd7in72ARjK0fTrsQv1bqolOri IQB2Y The mailing list software keeps inserting that line break. I re-constructed the URL and looked at the document. As you point out at the end, the way you attempt to formulate load balancing as a linear objective does not work. I think load-balancing is a non-linear thing. I also doubt that simple load balancing is what cloud providers want; I think cloud providers want to bunch up load, within limits, for example to keep some hosts idle so that they can be powered down to save on costs or left available for future exclusive use. From: Gil Rapaport g...@il.ibm.com ... As Alex Glikson hinted a couple of weekly meetings ago, our approach to this is to think of the driver's work as split between two entities: -- A Placement Advisor, that constructs placement problems for scheduling requests (filter-scheduler and policy-based-scheduler) -- A Placement Engine, that solves placement problems (HostManager in get_filtered_hosts() and solver-scheduler with its LP engine). Yes, I see the virtue in that separation. Let me egg it on a little. What Alex and KTT want is more structure in the Placement Advisor, where there is a multiplicity of plugins, each bound to some fraction of the whole system, and a protocol for combining the advice from the plugins. I would also like to remind you of another kind of structure: some of the placement desiderata come from the cloud users, and some from the cloud provider. From: Yathiraj Udupi (yudupi) yud...@cisco.com ... Like you point out, I do agree the two entities of placement advisor, and the placement engine, but I think there should be a third one – the provisioning engine, which should be responsible for whatever it takes to finally create the instances, after the placement decision has been taken. I'm not sure what you mean by whatever it takes to finally create the instances, but that sounds like what I had assumed everybody meant by orchestration (until I heard that there is no widespread agreement) ---
[openstack-dev] [oslo] team meeting 14 Feb at 1400 UTC
The Oslo team will meet this Friday, 14 Feb, at 1400 UTC. The primary item on the agenda is our icehouse-3 status, but if you have anything else we need to go over please add it to the wiki page: https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Using Python-Neutronclient from Python - docstrings needed?
I'm sure the Documentation team would love to hear from you:
https://wiki.openstack.org/wiki/Documentation
-Ben
On 2014-02-09 23:24, Rajdeep Dua wrote:
Yes, We would be interested in doing that.
Please let me know which is the right group/ team for this?
On Monday, February 10, 2014 10:34 AM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
Do you have plans to submit these back upstream? It would be a great first
start, perhaps we could add these as examples underneath the JSON
request/reponse in http://api.openstack.org/api-ref-networking.html
Sean M. Collins
-
FROM: Rajdeep Dua [dua_rajd...@yahoo.com]
SENT: Saturday, February 08, 2014 11:10 PM
TO: OpenStack Development Mailing List (not for usage questions)
SUBJECT: Re: [openstack-dev] [Neutron] Using Python-Neutronclient from Python
- docstrings needed?
Sean,
We have written a few docs for writing these samples
http://python-api-guide.cfapps.io/content/neutron.html
You can find get the source here
https://github.com/rajdeepd/openstack-samples
Thanks
Rajdeep
On Sunday, February 9, 2014 12:57 AM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
Hi,
I was writing a small script yesterday to parse a list of IP blocks and
create security groups and rules, by using python-neutronclient.
To be honest, it was very difficult - even though I have actually
written extensions to Python-Neutronclient for the QoS API.
For those that are trying to use the client from inside their code,
they end up getting zero help as to how to actually call any of the
functions, and what parameters they take.
neutron = client.Client('2.0', auth_url=os.environ['OS_AUTH_URL'],
... tenant_id=os.environ['OS_TENANT_ID'],
... username=os.environ['OS_USERNAME'],
... password=os.environ['OS_PASSWORD'])
help(neutron)
| create_credential = function with_params
|
| create_firewall = function with_params
|
| create_firewall_policy = function with_params
|
| create_firewall_rule = function with_params
|
| create_floatingip = function with_params
|
| create_health_monitor = function with_params
|
| create_ikepolicy = function with_params
|
| create_ipsec_site_connection = function with_params
|
| create_ipsecpolicy = function with_params
|
| create_member = function with_params
|
| create_metering_label = function with_params
Since there was nothing there, I decided to go check the source of
python-neutronclient and see if there are any examples.
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
[2]
If you read closely enough, you'll find out that the function takes a
dictionary, that looks very similar to the request/response examples
listed in the API documentation. So, I went over and checked it out.
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html
[3]
So from there, I was able to remember enough that each of these
functions takes a single argument, that is a dictionary, that mimics
the same structure that you see in the API documentation, so from there
it was just some experimentation to get the structure right.
Honestly it wasn't easy to remember all this stuff, since
it had been a couple months since I had worked with
python-neutronclient, and it had been from inside the library itself.
This was my first experience using it on the outside and it was pretty
tough - so I'm going to try and look into how we can improve the
docstrings for the client object, to make it a bit easier to figure out.
Thoughts?
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [1]
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [1]
Links:
--
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2]
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
[3]
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [infra] Proposing Sergey Lukjanov for infra-core
Hi, I'm very pleased to propose that we add Sergey Lukjanov to the infra-core team. He is among the top reviewers of projects in openstack-infra, and is very familiar with how jenkins-job-builder and zuul are used and configured. He has done quite a bit of work in helping new projects through the process and ensuring that changes to the CI system are correct. In addition to providing very helpful reviews he has also contributed significant patches to our Python projects illustrating a high degree of familiarity with the code base and project direction. And as a bonus, we're all looking forward to once again having an infra-core member in a non-US time zone! -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] universal wheel support
On Mon, Feb 10, 2014 at 9:00 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Sat, Feb 8, 2014 at 7:08 PM, Monty Taylor mord...@inaugust.com wrote: Hey all! There are a bunch of patches adding: [wheel] universal = 1 to setup.cfg: https://review.openstack.org/#/q/status:open+topic:wheel-publish,n,z I wanted to follow up on what the deal is with them, and what I think we should do about them. universal means that a wheel can be made that can work with any python. That's awesome, and we want it - it makes the wheel publishing code easier. I don't think we want it turned on for any project that doesn't, in fact, support python3 - because we'd be producing a wheel that says it works in python3. To be fair - the wheel itself will work just fine in python3 - it's just the software that doesn't - and we upload tarballs right now which don't block attempts to use them in python3. SO - my pedantic side says: Let's only land universal = 1 into python3 supporting projects upon further reflection, I think my other side says: It's fine, let's land it everywhere, it doesn't hurt anything, and then we can stop worrying about it Thoughts? Do we have any non-library projects that support python 3? yes, python-novaclient and many more https://wiki.openstack.org/wiki/Python3 Doug Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
+1! -- Thomas - Mail original - On Mon, Feb 10, 2014 at 11:38:40AM +1300, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. +1, and thanks for sticking with the multi-engine work, I know it's been a tough challenge at times! :) Steve ___ 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] [Solum] Milestone 1 End to end scenario
It is exciting to see we are getting close to delivering the first end to end use case for Solum ! Though we have blueprints to track individual work items for Milestone 1, it is useful to have a view into exactly what end to end experience we will be delivering. I have made an attempt at documenting that, and linked to the Solum High Level Roadmap wiki: https://wiki.openstack.org/wiki/Solum/Milestone1 The goal is not to have a comprehensive listing of all features delivered in M1, but rather to summarize in a few lines the desired outcome from a user perspective. Comments, suggestions welcome. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
+1 look forward to more from Jason! Regards -steve On 02/09/2014 03:38 PM, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. cheers ___ 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] Using Python-Neutronclient from Python - docstrings needed?
Hi Sean,
Yes, please do improve docstrings for the client object! And I think you
found that Lorin Hochstein recently added a Python SDK chapter to the end
user guide at http://docs.openstack.org/user-guide/content/ch_sdk.html.
As for the CLI project itself, the docs team has taken all the command help
and subcommand help for each python-projectclient and made a CLI
reference:
http://docs.openstack.org/cli-reference/content/neutronclient_commands.html
We haven't tackled or planned much for all the python-projectclient docs
due to: priorities, resources, and a wait-and-see approach to the unified
OpenStack client.
Hope that helps -- happy to plan an attack with you on the openstack-docs
list if you have ideas.
Anne
On Sat, Feb 8, 2014 at 1:20 PM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
Hi,
I was writing a small script yesterday to parse a list of IP blocks and
create security groups and rules, by using python-neutronclient.
To be honest, it was very difficult - even though I have actually
written extensions to Python-Neutronclient for the QoS API.
For those that are trying to use the client from inside their code,
they end up getting zero help as to how to actually call any of the
functions, and what parameters they take.
neutron = client.Client('2.0', auth_url=os.environ['OS_AUTH_URL'],
... tenant_id=os.environ['OS_TENANT_ID'],
... username=os.environ['OS_USERNAME'],
... password=os.environ['OS_PASSWORD'])
help(neutron)
| create_credential = function with_params
|
| create_firewall = function with_params
|
| create_firewall_policy = function with_params
|
| create_firewall_rule = function with_params
|
| create_floatingip = function with_params
|
| create_health_monitor = function with_params
|
| create_ikepolicy = function with_params
|
| create_ipsec_site_connection = function with_params
|
| create_ipsecpolicy = function with_params
|
| create_member = function with_params
|
| create_metering_label = function with_params
Since there was nothing there, I decided to go check the source of
python-neutronclient and see if there are any examples.
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
If you read closely enough, you'll find out that the function takes a
dictionary, that looks very similar to the request/response examples
listed in the API documentation. So, I went over and checked it out.
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html
So from there, I was able to remember enough that each of these
functions takes a single argument, that is a dictionary, that mimics
the same structure that you see in the API documentation, so from there
it was just some experimentation to get the structure right.
Honestly it wasn't easy to remember all this stuff, since
it had been a couple months since I had worked with
python-neutronclient, and it had been from inside the library itself.
This was my first experience using it on the outside and it was pretty
tough - so I'm going to try and look into how we can improve the
docstrings for the client object, to make it a bit easier to figure out.
Thoughts?
--
Sean M. Collins
___
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] [Solum] Milestone 1 End to end scenario
Hi Roshan, Great to see the big picture that we are targeting. Some minor comments/suggestions: 1) It will be helpful to explicitly call out in the first step that the git repositories are not hosted by Solum but are public repositories on github.com 1) In step 3, what do you mean by 'automatic' deployment? I would suggest we remove that word. 2) It will help if we use two different terms to identify the end users of an application and the developer of an application. In the line 'Only authorized users .. access the service', I think you mean 'only application developers who are also registered with Solum will be able to access the Solum API service'. In its current form it is not clear whether 'users' refer to developers or application users and whether 'service' refers to solum API or the running application. Similarly in the last line the last word can be changed from 'user' to 'API user'. Thanks, Devdatta -Original Message- From: Roshan Agrawal roshan.agra...@rackspace.com Sent: Monday, February 10, 2014 12:28pm To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: [openstack-dev] [Solum] Milestone 1 End to end scenario It is exciting to see we are getting close to delivering the first end to end use case for Solum ! Though we have blueprints to track individual work items for Milestone 1, it is useful to have a view into exactly what end to end experience we will be delivering. I have made an attempt at documenting that, and linked to the Solum High Level Roadmap wiki: https://wiki.openstack.org/wiki/Solum/Milestone1 The goal is not to have a comprehensive listing of all features delivered in M1, but rather to summarize in a few lines the desired outcome from a user perspective. Comments, suggestions welcome. ___ 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] [barbican] Meeting Today
All, Barbican will be having our weekly meeting in #openstack-meeting-alt in 30 minutes at 2:00pm Central, 2000 UTC. On the list today is a quick discussion covering the status of the Barbican incubation request. We may also discuss the asymmetric work going on and possibly an update on Dogtag support. Drop of by if you have questions, we should have time to add things to the agenda. Thanks, Jarret smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Proposing Sergey Lukjanov for infra-core
On 02/10/2014 12:48 PM, James E. Blair wrote: Hi, I'm very pleased to propose that we add Sergey Lukjanov to the infra-core team. He is among the top reviewers of projects in openstack-infra, and is very familiar with how jenkins-job-builder and zuul are used and configured. He has done quite a bit of work in helping new projects through the process and ensuring that changes to the CI system are correct. In addition to providing very helpful reviews he has also contributed significant patches to our Python projects illustrating a high degree of familiarity with the code base and project direction. And as a bonus, we're all looking forward to once again having an infra-core member in a non-US time zone! -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'm so glad. Welcome Sergey. Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Proposing Sergey Lukjanov for infra-core
On Mon, Feb 10, 2014 at 9:48 AM, James E. Blair jebl...@openstack.org wrote: Hi, I'm very pleased to propose that we add Sergey Lukjanov to the infra-core team. He is among the top reviewers of projects in openstack-infra, and is very familiar with how jenkins-job-builder and zuul are used and configured. He has done quite a bit of work in helping new projects through the process and ensuring that changes to the CI system are correct. In addition to providing very helpful reviews he has also contributed significant patches to our Python projects illustrating a high degree of familiarity with the code base and project direction. And as a bonus, we're all looking forward to once again having an infra-core member in a non-US time zone! -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev +1 here. Sergey has done a great job of keeping up with reviews lately, which has been quite helpful. Clark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron][ml2] Proposal to support VIF security, PCI-passthru/SR-IOV, and other binding-specific data
On 01/31/2014 03:47 PM, Robert Kukura wrote: On 01/29/2014 10:26 AM, Robert Kukura wrote: The neutron patch [1] and nova patch [2], proposed to resolve the get_firewall_required should use VIF parameter from neutron bug [3], replace the binding:capabilities attribute in the neutron portbindings extension with a new binding:vif_security attribute that is a dictionary with several keys defined to control VIF security. When using the ML2 plugin, this binding:vif_security attribute flows from the bound MechanismDriver to nova's GenericVIFDriver. Separately, work on PCI-passthru/SR-IOV for ML2 also requires binding-specific information to flow from the bound MechanismDriver to nova's GenericVIFDriver. See [4] for links to various documents and BPs on this. A while back, in reviewing [1], I suggested a general mechanism to allow ML2 MechanismDrivers to supply arbitrary port attributes in order to meet both the above requirements. That approach was incorporated into [1] and has been cleaned up and generalized a bit in [5]. I'm now becoming convinced that proliferating new port attributes for various data passed from the neutron plugin (the bound MechanismDriver in the case of ML2) to nova's GenericVIFDriver is not such a great idea. One issue is that adding attributes keeps changing the API, but this isn't really a user-facing API. Another is that all ports should have the same set of attributes, so the plugin still has to be able to supply those attributes when a bound MechanismDriver does not supply them. See [5]. Instead, I'm proposing here that the binding:vif_security attribute proposed in [1] and [2] be renamed binding:vif_details, and used to transport whatever data needs to flow from the neutron plugin (i.e. ML2's bound MechanismDriver) to the nova GenericVIFDriver. This same dictionary attribute would be able to carry the VIF security key/value pairs defined in [1], those needed for [4], as well as any needed for future GenericVIFDriver features. The set of key/value pairs in binding:vif_details that apply would depend on the value of binding:vif_type. I've filed a blueprint for this: https://blueprints.launchpad.net/neutron/+spec/vif-details An initial patch implementing the vif-details BP is at https://review.openstack.org/#/c/72452/. We need to decide if this approach is acceptable in order to proceed with the SR-IOV and VIF security implementations. Also, for a similar flow of binding-related information into the plugin/MechanismDriver, I've filed a blueprint to implement the existing binding:profile attribute in ML2: https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile I should have a patch implementing the ml2-binding-profile BP tomorrow. -Bob Both of these are admin-only dictionary attributes on port. One is read-only for output data, the other read-write for input data. Together they enable optional features like SR-IOV PCI passthrough to be implemented in ML2 MechanismDrivers without requiring feature-specific changes to the plugin itself. -Bob If this proposal is agreed to, I can quickly write a neutron BP covering this and provide a generic implementation for ML2. Then [1] and [2] could be updated to use binding:vif_details for the VIF security data and eliminate the existing binding:capabilities attribute. If we take this proposed approach of using binding:vif_details, the internal ML2 handling of binding:vif_type and binding:vif_details could either take the approach used for binding:vif_type and binding:capabilities in the current code, where the values are stored in the port binding DB table. Or they could take the approach in [5] where they are obtained from bound MechanismDriver when needed. Comments on these options are welcome. Please provide feedback on this proposal and the various options in this email thread and/or at today's ML2 sub-team meeting. Thanks, -Bob [1] https://review.openstack.org/#/c/21946/ [2] https://review.openstack.org/#/c/44596/ [3] https://bugs.launchpad.net/nova/+bug/1112912 [4] https://wiki.openstack.org/wiki/Meetings/Passthrough [5] https://review.openstack.org/#/c/69783/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this week
Gary- We do intend to talk about gantt this afternoon, you can join via a Google hangout, it's the first link on this pad: https://etherpad.openstack.org/p/nova-icehouse-mid-cycle-meetup-items -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Monday, February 10, 2014 2:50 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this week Hi, I saw that one of the days there will be talk about Gantt. Would it be possible that people not at the local meet up can join this discussion? Thanks Gary From: Dugger, Donald D donald.d.dug...@intel.commailto:donald.d.dug...@intel.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, February 10, 2014 6:54 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [gantt] Scheduler sub-group meeting 2/11 - Cancel this week Let's cancel the meeting this week, some of us (me for sure) will be tied up at the Icehouse mid-cycle meetup. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Validating Addressing and Routing configuration
During last week's IRC meeting, we ran into a question about validating the configuration options for ipv6_address_mode[1] and ipv6_ra_mode[1] for IPv6 networks. This brought up a few issues, but after mulling it over for a while I think it breaks down into 2 distinct questions. Question 1) Should we allow the user to build a potentially broken network, knowing that there may be a use case we haven't covered? The example of this is a service VM or corner case where it's absolutely mandatory that an administrator use an external routing/addressing mechanism that doesn't fit under our configuration options. I was asked to put together a list of cases where a potentially invalid configuration for OpenStack is still valid when external entities are in use. One of these is setting ipv6_address_mode to stateful and ipv6_ra_mode to none. Normally, this means a neutron network would never have addressed clients as no RA means no address. However, a provider network with an external router would provide this. So having the addressing mode in any state without an RA is still valid. The opposite case would also be true, where an external source could be providing dhcpv6 information. In this case, addressing could be set to off, but RA could be set to stateful/stateless. The only case where I see a collision is where the two attributes are on but in entirely different modes. For example, RA set to SLAAC but addressing set to stateful. Question 2) How do we alert the user of either a potentially invalid configuration or a configuration that we have blocked? Something else that came up in a Review[2] was that we need to honor enable_dhcp and alert the user as well. Per ijw[3], we are supposed to treat enable_dhcp as an overriding flag. If it's set to false, we don't even check the other two attributes, because we should be disabling addressing for this network. I think the answer to #2 should apply here as well, but I wanted to point out that we should be treating enable_dhcp = False as a killswitch. [1] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes [2] https://review.openstack.org/#/c/52983/22/neutron/api/v2/attributes.py [3] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014 -01-21-14.00.log.html timestamp 14:23:54 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
On Mon, Feb 10, 2014 at 11:38:40AM +1300, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. +1! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] logging wsgi requests exactly once ... issues with request usefulness
On Mon, Feb 10, 2014 at 2:56 PM, Sean Dague s...@dague.net wrote: In upstream Nova master we're currently logging ec2 wsgi requests twice, once in the paste pipeline, and once in eventlet. The following patch removes the paste pipeline portion - https://review.openstack.org/#/c/67736/ However... I'm not very satisfied with this approach, as the resulting log entries look as follows (lots more examples at - http://logs.openstack.org/36/67736/7/check/check-tempest-dsvm-full/9b0eb3e/logs/screen-n-api.txt.gz?level=INFO ) ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 2099 time: 0.8823061 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 449 time: 0.1196980 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 2095 time: 0.4743402 ... POST /services/Cloud/ HTTP/1.1 status: 400 len: 360 time: 0.5385840 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 449 time: 0.1317410 Because the eventlet logger is only logging the requestline (which is the URL), Post requests are basically completely information free. We have an equally opaque problem in the Nova API with server actions: ... POST /v2/85979842c31049fab70bcdd399cb9a3f/servers/4d5c5ba0-a975-4f4b-863a-390ad58e1c48/action HTTP/1.1 status: 202 len: 185 time: 1.1360781 Because these aren't really RESTful interfaces, so the url is not useful enough to determine the action. My feeling is that we need to make the wsgi request logs useful enough to know what was actually called on an API call, which means I'm not convinced we can actually use the eventlet logger for Nova, because our URLs aren't actually RESTful. I'm slightly surprised that in v3 we do the same thing. Could we at minimum change action urls to action/ACTIONNAME, or would that completely not work with our router? Yea this is a wsgi thing. I guess we'll need to log action POSTs twice to get enough useful info in the logs. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] logging wsgi requests exactly once ... issues with request usefulness
On 02/10/2014 05:05 PM, Christopher Yeoh wrote: On Mon, Feb 10, 2014 at 2:56 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: In upstream Nova master we're currently logging ec2 wsgi requests twice, once in the paste pipeline, and once in eventlet. The following patch removes the paste pipeline portion - https://review.openstack.org/#/c/67736/ However... I'm not very satisfied with this approach, as the resulting log entries look as follows (lots more examples at - http://logs.openstack.org/36/67736/7/check/check-tempest-dsvm-full/9b0eb3e/logs/screen-n-api.txt.gz?level=INFO) ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 2099 time: 0.8823061 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 449 time: 0.1196980 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 2095 time: 0.4743402 ... POST /services/Cloud/ HTTP/1.1 status: 400 len: 360 time: 0.5385840 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 449 time: 0.1317410 Because the eventlet logger is only logging the requestline (which is the URL), Post requests are basically completely information free. We have an equally opaque problem in the Nova API with server actions: ... POST /v2/85979842c31049fab70bcdd399cb9a3f/servers/4d5c5ba0-a975-4f4b-863a-390ad58e1c48/action HTTP/1.1 status: 202 len: 185 time: 1.1360781 Because these aren't really RESTful interfaces, so the url is not useful enough to determine the action. My feeling is that we need to make the wsgi request logs useful enough to know what was actually called on an API call, which means I'm not convinced we can actually use the eventlet logger for Nova, because our URLs aren't actually RESTful. I'm slightly surprised that in v3 we do the same thing. Could we at minimum change action urls to action/ACTIONNAME, or would that completely not work with our router? Yea this is a wsgi thing. I guess we'll need to log action POSTs twice to get enough useful info in the logs. No, I get that our urls are POST .../action. :) What I'm saying is that isn't a RESTful url. The API end point should be POST .../action/BLAH, and that's what attached to the controller. It seems like given that we haven't yet released the v3 API this is maybe changable. In REST the goal is the URL + Method (GET / PUT / POST / DELETE) is sufficient to determine the action being taken. For our /action API endpoints this is very far from the case. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core
Thanks everyone. It's an honor to join the team. I'm looking forward to meeting you all in Atlanta. On Mon, Feb 10 2014, Jeff Peeler wrote: On Mon, Feb 10, 2014 at 11:38:40AM +1300, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. +1! ___ 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] logging wsgi requests exactly once ... issues with request usefulness
On Mon, Feb 10, 2014 at 3:11 PM, Sean Dague s...@dague.net wrote: On 02/10/2014 05:05 PM, Christopher Yeoh wrote: On Mon, Feb 10, 2014 at 2:56 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: In upstream Nova master we're currently logging ec2 wsgi requests twice, once in the paste pipeline, and once in eventlet. The following patch removes the paste pipeline portion - https://review.openstack.org/#/c/67736/ However... I'm not very satisfied with this approach, as the resulting log entries look as follows (lots more examples at - http://logs.openstack.org/36/67736/7/check/check-tempest-dsvm-full/9b0eb3e/logs/screen-n-api.txt.gz?level=INFO ) ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 2099 time: 0.8823061 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 449 time: 0.1196980 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 2095 time: 0.4743402 ... POST /services/Cloud/ HTTP/1.1 status: 400 len: 360 time: 0.5385840 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 449 time: 0.1317410 Because the eventlet logger is only logging the requestline (which is the URL), Post requests are basically completely information free. We have an equally opaque problem in the Nova API with server actions: ... POST /v2/85979842c31049fab70bcdd399cb9a3f/servers/4d5c5ba0-a975-4f4b-863a-390ad58e1c48/action HTTP/1.1 status: 202 len: 185 time: 1.1360781 Because these aren't really RESTful interfaces, so the url is not useful enough to determine the action. My feeling is that we need to make the wsgi request logs useful enough to know what was actually called on an API call, which means I'm not convinced we can actually use the eventlet logger for Nova, because our URLs aren't actually RESTful. I'm slightly surprised that in v3 we do the same thing. Could we at minimum change action urls to action/ACTIONNAME, or would that completely not work with our router? Yea this is a wsgi thing. I guess we'll need to log action POSTs twice to get enough useful info in the logs. No, I get that our urls are POST .../action. :) What I'm saying is that isn't a RESTful url. The API end point should be POST .../action/BLAH, and that's what attached to the controller. It seems like given that we haven't yet released the v3 API this is maybe changable. Hrm perhaps. Probably require a bit of hacking on wsgi to change how wsgi.action works and then a bunch of unittests and tempest tests updated to allow the patches to merge (unless we allow both types of behaviour in the meantime. However, for a RESTful url api design aren't you meant to avoid using verbs in the URL? Which is why I think the design was done this way in the first place. eg http://stackoverflow.com/questions/2447722/rest-services-exposing-non-data-actions so I'm not convinced we should be changing this. And feature propsal deadline is only a week away anyway. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Proposing Sergey Lukjanov for infra-core
Clark Boylan clark.boy...@gmail.com writes: On Mon, Feb 10, 2014 at 9:48 AM, James E. Blair jebl...@openstack.org wrote: Hi, I'm very pleased to propose that we add Sergey Lukjanov to the infra-core team. He is among the top reviewers of projects in openstack-infra, and is very familiar with how jenkins-job-builder and zuul are used and configured. He has done quite a bit of work in helping new projects through the process and ensuring that changes to the CI system are correct. In addition to providing very helpful reviews he has also contributed significant patches to our Python projects illustrating a high degree of familiarity with the code base and project direction. And as a bonus, we're all looking forward to once again having an infra-core member in a non-US time zone! -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev +1 here. Sergey has done a great job of keeping up with reviews lately, which has been quite helpful. I seem to be Monty's IRC-to-email gateway today. He adds a very emphatic +1, which makes it unanimous. Congratulations, Sergey, and thanks for all the help! -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] logging wsgi requests exactly once ... issues with request usefulness
On 02/10/2014 05:37 PM, Christopher Yeoh wrote: On Mon, Feb 10, 2014 at 3:11 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: On 02/10/2014 05:05 PM, Christopher Yeoh wrote: On Mon, Feb 10, 2014 at 2:56 PM, Sean Dague s...@dague.net mailto:s...@dague.net mailto:s...@dague.net mailto:s...@dague.net wrote: In upstream Nova master we're currently logging ec2 wsgi requests twice, once in the paste pipeline, and once in eventlet. The following patch removes the paste pipeline portion - https://review.openstack.org/#/c/67736/ However... I'm not very satisfied with this approach, as the resulting log entries look as follows (lots more examples at - http://logs.openstack.org/36/67736/7/check/check-tempest-dsvm-full/9b0eb3e/logs/screen-n-api.txt.gz?level=INFO) ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 2099 time: 0.8823061 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 449 time: 0.1196980 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 2095 time: 0.4743402 ... POST /services/Cloud/ HTTP/1.1 status: 400 len: 360 time: 0.5385840 ... POST /services/Cloud/ HTTP/1.1 status: 200 len: 449 time: 0.1317410 Because the eventlet logger is only logging the requestline (which is the URL), Post requests are basically completely information free. We have an equally opaque problem in the Nova API with server actions: ... POST /v2/85979842c31049fab70bcdd399cb9a3f/servers/4d5c5ba0-a975-4f4b-863a-390ad58e1c48/action HTTP/1.1 status: 202 len: 185 time: 1.1360781 Because these aren't really RESTful interfaces, so the url is not useful enough to determine the action. My feeling is that we need to make the wsgi request logs useful enough to know what was actually called on an API call, which means I'm not convinced we can actually use the eventlet logger for Nova, because our URLs aren't actually RESTful. I'm slightly surprised that in v3 we do the same thing. Could we at minimum change action urls to action/ACTIONNAME, or would that completely not work with our router? Yea this is a wsgi thing. I guess we'll need to log action POSTs twice to get enough useful info in the logs. No, I get that our urls are POST .../action. :) What I'm saying is that isn't a RESTful url. The API end point should be POST .../action/BLAH, and that's what attached to the controller. It seems like given that we haven't yet released the v3 API this is maybe changable. Hrm perhaps. Probably require a bit of hacking on wsgi to change how wsgi.action works and then a bunch of unittests and tempest tests updated to allow the patches to merge (unless we allow both types of behaviour in the meantime. However, for a RESTful url api design aren't you meant to avoid using verbs in the URL? Which is why I think the design was done this way in the first place. eg http://stackoverflow.com/questions/2447722/rest-services-exposing-non-data-actions so I'm not convinced we should be changing this. And feature propsal deadline is only a week away anyway. Yeh, timing is unfortunate. I had honestly thought the actions methods were being put into the dustbin, and I apologize for only catching this during the log cleanup. I think this means we clearly need to not use the eventlet logger, and instead do the request logging ourself outside of it. I'm also pretty trepadatious on v3 going forward without the infrastructure to micro version once we get it, because these giant multi year API iterations aren't doing us any favors. We need a way to evolve and fix going forward. Because I don't want to be waiting another year for an API that we can evolve over time. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone][all] Keystone V2 and V3 support in icehouse
Hi, I’m working on a tempest blueprint to make tempest able to run 100% on keystone v3 (or later versions) – the auth version to be used will be available via a configuration switch. The rationale is that Keystone V2 is deprecated in icehouse, V3 being the primary version. Thus it would be good to have (at least) one of the gate jobs running entirely with keystone v3. There are other components beyond tempest that would need some changes to make this happen. Nova and cinder python bindings work only with keystone v2 [0], and as far as I know all core services work with keystone v2 (at least by default). Is there a plan to support identity v3 there until the end of icehouse? If not I think we may have to consider still supporting v2 in icehouse. Andrea [0] https://bugs.launchpad.net/python-novaclient/+bug/1262843 -- Andrea Frittoli IaaS Systems Engineering Team HP Cloud ☁ smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Milestone 1 End to end scenario
Thanks Dev. Done. -Original Message- From: devdatta kulkarni [mailto:devdatta.kulka...@rackspace.com] Sent: Monday, February 10, 2014 12:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Milestone 1 End to end scenario Hi Roshan, Great to see the big picture that we are targeting. Some minor comments/suggestions: 1) It will be helpful to explicitly call out in the first step that the git repositories are not hosted by Solum but are public repositories on github.com 1) In step 3, what do you mean by 'automatic' deployment? I would suggest we remove that word. 2) It will help if we use two different terms to identify the end users of an application and the developer of an application. In the line 'Only authorized users .. access the service', I think you mean 'only application developers who are also registered with Solum will be able to access the Solum API service'. In its current form it is not clear whether 'users' refer to developers or application users and whether 'service' refers to solum API or the running application. Similarly in the last line the last word can be changed from 'user' to 'API user'. Thanks, Devdatta -Original Message- From: Roshan Agrawal roshan.agra...@rackspace.com Sent: Monday, February 10, 2014 12:28pm To: openstack-dev@lists.openstack.org openstack- d...@lists.openstack.org Subject: [openstack-dev] [Solum] Milestone 1 End to end scenario It is exciting to see we are getting close to delivering the first end to end use case for Solum ! Though we have blueprints to track individual work items for Milestone 1, it is useful to have a view into exactly what end to end experience we will be delivering. I have made an attempt at documenting that, and linked to the Solum High Level Roadmap wiki: https://wiki.openstack.org/wiki/Solum/Milestone1 The goal is not to have a comprehensive listing of all features delivered in M1, but rather to summarize in a few lines the desired outcome from a user perspective. Comments, suggestions welcome. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Nominate Oleg Bondarev for Core
All- I’d like to nominate Oleg Bondarev to become a Neutron core reviewer. Oleg has been valuable contributor to Neutron by actively reviewing, working on bugs, and contributing code. Neutron cores please reply back with +1/0/-1 votes. mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] universal wheel support
On Mon, Feb 10, 2014 at 1:14 PM, Joe Gordon joe.gord...@gmail.com wrote: On Mon, Feb 10, 2014 at 9:00 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Sat, Feb 8, 2014 at 7:08 PM, Monty Taylor mord...@inaugust.com wrote: Hey all! There are a bunch of patches adding: [wheel] universal = 1 to setup.cfg: https://review.openstack.org/#/q/status:open+topic:wheel-publish,n,z I wanted to follow up on what the deal is with them, and what I think we should do about them. universal means that a wheel can be made that can work with any python. That's awesome, and we want it - it makes the wheel publishing code easier. I don't think we want it turned on for any project that doesn't, in fact, support python3 - because we'd be producing a wheel that says it works in python3. To be fair - the wheel itself will work just fine in python3 - it's just the software that doesn't - and we upload tarballs right now which don't block attempts to use them in python3. SO - my pedantic side says: Let's only land universal = 1 into python3 supporting projects upon further reflection, I think my other side says: It's fine, let's land it everywhere, it doesn't hurt anything, and then we can stop worrying about it Thoughts? Do we have any non-library projects that support python 3? yes, python-novaclient and many more https://wiki.openstack.org/wiki/Python3 OK, the clients always register with me as libraries even though they include the command line programs. Are we publishing wheels for any of the service apps where python 3 is not supported? It seems safe to just go ahead and use the universal flag, but how much work is it to be correct and only set the flags for projects that are actually universal? What are the ramifications of not using the flag everywhere? Doug Doug Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Proposing Sergey Lukjanov for infra-core
On Mon, Feb 10, 2014 at 12:48 PM, James E. Blair jebl...@openstack.orgwrote: Hi, I'm very pleased to propose that we add Sergey Lukjanov to the infra-core team. He is among the top reviewers of projects in openstack-infra, and is very familiar with how jenkins-job-builder and zuul are used and configured. He has done quite a bit of work in helping new projects through the process and ensuring that changes to the CI system are correct. In addition to providing very helpful reviews he has also contributed significant patches to our Python projects illustrating a high degree of familiarity with the code base and project direction. And as a bonus, we're all looking forward to once again having an infra-core member in a non-US time zone! +1, Sergey has helped us out with reviews for several infra changes we made for Oslo recently. Doug -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] CLI for the new subnet keywords
Hi IPv6 experts, This is regarding the BP - https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes Is it possible to give me a quick example of the CLI that you envision? This is so that the Horizon BP can be updated accordingly. Once the neutron side of things is ready, when creating a subnet, and the version is IPv6 will now enable these two options, yes? Can both options exist or is it an either/or combination, i.e. either ipv6_ra or ipv6_address? Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core
+1 On Tue, Feb 11, 2014 at 7:28 AM, Mark McClain mmccl...@yahoo-inc.comwrote: All- I'd like to nominate Oleg Bondarev to become a Neutron core reviewer. Oleg has been valuable contributor to Neutron by actively reviewing, working on bugs, and contributing code. Neutron cores please reply back with +1/0/-1 votes. mark ___ 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][IPv6] CLI for the new subnet keywords
Hi, Abishek: Thank you for taking care of Horizon for IPv6 enhancement. So now we have coverage on both CLI and dashboard side. Very exciting! W.r.t your questions, these two parameters work independently. In other words, Horizon should present both options if the interested subnet is IPv6. For each parameter, the valid values are: off slacc dhcpv6-stateful dhcpv6-stateless The CLI command may look like, for example, something below: neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode off NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode dhcpv6-stateful NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode slaac --ipv6_address_mode slaac NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateful --ipv6_address_mode off NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateless --ipv6_address_mode dhcpv6-stateless NETWORK CIDR The valid combinations are outlined in the PDF file below. https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf Please let me know if you have any further questions. Thanks! Shixiong On Feb 10, 2014, at 8:23 PM, Abishek Subramanian (absubram) absub...@cisco.com wrote: Hi IPv6 experts, This is regarding the BP - https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes Is it possible to give me a quick example of the CLI that you envision? This is so that the Horizon BP can be updated accordingly. Once the neutron side of things is ready, when creating a subnet, and the version is IPv6 will now enable these two options, yes? Can both options exist or is it an either/or combination, i.e. either ipv6_ra or ipv6_address? Thanks! ___ 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] [heat] Nominate Jason Dunsmore for heat-core
+1! On 02/10/2014 06:38 AM, Steve Baker wrote: I would like to nominate Jason Dunsmore for heat-core. His reviews are valuable and prolific, his code contributions have demonstrated a good knowledge of heat internals, and he has endured a sound hazing to get multi-engine into heat. http://russellbryant.net/openstack-stats/heat-reviewers-60.txt http://www.stackalytics.com/?release=icehousemetric=commitsuser_id=jasondunsmore Heat cores, please reply with your vote. cheers ___ 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] Nominate Oleg Bondarev for Core
+1 On Tue, Feb 11, 2014 at 10:10 AM, Yongsheng Gong gong...@unitedstack.comwrote: +1 On Tue, Feb 11, 2014 at 7:28 AM, Mark McClain mmccl...@yahoo-inc.comwrote: All- I'd like to nominate Oleg Bondarev to become a Neutron core reviewer. Oleg has been valuable contributor to Neutron by actively reviewing, working on bugs, and contributing code. Neutron cores please reply back with +1/0/-1 votes. mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [group-policy] Changing the meeting time
Folks: I’d like to propose moving the Neutron Group Policy meeting going forward, starting with this Thursday. The meeting has been at 1600 UTC on Thursdays, I’d like to move this to 1700UTC Thursdays on #openstack-meeting-alt. If this is a problem for anyone who regularly attends this meeting, please reply here. If I don’t hear any replies by Wednesday, I’ll officially move the meeting. Thanks! Kyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core
+1 On Feb 10, 2014, at 5:28 PM, Mark McClain mmccl...@yahoo-inc.com wrote: All- I’d like to nominate Oleg Bondarev to become a Neutron core reviewer. Oleg has been valuable contributor to Neutron by actively reviewing, working on bugs, and contributing code. Neutron cores please reply back with +1/0/-1 votes. mark ___ 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] Nominate Oleg Bondarev for Core
+1 -Original Message- From: Mark McClain [mailto:mmccl...@yahoo-inc.com] Sent: Tuesday, February 11, 2014 4:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core All- I'd like to nominate Oleg Bondarev to become a Neutron core reviewer. Oleg has been valuable contributor to Neutron by actively reviewing, working on bugs, and contributing code. Neutron cores please reply back with +1/0/-1 votes. mark ___ 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] Support for multiple provider networks with same VLAN segmentation id
Bob and Kyle, Thanks for your review. We looked at this option and it seems it might meet our needs. Here is what we intend to do: Let's say we have three racks (each rack supports three VLANs - 100, 200 and 300). We create the following config file for the neutron server tenant_network_type = vlan network_vlan_ranges = physnet1:100:300 network_vlan_ranges = phynet2:100:300 network_vlan_ranges = phynet3:100:300 integration_bridge = br-int bridge_mappings = physnet1:br-eth1, physnet2:br-eth1, physnet3:br-eth1 Is this what you meant? Vinay On Sun, Feb 9, 2014 at 6:03 PM, Robert Kukura rkuk...@redhat.com wrote: On 02/09/2014 12:56 PM, Kyle Mestery wrote: On Feb 6, 2014, at 5:24 PM, Vinay Bannai vban...@gmail.com wrote: Hello Folks, We are running into a situation where we are not able to create multiple provider networks with the same VLAN id. We would like to propose a solution to remove this restriction through a configuration option. This approach would not conflict with the present behavior where it is not possible to create multiple provider networks with the same VLAN id. The changes should be minimal and would like to propose it for the next summit. The use case for this need is documented in the blueprint specification. Any feedback or comments are welcome. https://blueprints.launchpad.net/neutron/+spec/duplicate-providernet-vlans Hi Vinay: This problem seems straightforward enough, though currently you are right in that we don't allow multiple Neutron networks to have the same segmentation ID. I've added myself as approver for this BP and look forward to further discussions of this before and during the upcoming Summit! Multiple networks with network_type of 'vlan' are already allowed to have the same segmentation ID with the ml2, openvswitch, or linuxbridge plugins - the networks just need to have different physical_network names. If they have the same network_type, physical_network, and segmentation_id, they are the same network. What else would distinguish them from each other? Could your use case be addressed by simply using different physical_network names for each rack? This would provide independent spaces of segmentation_ids for each. -Bob Thanks! Kyle Thanks -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ 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 -- Vinay Bannai Email: vban...@gmail.com Google Voice: 415 938 7576 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] in-instance update hooks
Hi, so in the previous thread about rolling updates it became clear that having in-instance control over updates is a more fundamental idea than I had previously believed. During an update, Heat does things to servers that may interrupt the server's purpose, and that may cause it to fail subsequent things in the graph. Specifically, in TripleO we have compute nodes that we are managing. Before rebooting a machine, we want to have a chance to live-migrate workloads if possible, or evacuate in the simpler case, before the node is rebooted. Also in the case of a Galera DB where we may even be running degraded, we want to ensure that we have quorum before proceeding. I've filed a blueprint for this functionality: https://blueprints.launchpad.net/heat/+spec/update-hooks I've cobbled together a spec here, and I would very much welcome edits/comments/etc: https://etherpad.openstack.org/p/heat-update-hooks ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Validating Addressing and Routing configuration
For Question 1, I think we can allow potential use cases (even OpenStack doesn't support it for now), but we should not permit the combinations of modes which don't make any sense. For Question 2, for modes which don't make sense, I think error messages and return code are needed. For mode combinations which require external RA or DHCP, I think it's not OpenStack's job to check the external configurations so we can just configure as the mode suggested in OpenStack and leave the user/admin to configure the external server. Xuhan On Tue, Feb 11, 2014 at 4:38 AM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: During last week's IRC meeting, we ran into a question about validating the configuration options for ipv6_address_mode[1] and ipv6_ra_mode[1] for IPv6 networks. This brought up a few issues, but after mulling it over for a while I think it breaks down into 2 distinct questions. Question 1) Should we allow the user to build a potentially broken network, knowing that there may be a use case we haven't covered? The example of this is a service VM or corner case where it's absolutely mandatory that an administrator use an external routing/addressing mechanism that doesn't fit under our configuration options. I was asked to put together a list of cases where a potentially invalid configuration for OpenStack is still valid when external entities are in use. One of these is setting ipv6_address_mode to stateful and ipv6_ra_mode to none. Normally, this means a neutron network would never have addressed clients as no RA means no address. However, a provider network with an external router would provide this. So having the addressing mode in any state without an RA is still valid. The opposite case would also be true, where an external source could be providing dhcpv6 information. In this case, addressing could be set to off, but RA could be set to stateful/stateless. The only case where I see a collision is where the two attributes are on but in entirely different modes. For example, RA set to SLAAC but addressing set to stateful. Question 2) How do we alert the user of either a potentially invalid configuration or a configuration that we have blocked? Something else that came up in a Review[2] was that we need to honor enable_dhcp and alert the user as well. Per ijw[3], we are supposed to treat enable_dhcp as an overriding flag. If it's set to false, we don't even check the other two attributes, because we should be disabling addressing for this network. I think the answer to #2 should apply here as well, but I wanted to point out that we should be treating enable_dhcp = False as a killswitch. [1] https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes [2] https://review.openstack.org/#/c/52983/22/neutron/api/v2/attributes.py [3] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014 -01-21-14.00.log.html timestamp 14:23:54 ___ 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] How to write a new neutron L2 plugin using ML2 framework?
Thank you for your detailed info, but I want to implement this in Havana release, mlnx is a good reference, what I want to implement on Intel NIC is similar to mlnx, but it is a standalone plugin and didn't use ML2 framework, I want to use ML2 framework, I think nova has supported SR-IOV in Havana, so I just need to implement Neutron part, I hope you can provide some guide about this. BTW, We can't afford to wait Icehouse release. -Original Message- From: Irena Berezovsky [mailto:ire...@mellanox.com] Sent: Monday, February 10, 2014 8:11 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Yang, Yi Y Subject: RE: [openstack-dev] How to write a new neutron L2 plugin using ML2 framework? Hi, As stated below, we are already having this work both in nova and neuron. Please take a look at the following discussions: https://wiki.openstack.org/wiki/Meetings#PCI_Passthrough_Meeting For neutron part there are two different flavors that are coming as part of this effort: 1. Cisco SRIOV supporting 802.1QBH - no L2 agent 2. Mellanox Flavor - SRIOV embedded switch (HW_VEB) - with L2 agent. My guess is that second flavor of SRIOV embedded switch should work for Intel NICs as well. Please join the PCI pass-through meeting discussions to see that you do not do any redundant work or just follow-up on mailing list. BR, Irena -Original Message- From: Mathieu Rohon [mailto:mathieu.ro...@gmail.com] Sent: Monday, February 10, 2014 1:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] How to write a new neutron L2 plugin using ML2 framework? Hi, SRIOV is under implementation in nova and neutron. Did you have a look to : https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov On Mon, Feb 10, 2014 at 7:27 AM, Isaku Yamahata isaku.yamah...@gmail.com wrote: On Sat, Feb 08, 2014 at 03:49:46AM +, Yang, Yi Y yi.y.y...@intel.com wrote: Hi, All Hi. I want to write a new neutron L2 plugin using ML2 framework, I noticed openvswitch and linxubridge have been ported into ML2 framework, but it seems many code is removed compared to standalone L2 plugin, I guess some code has been written into a common library. Now I want to write a L2 plugin to enable switch for a SR-IOV 10g NIC, I think I need to write as follows: having such a feature would be awesome : did you fill a BP for that? 1. a new mechanism driver neutron/plugins/ml2/drivers/mech_XXX.py, but from source code, it seems nothing to do. You mean, you want to use AgentMechanismDriverBase directly? this is an abstract class du to check_segment_for_agent method. This requires to define how your plugin utilize network. If multi tenant network is wanted, what/how technology will be used. The common one is VLAN or tunneling(GRE, VXLAN). This depends on what feature your NIC supports. 2. a new agent neutron/plugins/XXX/ XXX_neutron_plugin.py I don't know if this would be mandatory. May be you can just add necessary informations with extend_port_dict while your MD bind the port, as proposed by this patch : https://review.openstack.org/#/c/69783/ Nova will then configure the port correctly. The only need for an agent would be to populate the agent DB with supported segment types, so that during bind_port, the MD find an appropriate segment (with check_segment_for_agent). After this, an issue it how to let neutron know it and load it by default or by configuration. Debugging is also an issue, nobody can write code correctly once :-), does neutron have any good debugging way for a newbie? LOG.debug and debug middle ware. If there are any other better way, I'd also like to know. thanks, I'm very eager to be able to get your help and sincerely thank you in advance. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Ready to import Launchpad Answers into Ask OpenStack
Awesome! Stefano, is it possible to import savanna's answers@launchpad to ask.o.o? Thanks. On Fri, Feb 7, 2014 at 12:01 AM, Russell Bryant rbry...@redhat.com wrote: On 02/06/2014 12:07 PM, Stefano Maffulli wrote: Hello folks, we're ready to import the answers from Launchpad into Ask OpenStack. A script will import all questions, answers, comments (and data abou user accounts) from LP into Ask, tag them as the project of origin (nova, swift, etc). You can see the results of the test runs on http://ask-staging.openstack.org/en/questions/ For example, the questions migrated from LP Answers Swift are http://ask-staging.openstack.org/en/questions/scope:all/sort:activity-desc/tags:swift/page:1/ We'll try also to sync accounts already existing on Ask with those imported from LP, matching on usernames, OpenID and email addresses as exposed by LP API. If there is no match, a new account will be created. I'm writing to you to make sure that you're aware of this effort and to ask you if you are really, adamantly against closing LP Answers. In case you are against, I'll try to convince you otherwise :) You can see the history of the effort and its current status on https://bugs.launchpad.net/openstack-community/+bug/1212089 Next step is to set a date to run the import. The process will be: 1 - run the import script 2 - put Ask down for maintenance 3 - import data into Ask 4 - check that it run correctly 5 - close all LP Answers, reconfigure LP projects to redirect to Ask I think we can run this process one project at the time so we minimize interruptions. If the PTLs authorize me I think I have the necessary permissions to edit LP Answers, remove the archives from the public once the data is replicated correctly on Ask, so you can focus on coding. Let me know what you think about closing LP Answers, use Ask exclusively to handle support requests and about delegating to me closing LP Answers for your projects. All sounds good to me! Thanks for doing this! -- Russell Bryant -- Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tempest] Bluiprint for improvement neutron test coverage
Hello! I'm amoung people who are working on improvement neutron test coverage. Over work is cooperating on etherpad page https://etherpad.openstack.org/p/icehouse-summit-qa-neutron. Meanwhile some reviewers ask for blueprint or bug report to be associated with change. That's why I created this blueprint https://blueprints.launchpad.net/tempest/+spec/improve-neutron-test-coverage. So everybody who has the same questions can use link to this blueprint in his commit message (partially implement bp: improve-neutron-test-coverage). It is not necessary if you has good progress on your change and do not want to change commit message. This also could help to avoid duplication in work that sometimes happens. Ann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Ready to import Launchpad Answers into Ask OpenStack
Hi Sergey On Tue 11 Feb 2014 08:01:48 AM CET, Sergey Lukjanov wrote: Stefano, is it possible to import savanna's answers@launchpad to ask.o.o? Yes, indeed. I apologize for not putting you explicitly in the cc list. The full list of projects we'll work on is on the bug itself: https://bugs.launchpad.net/openstack-community/+bug/1212089 savanna was already there, I must have overlooked your email when composing this request. We'll be importing during the next few days. Regards, Stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
