Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
Hi Ian, I think we need to understand how these VRRP and HSRP will work and where it used. What is NFV problem domain also .. VRRP: is used to provide the redundancy for L2 network, where those routers are connected to Last mile L2 devices/L2 network. Since L2 network are stateless, Active entity going down and standby entity talking control is simple. HSRP: is proprietary protocol anyway. Here we are also talking about NFV and its redundancy is for L3 network also . (Routing /Signaling protocol redundancy) For routing protocols “Active Routing Entity” always wants to have control over ‘Standby Routing Entity’ so that Active is under the control of the network/Standby. If VRRP kind of approach is issued for ‘L3 Routing Redundancy’, each Active and Standby will be running as independently which is not good model and it will not provide the five-9 redundancy. In order to provide the 99.9 redundancy at L3 network/routing NFV elements it is required to run Active and Standby Entity, where Standby will be under the control of Active. VRRP will not be good option for this. Then it is required to run as I mentioned . I hope you got it . Thanks regards, Keshava From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: Saturday, November 01, 2014 4:07 AM 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@01CFF770.BF467FA0] [cid:image002.png@01CFF770.BF467FA0] 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@01CFF770.BF467FA0] 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
Re: [openstack-dev] [Keystone] Alternative federation mapping
On Nov 2, 2014, at 22:21, Dolph Mathews dolph.math...@gmail.com wrote: On Sunday, November 2, 2014, John Dennis jden...@redhat.com wrote: It was hoped we could simply borrow the Keystone mapping implementation but it was found to be too limiting and not sufficiently expressive. We could not find another alternative so we designed a new mapper which is described in this PDF. In what way was it too limited? Did you consider extending the existing grammar and extending the existing mapping engine? I am very interested in knowing the limitations you ran into. I am fairly certain we are willing to update the engine to meet the needs of the deployers, but knowing what those limitations are and what this new proposed engine provides that we don't (for this use case) is important. --Morgan Sent via mobile___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
Hi, What are all the Service-VM(NFV elements) HA architecture ? L2 NFV and L3 NFV elements HA architecture will be different. Keeping mind we need to expose the underlying port/interface architecture from OpenStack side to Service-VM’s. Thanks Regards, Keshava From: A, Keshava Sent: Monday, November 03, 2014 2:16 PM To: Ian Wells; OpenStack Development Mailing List (not for usage questions) Cc: A, Keshava Subject: RE: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Hi Ian, I think we need to understand how these VRRP and HSRP will work and where it used. What is NFV problem domain also .. VRRP: is used to provide the redundancy for L2 network, where those routers are connected to Last mile L2 devices/L2 network. Since L2 network are stateless, Active entity going down and standby entity talking control is simple. HSRP: is proprietary protocol anyway. Here we are also talking about NFV and its redundancy is for L3 network also . (Routing /Signaling protocol redundancy) For routing protocols “Active Routing Entity” always wants to have control over ‘Standby Routing Entity’ so that Active is under the control of the network/Standby. If VRRP kind of approach is issued for ‘L3 Routing Redundancy’, each Active and Standby will be running as independently which is not good model and it will not provide the five-9 redundancy. In order to provide the 99.9 redundancy at L3 network/routing NFV elements it is required to run Active and Standby Entity, where Standby will be under the control of Active. VRRP will not be good option for this. Then it is required to run as I mentioned . I hope you got it . Thanks regards, Keshava From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: Saturday, November 01, 2014 4:07 AM 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@01CFF772.FBECB440] [cid:image002.png@01CFF772.FBECB440] 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@01CFF772.FBECB440] 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
Re: [openstack-dev] [Ironic] disambiguating the term discovery
Hi all, Following the mail thread on disambiguating the term 'discovery' - In the lines of what Devananda had stated, Hardware Introspection also means retrieving and storing hardware details of the node whose credentials and IP Address are known to the system. (Correct me if I am wrong). I am currently in the process of extracting hardware details (cpu, memory etc..) of n no. of nodes belonging to a Chassis whose credentials are already known to ironic. Does this process fall in the category of hardware introspection? Thanks, Sandhya. -Original Message- From: Devananda van der Veen [mailto:devananda@gmail.com] Sent: Tuesday, October 21, 2014 5:41 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Ironic] disambiguating the term discovery Hi all, I was reminded in the Ironic meeting today that the words hardware discovery are overloaded and used in different ways by different people. Since this is something we are going to talk about at the summit (again), I'd like to start the discussion by building consensus in the language that we're going to use. So, I'm starting this thread to explain how I use those two words, and some other words that I use to mean something else which is what some people mean when they use those words. I'm not saying my words are the right words -- they're just the words that make sense to my brain right now. If someone else has better words, and those words also make sense (or make more sense) then I'm happy to use those instead. So, here are rough definitions for the terms I've been using for the last six months to disambiguate this: hardware discovery The process or act of identifying hitherto unknown hardware, which is addressable by the management system, in order to later make it available for provisioning and management. hardware introspection The process or act of gathering information about the properties or capabilities of hardware already known by the management system. Why is this disambiguation important? At the last midcycle, we agreed that hardware discovery is out of scope for Ironic -- finding new, unmanaged nodes and enrolling them with Ironic is best left to other services or processes, at least for the forseeable future. However, introspection is definitely within scope for Ironic. Even though we couldn't agree on the details during Juno, we are going to revisit this at the Kilo summit. This is an important feature for many of our current users, and multiple proof of concept implementations of this have been done by different parties over the last year. It may be entirely possible that no one else in our developer community is using the term introspection in the way that I've defined it above -- if so, that's fine, I can stop calling that introspection, but I don't know a better word for the thing that is find-unknown-hardware. Suggestions welcome, Devananda P.S. For what it's worth, googling for hardware discovery yields several results related to identifying unknown network-connected devices and adding them to inventory systems, which is the way that I'm using the term right now, so I don't feel completely off in continuing to say discovery when I mean find unknown network devices and add them to Ironic. ___ 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] [Keystone] Alternative federation mapping
I agree with Morgan. We designed the current mapping functionality to cover all the use cases we were aware of, but if there are more, then we would love to hear about them and make the fixes that are necessary. Attribute mapping is a critical component of federation, and it should be fit for purpose regards David On 03/11/2014 09:08, Morgan Fainberg wrote: On Nov 2, 2014, at 22:21, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: On Sunday, November 2, 2014, John Dennis jden...@redhat.com mailto:jden...@redhat.com wrote: It was hoped we could simply borrow the Keystone mapping implementation but it was found to be too limiting and not sufficiently expressive. We could not find another alternative so we designed a new mapper which is described in this PDF. In what way was it too limited? Did you consider extending the existing grammar and extending the existing mapping engine? I am very interested in knowing the limitations you ran into. I am fairly certain we are willing to update the engine to meet the needs of the deployers, but knowing what those limitations are and what this new proposed engine provides that we don't (for this use case) is important. --Morgan Sent via mobile ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][opendaylight]OpenDaylight Neutron Plugin design session etherpad
Hi, what is etherpad link for opendaylight neutron plugin design session? http://kilodesignsummit.sched.org/event/5a430f46842e9239ea6c29a69cbe4e84#.VFdhdPTF-0E Thanks, Richard ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Autoscaling][HA][Murano] Use cases for Murano actions feature. Autoscaling, HA and operations.
Hi Steve, WebHook authentication is one of the unresolved issue. Right now Murano expects to have a token supplied with he API requests even for actions. In our demo environment we added a simple proxy server which accepts POST requests with HTTP basic auth or NTLM for the action URL, does the authentication in keystone by using credentials stored in barbican and then pass a request to Murano auth. We plan to come up with some more elegant solution in Kilo release. We are working with our customers to figure out what solution will satisfy their security requirements. Once we have it we can use the same approach in Heat too. Thanks Gosha On Fri, Oct 31, 2014 at 4:11 AM, Steven Hardy sha...@redhat.com wrote: On Fri, Oct 31, 2014 at 03:23:20AM -0700, Georgy Okrokvertskhov wrote: Hi, In the Juno release Murano team added a new feature - Actions. This feature allows to declare actions as specific application methods which should be executed when an action is triggered. When Murano deploys an application with actions new web hooks will be created and exposed by Murano API. Can you provide links to any documentation which describes the auth scheme used for the web hooks please? I'm interested to see how you've approached it, vs AWS pre-signed URL, Swift TempURL's etc, as Heat needs an openstack-native solution to this problem as well. Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][opendaylight]OpenDaylight Neutron Plugin design session etherpad
https://etherpad.openstack.org/p/odl-neutron-plugin On Mon, Nov 3, 2014 at 4:05 AM, Richard Woo richardwoo2...@gmail.com wrote: Hi, what is etherpad link for opendaylight neutron plugin design session? http://kilodesignsummit.sched.org/event/5a430f46842e9239ea6c29a69cbe4e84#.VFdhdPTF-0E Thanks, Richard ___ 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] [Murano][Docker] Docker applications support in Murano
Hi Stackers, Murano Application Catalog is a project which is aimed to help OpenStack users to publish and run applications on top of OpenStack infrastructure. Murano Juno release supports two main application formats: HOT template apps and Murano packages. Today, I would like to announce an initial support of Docker images based application in Murano. It is possible to use Murano Application Catalog to publish Docker based applications and end users will be able to deploy these application on top of Docker Service VM provisioned by Murano. As usual, Murano uses Heat for doing the actual work. Initially, Murano generates a Heat template with networks, Nova server and Software config for Docker service VM. Once Docker Service is up and running Murano will update Heat stack with Docker resources provided by Docker plugin. Murano Docker Service VM workflows will help to create port bindings automatically so it is possible to host multiple Docker containers inside a Docker service VM. We plan to continue to significantly improve Docker containers integration in upcoming releases by adding support for Docker VM clusters, Nova Docker plugin support to place Docker containers on bare metal servers controlled by Nova adding integrating with monitoring tools and other 3rd party apps supported by Murano. Here is a link to a small demo video: https://www.youtube.com/watch?v=P51ZUIqS4n4 Thanks Georgy -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Multi host devstack
Hi, Has anyone successfully installed devstack as multi-node setup using this tutorial? http://docs.openstack.org/developer/devstack/guides/multinode-lab.html I'm unable to do so. Regards, Vineet Menon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!
I'm also interested in it. On Sat, Nov 01, 2014 at 10:27:59AM -0700, Chuck Carlino chuckjcarl...@gmail.com wrote: On 10/31/2014 01:01 PM, Ian Wells wrote: Maruti's talk is, in fact, so interesting that we should probably get together and talk about this earlier in the week. I very much want to see virtual-physical programmatic bridging, and I know Kevin Benton is also interested. Arguably the MPLS VPN stuff also is similar in scope. Can I propose we have a meeting on cloud edge functionality? -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I am interested in these discussions as well. Chuck Carlino ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata isaku.yamah...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] How to trap create/delete snapshot calls
Hi All, Our product (FS + block storage) uses FUSE to trap the filesystem calls. So, If I mount the filesystem on compute node then this way I can receive filesystem related calls also the IOs provided that I donot have cinder. But, this way I cannot trap/receive snapshot related calls. My question are, 1. How I can trap snapshot related calls? 2. Is cinder (volume driver) the only way? 3. Can I use loop devices? Thanks, Darshan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [mistral] Cancelling today's team meeting due to summit activities
Renat Akhmerov @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Multi host devstack
Vineet Menon mvineetme...@gmail.com writes: Has anyone successfully installed devstack as multi-node setup using this tutorial? http://docs.openstack.org/developer/devstack/guides/multinode-lab.html Yes, but I think I may be the last one to touch that (adding NOVA_VNC_ENABLED) so I'm probably not the best judge. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.db] Marker based paging
Hi Mike, I think that code was taken from Nova (or maybe some other project) as is and we haven't touched it since then. Please speak up - we want to know about all possible problems with current approach. Thanks, Roman On Fri, Oct 31, 2014 at 2:58 PM, Heald, Mike mike.he...@hp.com wrote: Hi all, I'm implementing paging on storyboard, and I wanted to ask why we decided to use marker based paging. I have some opinions on this, but I want to keep my mouth shut until I find out what problem it was solving :) Thanks, Mike ___ 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] [Policy][Group-based Policy] Audio stream for GBP Design Session in Paris
Hey all, I'm participating remotely this session. Any plan for audio stream of Tuesday's session? I'll happily offer a GoToMeeting, if needed. Would someone be willing to scribe discussion in #openstack-gbp channel? -- Open industry-related email from Gregory M. Lebovitz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [mistral] Join Mistral design session on Tue at 15.40 (Le Meridien)
Hi all, Please join us for the Mistral design session tomorrow Tue Nov 4 at 15.40 to discuss whatever you want about Mistral. Would be great if you added your items in the agenda in advance so we could plan the timing. Etherpad: https://etherpad.openstack.org/p/paris-2014-design-summit-mistral https://etherpad.openstack.org/p/paris-2014-design-summit-mistral Thanks! Renat Akhmerov @ Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] R: [blazar]: proposal for a new lease type
Hi Nikolay, yes I'm in Paris this week. That's good!! See you in irc the next week. Thanks a lot. Cheers, Lisa - Messaggio originale - Da: Nikolay Starodubtsev nstarodubt...@mirantis.com Inviato: 02/11/2014 21.39 A: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Cc: ver Marco Verlato marco.verl...@pd.infn.it; sga Massimo Sgaravatto massimo.sgarava...@pd.infn.it Oggetto: Re: [openstack-dev] [blazar]: proposal for a new lease type Hi Lisa, As far as I get the main idea of your blueprint it's something that we've planned to do in the future. So, yes this idea is something that Blazar should do. But the problem is that we have some real-time problems. I mean we are in rename process (yeah, it takes real long time for us) and our devstack job is broken (I tried to fix it, but have some problems with time). If you want to discuss how we, I mean Blazar core-team, and you, team from the Italian National Institute for Nuclear Physics, can collaborate we can discuss it in irc on blazar-channel, I think. We just need to appoint a time slot for that. May be week after summit? If I understand you'll be there this week. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-10-31 19:19 GMT+04:00 Lisa lisa.zangra...@pd.infn.it: Hi Nikolay, many thanks. Cheers, Lisa On 31/10/2014 14:10, Nikolay Starodubtsev wrote: Hi Lisa, Sylvain, I'll take a look at blueprint next week and will try to left some feedback about it. Stay tuned. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-10-31 16:14 GMT+04:00 Lisa lisa.zangra...@pd.infn.it: Hi Sylvain, thanks for your answer. Actually we haven't yet developed that because we'd like to be sure that our proposal is fine with BLAZAR. We already implemented a pluggable advanced scheduler for Nova which addresses the issues we are experiencing with OpenStack in the Italian National Institute for Nuclear Physics. This scheduler named FairShareScheduler is able to make OpenStack more efficient and flexible in terms of resource usage. Of course we wish to integrate our work in OpenStack and so we tried several times to start a discussion and a possible interaction with the OpenStack developers, but it seems to be so difficult to do it. The GANTT people suggested us to refer to BLAZAR because it may have more affinity with our scope. Is it so? Therefore, I would appreciate to know if you may be interested in our proposal. Thanks for your attention. Cheers, Lisa Such component's name is FairShareScheduler and On 31/10/2014 10:08, Sylvain Bauza wrote: Le 31/10/2014 09:46, Lisa a écrit : Dear Sylvain and BLAZAR team, I'd like to receive your feedback on our blueprint (https://blueprints.launchpad.net/blazar/+spec/fair-share-lease) and start a discussion in Paris the next week at the OpenStack Summit. Do you have a time slot for a very short meeting on this? Thanks in advance. Cheers, Lisa Hi Lisa, At the moment, I'm quite occupied on Nova to split out the scheduler, so I can't hardly dedicate time for Blazar. That said, I would appreciate if you could propose some draft implementation attached to the blueprint, so I could glance at it and see what you aim to deliver. Thanks, -Sylvain On 28/10/2014 12:07, Lisa wrote: Dear Sylvain, as you suggested me few weeks ago, I created the blueprint (https://blueprints.launchpad.net/blazar/+spec/fair-share-lease) and I'd like to start a discussion. I will be in Paris the next week at the OpenStack Summit, so it would be nice to talk with you and the BLAZAR team about my proposal in person. What do you think? thanks in advance, Cheers, Lisa On 18/09/2014 16:00, Sylvain Bauza wrote: Le 18/09/2014 15:27, Lisa a écrit : Hi all, my name is Lisa Zangrando and I work at the Italian National Institute for Nuclear Physics (INFN). In particular I am leading a team which is addressing the issue concerning the efficiency in the resource usage in OpenStack. Currently OpenStack allows just a static partitioning model where the resource allocation to the user teams (i.e. the projects) can be done only by considering fixed quotas which cannot be exceeded even if there are unused resources (but) assigned to different projects. We studied the available BLAZAR's documentation and, in agreement with Tim Bell (who is responsible the OpenStack cloud project at CERN), we think this issue could be addressed within your framework. Please find attached a document that describes our use cases (actually we think that many other environments have to deal with the same problems) and how they could be managed in BLAZAR, by defining a new lease type (i.e. fairShare lease) to be considered as extension of the list of the already supported lease types. I would then be happy to discuss these ideas with
[openstack-dev] Devstack with libvirt and xenlight
Hello, I am working with Openstack on ARMv8 and would like to test Devstack using libvirt with Xen (xenlight). I am looking for information on how to correctly configure Devstack for this. I have used Devstack with libvirt (and KVM) on ARMv8 recently and it works for the most part (with a few issues that we knew about). Currently, I have build libvirt (using --with-libxl) and have manually tested various operations with it (using virsh -c xen:///) and they are all working so far. I have already been told by Xen maintainers that using XenAPI on ARMv8 is not going to be an option yet, and that I need to proceed with libvirt + xenlight for now. Any pointers to how to setup Devstack correctly would be appreciated. Thank you, Clark L ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Multi host devstack
If it helps, I got it running using a much smaller configuration, simply this : SERVICE_TOKEN=footoken ADMIN_PASSWORD=foobar MYSQL_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWORD DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_HOST=10.192.194.164 HOST_IP=10.192.194.166 MULTI_HOST=1 MYSQL_HOST=$SERVICE_HOST RABBIT_HOST=$SERVICE_HOST CINDER_SERVICE_HOST=$SERVICE_HOST GLANCE_HOSTPORT=$SERVICE_HOST:9292 DATABASE_TYPE=mysql -Original Message- From: Robbie Harwood [mailto:rharw...@redhat.com] Sent: Monday, November 3, 2014 8:27 AM To: Vineet Menon; openstack-dev Subject: Re: [openstack-dev] Multi host devstack Vineet Menon mvineetme...@gmail.com writes: Has anyone successfully installed devstack as multi-node setup using this tutorial? http://docs.openstack.org/developer/devstack/guides/multinode- lab.html Yes, but I think I may be the last one to touch that (adding NOVA_VNC_ENABLED) so I'm probably not the best judge. ___ 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] [Keystone] Alternative federation mapping
On 11/03/2014 08:50 AM, John Dennis wrote:
I had a bunch of notes but I can't find them at the moment
so I'm going from memory here (always a bit risky).
I found my notes, attached is an reStructured text document that
summarizes the issues I found with the current Keystone mapping, the
basic requirements for mapping based on my prior experience and reasons
for selecting the approach I did. I hope this explains the motivations
and rationale to put things into context.
--
John
Federation Mapping
==
Introduction
With federated authentication a trusted external IdP (Identity
Provider) authenticates an entity and provides attributes associated
with the authenticated entity such as full name, organization,
location, group membership, roles, etc. to the local authorization
system. The remote identity attributes usually do not directly
correlate to the local identity attributes as such they must be mapped
or transformed to be consistent with the local identity attributes.
Problems with existing contributed OpenStack federation mapping
---
A federated mapping implementation was contributed to OpenStack which
is based on static rules. However that mapping system lacks basic
features required in real world deployments. Examples of the
deficiencies are:
* Replacement substitutions are specified by an index, e.g. {0} making
them difficult to use.
* If you edit a rule all the indices shift and you have carefully
adjust multiple locations, this is tedious and error prone.
* Numeric replacements are not friendly, it's difficult to remember what
index maps to which value. Likewise its difficult to read a rule
with a indexed substitutions and understand what is being
replaced, a number provides no context for the reader.
* Impossible to specify how strings containing lists of values are to
be split.
* Any string containing a colon is automatically split irregardless of
semantics of the string.
* Impossible to perform tests and perform conditional logic. For
example you cannot test if the user is a member of a group and if so
add a role based on the group membership. You cannot test if a list
is empty, has a certain number of members, if a value starts with a
prefix or ends with a suffix, etc.
* No mechanism to handle case sensitivity.
* Cannot split direct map value into multiple values, e.g. user@domain
cannot be returned as ['user', 'domain'], i.e. {0}, {1}. This
requires more robust regular expression support than is provided.
* Cannot operate on substrings or do replacements. Common operations
such as replacing hyphens with underscores or stripping off prefixes
or suffixes are impossible.
* Direct map values cannot be reassigned by later rules.
e.g. email might be in assertion so it would be direct map,
but if it was absent one can't synthesize it from other values
in the assertion, i.e. user + @ + domain
* Difficult to build values by string interpolation or concatenation.
* The local array elements are dicts whose keys can contain 'user' or
'group' or both, but you can't have more that one user or group in an
element and elements that define a user more than once produce an
error.
* Logical OR requires cut-n-paste copies of many rules with only a minor
difference in each rule, rules quickly become unreadable and difficult
to ascertain the logic.
* ``not_any_of`` does not work when regex is True, enabling regex
effectively changes the condition to ``any_one_of``. (This is a bug
that can be fixed)
Examples of real work tasks current mapping cannot handle
-
I've worked with RADIUS for years. RADIUS is often configured to
operate in a federated mode where the attributes supplied to the
RADIUS server have to be manipulated to match local conventions and
policies. Below are some of the most common issues I've seen admins
have to tackle.
* Split the realm from the username. Assign the username and realm
independently in the result. This is by far the most common issue
admins raise.
* Strip prefixes and suffixes and/or take a prefix or suffix and map
it to a new independent value. Believe it or not many organizations
embed group/role information in their usernames. Usernames such as
johndoe_staff where the username is johndoe and role is staff
are depressingly common.
* Behave differently depending on the realm, the IdP, a DNS name or a
network address.
* Test for membership in a collection. Examples are whitelists,
blacklists, groups, etc. The result of the membership test modifies
how the user is ultimately mapped and the privileges they receive.
* Search for and/or extract substrings, usually demands regular
expression support. The result of the regular expression search may
alter the flow of control.
* Filter certain characters.
* Convert to lower case or
[openstack-dev] [cinder][nova] Timeout problems
Hi, Parallel volume operations lead to inconsistencies between the OpenStack database and the deployed view on a centralized storage backend. When performing multiple volume operation on a centralized storage backend it can come to timeouts on the OpenStack side. These timeouts can be the RPC timeout or e.g. in high availability scenarios, the HA proxy timeout. When nova wants to attach a volume, it triggers the status change from available to attaching and sends initialize_connection via cinderclient to cinder API via the REST API. Cinder API performs a synchronous CALL to cinder volume, then via the driver the centralized storage backend is contacted. When now a timeout occurs, nova triggers the database to change the volume status from attaching to available. Meanwhile the centralized storage backend performs, what was originally requested. Here we can have a mismatch between database and the real view of the centralized storage backend. I would be curious if this behavior is also seen by others and would like to discuss possible solution. /Tobi See also https://blueprints.launchpad.net/cinder/+spec/volume-status-polling 11javascript:; https://review.openstack.org/#/c/132225/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.db] Marker based paging
Here are a few ML threads on this topic: http://lists.openstack.org/pipermail/openstack-dev/2014-March/030322.html http://www.gossamer-threads.com/lists/openstack/dev/2777 http://lists.openstack.org/pipermail/openstack-dev/2013-November/018861.html Thanks, Steven Kaufer Roman Podoliaka rpodoly...@mirantis.com wrote on 11/03/2014 10:35:21 AM: From: Roman Podoliaka rpodoly...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 11/03/2014 10:43 AM Subject: Re: [openstack-dev] [oslo.db] Marker based paging Hi Mike, I think that code was taken from Nova (or maybe some other project) as is and we haven't touched it since then. Please speak up - we want to know about all possible problems with current approach. Thanks, Roman On Fri, Oct 31, 2014 at 2:58 PM, Heald, Mike mike.he...@hp.com wrote: Hi all, I'm implementing paging on storyboard, and I wanted to ask why we decided to use marker based paging. I have some opinions on this, but I want to keep my mouth shut until I find out what problem it was solving :) Thanks, Mike ___ 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] [nfv] VM-based VLAN trunking blueprints
Hello, will this topic be discussed in the design session? Richard On Mon, Nov 3, 2014 at 10:36 PM, Erik Moe erik@ericsson.com wrote: I created an etherpad and added use cases (so far just the ones in your email). https://etherpad.openstack.org/p/tenant_vlans /Erik *From:* Erik Moe [mailto:erik@ericsson.com] *Sent:* den 2 november 2014 23:12 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints *From:* Ian Wells [mailto:ijw.ubu...@cack.org.uk ijw.ubu...@cack.org.uk] *Sent:* den 31 oktober 2014 23:35 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints On 31 October 2014 06:29, Erik Moe erik@ericsson.com wrote: I thought Monday network meeting agreed on that “VLAN aware VMs”, Trunk network + L2GW were different use cases. Still I get the feeling that the proposals are put up against each other. I think we agreed they were different, or at least the light was beginning to dawn on the differences, but Maru's point was that if we really want to decide what specs we have we need to show use cases not just for each spec independently, but also include use cases where e.g. two specs are required and the third doesn't help, so as to show that *all* of them are needed. In fact, I suggest that first we do that - here - and then we meet up one lunchtime and attack the specs in etherpad before submitting them. In theory we could have them reviewed and approved by the end of the week. (This theory may not be very realistic, but it's good to set lofty goals, my manager tells me.) Ok, let’s try. I hope you theory turns out to be realistic. J Here are some examples why bridging between Neutron internal networks using trunk network and L2GW IMO should be avoided. I am still fine with bridging to external networks. Assuming VM with trunk port wants to use floating IP on specific VLAN. Router has to be created on a Neutron network behind L2GW since Neutron router cannot handle VLANs. (Maybe not too common use case, but just to show what kind of issues you can get into) neutron floatingip-associate FLOATING_IP_ID INTERNAL_VM_PORT_ID The code to check if valid port has to be able to traverse the L2GW. Handing of IP addresses of VM will most likely be affected since VM port is connected to several broadcast domains. Alternatively new API can be created. Now, this is a very good argument for 'trunk ports', yes. It's not actually an argument against bridging between networks. I think the bridging case addresses use cases (generally NFV use cases) where you're not interested in Openstack managing addresses - often because you're forwarding traffic rather than being an endpoint, and/or you plan on disabling all firewalling for speed reasons, but perhaps because you wish to statically configure an address rather than use DHCP. The point is that, in the absence of a need for address-aware functions, you don't really care much about ports, and in fact configuring ports with many addresses may simply be overhead. Also, as you say, this doesn't address the external bridging use case where what you're bridging to is not necessarily in Openstack's domain of control. I know that many NFVs currently prefer to manage everything themselves. At the same time, IMO, I think they should be encouraged to become Neutronified. In “VLAN aware VMs” trunk port mac address has to be globally unique since it can be connected to any network, other ports still only has to be unique per network. But for L2GW all mac addresses has to be globally unique since they might be bridged together at a later stage. I'm not sure that that's particularly a problem - any VM with a port will have one globally unique MAC address. I wonder if I'm missing the point here, though. Ok, this was probably too specific, sorry. Neutron can reuse MAC addresses among Neutron networks. But I guess this is configurable. Also some implementations might not be able to take VID into account when doing mac address learning, forcing at least unique macs on a trunk network. If an implementation struggles with VLANs then the logical thing to do would be not to implement them in that driver. Which is fine: I would expect (for instance) LB-driver networking to work for this and leave OVS-driver networking to never work for this, because there's little point in fixing it. Same as above, this is related to reuse of MAC addresses. Benefits with “VLAN aware VMs” are integration with existing Neutron services. Benefits with Trunk networks are less consumption of Neutron networks, less management per VLAN. Actually, the benefit of trunk networks is: - if I use an infrastructure where all networks are trunks, I can find out that a network is a
[openstack-dev] [heat] AutoScalingGroup with LB Member
Please if you can help me out.. Here is my heat stack http://paste.opensuse.org/80575159 for some reason its failing on the member address.. not sure the syntax is right. Anyone? TIA, -- Cameron Seader Sr. Systems Engineer SUSE c...@suse.com (W)208-577-6857 (M)208-420-2167 SUSECon 2014 Register at suse.com/susecon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] pci pass through turing complete config options?
On Oct 31, 2014, at 9:27 PM, Robert Li (baoli) ba...@cisco.com wrote: On 10/28/14, 11:01 AM, Daniel P. Berrange berra...@redhat.com wrote: On Tue, Oct 28, 2014 at 10:18:37AM -0400, Jay Pipes wrote: On 10/28/2014 07:44 AM, Daniel P. Berrange wrote: One option would be a more CSV like syntax eg pci_passthrough_whitelist = address=*0a:00.*,physical_network=physnet1 pci_passthrough_whitelist = vendor_id=1137,product_id=0071 But this gets confusing if we want to specifying multiple sets of data so might need to use semi-colons as first separator, and comma for list element separators pci_passthrough_whitelist = vendor_id=8085;product_id=4fc2, vendor_id=1137;product_id=0071 What about this instead (with each being a MultiStrOpt, but no comma or semicolon delimiters needed…)? This is easy for a developer to access, but not easy for a deployer to make sure they have configured correctly because they have to keep up with the order of the options instead of making sure there is a new group header for each set of options. [pci_passthrough_whitelist] # Any Intel PRO/1000 F Sever Adapter vendor_id=8086 product_id=1001 address=* physical_network=* # Cisco VIC SR-IOV VF only on specified address and physical network vendor_id=1137 product_id=0071 address=*:0a:00.* physical_network=physnet1 I think this is reasonable, though do we actually support setting the same key twice ? Yes, if it is registered in different groups. As an alternative we could just append an index for each element in the list, eg like this: [pci_passthrough_whitelist] rule_count=2 # Any Intel PRO/1000 F Sever Adapter vendor_id.0=8086 Be careful about constructing the names. You can’t have “.” in them because then you can’t access them in python, for example: cfg.CONF.pci_passthrough_whitelist.vendor_id.0 product_id.0=1001 address.0=* physical_network.0=* # Cisco VIC SR-IOV VF only on specified address and physical network vendor_id.1=1137 product_id.1=0071 address.1=*:0a:00.* physical_network.1=physnet1 [pci_passthrough_whitelist] rule_count=2 # Any Intel PRO/1000 F Sever Adapter vendor_id.0=8086 product_id.0=1001 address.0=* physical_network.0=* # Cisco VIC SR-IOV VF only on specified address and physical network vendor_id.1=1137 product_id.1=0071 address.1=*:0a:00.* physical_network.1=physnet1 Or like this: [pci_passthrough] whitelist_count=2 [pci_passthrough_rule.0] # Any Intel PRO/1000 F Sever Adapter vendor_id=8086 product_id=1001 address=* physical_network=* [pci_passthrough_rule.1] # Cisco VIC SR-IOV VF only on specified address and physical network vendor_id=1137 product_id=0071 address=*:0a:00.* physical_network=physnet1 Yeah, The last format (copied in below) is a good idea (without the section for the count) to handle list of dictionaries. I¹ve seen similar config examples in neutron code. [pci_passthrough_rule.0] # Any Intel PRO/1000 F Sever Adapter vendor_id=8086 product_id=1001 address=* physical_network=* [pci_passthrough_rule.1] # Cisco VIC SR-IOV VF only on specified address and physical network vendor_id=1137 product_id=0071 address=*:0a:00.* physical_network=physnet1 Without direct oslo support, to implement it requires a small method that uses oslo cfg¹s MultiConfigParser(). I’m not sure what you mean needs new support? I think this would work, except for the “.” in the group name. Now a few questions if we want to do it in Kilo: ‹ Do we still need to be back-ward compatible in configuring the whitelist? If we do, then we still need to be able to handle the json docstring. If there is code released using that format, you need to support it. You can define options as being deprecated so the new options replace the old but the old are available if found in the config file. Doug ‹ To support the new format in devstack, we can use meta-section in local.conf. how would we support the old format which is still json docstring? Is something like this https://review.openstack.org/#/c/123599/ acceptable? ‹ Do we allow old/new formats coexist in the config file? Probably not. Either that, or the YAML file that Sean suggested, would be my preference... I think it is nice to have it all in the same file, not least because it will be easier for people supporting openstack in the field. ie in bug reports we cna just ask for nova.conf and know we'll have all the user config we care about in that one place. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [heat] AutoScalingGroup with LB Member
Hi Cameron, from the first look into the paste the member resource part of the template seems wrongly indented yaml. Is it or it is just paste formatting glitch? Best regards, Pavlo Shchelokovskyy. On Nov 4, 2014 12:28 AM, Cameron Seader csea...@suse.com wrote: Please if you can help me out.. Here is my heat stack http://paste.opensuse.org/80575159 for some reason its failing on the member address.. not sure the syntax is right. Anyone? TIA, -- Cameron Seader Sr. Systems Engineer SUSE c...@suse.com (W)208-577-6857 (M)208-420-2167 SUSECon 2014 Register at suse.com/susecon ___ 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] [oslo.db] Marker based paging
Thanks for that, Steven :) So just to clarify, results are ordered by the relevant timestamps to ensure consistent order and so that new records would never show on previous pages and be missed, and we're limited to just a next page navigation, and we cannot order the entire result set on any column but the timestamps, as this would break the paging because we can't do the comparisons we need to if the results aren't in that order. Have I got that correct? Thanks, Mike From: Steven Kaufer [kau...@us.ibm.com] Sent: 03 November 2014 22:39 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [oslo.db] Marker based paging Here are a few ML threads on this topic: http://lists.openstack.org/pipermail/openstack-dev/2014-March/030322.html http://www.gossamer-threads.com/lists/openstack/dev/2777 http://lists.openstack.org/pipermail/openstack-dev/2013-November/018861.html Thanks, Steven Kaufer Roman Podoliaka rpodoly...@mirantis.com wrote on 11/03/2014 10:35:21 AM: From: Roman Podoliaka rpodoly...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 11/03/2014 10:43 AM Subject: Re: [openstack-dev] [oslo.db] Marker based paging Hi Mike, I think that code was taken from Nova (or maybe some other project) as is and we haven't touched it since then. Please speak up - we want to know about all possible problems with current approach. Thanks, Roman On Fri, Oct 31, 2014 at 2:58 PM, Heald, Mike mike.he...@hp.com wrote: Hi all, I'm implementing paging on storyboard, and I wanted to ask why we decided to use marker based paging. I have some opinions on this, but I want to keep my mouth shut until I find out what problem it was solving :) Thanks, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] AutoScalingGroup with LB Member
well if it is then it should work right. :-) Do you see anything else wrong with it? -Cameron On 11/03/2014 04:49 PM, Pavlo Shchelokovskyy wrote: Hi Cameron, from the first look into the paste the member resource part of the template seems wrongly indented yaml. Is it or it is just paste formatting glitch? Best regards, Pavlo Shchelokovskyy. On Nov 4, 2014 12:28 AM, Cameron Seader csea...@suse.com mailto:csea...@suse.com wrote: Please if you can help me out.. Here is my heat stack http://paste.opensuse.org/80575159 for some reason its failing on the member address.. not sure the syntax is right. Anyone? TIA, -- Cameron Seader Sr. Systems Engineer SUSE c...@suse.com mailto:c...@suse.com (W)208-577-6857 tel:208-577-6857 (M)208-420-2167 tel:208-420-2167 SUSECon 2014 Register at suse.com/susecon http://suse.com/susecon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cameron Seader Sr. Systems Engineer SUSE c...@suse.com (W)208-577-6857 (M)208-420-2167 SUSECon 2014 Register at suse.com/susecon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] AutoScalingGroup with LB Member
Here is the error that I get. Error: ERROR: The specified reference web_server (in web_server_group.Properties.resource.member.properties.address) is incorrect. -Cameron On 11/03/2014 04:49 PM, Pavlo Shchelokovskyy wrote: Hi Cameron, from the first look into the paste the member resource part of the template seems wrongly indented yaml. Is it or it is just paste formatting glitch? Best regards, Pavlo Shchelokovskyy. On Nov 4, 2014 12:28 AM, Cameron Seader csea...@suse.com mailto:csea...@suse.com wrote: Please if you can help me out.. Here is my heat stack http://paste.opensuse.org/80575159 for some reason its failing on the member address.. not sure the syntax is right. Anyone? TIA, -- Cameron Seader Sr. Systems Engineer SUSE c...@suse.com mailto:c...@suse.com (W)208-577-6857 tel:208-577-6857 (M)208-420-2167 tel:208-420-2167 SUSECon 2014 Register at suse.com/susecon http://suse.com/susecon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cameron Seader Sr. Systems Engineer SUSE c...@suse.com (W)208-577-6857 (M)208-420-2167 SUSECon 2014 Register at suse.com/susecon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][opendaylight]OpenDaylight Neutron Plugin design session etherpad
A little confusion on this etherpad topic: Neutron is not a controller! Can OpenDaylight become The Controller? Is this the common consensus of the Whole Neutron community, and what does the word controller mean here? If Neutron controller nodes are not doing anything related with controlling, then what about the default built-in implementation of L2population in the ML2 plugin, and DVR in the L3 plugin, and the upcoming features like dynamic routing, BGP VPN, and so on? By my thought, ODL is a standalone controller separated from Neutron, and could co-exist with Neutron if customers choose to do so. But Neutron built-in implementation in the plugins is already a sort of *Controller*, there are no logical function difference in the natural positioning between them. What is the standpoint of Neutron community: is the built-in implementation just a reference for POC (waiting some future 3rd Controller like ODL for commercialized deployment), or aimed at large scale production deployment by itself? Who will be the first citizen? On Mon, Nov 3, 2014 at 7:15 PM, Carl Baldwin c...@ecbaldwin.net wrote: https://etherpad.openstack.org/p/odl-neutron-plugin On Mon, Nov 3, 2014 at 4:05 AM, Richard Woo richardwoo2...@gmail.com wrote: Hi, what is etherpad link for opendaylight neutron plugin design session? http://kilodesignsummit.sched.org/event/5a430f46842e9239ea6c29a69cbe4e84#.VFdhdPTF-0E Thanks, Richard ___ 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] [nfv] VM-based VLAN trunking blueprints
Is the trunk port use case like the super vlan? Also there is another typical use case maybe not covered: extended flat network. Traffic on the port carries multiple vlans, but these vlans are not necessarily managed by neutron-network, so can not be classified to trunk port. And they don't need a gateway to communicate with other nodes in the physical provider network, what they expect neutron to do, is much like what the flat network does(so I call it extended flat): just keep the packets as is bidirectionally between wire and vnic. From: Erik Moe [erik@ericsson.com] Sent: Tuesday, November 04, 2014 5:36 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints I created an etherpad and added use cases (so far just the ones in your email). https://etherpad.openstack.org/p/tenant_vlans /Erik From: Erik Moe [mailto:erik@ericsson.com] Sent: den 2 november 2014 23:12 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: den 31 oktober 2014 23:35 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints On 31 October 2014 06:29, Erik Moe erik@ericsson.commailto:erik@ericsson.com wrote: I thought Monday network meeting agreed on that “VLAN aware VMs”, Trunk network + L2GW were different use cases. Still I get the feeling that the proposals are put up against each other. I think we agreed they were different, or at least the light was beginning to dawn on the differences, but Maru's point was that if we really want to decide what specs we have we need to show use cases not just for each spec independently, but also include use cases where e.g. two specs are required and the third doesn't help, so as to show that *all* of them are needed. In fact, I suggest that first we do that - here - and then we meet up one lunchtime and attack the specs in etherpad before submitting them. In theory we could have them reviewed and approved by the end of the week. (This theory may not be very realistic, but it's good to set lofty goals, my manager tells me.) Ok, let’s try. I hope you theory turns out to be realistic. :) Here are some examples why bridging between Neutron internal networks using trunk network and L2GW IMO should be avoided. I am still fine with bridging to external networks. Assuming VM with trunk port wants to use floating IP on specific VLAN. Router has to be created on a Neutron network behind L2GW since Neutron router cannot handle VLANs. (Maybe not too common use case, but just to show what kind of issues you can get into) neutron floatingip-associate FLOATING_IP_ID INTERNAL_VM_PORT_ID The code to check if valid port has to be able to traverse the L2GW. Handing of IP addresses of VM will most likely be affected since VM port is connected to several broadcast domains. Alternatively new API can be created. Now, this is a very good argument for 'trunk ports', yes. It's not actually an argument against bridging between networks. I think the bridging case addresses use cases (generally NFV use cases) where you're not interested in Openstack managing addresses - often because you're forwarding traffic rather than being an endpoint, and/or you plan on disabling all firewalling for speed reasons, but perhaps because you wish to statically configure an address rather than use DHCP. The point is that, in the absence of a need for address-aware functions, you don't really care much about ports, and in fact configuring ports with many addresses may simply be overhead. Also, as you say, this doesn't address the external bridging use case where what you're bridging to is not necessarily in Openstack's domain of control. I know that many NFVs currently prefer to manage everything themselves. At the same time, IMO, I think they should be encouraged to become Neutronified. In “VLAN aware VMs” trunk port mac address has to be globally unique since it can be connected to any network, other ports still only has to be unique per network. But for L2GW all mac addresses has to be globally unique since they might be bridged together at a later stage. I'm not sure that that's particularly a problem - any VM with a port will have one globally unique MAC address. I wonder if I'm missing the point here, though. Ok, this was probably too specific, sorry. Neutron can reuse MAC addresses among Neutron networks. But I guess this is configurable. Also some implementations might not be able to take VID into account when doing mac address learning, forcing at least unique macs on a trunk network. If an implementation struggles with VLANs then the logical thing to do would be not to implement them in that
[openstack-dev] [neutron] what is the different between ovs-ofctl and iptalbes? Can we use ovs-ofctl to nat floating ip into fixed ip if we use openvswitch agent?
-- Best Li Tianqing___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] what is the different between ovs-ofctl and iptalbes? Can we use ovs-ofctl to nat floating ip into fixed ip if we use openvswitch agent?
Hi, OVS mainly focus on l2 which iptables mainly focus on l3 or higher. Damon Wang 2014-11-04 11:12 GMT+08:00 Li Tianqing jaze...@163.com: -- Best Li Tianqing ___ 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] pci pass through turing complete config options?
On 4 November 2014 12:32, Doug Hellmann d...@doughellmann.com wrote: ... Be careful about constructing the names. You can’t have “.” in them because then you can’t access them in python, for example: cfg.CONF.pci_passthrough_whitelist.vendor_id.0 And the use of an int as a name. Personally I think a separate yaml file would be a bit nicer. -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
Re: [openstack-dev] [neutron] what is the different between ovs-ofctl and iptalbes? Can we use ovs-ofctl to nat floating ip into fixed ip if we use openvswitch agent?
ovs is implemented open flow, in ovs, it can see the l3, why do not use ovs? -- Best Li Tianqing At 2014-11-04 11:55:46, Damon Wang damon.dev...@gmail.com wrote: Hi, OVS mainly focus on l2 which iptables mainly focus on l3 or higher. Damon Wang 2014-11-04 11:12 GMT+08:00 Li Tianqing jaze...@163.com: -- Best Li Tianqing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] AutoScalingGroup with LB Member
Cameron Seader csea...@suse.com wrote on 11/03/2014 06:22:32 PM: Please if you can help me out.. Here is my heat stack http://paste.opensuse.org/80575159 for some reason its failing on the member address.. not sure the syntax is right. Compare with https://github.com/openstack/heat-templates/blob/master/hot/asg_of_stacks.yaml Perhaps the text in the Template Guide ( http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::AutoScalingGroup ) is confusing on this point. The value of the resource property should be the definition of one resource (i.e., the value to which the resource name is mapped in the YAML), not a set of resource definitions. Regards, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] what is the different between ovs-ofctl and iptalbes? Can we use ovs-ofctl to nat floating ip into fixed ip if we use openvswitch agent?
maybe two reasons: performance caused by flow miss; feature parity L3+ flow table destroy the megaflow aggregation, so if your app has many concurrent sessions like web server, flow miss upcall would make vswitchd corrupted. iptable is already there, migrating it to ovs flow table needs a lot of extra development, not to say that some advanced features is lost (for example, stateful firewall). However ovs is considering to add some hook to iptable, but in the very early stage yet. Even with that, it is not implemented by ovs datapath flowtable, but by iptable. On Tue, Nov 4, 2014 at 1:07 PM, Li Tianqing jaze...@163.com wrote: ovs is implemented open flow, in ovs, it can see the l3, why do not use ovs? -- Best Li Tianqing At 2014-11-04 11:55:46, Damon Wang damon.dev...@gmail.com wrote: Hi, OVS mainly focus on l2 which iptables mainly focus on l3 or higher. Damon Wang 2014-11-04 11:12 GMT+08:00 Li Tianqing jaze...@163.com: -- Best Li Tianqing ___ 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] [oslo.db] Marker based paging
On 11/04/2014 01:08 AM, Heald, Mike wrote: Thanks for that, Steven :) So just to clarify, results are ordered by the relevant timestamps to ensure consistent order and so that new records would never show on previous pages and be missed, and we're limited to just a next page navigation, and we cannot order the entire result set on any column but the timestamps, as this would break the paging because we can't do the comparisons we need to if the results aren't in that order. Have I got that correct? No, that's not correct. There's nothing limiting one from ordering on other columns than timestamp. We always ensure that there is a secondary order on a column with unique values (like the primary key), in order to ensure that pages of results are strictly ordered even when the sort field is non-unique (like timestamp). We're limited to next-previous pagination by choice because of the scalability and performance limitations of a limit-offset pagination strategy. Best, jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][compute] propose to use a table to deal with the vm_state when _init_instance in compute
hello all:
in current _init_instance function in compute manager,
there's flood 'and' 'or' logic, to check the vm_state and task_state
when initialize a instance during service list,
this lead hard to read and hard to maintain, so I propose a new way to
handle this.
we can create a vm_state_table, by look up the table we can find the
action we need to do for the instance,
from this table , you can clearly see what vm_state and task_state
should take the action.
for example:
{vm_states list :{task_states list: action}},
each entry stands for an action,
and we walk though the tuple
so the table should be like this:
vm_state_table = (
{vm_states.SOFT_DELETE :{'ALL': ACTION_NONE}},
{vm_states.ERROR: {('NOT_IN',[task_states.RESIZE_MIGRATING,
task_states.DELETING]): ACTION_NONE}},
{vm_states.DELETED: {'ALL': _complete_partial_deletion}},
{vm_states.BUILDING: {'ALL': ACTION_ERROR}},
{'ALL': {('IN',[task_states.SCHEDULING,
task_states.BLOCK_DEVICE_MAPPING,
task_states.NETWORKING,
task_states.SPAWNING)]: ACTION_ERROR}},
{('IN',[vm_states.ACTIVE, vm_states.STOPPED]: {('IN',
[task_states.REBUILDING,
task_states.REBUILD_BLOCK_DEVICE_MAPPING,
task_states.REBUILD_SPAWNING]): ACTION_ERROR}},
{('NOT_IN',[vm_states.ERROR]): {('IN', [task_states.IMAGE_SNAPSHOT_PENDING,
task_states.IMAGE_PENDING_UPLOAD,
task_states.IMAGE_UPLOADING,
task_states.IMAGE_SNAPSHOT]): _post_interrupted_snapshot_cleanup}}
)
what do you think, do we need a bp for this?
--
Thanks,
Eli (Li Yong) Qiao
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][compute] propose to use a table to deal with the vm_state when _init_instance in compute
+1,
a good idea, it will make it more clear.
from implementation perspective we need to pay attention that some status
will pass through and some will just return
Best Regards!
Kevin (Chen) Ji 纪 晨
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
From: Eli Qiao ta...@linux.vnet.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 11/04/2014 03:13 PM
Subject:[openstack-dev] [nova][compute] propose to use a table to deal
with the vm_state when _init_instance in compute
hello all:
in current _init_instance function in compute manager,
there's flood 'and' 'or' logic, to check the vm_state and task_state when
initialize a instance during service list,
this lead hard to read and hard to maintain, so I propose a new way to
handle this.
we can create a vm_state_table, by look up the table we can find the
action we need to do for the instance,
from this table , you can clearly see what vm_state and task_state should
take the action.
for example:
{vm_states list :{task_states list: action}},
each entry stands for an action,
and we walk though the tuple
so the table should be like this:
vm_state_table = (
{vm_states.SOFT_DELETE :{'ALL': ACTION_NONE}},
{vm_states.ERROR: {('NOT_IN',[task_states.RESIZE_MIGRATING,
task_states.DELETING]): ACTION_NONE}},
{vm_states.DELETED: {'ALL': _complete_partial_deletion}},
{vm_states.BUILDING: {'ALL': ACTION_ERROR}},
{'ALL': {('IN',[task_states.SCHEDULING,
task_states.BLOCK_DEVICE_MAPPING,
task_states.NETWORKING,
task_states.SPAWNING)]: ACTION_ERROR}},
{('IN',[vm_states.ACTIVE, vm_states.STOPPED]: {('IN',
[task_states.REBUILDING,
task_states.REBUILD_BLOCK_DEVICE_MAPPING,
task_states.REBUILD_SPAWNING]): ACTION_ERROR}},
{('NOT_IN',[vm_states.ERROR]): {('IN',
[task_states.IMAGE_SNAPSHOT_PENDING,
task_states.IMAGE_PENDING_UPLOAD,
task_states.IMAGE_UPLOADING,
task_states.IMAGE_SNAPSHOT]): _post_interrupted_snapshot_cleanup}}
)
what do you think, do we need a bp for this?
--
Thanks,
Eli (Li Yong) Qiao___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][lbaas] rescheduling meeting
Hi LBaaS (and others), We’ve been talking about possibly re-schedulng the LBaaS meeting to a time to is less crazy early for those in the US. Alternately, we could also start alternating times. For now, let’s see if we can find a slot that works every week. Please respond with any time slots that you can NOT attend: Monday, 1600UTC Monday, 1700UTC Tuesday, 1600UTC (US pacific, 8am) Tuesday, 1700UTC Tuesday, 1800UTC Wednesday, 1600UTC (US pacific, 8am) Wednesday, 1700UTC Wednesday, 1800UTC Thursday, 1400UTC (US pacific, 6am) Note that many of these slots will require the approval of the #openstack-meeting-4 channel: https://review.openstack.org/#/c/132629/ https://review.openstack.org/#/c/132630/ Thanks, Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Alternative federation mapping
Hi John Its seems like your objective is somewhat different to what was intended with the current mapping rules. You seem to want a general purpose mapping engine that can map from any set of attribute values into any other set of values, whereas the primary objective of the current mapping rules is to map from any set of attribute values into a Keystone group, so that we can use the existing Keystone functions to assign roles (and hence permissions) to the group members. So the current mapping rules provide a means of identifying and then authorising a potentially random set of external users, who logically form a coherent group of users for authorisation purposes. Am I right in assuming that you will also want this functionality after your general purpose mapping has taken place? regards David On 03/11/2014 20:58, John Dennis wrote: On 11/03/2014 08:50 AM, John Dennis wrote: I had a bunch of notes but I can't find them at the moment so I'm going from memory here (always a bit risky). I found my notes, attached is an reStructured text document that summarizes the issues I found with the current Keystone mapping, the basic requirements for mapping based on my prior experience and reasons for selecting the approach I did. I hope this explains the motivations and rationale to put things into context. ___ 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][compute] propose to use a table to deal with the vm_state when _init_instance in compute
? 2014?11?04? 15:19, Chen CH Ji ??:
+1,
a good idea, it will make it more clear.
from implementation perspective we need to pay attention that some
status will pass through and some will just return
Best Regards!
hi Kevin
thanks for supporting.
yeah, I am considering vm_state first, it is much easier to start up,
all of them will return.
I need to heard more from others to see if we need a spec to do it.
Kevin (Chen) Ji ? ?
Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
District, Beijing 100193, PRC
Inactive hide details for Eli Qiao ---11/04/2014 03:13:26 PM---hello
all: in current _init_instance function in compute managerEli Qiao
---11/04/2014 03:13:26 PM---hello all: in current _init_instance
function in compute manager,
From: Eli Qiao ta...@linux.vnet.ibm.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 11/04/2014 03:13 PM
Subject: [openstack-dev] [nova][compute] propose to use a table to
deal with the vm_state when _init_instance in compute
hello all:
in current _init_instance function in compute manager,
there's flood 'and' 'or' logic, to check the vm_state and task_state
when initialize a instance during service list,
this lead hard to read and hard to maintain, so I propose a new way to
handle this.
we can create a vm_state_table, by look up the table we can find the
action we need to do for the instance,
from this table , you can clearly see what vm_state and task_state
should take the action.
for example:
{vm_states list :{task_states list: action}},
each entry stands for an action,
and we walk though the tuple
so the table should be like this:
vm_state_table = (
{vm_states.SOFT_DELETE :{'ALL': ACTION_NONE}},
{vm_states.ERROR: {('NOT_IN',[task_states.RESIZE_MIGRATING,
task_states.DELETING]): ACTION_NONE}},
{vm_states.DELETED: {'ALL': _complete_partial_deletion}},
{vm_states.BUILDING: {'ALL': ACTION_ERROR}},
{'ALL': {('IN',[task_states.SCHEDULING,
task_states.BLOCK_DEVICE_MAPPING,
task_states.NETWORKING,
task_states.SPAWNING)]: ACTION_ERROR}},
{('IN',[vm_states.ACTIVE, vm_states.STOPPED]: {('IN',
[task_states.REBUILDING,
task_states.REBUILD_BLOCK_DEVICE_MAPPING,
task_states.REBUILD_SPAWNING]): ACTION_ERROR}},
{('NOT_IN',[vm_states.ERROR]): {('IN',
[task_states.IMAGE_SNAPSHOT_PENDING,
task_states.IMAGE_PENDING_UPLOAD,
task_states.IMAGE_UPLOADING,
task_states.IMAGE_SNAPSHOT]): _post_interrupted_snapshot_cleanup}}
)
what do you think, do we need a bp for this?
--
Thanks,
Eli (Li Yong) Qiao___
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
--
Thanks,
Eli (Li Yong) Qiao
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
