Re: [openstack-dev] Cross distribution talks on Friday
On 01/11/14 14:13, Thomas Goirand wrote: Hi, I was wondering if some distribution OpenStack package maintainers would be interested to have some cross-distribution discussion on Friday, during the contributors sessions. Unfortunately, this is at the same time as Ceilometer, Glance, Heat, Horizon, Keystone, Neutron, Nova, TripleO, Ironic contributors meetup. I could imagine, some folks, (like me) are wearing more than one hat and will have to decide. Could we discuss the time? There might be time slots better suited for this. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On 10/31/2014 05:17 PM, Matt Joyce wrote: On one hand, I agree a member of the TC should be a very active member of the development community. Something I have not been, much to my shame. However, there are obviously some fundamental issues in how the TC has been governing OpenStack in the past few releases. Very serious issues in the project have been largely ignored. Foremost in my mind, among them, is the lack of an upgradability path. I remember there being large discussion and agreement to address this at folsom, and further back. I have seen no meaningful effort made to address a functionality requirement that has been requested repeatedly and emphatically since as far back as austin. There has been quite a lot of meaningful effort in this area. The offline upgrade testing on every patch was added in Grizzly (grenade), enforced early in Havana. It was made an integrated project requirement in Icehouse (as soon as we got a fully directly elected TC), and now most integrated projects participate in it (after TC gap analysis). We held Ironic graduation a cycle largely due to the lack of an upgrade path. The Nova team has been working on something better than that, which is mixed version services, which we also test on every commit. With the import of nova versioned objects into oslo, that should create the framework for other projects to do the same kind of thing. There are other decoupling that are happening for libraries consumed by servers which should make this better as well (just pushed another patch for that this morning). And realistically part of my motivation for advocating a smaller ring 0 in OpenStack is to provide the focus on just this class of issues within that. I can raise other issues that continue to plague usership, such as neutron failing to take over for nova-network now two releases after it's planned obsolescence. My concern, is that the TC comprised entirely of active developers ( most of whom are full time on the open source side of this project ), is trapped in something of an echo chamber. I have no real reason to suggest this is the case, beyond the obvious failure by the project to address concerns that have been paramount in the eyes of users for years now. But, the concern lingers. I fear that the TC is beholden entirely to the voice of the development community and largely ignorant of the concerns of others. Certainly, the incentives promote that. The problem of course, is that the TC is responsible for driving purogratives in development that reflect more than the development communities desires. I think this was far more the case when the TC was largely made up of PTLs. I also think we need to admit that the TC has limited direct authority, and what those of us on the TC get done in these areas is as much about our personal authority, i.e. we're useful humans that contribute broadly, so when run in one direction people give us the benefit of the doubt and tend to help out. I agree that I'd love to have these problems fully solved already. They definitely are not. But there is meaningful effort going into them. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] [barbican] Stable check of openstack/cinder failed
the release of the new barbicanclient caused another bug as well: https://bugs.launchpad.net/cinder/+bug/1388414, this one is causing all grenade jobs on master to fail. It looks like we have a hole in the gating logic somewhere. On Sat, Nov 1, 2014 at 3:42 PM, Alan Pevec ape...@gmail.com wrote: Hi, cinder juno tests are failing after new barbicanclient release - periodic-cinder-python26-juno http://logs.openstack.org/periodic-stable/periodic-cinder-python26-juno/d660c21 : FAILURE in 11m 37s - periodic-cinder-python27-juno http://logs.openstack.org/periodic-stable/periodic-cinder-python27-juno/d9bf4cb : FAILURE in 9m 04s I've filed https://bugs.launchpad.net/cinder/+bug/1388461 AFACT this affects master too. Cheers, 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
[openstack-dev] Keybase.io invites for OpenStack people (was Re: Key signing at the summit?)
I will also try to get more keybase.io invites, for those who want them. keybase.io is a web service that provides an independently provable binding between your social media and github identities, and your gpg key. I have been granted *many* invites from keybase.io for OpenStack developers. I have already sent an invite to everyone who already participated in the keysigning party in Hong Kong and in Atlanta. If anyone else wants an invite, do please approach me at the Summit in Paris, or email me. ..m -- Mark Atwood mark.atw...@hp.com Mark Atwood m...@mark.atwood.name ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Third-party] Third-party CI WG Meeting
Hi, Reminder: the Third-party Work Group meeting for this week (November 3) has been cancelled due to Summit. We will resume our normal time next week. The meeting details are here: https://wiki.openstack.org/wiki/Meetings/ThirdParty Kurt Taylor (krtaylor) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] [barbican] Stable check of openstack/cinder failed
On 11/02/2014 12:13 PM, Joe Gordon wrote:
the release of the new barbicanclient caused another bug as
well: https://bugs.launchpad.net/cinder/+bug/1388414, this one is
causing all grenade jobs on master to fail. It looks like we have a hole
in the gating logic somewhere.
python-barbicanclient is not in projects.txt of the requirements repo
and there's no gate setup for checking either ;(
Patches for both barbican and the client:
https://review.openstack.org/132472
https://review.openstack.org/132473
Andreas
On Sat, Nov 1, 2014 at 3:42 PM, Alan Pevec ape...@gmail.com
mailto:ape...@gmail.com wrote:
Hi,
cinder juno tests are failing after new barbicanclient release
- periodic-cinder-python26-juno
http://logs.openstack.org/periodic-stable/periodic-cinder-python26-juno/d660c21
: FAILURE in 11m 37s
- periodic-cinder-python27-juno
http://logs.openstack.org/periodic-stable/periodic-cinder-python27-juno/d9bf4cb
: FAILURE in 9m 04s
I've filed https://bugs.launchpad.net/cinder/+bug/1388461 AFACT this
affects master too.
Cheers,
Alan
___
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tempest] Fault Injection
Hi all, I'd like to continue the discussion on the following thread: http://lists.openstack.org/pipermail/openstack-dev/2014-April/031660.html Are there still plans for fault injection as an integrated OpenStack project? Is there any currently ongoing work on it? I would be interested in implementing fault injection as an its own service, with a REST API, in order to incorporate a broader fault model in the future. I noticed the stress test scenarios in tempest and that might be another place to include fault injection, but a separate API seems cleaner and better decoupled. Probably it would be good to start off with a service supporting roughly the features offered by ChaosMonkey, and then extending it to allow for orchestrated, bigger fault injection campaigns. Could I contribute something in that direction? There is also an interesting sketch here: https://wiki.openstack.org/wiki/Stackmonkey Best, Lena ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] Alternative federation mapping
While working on federated authentication for a different project (OpenDaylight) we discovered we needed to map from the assertion provided by an external federated IdP to local values. This is essentially the same requirement which exists in Keystone's federated support. 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. https://jdennis.fedorapeople.org/doc/mapping.pdf The mapper as described in the document has implementations in both Java and Python. The Java implementation is currently in use in OpenDaylight (a Java based project). For those interested I can provide a pointer to OpenDaylight specific documentation on how this mapper is used in conjunction with the Apache web server providing authentication and SSSD providing identity attributes to a Java servlet container. My goal here is to make Keystone developers aware of an alternative mapper which may provide needed mapping features not currently available and for which different language implementations already exist. Note, the mapper is easily extended should a need arise. Source code and documentation can be found here by cloning this git repo: git clone git://fedorapeople.org/~jdennis/federated-mapping.git Note, I put this git repo together quickly by pulling together things from a variety of sources, as such there may be things needing to be cleaned up in the repo, at the moment it's really just meant to browse. Over the next few days I'll make sure everything builds and executes cleanly. Posting this now in case folks want to have conversations at the Paris Summit. -- John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 you. Thanks in advance, Lisa Hi Lisa, Glad to see you're interested in Blazar. I tried to go thru your proposal, but could you please post the main concepts of what you plan to add into an etherpad and create a blueprint [1] mapped to it so we could discuss on the implementation ? Of course, don't hesitate to ping me or the blazar community in #openstack-blazar if you need help with the process or the current Blazar design. Thanks, -Sylvain [1] https://blueprints.launchpad.net/blazar/
Re: [openstack-dev] [Keystone] Alternative federation mapping
Hi John, It indeed looks interesting and enhancing the mapping engine is on ours to-do list for a long time. I'd be happy to talk this through during the summit. Do you think you will be able to come for a Keystone websso/federation Design Session on Wednesday at 16.30? Thanks, Marek On 02.11.2014 18:29, John Dennis wrote: While working on federated authentication for a different project (OpenDaylight) we discovered we needed to map from the assertion provided by an external federated IdP to local values. This is essentially the same requirement which exists in Keystone's federated support. 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. https://jdennis.fedorapeople.org/doc/mapping.pdf The mapper as described in the document has implementations in both Java and Python. The Java implementation is currently in use in OpenDaylight (a Java based project). For those interested I can provide a pointer to OpenDaylight specific documentation on how this mapper is used in conjunction with the Apache web server providing authentication and SSSD providing identity attributes to a Java servlet container. My goal here is to make Keystone developers aware of an alternative mapper which may provide needed mapping features not currently available and for which different language implementations already exist. Note, the mapper is easily extended should a need arise. Source code and documentation can be found here by cloning this git repo: git clone git://fedorapeople.org/~jdennis/federated-mapping.git Note, I put this git repo together quickly by pulling together things from a variety of sources, as such there may be things needing to be cleaned up in the repo, at the moment it's really just meant to browse. Over the next few days I'll make sure everything builds and executes cleanly. Posting this now in case folks want to have conversations at the Paris Summit. ___ 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 Fri, Oct 31, 2014 at 08:27:24PM +, Robert Li (baoli) wrote: Without direct oslo support, to implement it requires a small method that uses oslo cfg¹s MultiConfigParser(). 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. Yes, backwards compatibility is mandatory. If we want to get rid of the old format you need to have 1 release cycle where it is issuing a deprecation warning. So the L release would be first place it cna be deleted entirely ‹ 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. Just use a different name for the new config option to avoid confusion between old new syntax. 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Alternative federation mapping
On 11/02/2014 03:55 PM, Marek Denis wrote: Hi John, It indeed looks interesting and enhancing the mapping engine is on ours to-do list for a long time. I'd be happy to talk this through during the summit. Do you think you will be able to come for a Keystone websso/federation Design Session on Wednesday at 16.30? Thank you Marek. I'd love to discuss this in person however I'm not attending this summit. However, my manager Nathan Kinder who has been following this work will be in Paris as well as Adam Young who is also in our group. Of course I'm happy to discuss this electronically, turn it into a blueprint or whatever is deemed appropriate. -- John ___ 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 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? ___ 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
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 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 trunk - if I use an infrastructure where no networks are trunks, I can find out that a network is not a trunk - if I use an infrastructure where trunk networks are more expensive, my operator can price accordingly And, again, this is all entirely independent of either VLAN-aware ports or L2GW blocks. Both are true. I was referring of “true” trunk networks, you were referring to your additions, right? Benefits with L2GW is ease to do network stitching. There are other benefits with the different proposals, the point is that it might be beneficial to have all solutions. I totally agree
Re: [openstack-dev] [tuskar] Puppet module
On Wed, Oct 29, 2014 at 05:21:15PM (-0400), Emilien Macchi wrote: Just started a PoC: https://github.com/enovance/puppet-tuskar Once I'll finish unit tests, I'll move it to Stackforge. Unit tests added, and patch for stackforge in review https://review.openstack.org/132488 Cheers, Seb -- Sebastien Badia signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tuskar] Puppet module
Sebastien Badia I finished the code (manifests + unit tests) and now move puppet-tuskar in Stackforge: https://review.openstack.org/#/c/132488/ Would be great to have reviews from Tuskar folks. Thanks! Emilien On 10/29/2014 10:21 PM, Emilien Macchi wrote: Just started a PoC: https://github.com/enovance/puppet-tuskar Once I'll finish unit tests, I'll move it to Stackforge. On 10/29/2014 10:25 AM, Jay Dobies wrote: Nope, there isn't a puppet module for deploying Tuskar, but starting one makes sense. On 10/28/2014 06:04 PM, Emilien Macchi wrote: Hi, I was looking at deploying Tuskar API with Puppet and I was wondering if you guys have already worked on a Puppet module. If not, I think we could start something in stackforge like we already did for other OpenStack components. Thanks, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi ___ 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
When/where is the meeting on Monday? -- Kevin Benton On Nov 2, 2014, at 11:12 PM, Erik Moe erik@ericsson.com wrote: 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.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 trunk - if I use an infrastructure where no networks are trunks, I can find out that a network is not a trunk - if I use an infrastructure where trunk networks are more expensive, my operator can price accordingly And, again, this is all entirely independent of either VLAN-aware ports or L2GW blocks. Both are true. I was referring of “true” trunk networks, you were referring to
