Re: [openstack-dev] / IDS + openstack meeting in Vancouver 4:10 Wednesday May 20
Hi Dan et.al
Thanks for reaching out, I attended your IDS talk yesterday and we can meet up
after our TaaS tech talk where we do a walk through from the why, what and how
and a demo with detail explanations on its built.
/Alan
-Original Message-
From: Dan Lambright [mailto:dlamb...@redhat.com]
Sent: May-19-15 2:30 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [security] / IDS + openstack meeting in Vancouver 4:10
Wednesday May 20
Hello,
While at the Vancouver summit, it would be good to have an informal meeting on
IDS + openstack. My understanding is there has not been a community driven
effort in this area to date. It would be good to kick something off. Likely
subjects would be neutron plug-ins and scalability (management and monitoring).
The best time would probably be after the TaaS talk Wednesday. TaaS may
influence what direction to take.
I will be next to the ATM machine on the 1st floor, next to where they give
away the windbreaker SWAG. I’ll hang out there between 4:10 and 4:30. Please
feel free to find a drink and walk over. I will also post this announcement to
the openstack-dev mailing list
(http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev). The
subject will contain: [security] {IDS}
Thanks,
Dan Lambright
Red Hat
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Data-plane performance testing with Shaker
Hi Ilya I am interested in this and many thanks for posting this. I have to ask how relevant the performance testing is given that Neutron overlays are dependent on the underlay? I believe your point 4 below I can see some uses and value for, but I am struggling to this been used as a “tool for data-plane performance testing” in Neutron networks. I look forward to the lightning talks. /Alan From: Ilya Shakhat [mailto:ishak...@mirantis.com] Sent: May-14-15 11:30 PM To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) Subject: [openstack-dev] [Neutron] Data-plane performance testing with Shaker Hi all! Let me introduce you Shaker - a tool for data-plane performance testing in OpenStack. The motivation behind it is to have a simple way for measuring networking bandwidth between instances. Shaker key features are: 1. User-defined topology. The topology is specified as Heat template, so users may do arbitrary configuration for instances, networks, routers, floating ips, etc. Instance scheduling is controlled, it is possible to specify number of instances per compute node and their location. 2. Simultaneous test execution. By default Shaker runs tests synchronously on all deployed instances. It is also possible to increase the load, thus measuring dependency on number of concurrently working instances. The feature is useful when one needs to find bottleneck in the cloud (like usage of non-DVR routers). 3. Pluggable tools. Out of the box Shaker supports iperf, netperf and able to calculate aggregated stats based on their output. Adding a new tool is easy, in the simplest case it does not even require coding. 4. Interactive report. Shaker produces report as single-page HTML application. The report contains aggregated charts for bandwidth depending on concurrency, bandwidth per node and precise timeline of traffic on every node. The report does not have any dependencies and can be shared easily. If you are interested in knowing more about Shaker welcome to Neutron Lightning talk presentation by Oleg Bondarev next Wed in Vancouver (http://sched.co/3BNR). And certainly welcome to use and contribute! Code: https://github.com/stackforge/shaker Docs: http://pyshaker.readthedocs.org/ Launchpad: https://launchpad.net/shaker/ PyPi - https://pypi.python.org/pypi/pyshaker/ Thanks, Ilya __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
+1 yep, as an NFV vendor this is how it really works, and no need for an active/standby on ports….does not make sense for this type of deployment scenario. Typically the two or more sets of apps synch together and address the failover/HA, so no need to make this also in the Infra….you gain nothing from doing active-standby port mgmt. in ovs. /Alan From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: October-31-14 11:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Go read about HSRP and VRRP. What you propose is akin to turning off one physical switch port and turning on another when you want to switch from an active physical server to a standby, and this is not how it's done in practice; instead, you connect the two VMs to the same network and let them decide which gets the primary address. On 28 October 2014 10:27, A, Keshava keshav...@hp.commailto:keshav...@hp.com wrote: Hi Alan and Salvatore, Thanks for response and I also agree we need to take small steps. However I have below points to make. It is very important how the Service VM needs will be deployed w.r.t HA. As per current discussion, you are proposing something like below kind of deployment for Carrier Grade HA. Since there is a separate port for Standby-VM also, then the corresponding standby-VM interface address should be globally routable also. Means it may require the Standby Routing protocols to advertise its interface as Next-HOP for prefix it routes. However external world should not be aware of the standby-routing running in the network. [cid:image001.png@01CFF601.E49C6A50] [cid:image002.png@01CFF601.E49C6A50] Instead if we can think of running Standby on same stack with Passive port, ( as shown below) then external world will be unaware of the standing Service Routing running. This may be something very basic requirement from Service-VM (NFV HA perspective) for Routing/MPLS/Packet processing domain. I am brining this issue now itself, because you are proposing to change the basic framework of packer delivering to VM’s. (Of course there may be other mechanism of supporting redundancy, however it will not be as efficient as that of handing at packet level). [cid:image003.png@01CFF601.E49C6A50] Thanks regards, Keshava From: Alan Kavanagh [mailto:alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com] Sent: Tuesday, October 28, 2014 6:48 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Hi Salvatore Inline below. From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: October-28-14 12:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Keshava, I think the thread is not going a bit off its stated topic - which is to discuss the various proposed approaches to vlan trunking. Regarding your last post, I'm not sure I saw either spec implying that at the data plane level every instance attached to a trunk will be implemented as a different network stack. AK-- Agree Also, quoting the principle earlier cited in this thread - make the easy stuff easy and the hard stuff possible - I would say that unless five 9s is a minimum requirement for a NFV application, we might start worrying about it once we have the bare minimum set of tools for allowing a NFV application over a neutron network. AK-- five 9’s is a 100% must requirement for NFV, but lets ensure we don’t mix up what the underlay service needs to guarantee and what openstack needs to do to ensure this type of service. Would agree, we should focus more on having the right configuration sets for onboarding NFV which is what Openstack needs to ensure is exposed then what is used underneath guarantee the 5 9’s is a separate matter. I think Ian has done a good job in explaining that while both approaches considered here address trunking for NFV use cases, they propose alternative implementations which can be leveraged in different way by NFV applications. I do not see now a reason for which we should not allow NFV apps to leverage a trunk network or create port-aware VLANs (or maybe you can even have VLAN aware ports which tap into a trunk network?) AK-- Agree, I think we can hammer this out once and for all in Paris…….this feature has been lingering too long. We may continue discussing the pros and cons of each approach - but to me it's now just a matter of choosing the best solution for exposing them at the API layer. At the control/data plane layer, it seems to me that trunk networks are pretty much straightforward. VLAN aware ports are instead a bit more convoluted, but not excessively complicated in my opinion. AK-- My thinking too Salvatore, lets ensure the right elements are exposed at API Layer, I would also go a little
Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
Hi Please find some additions to Ian and responses below. /Alan From: A, Keshava [mailto:keshav...@hp.com] Sent: October-28-14 9:57 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Hi, Pl fine the reply for the same. Regards, keshava From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: Tuesday, October 28, 2014 1:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints This all appears to be referring to trunking ports, rather than anything else, so I've addressed the points in that respect. On 28 October 2014 00:03, A, Keshava keshav...@hp.commailto:keshav...@hp.com wrote: Hi, 1. How many Trunk ports can be created ? Why would there be a limit? Will there be any Active-Standby concepts will be there ? I don't believe active-standby, or any HA concept, is directly relevant. Did you have something in mind? For the NFV kind of the scenario, it is very much required to run the ‘Service VM’ in Active and Standby Mode. AK-- We have a different view on this, the “application runs as a pair” of which the application either runs in active-active or active standby…this has nothing to do with HA, its down to the application and how its provisioned and configured via Openstack. So agree with Ian on this. Standby is more of passive entity and will not take any action to external network. It will be passive consumer of the packet/information. AK-- Why would we need to care? In that scenario it will be very meaningful to have “Active port – connected to “Active Service VM”. “Standby port – connected to ‘Standby Service VM’. Which will turn Active when old Active-VM goes down ? AK-- Cant you just have two VM’s and then via a controller decide how to address MAC+IP_Address control…..FYI…most NFV Apps have that built-in today. Let us know others opinion about this concept. AK--Perhaps I am miss reading this but I don’t understand what this would provide as opposed to having two VM’s instantiated and running, why does Neutron need to care about the port state between these two VM’s? Similarly its better to just have 2 or more VM’s up and the application will be able to address when failover occurs/requires. Lets keep it simple and not mix up with what the apps do inside the containment. 2. Is it possible to configure multiple IP address configured on these ports ? Yes, in the sense that you can have addresses per port. The usual restrictions to ports would apply, and they don't currently allow multiple IP addresses (with the exception of the address-pair extension). In case IPv6 there can be multiple primary address configured will this be supported ? No reason why not - we're expecting to re-use the usual port, so you'd expect the features there to apply (in addition to having multiple sets of subnet on a trunking port). 3. If required can these ports can be aggregated into single one dynamically ? That's not really relevant to trunk ports or networks. 4. Will there be requirement to handle Nested tagged packet on such interfaces ? For trunking ports, I don't believe anyone was considering it. Thanks Regards, Keshava From: Ian Wells [mailto:ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk] Sent: Monday, October 27, 2014 9:45 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints On 25 October 2014 15:36, Erik Moe erik@ericsson.commailto:erik@ericsson.com wrote: Then I tried to just use the trunk network as a plain pipe to the L2-gateway and connect to normal Neutron networks. One issue is that the L2-gateway will bridge the networks, but the services in the network you bridge to is unaware of your existence. This IMO is ok then bridging Neutron network to some remote network, but if you have an Neutron VM and want to utilize various resources in another Neutron network (since the one you sit on does not have any resources), things gets, let’s say non streamlined. Indeed. However, non-streamlined is not the end of the world, and I wouldn't want to have to tag all VLANs a port is using on the port in advance of using it (this works for some use cases, and makes others difficult, particularly if you just want a native trunk and are happy for Openstack not to have insight into what's going on on the wire). Another issue with trunk network is that it puts new requirements on the infrastructure. It needs to be able to handle VLAN tagged frames. For a VLAN based network it would be QinQ. Yes, and that's the point of the VLAN trunk spec, where we flag a network as passing VLAN tagged packets; if the operator-chosen network implementation doesn't support trunks, the API can refuse to make a trunk network. Without it we're still in the situation
Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
Hi Salvatore Inline below. From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: October-28-14 12:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Keshava, I think the thread is not going a bit off its stated topic - which is to discuss the various proposed approaches to vlan trunking. Regarding your last post, I'm not sure I saw either spec implying that at the data plane level every instance attached to a trunk will be implemented as a different network stack. AK-- Agree Also, quoting the principle earlier cited in this thread - make the easy stuff easy and the hard stuff possible - I would say that unless five 9s is a minimum requirement for a NFV application, we might start worrying about it once we have the bare minimum set of tools for allowing a NFV application over a neutron network. AK-- five 9’s is a 100% must requirement for NFV, but lets ensure we don’t mix up what the underlay service needs to guarantee and what openstack needs to do to ensure this type of service. Would agree, we should focus more on having the right configuration sets for onboarding NFV which is what Openstack needs to ensure is exposed then what is used underneath guarantee the 5 9’s is a separate matter. I think Ian has done a good job in explaining that while both approaches considered here address trunking for NFV use cases, they propose alternative implementations which can be leveraged in different way by NFV applications. I do not see now a reason for which we should not allow NFV apps to leverage a trunk network or create port-aware VLANs (or maybe you can even have VLAN aware ports which tap into a trunk network?) AK-- Agree, I think we can hammer this out once and for all in Paris…….this feature has been lingering too long. We may continue discussing the pros and cons of each approach - but to me it's now just a matter of choosing the best solution for exposing them at the API layer. At the control/data plane layer, it seems to me that trunk networks are pretty much straightforward. VLAN aware ports are instead a bit more convoluted, but not excessively complicated in my opinion. AK-- My thinking too Salvatore, lets ensure the right elements are exposed at API Layer, I would also go a little further to ensure we get those feature sets to be supported into the Core API (another can of worms discussion but we need to have it). Salvatore On 28 October 2014 11:55, A, Keshava keshav...@hp.commailto:keshav...@hp.com wrote: Hi, Pl find my reply .. Regards, keshava From: Alan Kavanagh [mailto:alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com] Sent: Tuesday, October 28, 2014 3:35 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Hi Please find some additions to Ian and responses below. /Alan From: A, Keshava [mailto:keshav...@hp.com] Sent: October-28-14 9:57 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Hi, Pl fine the reply for the same. Regards, keshava From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: Tuesday, October 28, 2014 1:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints This all appears to be referring to trunking ports, rather than anything else, so I've addressed the points in that respect. On 28 October 2014 00:03, A, Keshava keshav...@hp.commailto:keshav...@hp.com wrote: Hi, 1. How many Trunk ports can be created ? Why would there be a limit? Will there be any Active-Standby concepts will be there ? I don't believe active-standby, or any HA concept, is directly relevant. Did you have something in mind? For the NFV kind of the scenario, it is very much required to run the ‘Service VM’ in Active and Standby Mode. AK-- We have a different view on this, the “application runs as a pair” of which the application either runs in active-active or active standby…this has nothing to do with HA, its down to the application and how its provisioned and configured via Openstack. So agree with Ian on this. Standby is more of passive entity and will not take any action to external network. It will be passive consumer of the packet/information. AK-- Why would we need to care? In that scenario it will be very meaningful to have “Active port – connected to “Active Service VM”. “Standby port – connected to ‘Standby Service VM’. Which will turn Active when old Active-VM goes down ? AK-- Cant you just have two VM’s and then via a controller decide how to address MAC+IP_Address control…..FYI…most NFV Apps have that built-in today. Let us know others opinion about this concept. AK--Perhaps I am miss reading this but I don’t understand what this would
Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
+1 many thanks to Kyle for putting this as a priority, its most welcome. /Alan -Original Message- From: Erik Moe [mailto:erik@ericsson.com] Sent: October-22-14 5:01 PM To: Steve Gordon; OpenStack Development Mailing List (not for usage questions) Cc: iawe...@cisco.com Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Hi, Great that we can have more focus on this. I'll attend the meeting on Monday and also attend the summit, looking forward to these discussions. Thanks, Erik -Original Message- From: Steve Gordon [mailto:sgor...@redhat.com] Sent: den 22 oktober 2014 16:29 To: OpenStack Development Mailing List (not for usage questions) Cc: Erik Moe; iawe...@cisco.com; calum.lou...@metaswitch.com Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints - Original Message - From: Kyle Mestery mest...@mestery.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org There are currently at least two BPs registered for VLAN trunk support to VMs in neutron-specs [1] [2]. This is clearly something that I'd like to see us land in Kilo, as it enables a bunch of things for the NFV use cases. I'm going to propose that we talk about this at an upcoming Neutron meeting [3]. Given the rotating schedule of this meeting, and the fact the Summit is fast approaching, I'm going to propose we allocate a bit of time in next Monday's meeting to discuss this. It's likely we can continue this discussion F2F in Paris as well, but getting a head start would be good. Thanks, Kyle [1] https://review.openstack.org/#/c/94612/ [2] https://review.openstack.org/#/c/97714 [3] https://wiki.openstack.org/wiki/Network/Meetings Hi Kyle, Thanks for raising this, it would be great to have a converged plan for addressing this use case [1] for Kilo. I plan to attend the Neutron meeting and I've CC'd Erik, Ian, and Calum to make sure they are aware as well. Thanks, Steve [1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/047548.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] ETSI NFV gap analysis [NFV]
I believe pointing it to the NFV Wiki would be good and that way it can be discussed during one of the weekly meetings run by Steven et.al and match the list to what is being requested to what is identified in the wiki list as a good starting point. /Alan -Original Message- From: Sylvain Bauza [mailto:sba...@redhat.com] Sent: October-06-14 9:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] ETSI NFV gap analysis [NFV] Le 05/10/2014 09:22, MENDELSOHN, ITAI (ITAI) a écrit : Team, Following my action item from last week IRC. It seems that the document is ready for submission by ETSI NFV team. It was written in a liaison form as this is how they are used to operate. They are wondering who should they send it to... IMHO it seems a good idea that the NFV sub group will receive it in behalf of the community. Thoughts? Itai I don't know the legal conditions of the publication of this document, but I would assume it would be worth of interest within the whole OpenStack community so anyone could see what's missing and contribute to it. At least pointing the document to the NFV wiki page sounds important, provided this communication can be done this way (ie. no opt-in list for people looking at the doc) -Sylvain Sent from my iPhone ___ 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] [all][tripleo] New Project - Kolla: Deploy and Manage OpenStack using Kubernetes and Docker
Steven I have to ask what is the motivation and benefits we get from integrating Kubernetes into Openstack? Would be really useful if you can elaborate and outline some use cases and benefits Openstack and Kubernetes can gain. /Alan From: Steven Dake [mailto:sd...@redhat.com] Sent: September-24-14 7:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all][tripleo] New Project - Kolla: Deploy and Manage OpenStack using Kubernetes and Docker On 09/24/2014 10:12 AM, Joshua Harlow wrote: Sounds like an interesting project/goal and will be interesting to see where this goes. A few questions/comments: How much golang will people be exposed to with this addition? Joshua, I expect very little. We intend to use Kubernetes as an upstream project, rather then something we contribute to directly. Seeing that this could be the first 'go' using project it will be interesting to see where this goes (since afaik none of the infra support exists, and people aren't likely to familiar with go vs python in the openstack community overall). What's your thoughts on how this will affect the existing openstack container effort? I don't think it will have any impact on the existing Magnum project. At some point if Magnum implements scheduling of docker containers, we may add support for Magnum in addition to Kubernetes, but it is impossible to tell at this point. I don't want to derail either project by trying to force them together unnaturally so early. I see that kubernetes isn't exactly a small project either (~90k LOC, for those who use these types of metrics), so I wonder how that will affect people getting involved here, aka, who has the resources/operators/other... available to actually setup/deploy/run kubernetes, when operators are likely still just struggling to run openstack itself (at least operators are getting used to the openstack warts, a new set of kubernetes warts could not be so helpful). Yup it is fairly large in size. Time will tell if this approach will work. This is an experiment as Robert and others on the thread have pointed out :). Regards -steve On Sep 23, 2014, at 3:40 PM, Steven Dake sd...@redhat.commailto:sd...@redhat.com wrote: Hi folks, I'm pleased to announce the development of a new project Kolla which is Greek for glue :). Kolla has a goal of providing an implementation that deploys OpenStack using Kubernetes and Docker. This project will begin as a StackForge project separate from the TripleO/Deployment program code base. Our long term goal is to merge into the TripleO/Deployment program rather then create a new program. Docker is a container technology for delivering hermetically sealed applications and has about 620 technical contributors [1]. We intend to produce docker images for a variety of platforms beginning with Fedora 20. We are completely open to any distro support, so if folks want to add new Linux distribution to Kolla please feel free to submit patches :) Kubernetes at the most basic level is a Docker scheduler produced by and used within Google [2]. Kubernetes has in excess of 100 technical contributors. Kubernetes is more then just a scheduler, it provides additional functionality such as load balancing and scaling and has a significant roadmap. The #tripleo channel on Freenode will be used for Kolla developer and user communication. Even though we plan to become part of the Deployment program long term, as we experiment we believe it is best to hold a separate weekly one hour IRC meeting on Mondays at 2000 UTC in #openstack-meeting [3]. This project has been discussed with the current TripleO PTL (Robert Collins) and he seemed very supportive and agreed with the organization of the project outlined above. James Slagle, a TripleO core developer, has kindly offered to liase between Kolla and the broader TripleO community. I personally feel it is necessary to start from a nearly empty repository when kicking off a new project. As a result, there is limited code in the repository [4] at this time. I suspect folks will start cranking out a kick-ass implementation once the Kolla/Stackforge integration support is reviewed by the infra team [5]. The initial core team is composed of Steven Dake, Ryan Hallisey, James Lebocki, Jeff Peeler, James Slagle, Lars Kellogg-Sedman, and David Vossel. The core team will be reviewed every 6 weeks to add fresh developers. Please join the core team in designing and inventing this rockin' new technology! Regards -steve ~~ [1] https://github.com/docker/docker [2] https://github.com/GoogleCloudPlatform/kubernetes [3] https://wiki.openstack.org/wiki/Meetings/Kolla [4] https://github.com/jlabocki/superhappyfunshow [5] https://review.openstack.org/#/c/122972/ ___ OpenStack-dev mailing list
Re: [openstack-dev] [nova] [neutron] Specs for K release
How to do we handle specs that have slipped through the cracks and did not make it for Juno? /Alan From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: August-28-14 9:48 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] [neutron] Specs for K release I think it's ok to submit specs for Kilo - mostly because it would be a bit pointless submitting them for Juno! Salvatore On 28 August 2014 09:26, Kevin Benton blak...@gmail.commailto:blak...@gmail.com wrote: You could just make the kilo folder in your commit and then rebase it once Kilo is open. On Thu, Aug 28, 2014 at 12:07 AM, Andreas Scheuring scheu...@linux.vnet.ibm.commailto:scheu...@linux.vnet.ibm.com wrote: Hi, is it already possible to submit specs (nova neutron) for the K release? Would be great for getting early feedback and tracking comments. Or should I just commit it to the juno folder? Thanks, Andreas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Is the BP approval process broken?
+1, that would be the most pragmatic way to address this, silence has different meanings to different people, a response would clarify the ambiguity and misunderstanding. /Alan -Original Message- From: Chris Friesen [mailto:chris.frie...@windriver.com] Sent: August-28-14 11:18 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Is the BP approval process broken? On 08/28/2014 03:02 PM, Jay Pipes wrote: I understand your frustration about the silence, but the silence from core team members may actually be a loud statement about where their priorities are. Or it could be that they haven't looked at it, aren't aware of it, or haven't been paying attention. I think it would be better to make feedback explicit and remove any uncertainty/ambiguity. Chris ___ 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] Is the BP approval process broken?
I don't think silence ever helps, its better to respond even if it is to disagree, one on one with the person. Alan -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: August-28-14 11:02 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Is the BP approval process broken? On 08/28/2014 04:42 PM, Dugger, Donald D wrote: I would contend that that right there is an indication that there's a problem with the process. You submit a BP and then you have no idea of what is happening and no way of addressing any issues. If the priority is wrong I can explain why I think the priority should be higher, getting stonewalled leaves me with no idea what's wrong and no way to address any problems. I think, in general, almost everyone is more than willing to adjust proposals based upon feedback. Tell me what you think is wrong and I'll either explain why the proposal is correct or I'll change it to address the concerns. In many of the Gantt IRC meetings as well as the ML, I and others have repeatedly raised concerns about the scheduler split being premature and not a priority compared to the cleanup of the internal interfaces around the resource tracker and scheduler. This feedback was echoed in the mid-cycle meetup session as well. Sylvain and I have begun the work of cleaning up those interfaces and fixing the bugs around non-versioned data structures and inconsistent calling interfaces in the scheduler and resource tracker. Progress is being made towards these things. Trying to deal with silence is really hard and really frustrating. Especially given that we're not supposed to spam the mailing it's really hard to know what to do. I don't know the solution but we need to do something. More core team members would help, maybe something like an automatic timeout where BPs/patches with no negative scores and no activity for a week get flagged for special handling. Yes, I think flagging blueprints for special handling would be a good thing. Keep in mind, though, that there are an enormous number of proposed specifications, with the vast majority of folks only caring about their own proposed specs, and very few doing reviews on anything other than their own patches or specific area of interest. Doing reviews on other folks' patches and blueprints would certainly help in this regard. If cores only see someone contributing to a small, isolated section of the code or only to their own blueprints/patches, they generally tend to implicitly down-play that person's reviews in favor of patches/blueprints from folks that are reviewing non-related patches and contributing to reduce the total review load. I understand your frustration about the silence, but the silence from core team members may actually be a loud statement about where their priorities are. Best, -jay I feel we need to change the process somehow. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Thursday, August 28, 2014 1:44 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Is the BP approval process broken? On 08/27/2014 09:04 PM, Dugger, Donald D wrote: I'll try and not whine about my pet project but I do think there is a problem here. For the Gantt project to split out the scheduler there is a crucial BP that needs to be implemented ( https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP has been rejected and we'll have to try again for Kilo. My question is did we do something wrong or is the process broken? Note that we originally proposed the BP on 4/23/14, went through 10 iterations to the final version on 7/25/14 and the final version got three +1s and a +2 by 8/5. Unfortunately, even after reaching out to specific people, we didn't get the second +2, hence the rejection. I understand that reviews are a burden and very hard but it seems wrong that a BP with multiple positive reviews and no negative reviews is dropped because of what looks like indifference. I would posit that this is not actually indifference. The reason that there may not have been 1 +2 from a core team member may very well have been that the core team members did not feel that the blueprint's priority was high enough to put before other work, or that the core team members did have the time to comment on the spec (due to them not feeling the blueprint had the priority to justify the time to do a full review). Note that I'm not a core drivers team member. 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
Re: [openstack-dev] [nova] Is the BP approval process broken?
I share Donald's points here, I believe what would help is to clearly describe in the Wiki the process and workflow for the BP approval process and build in this process how to deal with discrepancies/disagreements and build timeframes for each stage and process of appeal etc. The current process would benefit from some fine tuning and helping to build safe guards and time limits/deadlines so folks can expect responses within a reasonable time and not be left waiting in the cold. My 2cents! /Alan -Original Message- From: Dugger, Donald D [mailto:donald.d.dug...@intel.com] Sent: August-28-14 10:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Is the BP approval process broken? I would contend that that right there is an indication that there's a problem with the process. You submit a BP and then you have no idea of what is happening and no way of addressing any issues. If the priority is wrong I can explain why I think the priority should be higher, getting stonewalled leaves me with no idea what's wrong and no way to address any problems. I think, in general, almost everyone is more than willing to adjust proposals based upon feedback. Tell me what you think is wrong and I'll either explain why the proposal is correct or I'll change it to address the concerns. Trying to deal with silence is really hard and really frustrating. Especially given that we're not supposed to spam the mailing it's really hard to know what to do. I don't know the solution but we need to do something. More core team members would help, maybe something like an automatic timeout where BPs/patches with no negative scores and no activity for a week get flagged for special handling. I feel we need to change the process somehow. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Thursday, August 28, 2014 1:44 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Is the BP approval process broken? On 08/27/2014 09:04 PM, Dugger, Donald D wrote: I'll try and not whine about my pet project but I do think there is a problem here. For the Gantt project to split out the scheduler there is a crucial BP that needs to be implemented ( https://review.openstack.org/#/c/89893/ ) and, unfortunately, the BP has been rejected and we'll have to try again for Kilo. My question is did we do something wrong or is the process broken? Note that we originally proposed the BP on 4/23/14, went through 10 iterations to the final version on 7/25/14 and the final version got three +1s and a +2 by 8/5. Unfortunately, even after reaching out to specific people, we didn't get the second +2, hence the rejection. I understand that reviews are a burden and very hard but it seems wrong that a BP with multiple positive reviews and no negative reviews is dropped because of what looks like indifference. I would posit that this is not actually indifference. The reason that there may not have been 1 +2 from a core team member may very well have been that the core team members did not feel that the blueprint's priority was high enough to put before other work, or that the core team members did have the time to comment on the spec (due to them not feeling the blueprint had the priority to justify the time to do a full review). Note that I'm not a core drivers team member. 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
Re: [openstack-dev] [nova] [neutron] Specs for K release
That's a fairly good point Michael, and if that can get correlated to the proposed incubation section for that project then I believe this would help alleviate a lot of frustration and help folks understand what to expect and what are the next steps etc. How do we get this formulated and agreed so we can have this approved and proceed? /Alan -Original Message- From: Michael Still [mailto:mi...@stillhq.com] Sent: August-28-14 6:51 PM To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] [neutron] Specs for K release On Thu, Aug 28, 2014 at 6:53 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Aug 28, 2014 at 11:51:32AM +, Alan Kavanagh wrote: How to do we handle specs that have slipped through the cracks and did not make it for Juno? Rebase the proposal so it is under the 'kilo' directory path instead of 'juno' and submit it for review again. Make sure to keep the ChangeId line intact so people see the history of any review comments in the earlier Juno proposal. Yes, but... I think we should talk about tweaking the structure of the juno directory. Something like having proposed, approved, and implemented directories. That would provide better signalling to operators about what we actually did, what we thought we'd do, and what we didn't do. I worry that gerrit is a terrible place to archive the things which were proposed by not approved. If someone else wants to pick something up later, its super hard for them to find. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Is the BP approval process broken?
+1 my sentiments exactly, and this will actually help folks contribute in a more meaningful and productive way. /Alan -Original Message- From: Chris Friesen [mailto:chris.frie...@windriver.com] Sent: August-29-14 12:28 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Is the BP approval process broken? On 08/28/2014 04:01 PM, Joe Gordon wrote: On Thu, Aug 28, 2014 at 2:43 PM, Alan Kavanagh alan.kavan...@ericsson.com mailto:alan.kavan...@ericsson.com wrote: I share Donald's points here, I believe what would help is to clearly describe in the Wiki the process and workflow for the BP approval process and build in this process how to deal with discrepancies/disagreements and build timeframes for each stage and process of appeal etc. The current process would benefit from some fine tuning and helping to build safe guards and time limits/deadlines so folks can expect responses within a reasonable time and not be left waiting in the cold. This is a resource problem, the nova team simply does not have enough people doing enough reviews to make this possible. All the more reason to make it obvious which reviews are not being addressed in a timely fashion. (I'm thinking something akin to the order screen at a fast food restaurant that starts blinking in red and beeping if an order hasn't been filled in a certain amount of time.) Perhaps by making it clear that reviews are a bottleneck this will actually help to address the problem. Chris ___ 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] [all] [ptls] The Czar system, or how to scale PTLs
That's a fair point Jay. The Czar does sound like a reasonable approach and what would be useful and helpful would be to appoint additional PTL's and not have the burden of everything falling on one individual which becomes over loading after a period of time. In this case, imho it would be useful to have 2 or more PTL's assigned per project to adjust the workload and have different views and assess the sticky points with different views. /Alan -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: August-25-14 1:58 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs On 08/23/2014 06:35 PM, Clint Byrum wrote: I agree as well. PTL is a servant of the community, as any good leader is. If the PTL feels they have to drop the hammer, or if an impass is reached where they are asked to, it is because they have failed to get everyone communicating effectively, not because that's their job. The problem isn't really that teams are not communicating effectively, nor is the problem to do with some deficit of a PTL in either putting the hammer down or failing to figure out common ground. The issue in my opinion and my experience is that there are multiple valid ways of doing something (say, deployment or metering or making toast) and the TC and our governing structure has decided to pick winners in spaces instead of having a big tent and welcoming different solutions and projects into the OpenStack fold. We pick winners and by doing so, we are exclusionary, and this exclusivity does not benefit our user community, but rather just gives it fewer options. IMHO, the TC should become an advisory team that recommends to interested project teams ways in which they can design and architect their projects to integrate well with other projects in the OpenStack community, and design their projects for the scale, stability and requirements (such as multi-tenancy) that an open cloud software ecosystem demands. Just my two cents, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator
+1, I am hoping this is just a short term holding point and this will eventually be merged into main branch as this is a feature a lot of companies, us included would definitely benefit from having supported and many thanks to Sean for sticking with this and continue to push this. /Alan -Original Message- From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] Sent: August-19-14 8:33 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator Hi, The QoS API extension has lived in Gerrit/been in review for about a year. It's gone through revisions, summit design sessions, and for a little while, a subteam. I would like to request incubation in the upcoming incubator, so that the code will have a more permanent home where we can collaborate and improve. -- 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] Fwd: FW: [Neutron] Group Based Policy and the way forward
+1 I believe Pedro has a very valid point here, and that is the the community to approve the spec and that decision should be respected. It makes sense to again clearly denote the process and governance and have this noted on the thread Stefano started earlier today. /Alan -Original Message- From: Pedro Marques [mailto:pedro.r.marq...@gmail.com] Sent: August-06-14 4:52 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward On Aug 6, 2014, at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote: However, it seems to me that the end-goal of the GBP effort is *actually* to provide a higher-layer API to Neutron that would essentially enable proprietary vendors to entirely swap out all of Neutron core for a new set of drivers that spoke proprietary device APIs. If this is the end-goal, it should be stated more clearly, IMO. I believe that people should be considered innocent until proven otherwise. Is there a reason to believe there is some hidden reason behind this proposal ? It seems to me that this is uncalled for. Neutron allows vendors to speak to proprietary device APIs, it was designed to do so, AFAIK. It is also possibly to entirely swap out all of the Neutron core... the proponents of the group based policy didn't have to go through so much trouble if that was their intent. As far as i know most plugins talk to a proprietary API. I happen to disagree technically with a couple of choices made by this proposal; but the blueprint was approved. Which means that i lost the argument, or didn't raise it on time, or didn't argue convincingly... regardless of the reason, the time to argue about the goal has passed. The decision of the community was to approve the spec and that decision should be respected. Pedro. ___ 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] Spec exceptions are closed, FPF is August 21
+1 I think your suggestions are admirable and would be good if this is taken on board, having a timeframe around items would definitely help focus and ensure reviews in a timely manner. /Alan From: Rudra Rugge [mailto:ru...@contrailsystems.com] Sent: July-31-14 6:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21 Hi Kyle, I also agree with Mandeep's suggestion of putting a time frame on the lingering -2 if the addressed concerns have been taken care of. In my experience also a sticky -2 detracts other reviewers from reviewing an updated patch. Either a time-frame or a possible override by PTL (move to -1) would help make progress on the review. Regards, Rudra On Thu, Jul 31, 2014 at 2:29 PM, Mandeep Dhami dh...@noironetworks.commailto:dh...@noironetworks.com wrote: Hi Kyle: As -2 is sticky, and as there exists a possibility that the original core might not get time to get back to re-reviewing his, do you think that there should be clearer guidelines on it's usage (to avoid what you identified as dropping of the balls)? Salvatore had a good guidance in a related thread [0], do you agree with something like that? I try to avoid -2s as much as possible. I put a -2 only when I reckon your patch should never be merged because it'll make the software unstable or tries to solve a problem that does not exist. -2s stick across patches and tend to put off other reviewers. [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041339.html Or do you think that 3-5 days after an update that addresses the issues identified in the original -2, we should automatically remove that -2? If this does not happen often, this process does not have to be automated, just an exception that the PTL can exercise to address issues where the original reason for -2 has been addressed and nothing new has been identified? On Thu, Jul 31, 2014 at 11:25 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: On Thu, Jul 31, 2014 at 7:11 AM, Yuriy Taraday yorik@gmail.commailto:yorik@gmail.com wrote: On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments in some ML thread not directly related to the BP. Why is my spec blocked? Neither spec [1] nor code (which is available for a really long time now [2] [3]) can get enough reviewers' attention because of those groundless -2's. Should I abandon these change requests and file new ones to get some eyes on my code and proposals? It's just getting ridiculous. Let's take a look at timeline, shall we? I share your concerns here as well, and I'm sorry you've had a bad experience working with the community here. Mar, 25 - first version of the first part of Neutron code is published at [2] Mar, 28 - first reviewers come and it gets -1'd by Mark because of lack of BP (thankful it wasn't -2 yet, so reviews continued) Apr, 1 - Both Oslo [5] and Neturon [6] BPs are created; Apr, 2 - first version of the second part of Neutron code is published at [3]; May, 16 - first version of Neutron spec is published at [1]; May, 19 - Neutron spec gets frozen by Mark's -2 (because Oslo BP is not approved yet); May, 21 - first part of Neutron code [2] is found generally OK by reviewers; May, 21 - first version of Oslo spec is published at [4]; May, 29 - a version of the second part of Neutron code [3] is published that later raises only minor comments by reviewers; Jun, 5 - both parts of Neutron code [2] [3] get frozen by -2 from Mark because BP isn't approved yet; Jun, 23 - Oslo spec [4] is mostly ironed out; Jul, 8 - Oslo spec [4] is merged, Neutron spec immediately gets +1 and +2; Jul, 20 - SAD kicks in, no comments from Mark or anyone on blocked change requests; Jul, 24 - in response to Kyle's suggestion I'm filing SAD exception; Jul, 31 - I'm getting final decision as follows: Your BP will extremely unlikely get to Juno. Do you see what I see? Code and spec is mostly finished in May (!) where the mostly part is lack of reviewers because of that Mark's -2. And 1 month later when all bureaucratic reasons fall off nothing happens. Don't think I didn't try to approach Mark. Don't think I didn't approach Kyle on this issue. Because I did. But nothing happens and another month passes by and I get You know, may be later general response. Noone (but those who knew about it originally) even looks at my code for 2 months already because Mark doesn't think (I hope he did think) he should lift -2 and I'm getting why not wait another 3 months? What the hell is that? You don't want to land features that doesn't have code 2 weeks before Juno-3, I get
Re: [openstack-dev] [neutron] Spec Approval Deadline (SAD) has passed, next steps
Hi Kyle I do sympathise and know its not easy to accommodate all BP's, and I know it's a difficult job to take these decisions. May I therefore suggest that anything that gets punted from Juno is ensured for high priority and acceptance for Kilo Release ? This means we will have those that are not approved ensure they take high priority and guaranteed for the next release (Kilo in this case) and send an email to confirm this. That way we don't have people feeling constantly disappointed and being pushed further down the pecking order, and ensure they are not being demoted and support on progressing their work at the next release. Interested to hear your thoughts on this Kyle and others and feel free to suggest an alternatives, I know this is a difficult topic to address but I feel it is necessary for us to have this discussion. Alan -Original Message- From: Kyle Mestery [mailto:mest...@mestery.com] Sent: July-24-14 9:14 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Kyle Mestery Subject: Re: [openstack-dev] [neutron] Spec Approval Deadline (SAD) has passed, next steps On Thu, Jul 24, 2014 at 5:38 AM, Livnat Peer lp...@redhat.com wrote: On 07/21/2014 04:16 PM, Kyle Mestery wrote: Hi all! A quick note that SAD has passed. We briskly approved a pile of BPs over the weekend, most of them vendor related as low priority, best effort attempts for Juno-3. At this point, we're hugely oversubscribed for Juno-3, so it's unlikely we'll make exceptions for things into Juno-3 now. I don't plan to open a Kilo directory in the specs repository quite yet. I'd like to first let things settle down a bit with Juno-3 before going there. Once I do, specs which were not approved should be moved to that directory where they can be reviewed with the idea they are targeting Kilo instead of Juno. Also, just a note that we have a handful of bugs and BPs we're trying to land in Juno-3 yet today, so core reviewers, please focus on those today. Thanks! Kyle [1] https://launchpad.net/neutron/+milestone/juno-2 Hi Kyle, Do we have guidelines for what can/should qualify as an exception? I see some exception requests and I would like to understand what criteria they should meet in order to qualify as an exception. Thanks ,Livnat Salvatore sent an email to the list [1] which perfectly describes the types of things we'll allow exceptions for. To be honest, we're already 4x oversubscribed for Juno-3 [2] as it is, and it's unlikely even 2/3 of the existing approved BPs will land code. That's one reason it's hard for me to think of approving existing ones, especially considering how close we are to feature freeze and the end of Juno [3]. Thanks, Kyle [1] http://lists.openstack.org/pipermail/openstack-dev/2014-July/040969.html [2] https://launchpad.net/neutron/+milestone/juno-3 [3] https://wiki.openstack.org/wiki/Juno_Release_Schedule ___ 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] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
Hi Kyle Thanks for taking the time for writing this note also I know this is not an easy discussion and not something being a matter of waving hands or fingers. I believe what you have stated is well understood, though the main points I raised seems to be missing from this Neutron Policies wiki (interested to see if other projects have addressed and document this) such as (1) How to address when a contribution gets punted, (2) how to address BP's that are not progressing, (3)how to ensure that in the even a given BP/patch/etc gets no reviews how to address these. I feel this is around the Governance than just about the procedures and processes. Also, having more Core reviewers from different companies would also go a long way to helping to ensure that the different views and expectations are addressed community wide. I agree on the need to groom core reviewers, I guess what I miss here is the time it takes and how large would the Core Team grow, are their limits? Kyle you are doing an amazing job, full commend you on that and believe you are definitely going beyond here to help out and its most appreciated. It would be good to get these points ironed out as they are lingering and having them addressed will help us going forward. BR Alan -Original Message- From: Kyle Mestery [mailto:mest...@mestery.com] Sent: July-24-14 11:10 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron I've received a lot of emails lately, mostly private, from people who feel they are being left out of the Neutron process. I'm unsure if other projects have people who feel this way, thus the uniquely worded subject above. I wanted to broadly address these concerns with this email. One thing I'd like to reiterate for people here, publicly on the list, is that there is no hidden agendas in Neutron, no political machines in the background working. As PTL, I've tried to be as transparent as possible. The honest reality is that if you want to have influence in Neutron or even in OpenStack in general, get involved upstream. Start committing small patches. Start looking at bugs. Participate in the weekly meetings. Build relationships upstream. Work across projects, not just Neutron. None of this is specific to Neutron or even OpenStack, but in fact is how you work in any upstream Open Source community. I'd also like to address the add more core reviewers to solve all these problems angle. While adding more core reviewers is a good thing, we need to groom core reviewers and meld them into the team. This takes time, and it's something we in Neutron actively work on. The process we use is documented here [1]. I'd also like to point out that one of the things I've tried to do in Neutron as PTL during the Juno cycle is document as much of the process around working in Neutron. That is all documented on this wiki page here [2]. Feedback on this is most certainly welcome. I'm willing to help work with anyone who wants to contribute more to Neutron. I spend about half of my time doing just this already, between reviews, emails, and IRC conversations. So please feel free to find me on IRC (mestery on Freenode), on the ML, or even just use this email address. Thanks, Kyle [1] https://wiki.openstack.org/wiki/NeutronCore [2] https://wiki.openstack.org/wiki/NeutronPolicies ___ 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] [not-only-neutron] How to Contribute upstream in OpenStack Neutron
-Original Message- From: Anita Kuno [mailto:ante...@anteaya.info] Sent: July-24-14 12:27 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron On 07/24/2014 11:50 AM, Alan Kavanagh wrote: Hi Kyle Thanks for taking the time for writing this note also I know this is not an easy discussion and not something being a matter of waving hands or fingers. I believe what you have stated is well understood, though the main points I raised seems to be missing from this Neutron Policies wiki (interested to see if other projects have addressed and document this) such as (1) How to address when a contribution gets punted, (2) how to address BP's that are not progressing, (3)how to ensure that in the even a given BP/patch/etc gets no reviews how to address these. I feel this is around the Governance than just about the procedures and processes. Hi Alan, Let me add some thoughts here. The listed items mostly boil down to communication. Are those contributors with punted contributions in IRC channels? Do the attend the program weekly meeting? Many punted contributions, be they patches or blueprints, have the status they do because noone can find who the owners of these contributions are to ask them to fill in the gaps so reviewers even know what is being proposed. AK-- to my understanding our folks have attended the weekly meetings as often as possible. Now if folks don't know what channels to use or how to use IRC then that is an issue the we need to address, but having people available so reviewers can ask them about their offerings is a great first step and no I personally don't think that this is a governance issue. If you want to find out what items are governance issues, do attend the TC weekly meeting: https://wiki.openstack.org/wiki/Governance/TechnicalCommittee and be sure to read the logs of past meetings: http://eavesdrop.openstack.org/meetings/tc/ Also, having more Core reviewers from different companies would also go a long way to helping to ensure that the different views and expectations are addressed community wide. I agree on the need to groom core reviewers, I guess what I miss here is the time it takes and how large would the Core Team grow, are their limits? I agree that having diversity in core reviewers is very important. Core reviewers are those reviewers that have put in the time to do the reviews to demonstrate their commitment to the program. They also have enough experience with the program to gain the trust of other core reviewers. How long it takes is based on the individual reviewer. As for how large the team can grow, it is based on how many people want to do the work that it takes to gain that knowledge and experience. AK-- It's a suggestion that works in other communities. In short, it is up to the potential core reviewer. Thanks Alan, Anita. Kyle you are doing an amazing job, full commend you on that and believe you are definitely going beyond here to help out and its most appreciated. It would be good to get these points ironed out as they are lingering and having them addressed will help us going forward. BR Alan -Original Message- From: Kyle Mestery [mailto:mest...@mestery.com] Sent: July-24-14 11:10 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] [not-only-neutron] How to Contribute upstream in OpenStack Neutron I've received a lot of emails lately, mostly private, from people who feel they are being left out of the Neutron process. I'm unsure if other projects have people who feel this way, thus the uniquely worded subject above. I wanted to broadly address these concerns with this email. One thing I'd like to reiterate for people here, publicly on the list, is that there is no hidden agendas in Neutron, no political machines in the background working. As PTL, I've tried to be as transparent as possible. The honest reality is that if you want to have influence in Neutron or even in OpenStack in general, get involved upstream. Start committing small patches. Start looking at bugs. Participate in the weekly meetings. Build relationships upstream. Work across projects, not just Neutron. None of this is specific to Neutron or even OpenStack, but in fact is how you work in any upstream Open Source community. I'd also like to address the add more core reviewers to solve all these problems angle. While adding more core reviewers is a good thing, we need to groom core reviewers and meld them into the team. This takes time, and it's something we in Neutron actively work on. The process we use is documented here [1]. I'd also like to point out that one of the things I've tried to do in Neutron as PTL during the Juno cycle is document as much of the process around working in Neutron. That is all documented
Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions
I find it really hard to comprehend the level of transparency here, or lack thereof. It seems to me that when we want to get features into a given release we are at the mercy of others and while I do understand that the core team cant approve and review everything we also can not wait for another release or another release for features that would be of importance for Openstack in general. Its very discouraging for other members of the community to have certain features which are important for them but maybe not for others being demoted and pushed further out. Also, having a core set of people vote on what is essential for one release to the next to me is not very transparent and not very democratic way of working, it supports only those who want to guide the community one way. While I do see a need for ensuring priority, setting of priority to me is again not transparent imho. Also, having folks comment really late on BP's that have been progressing and folks working hard to progress them only for at the last minute to get it demoted and then moved to another track I find this not a nice way to work in the community, politics are a way of life but if they are going to be used as the rule for Openstack and its releases and a way for others to govern within the community I find this really disappointing. If we have more work being put on the table, then more Core members would definitely go a long way with assisting this, we cant wait for folks to be reviewing stuff as an excuse to not get features landed in a given release. I know this will strike a cord with some, but I see too much going on that makes me very disappointed so I hope by reaching out others will take note to help us improve this process, perhaps this is something the Openstack Board can take note of and jump in and try and resolve. Alan -Original Message- From: Kyle Mestery [mailto:mest...@mestery.com] Sent: July-23-14 9:23 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Specs approved for Juno-3 and exceptions On Wed, Jul 23, 2014 at 7:28 AM, Salvatore Orlando sorla...@nicira.com wrote: I'm sure it is not news to anyone that we already have approved a too many specifications for Juno-3. The PTL made clear indeed that Low priority blueprints are considered best effort. However, this already leaves us with 23 medium to high specifications to merge in Juno-3. This is already quite close to what the core team can handle, considering history from previous releases and the fact that there are 3 very big items in the list (new LB APIs, distributed router, and group policies). I've counted already at least 7 requests for spec freeze exceptions on the mailing list, and it is likely more will come. In order to limit oversubscribing, I would suggest to exclude freeze exceptions requests for items which are not: - targeting stability and scalability for Neutron FOSS framework - have a community interest. By that I do not mean necessarily targeting the FOSS bits, but necessarily have support and interest from a number of teams of neutron contributors. I don't want to be evil to contributors, but I think it is better to be clear now rather than arriving at the end of Juno-3 and having to tell contributors that unfortunately we were not able to give their patches enough review cycles. Thanks for sending this out Salvatore. We are way oversubscribed, and at this point, I'm in agreement on not letting any new exceptions which do not fall under the above guidelines. Given how much is already packed in there, this makes the most sense. Thanks, Kyle Salvatore ___ 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] NFV in OpenStack use cases and context
Hi Ramki Really like the smart scheduler idea, we made a couple of blueprints that are related to ensuring you have the right information to build a constrained based scheduler. I do however want to point out that this is not NFV specific but is useful for all applications and services of which NFV is one. /Alan -Original Message- From: ramki Krishnan [mailto:r...@brocade.com] Sent: June-10-14 6:06 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Chris Wright; Nicolas Lemieux; Norival Figueira Subject: Re: [openstack-dev] NFV in OpenStack use cases and context Hi Steve, Forgot to mention, the Smart Scheduler (Solver Scheduler) enhancements for NFV: Use Cases, Constraints etc. is a good example of an NFV use case deep dive for OpenStack. https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/document/d/1k60BQXOMkZS0SIxpFOppGgYp416uXcJVkAFep3Oeju8/edit%23heading%3Dh.wlbclagujw8ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0Am=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRzGZnz4%3D%0As=836991d6daab66b519de3b670db8af001144ddb20e636665b395597aa118538f Thanks, Ramki -Original Message- From: ramki Krishnan Sent: Tuesday, June 10, 2014 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Chris Wright; Nicolas Lemieux; Norival Figueira Subject: RE: NFV in OpenStack use cases and context Hi Steve, We are have OpenStack gap analysis documents in ETSI NFV under member only access. I can work on getting public version of the documents (at least a draft) to fuel the kick start. Thanks, Ramki -Original Message- From: Steve Gordon [mailto:sgor...@redhat.com] Sent: Tuesday, June 10, 2014 12:06 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Chris Wright; Nicolas Lemieux Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context - Original Message - From: Steve Gordon sgor...@redhat.com To: Stephen Wong stephen.kf.w...@gmail.com - Original Message - From: Stephen Wong stephen.kf.w...@gmail.com To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Hi, Perhaps I have missed it somewhere in the email thread? Where is the use case = bp document we are supposed to do for this week? Has it been created yet? Thanks, - Stephen Hi, Itai is referring to the ETSI NFV use cases document [1] and the discussion is around how we distill those - or a subset of them - into a more consumable format for an OpenStack audience on the Wiki. At this point I think the best approach is to simply start entering one of them (perhaps #5) into the Wiki and go from there. Ideally this would form a basis for discussing the format etc. Thanks, Steve [1] http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV 001v010101p.pdf To try and kick start things I have created a table on the wiki [1] based on the *DRAFT* NFV Performance Portability Best Practises document [2]. This really lists workload types rather than specific applications, although I've put in an examples column we can populate with them. I find it a useful way to quickly break down some of the characteristics of NFV applications at a glance. What do people think of this as something to start with? Remember, it's a wiki! So anyone is welcome to either expand the table or start adding more concrete user stories (e.g. around ETSI NFV use case number 5 that Itai and I have been referring to, or any other VNF for that matter) in this section (we may/want need to create a separate page but for now it seems OK to get started here). Thanks, Steve [1] https://wiki.openstack.org/wiki/Meetings/NFV#Use_Cases [2] http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-PER001v009%20-%20NFV%20Performance%20%20Portability%20Best%20Practises.pdf ___ 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] NFV in OpenStack use cases and context
Hi Yathi The BP's I am referring too are the nic state aware scheduling (https://blueprints.launchpad.net/nova/+spec/nic-state-aware-scheduling ) and the PCI device capability aware scheduling (appears to have been deleted, will upload it again). I can see NFV utilising this for some apps we have the same view point on this too, though my main gripe on this was its applicable to others. /Alan -Original Message- From: Yathiraj Udupi (yudupi) [mailto:yud...@cisco.com] Sent: June-12-14 2:53 PM To: Alan Kavanagh Cc: OpenStack Development Mailing List (not for usage questions); Debojyoti Dutta Subject: Re: [openstack-dev] NFV in OpenStack use cases and context Hi Alan, Our Smart (Solver) Scheduler blueprint (https://blueprints.launchpad.net/nova/+spec/solver-scheduler ) has been in the works in the Nova community since late 2013. We have demoed at the Hong Kong summit, as well as the Atlanta summit, use cases using this smart scheduler for better, optimized resource placement with complex constrained scenarios. So to let you know this work was started as a smart way of doing scheduling, applicable in general and not limited to NFV. Currently we feel NFV is a killer app for driving this blueprint and work ahead, however is applicable for all kinds of resource placement scenarios. We will be very interested in finding out more about your blueprints that you are referring to here, and see how it can be integrated as part of our future roadmap. Thanks, Yathi. On 6/12/14, 10:55 AM, Alan Kavanagh alan.kavan...@ericsson.com wrote: Hi Ramki Really like the smart scheduler idea, we made a couple of blueprints that are related to ensuring you have the right information to build a constrained based scheduler. I do however want to point out that this is not NFV specific but is useful for all applications and services of which NFV is one. /Alan -Original Message- From: ramki Krishnan [mailto:r...@brocade.com] Sent: June-10-14 6:06 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Chris Wright; Nicolas Lemieux; Norival Figueira Subject: Re: [openstack-dev] NFV in OpenStack use cases and context Hi Steve, Forgot to mention, the Smart Scheduler (Solver Scheduler) enhancements for NFV: Use Cases, Constraints etc. is a good example of an NFV use case deep dive for OpenStack. https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/docu men t/d/1k60BQXOMkZS0SIxpFOppGgYp416uXcJVkAFep3Oeju8/edit%23heading%3Dh.wlb cla gujw8ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=%2FZ35AkRhp2kCW4Q3MPeE%2Bx Y2b qaf%2FKm29ZfiqAKXxeo%3D%0Am=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRz GZn z4%3D%0As=836991d6daab66b519de3b670db8af001144ddb20e636665b395597aa118 538 f Thanks, Ramki -Original Message- From: ramki Krishnan Sent: Tuesday, June 10, 2014 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Chris Wright; Nicolas Lemieux; Norival Figueira Subject: RE: NFV in OpenStack use cases and context Hi Steve, We are have OpenStack gap analysis documents in ETSI NFV under member only access. I can work on getting public version of the documents (at least a draft) to fuel the kick start. Thanks, Ramki -Original Message- From: Steve Gordon [mailto:sgor...@redhat.com] Sent: Tuesday, June 10, 2014 12:06 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Chris Wright; Nicolas Lemieux Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context - Original Message - From: Steve Gordon sgor...@redhat.com To: Stephen Wong stephen.kf.w...@gmail.com - Original Message - From: Stephen Wong stephen.kf.w...@gmail.com To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Hi, Perhaps I have missed it somewhere in the email thread? Where is the use case = bp document we are supposed to do for this week? Has it been created yet? Thanks, - Stephen Hi, Itai is referring to the ETSI NFV use cases document [1] and the discussion is around how we distill those - or a subset of them - into a more consumable format for an OpenStack audience on the Wiki. At this point I think the best approach is to simply start entering one of them (perhaps #5) into the Wiki and go from there. Ideally this would form a basis for discussing the format etc. Thanks, Steve [1] http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NF V 001v010101p.pdf To try and kick start things I have created a table on the wiki [1] based on the *DRAFT* NFV Performance Portability Best Practises document [2]. This really lists workload types rather than specific applications, although I've put in an examples column we can populate with them. I find it a useful way to quickly break down some of the characteristics of NFV applications
Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
More than happy to help out, I think we are on a good path by focusing on the current BP's we have. I will not make it to IRC meeting today, but will comment afterwords. I think Adrian also pointed out one other point just to put on the table so we set the tone and scope accordingly, that is some of these BP's while being NFV related and not NFV essential but also benefit the generic cases too imho. For example the port-mirroring is in some cases a feature some NFV services would utilise (lots of strange stuff in the wild :-) ) this and others would never need this. Alan -Original Message- From: Steve Gordon [mailto:sgor...@redhat.com] Sent: June-11-14 6:54 AM To: Alan Kavanagh Cc: OpenStack Development Mailing List (not for usage questions); ITAI MENDELSOHN (ITAI); Chris Wright; Stephen Wong; Nicolas Lemieux Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context - Original Message - From: Alan Kavanagh alan.kavan...@ericsson.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Steve Hi Adrian et.al Adrian thanks for taking a stab at this, I think the use case list is a little long but good to put on the map. One item I would point out is that its fairly difficult and perhaps misleading to map the blueprints list to the ETSI NFV use case, for example you can argue that based on configuration and deployment of say vCPE some may require VLAN Trunking, others will not. Similarly for SR-IOV support when you a Transport node that consumes the total CPU and NIC available on the host and would in some cases be provisioned on bare metal SR-IOV is not a required feature set. Also some of these would not require anything in addition to support apart from what we already have in Openstack, for example in the case of CDN do we needed additional feature sets, imho apart from the nice state aware scheduling and VM allocation based on specific attributes required (specific PCI device type, topology based placement, on board SSD, etc) and IP end point for delivery, do we need anything else beyond this? Perhaps what might be more beneficial is to ensure we can deploy a given app in the current OS distro and identify the necessary configuration attributes we would need to expose, would that be a good way forward? Interested to hear from others on this front. A suggestion, is we start with use cases 2 and 7 that are more well defined and simpler to address and this is where I believe Itai had a good statement of “not boiling the ocean”, lets start with some simple ones that are well defined and well known and don’t have too many intrinsic configurations. /Alan Yes, thanks all - it's great to see plenty of people putting forward their thoughts on this :). I agree that it is somewhat problematic to map the ETSI NFV use cases as is directly to the list of blueprints, finding an appropriate way to distil them into the hard requirements of the most minimal configurations of each is key. I definitely agree concentrating on doing this for a subset of them that are particularly well defined first is the best way to start off without spreading our efforts too thinly. Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] NFV in OpenStack use cases and context
Thanks Martin Perhaps I am missing this a little bit, but in relation to the control plane and signal processing, how do you see that fitting into requirements we would need in Openstack? If I may jump a little bit here, the only one I can see is making sure the app is installed on a given PCI device with a given set of necessary capabilities and driver types which is a BP Ericsson+Intel submitted for PCI/e device discovery and registration and this is applicable to a whole range of apps and services. Do you see others that are needed? /Alan -Original Message- From: Martin Taylor [mailto:martin.tay...@metaswitch.com] Sent: June-11-14 4:40 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Chris Wright; Nicolas Lemieux Subject: Re: [openstack-dev] NFV in OpenStack use cases and context I've added examples in data plane, control plane and signal processing that relate to ETSI use case #5 (IMS). Martin -Original Message- From: Steve Gordon [mailto:sgor...@redhat.com] Sent: 10 June 2014 20:06 To: OpenStack Development Mailing List (not for usage questions) Cc: Chris Wright; Nicolas Lemieux Subject: Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context - Original Message - From: Steve Gordon sgor...@redhat.com To: Stephen Wong stephen.kf.w...@gmail.com - Original Message - From: Stephen Wong stephen.kf.w...@gmail.com To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Hi, Perhaps I have missed it somewhere in the email thread? Where is the use case = bp document we are supposed to do for this week? Has it been created yet? Thanks, - Stephen Hi, Itai is referring to the ETSI NFV use cases document [1] and the discussion is around how we distill those - or a subset of them - into a more consumable format for an OpenStack audience on the Wiki. At this point I think the best approach is to simply start entering one of them (perhaps #5) into the Wiki and go from there. Ideally this would form a basis for discussing the format etc. Thanks, Steve [1] http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV 001v010101p.pdf To try and kick start things I have created a table on the wiki [1] based on the *DRAFT* NFV Performance Portability Best Practises document [2]. This really lists workload types rather than specific applications, although I've put in an examples column we can populate with them. I find it a useful way to quickly break down some of the characteristics of NFV applications at a glance. What do people think of this as something to start with? Remember, it's a wiki! So anyone is welcome to either expand the table or start adding more concrete user stories (e.g. around ETSI NFV use case number 5 that Itai and I have been referring to, or any other VNF for that matter) in this section (we may/want need to create a separate page but for now it seems OK to get started here). Thanks, Steve [1] https://wiki.openstack.org/wiki/Meetings/NFV#Use_Cases [2] http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-PER001v009%20-%20NFV%20Performance%20%20Portability%20Best%20Practises.pdf ___ 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] NFV BoF at design summit
+1 I believe the main point is not to confuse what we is need on the Hypervisor and networking but focus on what we need Openstack to support to be a robust and reliable system, for example most systems aim for 5 9's due to various requirements but what they really want to aim for us predictable and deterministic systems. I think to be fair to Kevins email, the focus should be that when we issue a port connection that we guanrantee its connected and we have a way to validate that. Carrier grade is not just about system availability/uptime but also that we can ensure when a call for an object/resource is requested we can ensure its 99.999% of the time going to be handled and not dropped etc etc etc. Alan -Original Message- From: Steve Gordon [mailto:sgor...@redhat.com] Sent: May-22-14 9:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit - Original Message - From: Kevin Benton blak...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Thursday, May 22, 2014 2:48:37 AM Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit 3. OpenStack itself should ( its own Compute Node/L3/Routing, Controller ) have (5 nine capable) reliability. Can you elaborate on this a little more? Reliability is pretty deployment specific (e.g. database chosen, number of cluster members, etc). I'm sure nobody would disagree that OpenStack should be reliable, but without specific issues to address it doesn't really give us a clear target. Thanks, Kevin Benton I think this comment applies equally to the other items listed. There seemed to be agreement at the BoF that one of our key tasks/challenges is to boil down such high level NFV requirements to create actionable feature requests/proposals in the context of OpenStack. Thanks, 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
Re: [openstack-dev] Link to patch/review for allowing instances to receive vlan tagged traffic
Hi Steven More than happy to help out here: The BP in question is this, patches have been submitted 3 weeks ago by Erik Moe: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms https://review.openstack.org/#/c/92541/ This is a generic feature a lot of Telco traffic nodes have and even non telco nodes too ;-) so it’s a great feature to have supported. Alan -Original Message- From: Steve Gordon [mailto:sgor...@redhat.com] Sent: May-22-14 2:05 PM To: Alan Kavanagh; Balázs Gibizer Cc: OpenStack Development Mailing List (not for usage questions) Subject: [NFV][Neutron] Link to patch/review for allowing instances to receive vlan tagged traffic Hi Alan/Balazs, In one of the NFV BoF sessions in Atlanta one of you (I assume one of you anyway!) noted in the etherpad [1] (line 89) that Ericsson had submitted a patch to Neutron which would allow instances to use tagged vlan traffic. Do you happen to have a link handy to the review for this? Thanks in advance, Steve [1] https://etherpad.openstack.org/p/juno-nfv-bof ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV][Neutron] Link to patch/review for allowing instances to receive vlan tagged traffic
Yes that’s the one Yi, thanks ;-) /Alan From: Yi Sun [mailto:beyo...@gmail.com] Sent: May-22-14 2:56 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Alan Kavanagh; Balázs Gibizer Subject: Re: [openstack-dev] [NFV][Neutron] Link to patch/review for allowing instances to receive vlan tagged traffic Is this the one? https://review.openstack.org/#/c/92541/ On Thu, May 22, 2014 at 11:04 AM, Steve Gordon sgor...@redhat.commailto:sgor...@redhat.com wrote: Hi Alan/Balazs, In one of the NFV BoF sessions in Atlanta one of you (I assume one of you anyway!) noted in the etherpad [1] (line 89) that Ericsson had submitted a patch to Neutron which would allow instances to use tagged vlan traffic. Do you happen to have a link handy to the review for this? Thanks in advance, Steve [1] https://etherpad.openstack.org/p/juno-nfv-bof ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Android-x86 http://www.android-x86.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
Hi Just wanted to comment on some points below inline. /Alan -Original Message- From: A, Keshava [mailto:keshav...@hp.com] Sent: May-22-14 2:25 AM To: Kyle Mestery; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit Hi In my opinion the first and foremost requirement for NFV ( which is from carrier class ) is 99.9 ( 5 nines ) reliability. If we want OpenStack architecture to scale to Carrier class below are basic thing we need to address. 1. There should be a framework from open-stack to support 5 nine level reliability to Service/Tennant-VM . ? ( Example for Carrier Class NAT Service/ SIP Service/HLR/VLR service/BRAS service) AK-- I believe what is important is for Openstack to support various degrees of configurations for a given tenant network. The reliability of the network is outside of Openstack, but where Openstack plays a role here imho is for check and validation of the network when its been provisioned and configured. Similarly for VM to ensure we have sufficient check and validation (watchdogs/event call backs etc etc) so that we can expose faults and act on them. 2. They also should be capable of 'In-service up gradation (ISSU) without service disruption. AK-- Fully agree, its imperative to be able to upgrade Openstack without any service interruption. 3. OpenStack itself should ( its own Compute Node/L3/Routing, Controller ) have (5 nine capable) reliability. AK-- If we are referring to Openstack controllers/agents/db's etc then yes makes perfect sense, I would however stop short on saying you can achieve 5 nine's in various ways and its typically up to the vendors themselves how they want to implement this even in OS. If we can provide such of infrastructure to NFV then we think of adding rest of requirement . Let me know others/NFv people opinion for the same. Thanks regards, Keshava.A -Original Message- From: Kyle Mestery [mailto:mest...@noironetworks.com] Sent: Monday, May 19, 2014 11:49 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit On Mon, May 19, 2014 at 1:44 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: I think the Service VM discussion resolved itself in a way that reduces the problem to a form of NFV - there are standing issues using VMs for services, orchestration is probably not a responsibility that lies in Neutron, and as such the importance is in identifying the problems with the plumbing features of Neutron that cause implementation difficulties. The end result will be that VMs implementing tenant services and implementing NFV should be much the same, with the addition of offering a multitenant interface to Openstack users on the tenant service VM case. Geoff Arnold is dealing with the collating of information from people that have made the attempt to implement service VMs. The problem areas should fall out of his effort. I also suspect that the key points of NFV that cause problems (for instance, dealing with VLANs and trunking) will actually appear quite high up the service VM list as well. -- There is a weekly meeting for the Service VM project [1], I hope some representatives from the NFB sub-project can make it to this meeting and participate there. Thanks, Kyle [1] https://wiki.openstack.org/wiki/Meetings/ServiceVM Ian. On 18 May 2014 20:01, Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Sumit Naiksatam sumitnaiksa...@gmail.com Thanks for initiating this conversation. Unfortunately I was not able to participate during the summit on account of overlapping sessions. As has been identified in the wiki and etherpad, there seem to be obvious/potential touch points with the advanced services' discussion we are having in Neutron [1]. Our sub team, and I, will track and participate in this NFV discussion. Needless to say, we are definitely very keen to understand and accommodate the NFV requirements. Thanks, ~Sumit. [1] https://wiki.openstack.org/wiki/Neutron/AdvancedServices Yes, there are definitely touch points across a number of different existing projects and sub teams. The consensus seemed to be that while a lot of people in the community have been working in independent groups on advancing the support for NFV use cases in OpenStack we haven't necessarily been coordinating our efforts effectively. Hopefully having a cross-project sub team will allow us to do this. In the BoF sessions we started adding relevant *existing* blueprints on the wiki page, we probably need to come up with a more robust way to track these from launchpad :). Further proposals will no doubt need to be built out from use cases as we discuss them further: https://wiki.openstack.org/wiki/Meetings/NFV Feel free to add any blueprints from the Advanced
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
+1 can we reschedule to push this forward Chris please? Alan From: Stephen Wong [mailto:s3w...@midokura.com] Sent: May-15-14 10:01 AM To: OpenStack Development Mailing List (not for usage questions) Cc: iawe...@cisco.com Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit Hi Chris, A good number of people involved in Neutron advanced service / group-policy / individual services subteams will be at the Group Policy conference session (at 1:30pm). Is it possible to reschedule this to a different time? Thanks, - Stephen On Wed, May 14, 2014 at 10:06 AM, Chris Wright chr...@redhat.commailto:chr...@redhat.com wrote: Thursday at 1:30 PM in the Neutron Pod we'll do an NFV BoF. If you are at design summit and interested in Neutron + NFV please come join us. thanks, -chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?
+1 would be interested. -Original Message- From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] Sent: May-06-14 12:19 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit? For those attending, to discuss the QoS API current status? -- 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] [Neutron] Flavor(?) Framework
Suggest “service-type” Eugene. /Alan From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: April-23-14 11:05 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Neutron] Flavor(?) Framework Hi neutrons, A quick question of the ^^^ I heard from many of you that a term 'flavor' is undesirable, but so far there were no suggestions for the notion that we are going to introduce. So please, suggest you name for the resource. Names that I've been thinking of: - Capability group - Service Offering Thoughts? Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
Think that's a good idea Jay A slight twist perhaps: Network Service Type /Alan -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: April-23-14 11:29 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework On Wed, 2014-04-23 at 19:24 +0400, Eugene Nikanorov wrote: Thanks, that can be an option. Just wondering, can we find a single name? service type? :) Oh, I guess that's taken. Well, we could always rename the existing service type to service class or service family. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [openstack][nova][specs] Where to store images used in the spec
I think Ascii diagrams do make sense if the Blueprint is a major architecture input and will be long lived through many Os cycles, if it's a small short feature and the diagram is useful to describe the architecture then I think its overly painful, speaking from experience! Alan -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: April-16-14 1:19 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [openstack][nova][specs] Where to store images used in the spec On 04/16/2014 12:55 PM, Russell Bryant wrote: On 04/16/2014 12:42 PM, Kevin Benton wrote: The only downside to putting it on the wiki is that it no longer has a shared fate with the specification in the repo. If someone deletes it or replaces it on the wiki, information for the spec is lost. External connectivity is also required just to view a template as well. Yeah, that's right. I'd honestly really prefer simple ascii diagrams in almost all cases anyway. Requiring an external diagram should be a rare exception, not the rule, IMO. After some additional discussion on this topic on IRC, I really think we should start by requiring diagrams in ASCII and see if that becomes overly painful. Proposed update to the template regarding this topic here: https://review.openstack.org/88028 -- Russell Bryant ___ 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] Neutron BP review process for Juno
Tend to agree Nachi, that would be my preference, especially when the diagrams
are fairly complex which is the case most of the time in Neutron. However if
the BP is long lived then I think it makes sense to use ASCII, but if its short
for a small feature to be included in next release then I agree the simplest
and quickest way is a better use of our time.
/Alan
-Original Message-
From: Nachi Ueno [mailto:na...@ntti3.com]
Sent: April-16-14 3:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron BP review process for Juno
Hi folks
I don't think to use ASCII digrams is good idea because it is hard to
maintenance update diagrams..
so I would like to recommend Blockdiag Netdiag which are plugins for sphinx.
Blockdiag
http://blockdiag.com/en/blockdiag/
blockdiag {
A - B - C - D;
A - E - F - G;
}
will be
http://blockdiag.com/en/_images/blockdiag-69b48ddf499e79e437fbdf9f0e767e365f846d7a.png
(see more example
http://blockdiag.com/en/blockdiag/examples.html )
or you can try online http://blockdiag.appspot.com/
NetDiag
http://blockdiag.com/en/nwdiag/
nwdiag {
network dmz {
address = 210.x.x.x/24
web01 [address = 210.x.x.1];
web02 [address = 210.x.x.2];
}
network internal {
address = 172.x.x.x/24;
web01 [address = 172.x.x.1];
web02 [address = 172.x.x.2];
db01;
db02;
}
}
will be
http://blockdiag.com/en/_images/nwdiag-472a0e8ead9b236d7d929e645767514615bb2392.png
try
http://blockdiag.appspot.com/nwdiag/
http://blockdiag.com/en/nwdiag/nwdiag-examples.html
We have more diagrams can be generated
Activity diagram
http://blockdiag.appspot.com/actdiag/
Sequence diagram
http://blockdiag.appspot.com/seqdiag/
Best
Nachi
2014-04-16 10:42 GMT-07:00 Kyle Mestery mest...@noironetworks.com:
On Wed, Apr 16, 2014 at 12:23 PM, Russell Bryant rbry...@redhat.com wrote:
On 04/16/2014 09:51 AM, Russell Bryant wrote:
On 04/16/2014 09:39 AM, Salvatore Orlando wrote:
if the image you're adding is a diagram, I would think about
asciiflow.com http://asciiflow.com first!
In all seriousness, I think that's a very nice solution for simple
diagrams. :-)
For other diagrams, I wonder if it makes sense to just upload them
to the wiki and include links to them from the spec using the image
directive.
Another thread got started on this topic for Nova.
I put up a proposal to require ASCII digrams for nova-specs here:
https://review.openstack.org/#/c/88028/
Great idea! I've done the same for neutron-specs here:
https://review.openstack.org/88037
--
Russell Bryant
___
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] Operators Design Summit ideas for Atlanta
Hi Steve I believe this is a good idea, and what would also be good is to get input from the Telco Cloud Providers who run and view networks much differently that the traditional enterprise/hosting companies and the type of services and Configuration Deployment models are very differently. The Telco services is something Openstack clearly need help in understanding. /Alan -Original Message- From: Steven Hardy [mailto:sha...@redhat.com] Sent: April-08-14 5:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Operators Design Summit ideas for Atlanta On Fri, Mar 28, 2014 at 03:01:30PM +0800, Tom Fifield wrote: Thanks to those projects that responded. I've proposed sessions in swift, ceilometer, tripleO and horizon. I just created a session for Heat: http://summit.openstack.org/cfp/details/247 Historically Heat sessions have been quite well attended by operators and deployers with lots of real-world feedback from users. However I still think having a specific session dedicated to this discussion could be good, and would potentially serve to provide some additional focus and defininition between user-visible and internal-design discussions. 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
Re: [openstack-dev] Operators Design Summit ideas for Atlanta
This is a really good initiative Tom, and from an ops perspective the main frustration we have is on the Neutron side and also on lack to Tool support. Alan -Original Message- From: Tom Fifield [mailto:t...@openstack.org] Sent: April-06-14 10:23 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Operators Design Summit ideas for Atlanta So far, there's been no comment from anyone working on nova, so there's been no session proposed. I can, of course, propose a session ... but without buy-in from the project team it's unlikely to be accepted. Regards, Tom On 01/04/14 22:44, Matt Van Winkle wrote: So, I've been watching the etherpad and the summit submissions and I noticed that there isn't anything for nova. Maybe I'm off base, but it seems like we'd be missing the mark to not have a Developer/Operator's exchange on the key product. Is there anything we can do to get a session slotted like these other products? Thanks! Matt On 3/28/14 2:01 AM, Tom Fifield t...@openstack.org wrote: Thanks to those projects that responded. I've proposed sessions in swift, ceilometer, tripleO and horizon. On 17/03/14 07:54, Tom Fifield wrote: All, Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success. However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer. It worked really well ... perhaps this is something we'd like to have happen for all the projects? *Idea*: Add an ops session for each project in the design summit https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions Most operators running OpenStack tend to treat it more holistically than those coding it. They are aware of, but don't necessarily think or work in terms of project breakdowns. To this end, I'd imagine the such sessions would: * have a primary purpose for developers to ask the operators to answer questions, and request information * allow operators to tell the developers things (give feedback) as a secondary purpose that could potentially be covered better in a cross-project session * need good moderation, for example to push operator-to-operator discussion into forums with more time available (eg https://etherpad.openstack.org/p/ATL-ops-unconference-RFC ) * be reinforced by having volunteer good users in potentially every design summit session (https://etherpad.openstack.org/p/ATL-ops-in-design-sessions ) Anyway, just a strawman - please jump on the etherpad (https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-session s) or leave your replies here! Regards, Tom ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services?
Hi Paul Yes I would be interested in this as I believe its an area we have not got around to so far in Neutron. /Alan From: Paul Michali [mailto:p...@cisco.com] Sent: February-03-14 5:20 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron] Interest in discussing vendor plugins for L3 services? I'd like to see if there is interest in discussing vendor plugins for L3 services. The goal is to strive for consistency across vendor plugins/drivers and across service types (if possible/sensible). Some of this could/should apply to reference drivers as well. I'm thinking about these topics (based on questions I've had on VPNaaS - feel free to add to the list): * How to handle vendor specific validation (e.g. say a vendor has restrictions or added capabilities compared to the reference drivers for attributes). * Providing client feedback (e.g. should help and validation be extended to include vendor capabilities or should it be delegated to server reporting?) * Handling and reporting of errors to the user (e.g. how to indicate to the user that a failure has occurred establishing a IPSec tunnel in device driver?) * Persistence of vendor specific information (e.g. should new tables be used or should/can existing reference tables be extended?). * Provider selection for resources (e.g. should we allow --provider attribute on VPN IPSec policies to have vendor specific policies or should we rely on checks at connection creation for policy compatibility?) * Handling of multiple device drivers per vendor (e.g. have service driver determine which device driver to send RPC requests, or have agent determine what driver requests should go to - say based on the router type) If you have an interest, please reply to me and include some days/times that would be good for you, and I'll send out a notice on the ML of the time/date and we can discuss. Looking to hearing form you! PCM (Paul Michali) MAIL p...@cisco.commailto:p...@cisco.com IRCpcm_ (irc.freenode.nethttp://irc.freenode.net) TW@pmichali GPG key4525ECC253E31A83 Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] Disk Eraser
+1, that is another point Rob. When I started this thread my main interest was disk and then firmware. It is clear we really need to have a clear discussion on this, as imho I would not be supportive or lease baremetal to tenants if I can not guarantee the service, otherwise the cost of risking tenants to adverse attacks and data screening are far greater that the revenue generated from the service. When it comes to the tenants in our DC we consider all tenants need to be provided a guarantee of the baremetal service on the disk, loaders etc etc, otherwise its difficult to assure your customer. /Alan -Original Message- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: January-18-14 12:55 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic] Disk Eraser On 18 January 2014 12:21, Chris Friesen chris.frie...@windriver.com wrote: On 01/17/2014 04:20 PM, Devananda van der Veen wrote: tl;dr, We should not be recycling bare metal nodes between untrusted tenants at this time. There's a broader discussion about firmware security going on, which, I think, will take a while for the hardware vendors to really address. What can the hardware vendors do? Has anyone proposed a meaningful solution for the firmware issue? So historically, for 99% of users of new machines, it's been considered a super low risk right - they don't boot off of unknown devices, and they aren't reusing machines across different users. Second hand users had risks, but vendors aren't designing for the second hand purchaser. However more and more viruses are targeting lower and lower parts of the boot stack (see why UEFI is so important) and there are now multiple confirmations of hostile payloads that can live in hard disk drive microcontrollers - and some of the NSA payloads look like they inhabit system management bioses... - it's become clear that this is something that is a genuine risk for all users; new users from viruses and other malware, second hand users from the original user. So, industry wise, I think over the next few years folk will finish auditing their supply chain to determine what devices are at risk and then start implementing defenses. The basic problem though is that our entire machine architecture trusts that the rest of the machine is trusted (e.g. device can DMA anything they want... - one previous class of attack was compromised firewire devices - plugin, and they would disable your screen saver without password entry.) Given the number of devices (NIC, GPU, storage controllers, etc.) that could potentially have firmware update capabilities it's not clear to me how this could be reliably solved. Slowly and carefully :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ 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] FW: OpenStack Cloud Virtualization Implementation Strategies
FYI From: Light Reading [mailto:sen...@responses.lightreading.com] Sent: January-17-14 2:20 PM To: Alan Kavanagh Subject: OpenStack Cloud Virtualization Implementation Strategies If you have trouble viewing this email, read the online versionhttp://app.reg.techweb.com/e/es.aspx?s=2150e=212470elq=62671bda0e344eeb82af3927ad56d07f. [http://twimgs.com/audiencedevelopment/JT/OE/promos/LR/logos/LR_Windriver_hdr.jpg]http://www.lightreading.com/radio.asp?webinar_id=78cid=Windriver011714elq=62671bda0e344eeb82af3927ad56d07f OpenStack Cloud Virtualization Implementation Strategieshttp://www.lightreading.com/radio.asp?webinar_id=78cid=Windriver011714elq=62671bda0e344eeb82af3927ad56d07f Dear Alan, Join us on Wednesday, January 29, 2014, 12:00 pm New York for this live radio show sponsored by Wind River. [Register Now]http://www.lightreading.com/radio.asp?webinar_id=78cid=Windriver011714elq=62671bda0e344eeb82af3927ad56d07f In only a few years, OpenStack has emerged as a leading approach for meeting the massive cloud compute, networking, and storage challenges that datacenters and network infrastructures now face. However, since implementation requirements differ based on a number of factors, including type of cloud architecture supported (public, private, hybrid), no single implementation strategy exists. Rather, operators and equipment providers must create individualized cloud virtualization strategies to best meet unique service agility and monetization requirements. Accordingly, join Davide Ricci, Product Line Manager at Wind River, and Jim Hodges, Heavy Reading Analyst, for a technical discussion addressing the factors and design attributes to be considered in creating a cohesive OpenStack-based cloud virtualization implementation strategy. Topics they will discuss include: * The impact of OpenStack on existing open-source embedded software ecosystem projects * The factors and timeline that must be considered in the creation of a virtualized cloud network (including cloud-based hardware and software clusters) * Best-practices for OpenStack component integration (including OpenStack Neutron and Swift) * The value proposition of existing and new OpenStack release capabilities * OpenStack Cloud implementation challenges, including the need to provide carrier-grade reliability ensuring maximum possible uptime * Wind River's OpenStack roadmap and how it fits into its network functions virtualization product and solution portfolio Register Todayhttp://www.lightreading.com/radio.asp?webinar_id=78cid=Windriver011714elq=62671bda0e344eeb82af3927ad56d07f TO UNSUBSCRIBE This email was sent to alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com. You are receiving this email because you provided Light Reading with your email address. If you wish to opt-out of webinar promotions via Light Reading, please respond herehttp://reg.techweb.com/forms/LightReadingWebinars. Light Reading 150 West 30th Street, 20th Floor New York, NY 10001 [http://app.reg.techweb.com/e/FooterImages/FooterImage1?elq=62671bda0e344eeb82af3927ad56d07fsiteid=2150] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] Disk Eraser
Hi Rob Then apart from the disk eraser and reinstalling the blade from scratch everytime it is returned from lease, and ensure network isolation, what are the other many concerns you are worried about for sharing the bare metal then? Would really like to know what the other major issues are that you see? /Aaln -Original Message- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: January-17-14 3:15 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic] Disk Eraser On 16 January 2014 03:31, Alan Kavanagh alan.kavan...@ericsson.com wrote: Hi fellow OpenStackers Does anyone have any recommendations on open source tools for disk erasure/data destruction software. I have so far looked at DBAN and disk scrubber and was wondering if ironic team have some better recommendations? So for Ironic this is a moderately low priority thing right now - and certainly I think it should be optional (what the default is is a different discussion). It's low priority because there are -so- many other concerns about sharing bare metal machines between tenants that don't have comprehensive mutual trust, that it's really not viable today (even on relatively recent platforms IMNSHO). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ 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] Proposal for dd disk i/o performance blueprint of cinder.
-Original Message- From: CARVER, PAUL [mailto:pc2...@att.com] Sent: January-16-14 8:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder. Alan Kavanagh wrote: I posted a query to Ironic which is related to this discussion. My thinking was I want to ensure the case you note here (1) a tenant can not read another tenants disk.. the next (2) was where in Ironic you provision a baremetal server that has an onboard dish as part of the blade provisioned to a given tenant-A. then when tenant-A finishes his baremetal blade lease and that blade comes back into the pool and tenant-B comes along, I was asking what open source tools guarantee data destruction so that no ghost images or file retrieval is possible? That is an excellent point. I think the needs of Ironic may be different from Cinder. As a volume manager Cinder isn't actually putting the raw disk under the control of a tenant. If it can be assured that (as is the case with NetApp and other storage vendor hardware) that a fake all zeros is returned on a read-before-first-write of a chunk of disk space then that's sufficient to address the case of some curious ne'er-do-well alllancating volumes purely for the purpose of reading them to see what's left on them. exactly, that was my thinking too. My main concern is to ensure that no ghost file and no way for another tenant to retrieve any data stored from a previous tenant. But with bare metal the whole physical disk is at the mercy of the tenant so you're right that it must be ensured that the none of the previous tenant's bits are left lying around to be snooped on. Fully agree Paul,. What I was thinking was that when the tenants bare metal node lease has expired and the blade is to be brought back into the pool for available scheduling to other tenants, we should run a disk eraser before making the blade available, so Ironic would run a disk eraser and validate this before taking it back into the pool. IF folks think this is a good idea, I will write up a blueprint on this for Ironic. But I still think an *option* of wipe=none may be desirable because a cautious client might well take it into their own hands to wipe the disk before releasing it (and perhaps encrypt as well). In which case always doing an additional wipe is going to be more disk I/O for no real benefit. I hear you on this one, and most clients who go for baremetal service are not novice, however it is also good to not take the chance and ensure all data is wiped before taking the blade back into service, at least that is what I would do and we typically do that with our laptops and PC's that we move/lease around ;-) /Alan ___ 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] Proposal for dd disk i/o performance blueprint of cinder.
+1makes sense to me. I will write up a Blueprint for this for review in Ironic and we take it from their. I don't see this as evil firmware, more a good process we need to automate as part of sanity checks before taking a leased baremetal back and making it available in the pool again, imho. Or do others see it differently, if so would like to hear so. /Alan -Original Message- From: CARVER, PAUL [mailto:pc2...@att.com] Sent: January-16-14 8:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder. Clint Byrum wrote: Is that really a path worth going down, given that tenant-A could just drop evil firmware in any number of places, and thus all tenants afterward are owned anyway? I think a change of subject line is in order for this topic (assuming it hasn't been discussed in sufficient depth already). I propose [Ironic] Evil Firmware but I didn't change it on this message in case folks interested in this thread aren't reading Ironic threads. Ensuring clean firmware is definitely something Ironic needs to account for. Unless you're intending to say that multi-tenant bare metal is a dead end that shouldn't be done at all. As long as anyone is considering Ironic and bare metal in general as a viable project and service it is critically important that people are focused on how to ensure that a server released by one tenant is clean before being provided to another tenant. It doesn't even have to be evil firmware. Simply providing a tenant with a server where the previous tenant screwed up a firmware update or messed with BIOS settings or whatever is a problem. If you're going to lease bare metal out on a short term basis you've GOT to have some sort of QC to ensure that when the hardware is reused for another tenant it's as good as new. If not, it will be all too common for a tenant to receive a bare metal server that's been screwed up by a previous tenant through incompetence as much as through maliciousness. ___ 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] Proposal for dd disk i/o performance blueprint of cinder.
The point was that tenant-A can not read or be able to retrieve any data once the blade lease is over the the blade is returned to the pool. Therefore, what would make sense is that we build an in-service a method to ensure that the disk is erased before being brought back into the pool to be made available for provisioning, at least that is my thinking here and the concerns Paul had too. Do I sense a Blueprint!!! Alan -Original Message- From: Clint Byrum [mailto:cl...@fewbar.com] Sent: January-16-14 12:25 AM To: openstack-dev Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder. Excerpts from Alan Kavanagh's message of 2014-01-15 19:11:03 -0800: Hi Paul I posted a query to Ironic which is related to this discussion. My thinking was I want to ensure the case you note here (1) a tenant can not read another tenants disk.. the next (2) was where in Ironic you provision a baremetal server that has an onboard dish as part of the blade provisioned to a given tenant-A. then when tenant-A finishes his baremetal blade lease and that blade comes back into the pool and tenant-B comes along, I was asking what open source tools guarantee data destruction so that no ghost images or file retrieval is possible? Is that really a path worth going down, given that tenant-A could just drop evil firmware in any number of places, and thus all tenants afterward are owned anyway? ___ 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] [ironic] Disk Eraser
Cheers Chris I have used diskscrub and its one of the better tools. It would make sense as I noted in a previous email to have ironic run some dd tool before bringing the compute blade back into pool for scheduling. Should we write up a blueprint for this? Would also good to know if anyone has tried to do any data recovery after doing dd on the local disk? /Alan From: Chris Jones [mailto:c...@tenshu.net] Sent: January-16-14 6:33 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic] Disk Eraser Hi https://code.google.com/p/diskscrub/ If you need more than /dev/zero, scrub should be packaged in most distros and offers a choice of high grade algorithms. Cheers, -- Chris Jones On 15 Jan 2014, at 14:31, Alan Kavanagh alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com wrote: Hi fellow OpenStackers Does anyone have any recommendations on open source tools for disk erasure/data destruction software. I have so far looked at DBAN and disk scrubber and was wondering if ironic team have some better recommendations? BR Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] Disk Eraser
Although the performance is important the more critical feature is to guarantee complete dd for the disk. Alan From: Oleg Gelbukh [mailto:ogelb...@mirantis.com] Sent: January-16-14 5:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic] Disk Eraser On Wed, Jan 15, 2014 at 10:25 PM, Alan Kavanagh alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com wrote: Cheers Guys So what would you recommend Oleg. Yes its for linux system. Alan, Approach proposed below (/dev/zero) is probably better as it allows to perform at around 60MB/s. Another approach that I've seen flying around is to generate random string and use it's hashes for dd. There are some one-liners out there which do that with openssl, just one example: openssl enc -aes-256-ctr -pass pass:$(dd if=/dev/urandom bs=128 count=1 2/dev/null | base64) -nosalt /dev/zero randomfile.bin Hope this helps. -- Best regards, Oleg Gelbukh /Alan From: Oleg Gelbukh [mailto:ogelb...@mirantis.commailto:ogelb...@mirantis.com] Sent: January-15-14 10:30 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic] Disk Eraser On Wed, Jan 15, 2014 at 6:42 PM, Alexei Kornienko alexei.kornie...@gmail.commailto:alexei.kornie...@gmail.com wrote: If you are working on linux system following can help you: dd if=/dev/urandom of=/dev/sda bs=4k I would not recommend that as /dev/urandom is real slow (10-15 MB/s). -- Best regards, Oleg Gelbukh :) Best Regards, On 01/15/2014 04:31 PM, Alan Kavanagh wrote: Hi fellow OpenStackers Does anyone have any recommendations on open source tools for disk erasure/data destruction software. I have so far looked at DBAN and disk scrubber and was wondering if ironic team have some better recommendations? BR Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic] Disk Eraser
Hi fellow OpenStackers Does anyone have any recommendations on open source tools for disk erasure/data destruction software. I have so far looked at DBAN and disk scrubber and was wondering if ironic team have some better recommendations? BR Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] Disk Eraser
Cheers Guys So what would you recommend Oleg. Yes its for linux system. /Alan From: Oleg Gelbukh [mailto:ogelb...@mirantis.com] Sent: January-15-14 10:30 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic] Disk Eraser On Wed, Jan 15, 2014 at 6:42 PM, Alexei Kornienko alexei.kornie...@gmail.commailto:alexei.kornie...@gmail.com wrote: If you are working on linux system following can help you: dd if=/dev/urandom of=/dev/sda bs=4k I would not recommend that as /dev/urandom is real slow (10-15 MB/s). -- Best regards, Oleg Gelbukh :) Best Regards, On 01/15/2014 04:31 PM, Alan Kavanagh wrote: Hi fellow OpenStackers Does anyone have any recommendations on open source tools for disk erasure/data destruction software. I have so far looked at DBAN and disk scrubber and was wondering if ironic team have some better recommendations? BR Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.
Hi Paul I posted a query to Ironic which is related to this discussion. My thinking was I want to ensure the case you note here (1) a tenant can not read another tenants disk.. the next (2) was where in Ironic you provision a baremetal server that has an onboard dish as part of the blade provisioned to a given tenant-A. then when tenant-A finishes his baremetal blade lease and that blade comes back into the pool and tenant-B comes along, I was asking what open source tools guarantee data destruction so that no ghost images or file retrieval is possible? /Alan -Original Message- From: CARVER, PAUL [mailto:pc2...@att.com] Sent: January-15-14 6:00 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder. Chris Friesen [mailto:chris.frie...@windriver.com] wrote: I read a proposal about using thinly-provisioned logical volumes as a way around the cost of wiping the disks, since they zero-fill on demand rather than incur the cost at deletion time. I think it make a difference where the requirement for deletion is coming from. If it's just to make sure that a tenant can't read another tenant's disk then what you're talking about should work. It sounds similar (or perhaps identical to) how NetApp (and I assume others) work by tracking whether the current client has written to the volume and returning zeros rather than the actual contents of the disk sector on a read that precedes the first write to that sector. However, in that case the previous client's bits are still on the disk. If they were unencrypted then they're still available if someone somehow got ahold of the physical disk out of the storage array. That may not be acceptable depending on the tenant's security requirements. Though one may reasonably ask why they were writing unencrypted bits to a disk that they didn't have physical control over. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
+1 PCI Flavor.
From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com]
Sent: January-10-14 1:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
BTW, I like the PCI flavor :)
From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com]
Sent: Thursday, January 09, 2014 10:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
Hi, Ian, when you in aggrement with all of this, do you agree with the 'group
name', or agree with John's pci flavor?
I'm against the PCI group and will send out a reply later.
--jyh
From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Thursday, January 09, 2014 9:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
I think I'm in agreement with all of this. Nice summary, Robert.
It may not be where the work ends, but if we could get this done the rest is
just refinement.
On 9 January 2014 17:49, Robert Li (baoli)
ba...@cisco.commailto:ba...@cisco.com wrote:
Hi Folks,
With John joining the IRC, so far, we had a couple of productive meetings in an
effort to come to consensus and move forward. Thanks John for doing that, and I
appreciate everyone's effort to make it to the daily meeting. Let's reconvene
on Monday.
But before that, and based on our today's conversation on IRC, I'd like to say
a few things. I think that first of all, we need to get agreement on the
terminologies that we are using so far. With the current nova PCI passthrough
PCI whitelist: defines all the available PCI passthrough devices on a
compute node. pci_passthrough_whitelist=[{
vendor_id:,product_id:}]
PCI Alias: criteria defined on the controller node with which requested
PCI passthrough devices can be selected from all the PCI passthrough devices
available in a cloud.
Currently it has the following format:
pci_alias={vendor_id:, product_id:, name:str}
nova flavor extra_specs: request for PCI passthrough devices can be
specified with extra_specs in the format for
example:pci_passthrough:alias=name:count
As you can see, currently a PCI alias has a name and is defined on the
controller. The implications for it is that when matching it against the PCI
devices, it has to match the vendor_id and product_id against all the available
PCI devices until one is found. The name is only used for reference in the
extra_specs. On the other hand, the whitelist is basically the same as the
alias without a name.
What we have discussed so far is based on something called PCI groups (or PCI
flavors as Yongli puts it). Without introducing other complexities, and with a
little change of the above representation, we will have something like:
pci_passthrough_whitelist=[{ vendor_id:,product_id:,
name:str}]
By doing so, we eliminated the PCI alias. And we call the name in above as a
PCI group name. You can think of it as combining the definitions of the
existing whitelist and PCI alias. And believe it or not, a PCI group is
actually a PCI alias. However, with that change of thinking, a lot of benefits
can be harvested:
* the implementation is significantly simplified
* provisioning is simplified by eliminating the PCI alias
* a compute node only needs to report stats with something like: PCI
group name:count. A compute node processes all the PCI passthrough devices
against the whitelist, and assign a PCI group based on the whitelist definition.
* on the controller, we may only need to define the PCI group names.
if we use a nova api to define PCI groups (could be private or public, for
example), one potential benefit, among other things (validation, etc), they
can be owned by the tenant that creates them. And thus a wholesale of PCI
passthrough devices is also possible.
* scheduler only works with PCI group names.
* request for PCI passthrough device is based on PCI-group
* deployers can provision the cloud based on the PCI groups
* Particularly for SRIOV, deployers can design SRIOV PCI groups based
on network connectivities.
Further, to support SRIOV, we are saying that PCI group names not only can be
used in the extra specs, it can also be used in the -nic option and the neutron
commands. This allows the most flexibilities and functionalities afforded by
SRIOV.
Further, we are saying that we can define default PCI groups based on the PCI
device's class.
For vnic-type (or nic-type), we are saying that it defines the link
characteristics of the nic that is attached to a VM: a nic that's connected to
a virtual switch, a nic that is connected to a physical switch, or a nic that
is connected to a physical switch, but has a host macvtap device in between.
The actual
Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI
Cheers Gao. So my only comment here is how complex and how many attributes are we expecting the scheduler to take as input. Similarly the more variables you schedule on the more complex the beast becomes and from experience you end up having cross dependencies. I can see power be an item of concern but don't you think that we could solve that one with Nova Cells Parent being aware of the Power consumption costs at time-T and then just forward the Nova API call to the appropriate Child which has say the least power consumption cost? Also, on a priority scale, some DC providers (speaking as one of the DC Providers here) will not have power cost on their top say 5 list for scheduling. So I agree its definitely interesting but if you consider scheduling inside a large DC in the same geographical region and Dc site, Scheduling for power consumption becomes null and void. ;-( BR Alan From: Gao, Fengqian [mailto:fengqian@intel.com] Sent: December-19-13 11:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Yes, Alan, you got me. Providing power/temperature to scheduler, set threshold or different weight, then the scheduler can boot VM on the most suitable node. Thanks --fengqian From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com] Sent: Friday, December 20, 2013 11:58 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Cheers Gao It definitely makes sense to collect additional metrics such as power and temperature, and make that available for selective decisions you would want to take. However, I am just wondering if you could realistically feed those metrics as variables for scheduling, this is the main part I feel is questionable. I assume then you would use temperature || power etc to gauge if you want to schedule another VM on a given node when a given temperature threshold is reached. Is this the main case you are thinking of Gao? Alan From: Gao, Fengqian [mailto:fengqian@intel.com] Sent: December-18-13 10:23 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi, Alan, I think, for nova-scheduler it is better if we gather more information. And In today's DC, power and temperature are very important facts to considering. CPU/Memory utilization is not enough to describe nodes' status. Power/inlet temperature should be noticed. Best Wishes --fengqian From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com] Sent: Thursday, December 19, 2013 2:14 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi Gao What is the reason why you see it would be important to have these two additional metrics power and temperature for Nova to base scheduling on? Alan From: Gao, Fengqian [mailto:fengqian@intel.com] Sent: December-18-13 1:00 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi, all, I am planning to extend bp https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling with power and temperature. In other words, power and temperature can be collected and used for nova-scheduler just as CPU utilization. I have a question here. As you know, IPMI is used to get power and temperature and baremetal implements IPMI functions in Nova. But baremetal driver is being split out of nova, so if I want to change something to the IPMI, which part should I choose now? Nova or Ironic? Best wishes --fengqian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI
One additional item Gao and apologies as I was thinking power on two front here. I assume then the limit here is per compute node within a given DC site, so yes I can see some small benefits on that for sure. I still however have a hard time seeing if I want to do scheduling based on power as one of my main attributes I need to schedule based on, but sure I can see some value in this. Let me know when you flesh this out in the blueprint, would be willing to support and take some items for dev for this. BR Alan From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com] Sent: December-20-13 8:21 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Cheers Gao. So my only comment here is how complex and how many attributes are we expecting the scheduler to take as input. Similarly the more variables you schedule on the more complex the beast becomes and from experience you end up having cross dependencies. I can see power be an item of concern but don't you think that we could solve that one with Nova Cells Parent being aware of the Power consumption costs at time-T and then just forward the Nova API call to the appropriate Child which has say the least power consumption cost? Also, on a priority scale, some DC providers (speaking as one of the DC Providers here) will not have power cost on their top say 5 list for scheduling. So I agree its definitely interesting but if you consider scheduling inside a large DC in the same geographical region and Dc site, Scheduling for power consumption becomes null and void. ;-( BR Alan From: Gao, Fengqian [mailto:fengqian@intel.com] Sent: December-19-13 11:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Yes, Alan, you got me. Providing power/temperature to scheduler, set threshold or different weight, then the scheduler can boot VM on the most suitable node. Thanks --fengqian From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com] Sent: Friday, December 20, 2013 11:58 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Cheers Gao It definitely makes sense to collect additional metrics such as power and temperature, and make that available for selective decisions you would want to take. However, I am just wondering if you could realistically feed those metrics as variables for scheduling, this is the main part I feel is questionable. I assume then you would use temperature || power etc to gauge if you want to schedule another VM on a given node when a given temperature threshold is reached. Is this the main case you are thinking of Gao? Alan From: Gao, Fengqian [mailto:fengqian@intel.com] Sent: December-18-13 10:23 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi, Alan, I think, for nova-scheduler it is better if we gather more information. And In today's DC, power and temperature are very important facts to considering. CPU/Memory utilization is not enough to describe nodes' status. Power/inlet temperature should be noticed. Best Wishes --fengqian From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com] Sent: Thursday, December 19, 2013 2:14 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi Gao What is the reason why you see it would be important to have these two additional metrics power and temperature for Nova to base scheduling on? Alan From: Gao, Fengqian [mailto:fengqian@intel.com] Sent: December-18-13 1:00 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi, all, I am planning to extend bp https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling with power and temperature. In other words, power and temperature can be collected and used for nova-scheduler just as CPU utilization. I have a question here. As you know, IPMI is used to get power and temperature and baremetal implements IPMI functions in Nova. But baremetal driver is being split out of nova, so if I want to change something to the IPMI, which part should I choose now? Nova or Ironic? Best wishes --fengqian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI
Cheers Gao It definitely makes sense to collect additional metrics such as power and temperature, and make that available for selective decisions you would want to take. However, I am just wondering if you could realistically feed those metrics as variables for scheduling, this is the main part I feel is questionable. I assume then you would use temperature || power etc to gauge if you want to schedule another VM on a given node when a given temperature threshold is reached. Is this the main case you are thinking of Gao? Alan From: Gao, Fengqian [mailto:fengqian@intel.com] Sent: December-18-13 10:23 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi, Alan, I think, for nova-scheduler it is better if we gather more information. And In today's DC, power and temperature are very important facts to considering. CPU/Memory utilization is not enough to describe nodes' status. Power/inlet temperature should be noticed. Best Wishes --fengqian From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com] Sent: Thursday, December 19, 2013 2:14 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi Gao What is the reason why you see it would be important to have these two additional metrics power and temperature for Nova to base scheduling on? Alan From: Gao, Fengqian [mailto:fengqian@intel.com] Sent: December-18-13 1:00 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi, all, I am planning to extend bp https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling with power and temperature. In other words, power and temperature can be collected and used for nova-scheduler just as CPU utilization. I have a question here. As you know, IPMI is used to get power and temperature and baremetal implements IPMI functions in Nova. But baremetal driver is being split out of nova, so if I want to change something to the IPMI, which part should I choose now? Nova or Ironic? Best wishes --fengqian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI
Hi Gao What is the reason why you see it would be important to have these two additional metrics power and temperature for Nova to base scheduling on? Alan From: Gao, Fengqian [mailto:fengqian@intel.com] Sent: December-18-13 1:00 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Nova] [Ironic] Get power and temperature via IPMI Hi, all, I am planning to extend bp https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling with power and temperature. In other words, power and temperature can be collected and used for nova-scheduler just as CPU utilization. I have a question here. As you know, IPMI is used to get power and temperature and baremetal implements IPMI functions in Nova. But baremetal driver is being split out of nova, so if I want to change something to the IPMI, which part should I choose now? Nova or Ironic? Best wishes --fengqian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-dev][Nova][Discussion]Blueprint : Auto VM Discovery in OpenStack for existing workload
Sorry Russell but I have to ask, what is the different you see between traditional datacenter virtualization and cloud. IMHO the two co-exist and Cloud (the buzz word that it is) is the umbrella for all encompassing data center. That said im still missing why this would not be a useful feature for us? BR Alan -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: October-30-13 4:21 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [OpenStack-dev][Nova][Discussion]Blueprint : Auto VM Discovery in OpenStack for existing workload On 10/30/2013 03:13 AM, Alex Glikson wrote: Maybe a more appropriate approach could be to have a tool/script that does it, as a one time thing. For example, it could make sense in a scenario when Nova DB gets lost or corrupted, a new Nova controller is deployed, and the DB needs to be recreated. Potentially, since Nova DB is primarily a cache, this could be done by 'discovery' (maybe with some manual intervention) - instead of dealing with backup/restore of the DB, or similar approaches. The need for this sort of thing makes more sense for traditional datacenter virtualization, but not as much for cloud. That's the root of my objection. -- Russell Bryant ___ 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] Distributed Virtual Router Discussion
Hi Swami I am interested in this, please keep me in the loop. /Alan From: Vasudevan, Swaminathan (PNB Roseville) [mailto:swaminathan.vasude...@hp.com] Sent: October-22-13 8:50 PM To: cloudbengo; Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion Hi Folks, Thanks for your interests in the DVR feature. We should get together to start discussing the details in the DVR. Please let me know who else is interested, probably the time slot and we can start nailing down the details. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Thanks Swami From: Robin Wang [mailto:cloudbe...@gmail.com] Sent: Tuesday, October 22, 2013 11:45 AM To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.commailto:gong...@unitedstack.com); OpenStack Development Mailing List; Vasudevan, Swaminathan (PNB Roseville) Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion Hi Artem, Very happy to see more stackers working on this feature. : ) Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. I met the same issue at first. Downloading the doc and open it locally may help. It works for me. Also, a wiki page for DVR/VDR feature is created, including some interesting performance test output. Thanks. https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Best, Robin Wang From: Artem Dmytrenkomailto:nexton...@yahoo.com Date: 2013-10-22 02:51 To: yong sheng gong \(gong...@unitedstack.com\)mailto:gong...@unitedstack.com; cloudbe...@gmail.commailto:cloudbe...@gmail.com; OpenStack Development Mailing Listmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Distributed Virtual Router Discussion Hi Swaminathan. I work for a virtual networking startup called Midokura and I'm very interested in joining the discussion. We currently have distributed router implementation using existing Neutron API. Could you clarify why distributed vs centrally located routing implementation need to be distinguished? Another question is that are you proposing distributed routing implementation for tenant routers or for the router connecting the virtual cloud to the external network? The reason that I'm asking this question is because our company would also like to propose a router implementation that would eliminate a single point uplink failures. We have submitted a couple blueprints on that topic (https://blueprints.launchpad.net/neutron/+spec/provider-router-support, https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would appreciate an opportunity to collaborate on making it a reality. Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. Could you update your document with legible diagrams? Looking forward to further discussing this topic with you! Sincerely, Artem Dmytrenko On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com wrote: Subject: [openstack-dev] Distributed Virtual Router Discussion To: yong sheng gong (gong...@unitedstack.commailto:gong...@unitedstack.com) gong...@unitedstack.commailto:gong...@unitedstack.com, cloudbe...@gmail.commailto:cloudbe...@gmail.com cloudbe...@gmail.commailto:cloudbe...@gmail.com, OpenStack Development Mailing List (openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, October 21, 2013, 12:18 PM Hi Folks, I am currently working on a blueprint for Distributed Virtual Router. If anyone interested in being part of the discussion please let me know. I have put together a first draft of my blueprint and have posted it on Launchpad for review. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com -Inline Attachment Follows- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Blueprint review process
Is this really a viable solution? I believe its more democratic to ensure everyone gets a chance to present the blueprint someone has spent time to write. This was no favoritism or biased view will ever take place and we let the community gauge the interest. /Alan -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: October-24-13 5:08 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] Blueprint review process On 10/24/2013 10:52 AM, Gary Kotton wrote: On 10/24/13 4:46 PM, Dan Smith d...@danplanet.com wrote: In the last meeting we discussed an idea that I think is worth trying at least for icehouse-1 to see if we like it or not. The idea is that *every* blueprint starts out at a Low priority, which means best effort, but no promises. For a blueprint to get prioritized higher, it should have 2 nova-core members signed up to review the resulting code. Huge +1 to this. I'm in favor of the whole plan, but specifically the prioritization piece is very important, IMHO. I too am in favor of the idea. It is just not clear how 2 Nova cores will be signed up. Good point, there was no detail on that. I propose just comments on the blueprint whiteboard. It can be something simple like this to indicate that Dan and I have agreed to review the code for something: nova-core reviewers: russellb, dansmith -- Russell Bryant ___ 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] QoS API Extension update
Hi Sean Just an FYI, we are also planning a QoS API Extension Blueprint for the Icehouse Design Summit. Will hopefully submit that really soon. Perhaps we can look at combining both of them and discuss this in Hong Kong as I have looked over your BP and I can see some benefit in combining them both. BR Alan -Original Message- From: Sean M. Collins [mailto:s...@coreitpro.com] Sent: October-16-13 10:55 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Neutron] QoS API Extension update Hello, Just a quick update on the QoS API Extension - I plan on attending the summit in Hong Kong and have registered a summit proposal to discuss the current work that has been done. Currently I have two reviews under way: API Extension Database models: https://review.openstack.org/#/c/28313/ Agent OVS implementation: https://review.openstack.org/#/c/45232/ Our current environment uses provider networking VLANs, so I've been targeting the work to what we currently are deploying inside of Comcast, so the work on the OVS agent is a bit narrow - I haven't done any work on the GRE side. Both are currently WIP - I need better test coverage in places, handle some edge cases (Agent restarts for example) and code quality improvements. If people would be so kind as to look over the Agent OVS implementation and give me some feedback, I would really appreciate it. I plan to study up on the ML2 plugin and add support for the QoS extension, so we can transition away from the OVS plugin when it is deprecated. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Blueprint Submission Deadline
Hi All Does anyone know when is the Blueprint Icehouse Submission deadline? BR Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Blueprint Submission Deadline
Cheers Thierry I was looking for some cut off date for blueprints submission to the actual Icehouse Design Summit, so that it gives folks a date to shoot towards and then time for the relevant projects/team to review/discuss. Perhaps that is something we should put in as a hard limit, a cut off date say 2 weeks before the Design Summit which in this case if mid-October and we apply that for all future Design Summits going forward, just my 2 cents on it. BR Alan -Original Message- From: Thierry Carrez [mailto:thie...@openstack.org] Sent: October-02-13 2:51 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Blueprint Submission Deadline Alan Kavanagh wrote: Does anyone know when is the Blueprint Icehouse Submission deadline? There are a number of soft deadlines, depending on how early you want to be on the release radar (which generally increases the odds of being included in the final release). The first one is the Icehouse design summit. If you want your blueprint discussed there, you should submit your blueprint and a session suggestion linking to it (on summit.openstack.org) before mid-October. The second one is the original icehouse roadmap, which is generally built a couple weeks after the summit. If you want to be formally included in it, your blueprint should be filed (and targeted to one of the icehouse milestones) before mid-November. Then blueprints can be added pretty much until Feature Proposal Freeze, which should be somewhere around the end of February (release schedule is not final yet). But the later it is visible, the less likely it is to make it. Reference: https://wiki.openstack.org/wiki/Release_Cycle Hope this helps, -- Thierry Carrez (ttx) ___ 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] New Plug-in development for Neutron
+1 This is the best approach and one we discussed in Portland and a track most folks are developing plugins under ML2 /Alan -Original Message- From: Robert Kukura [mailto:rkuk...@redhat.com] Sent: September-10-13 12:27 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] New Plug-in development for Neutron On 09/10/2013 10:45 AM, Mark McClain wrote: I think Gary and Kyle have answered this very well; however I do have a few things to add. It is definitely too late for Havana, so Icehouse is next available release for new plugins. I can work with you offline to find you a core sponsor. One more thing: Rather than implementing and maintaining an entire new plugin, consider whether it might make sense to integrate as an ml2 MechanismDriver instead. The ml2 plugin's MechanismDrivers can interface with network devices or controllers, and can work in conjunction with the existing L2 agents if needed. See https://wiki.openstack.org/wiki/Neutron/ML2 for more info. -Bob mark On Sep 10, 2013, at 9:37 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Sep 10, 2013, at 4:05 AM, P Balaji-B37839 b37...@freescale.com wrote: Hi, We have gone through the below link for new plug-in development. https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neut ron_Plugin Just want to confirm that is it mandatory to be Core Neutron Developer for submitting a new plug-in.? It's not necessary for you to have a core developer from your company, but you will need an existing core developer to support your plugin upstream. When you file the blueprint, let us know and we'll work with you on this one Balaji. Thanks, Kyle How do we get a reviewer for this like Can we approach any Core Neutron developer for review our plugin? We are developing new plug-in for our product and want to make it upstream to Neutron Core. Any information on this will be helpful!. Regards, Balaji.P ___ 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] [Ceilometer] what's in scope of Ceilometer
+1 I believe the important point here is to identify additional metrics required and the relevant attributes which can be specified and have them returned to the Collector. Then in turn the collector can either push/pull those metrics/etc into an Anlytics Engine and tools. Its not a good idea to start designing and building analytics engines etc into Ceilometer, it should just the monitor and collecting project. For the metrics Ceilometer is definitely the place to set and collect what metrics you need to know of for both the Hardware functions (cpu/mem/disk-i/o/nic utilisation etc etc) and also for some base application sets for example on an Apache server the number of TCP-sessions in utilisation etc etc. BR Alan -Original Message- From: Julien Danjou [mailto:jul...@danjou.info] Sent: August-29-13 4:20 AM To: Gordon Chung Cc: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Ceilometer] what's in scope of Ceilometer On Thu, Aug 29 2013, Gordon Chung wrote: the first question is, Ceilometer currently does metering/alarming/maybe a few other things... will it go beyond that? specifically: capacity planning, optimization, dashboard(i assume this falls under horizon/ceilometer plugin work), analytics. they're pretty broad items so i would think they would probably end up being separate projects? I think we can extend Ceilometer API to help build such tools, but I don't think we should build these tools inside Ceilometer. another question is what metrics will we capture. some of the product teams we have collect metrics on datacenter memory/cpu utilization, cluster cpu/memory/vm, and a bunch of other clustered stuff. i'm a nova-idiot, but is this info possible to retrieve? is the consensus that Ceilometer will collect anything and everything the other projects allow for? Yeah, I think that Ceilometer's the place to collect anything. I don't know if that metrics you are talking about are collectable through Nova though. -- Julien Danjou -- Free Software hacker - independent consultant -- http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [networking] Changes to the OVS agent tunneling
+1 eagerly awaiting, sounds good. Alan -Original Message- From: Edgar Magana [mailto:emag...@plumgrid.com] Sent: July-02-13 12:15 PM To: OpenStack List Subject: Re: [openstack-dev] [networking] Changes to the OVS agent tunneling Hi Kyle, It seems that the document is locked, could you provide the access code? Thanks, Edgar On 7/2/13 8:32 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: I've been spending a fair amount of time working with the OVS agent recently, and I've written up a small Google Document [1] detailing the end goal of all of this work. The short story is that I am introducing changes into the OVS agent to add support for multiple tunnel_types when the agent is run with the ML2 plugin. The ML2 plugin will support both GRE and VXLAN tunnels at the same time, for example. I'd appreciate feedback from folks on this document. Thanks, Kyle [1] https://docs.google.com/a/mestery.com/document/d/1NT3JVn2lNk_Hp7lP7spc3 ysW gSyHa4V0pYELAiePD1s/edit?usp=sharing ___ 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
