Re: [openstack-dev] [neutron] What does flavor mean for a network?
Aha! Thanks so much for pointing that out. Although actually it's a reminder, and I should have known that already, as I now remember your recent thread about this. So, 100% understood now that flavors aren't intended for networks. I hope that the metaplugin removal change might land quickly now, as it's always nice to clarify the picture by removing obsolete things. Regards, Neil Original Message From: Itsuro ODA Sent: Thursday, 16 July 2015 23:22 To: OpenStack Development Mailing List (not for usage questions) Reply To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] What does flavor mean for a network? Neil, flavor:network is for Metaplugin. It is unrelated to flavor framework. FYI, Metaplugin will be removed in liberty. https://review.openstack.org/#/c/192056/ Thanks. Itsuro Oda (oda-g) On Thu, 16 Jul 2015 10:44:01 +0100 Neil Jerram neil.jer...@metaswitch.com wrote: Thanks everyone for your responses... On 15/07/15 21:01, Doug Wiegley wrote: That begins to looks like nova’s metadata tags and scheduler, which is a valid use case. The underpinnings of flavors could do this, but it’s not in the initial implementation. doug On Jul 15, 2015, at 12:38 PM, Kevin Benton blak...@gmail.com mailto:blak...@gmail.com wrote: Wouldn't it be valid to assign flavors to groups of provider networks? e.g. a tenant wants to attach to a network that is wired up to a 40g router so he/she chooses a network of the fat pipe flavor. Indeed. Otherwise, why does 'flavor:network' exist at all in the current codebase? As the code currently stands, 'flavor:network' appears to be consumed only by agent/linux/interface.py, with the logic that if the interface_driver setting is set to MetaInterfaceDriver, the interface driver class that is actually used for a particular network will be derived by using the network's 'flavor:network' value as a lookup key in the dict specified by the meta_flavor_driver_mappings setting. Is that an intended part of the flavors design? I hope it doesn't sound like I'm just complaining! My reason for asking these questions is that I'm working at https://review.openstack.org/#/c/198439/ on a type of network that works through routing on each compute host instead of bridging, and two of the consequences of that are that (1) there will not be L2 broadcast connectivity between the instances attached to such a network, whereas there would be with all existing Neutron network types (2) the DHCP agent needs some changes to provide DHCP service on unbridged TAP interfaces. Probably best here not to worry too much about the details. But, at a high level: - there is an aspect of the network's behavior that needs to be portrayed in the UI, so that tenants/projects can know when it is appropriate to attach instances to that network - there is an aspect of the network's implementation that the DHCP agent needs to be aware of, so that it can adjust accordingly. I believe the flavor:network 'works', for these purposes, in the senses that it is portrayed in the UI, and that it is available to software components such as the DHCP agent. So I was wondering whether 'flavor:network' would be the correct location in principle for a value identifying this kind of network, according to the intention of the flavors enhancement. On Wed, Jul 15, 2015 at 10:40 AM, Madhusudhan Kandadai madhusudhan.openst...@gmail.com mailto:madhusudhan.openst...@gmail.com wrote: On Wed, Jul 15, 2015 at 9:25 AM, Kyle Mestery mest...@mestery.com mailto:mest...@mestery.com wrote: On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com wrote: I've been reading available docs about the forthcoming Neutron flavors framework, and am not yet sure I understand what it means for a network. In reality, this is envisioned more for service plugins (e.g. flavors of LBaaS, VPNaaS, and FWaaS) than core neutron resources. Yes. Right put. This is for service plugins and its part of extensions than core network resources// Is it a way for an admin to provide a particular kind of network, and then for a tenant to know what they're attaching their VMs to? I'll defer to Madhu who is implementing this, but I don't believe that's the intention at all. Currently, an admin will be able to assign particular flavors, unfortunately, this is not going to be tenant specific flavors. To be clear - I wasn't suggesting or asking for tenant-specific flavors. I only meant that a tenant might choose which network to attach a particular set of VMs to, depending on the flavors of the available networks. (E.g. as in Kevin's example above.) As you might have seen in the review, we are just using tenant_id to bypass the keystone checks implemented in base.py
Re: [openstack-dev] [Neutron]Request for help to review a patch
As it is a bug fix, perhaps you could add this to the agenda for the next Neutron IRC meeting, in the Bugs section?Regards, NeilFrom: Damon WangSent: Thursday, 16 July 2015 07:18To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Subject: [openstack-dev] [Neutron]Request for help to review a patchHi,I know that request review is not good in mail list, but the review process of this patch seems freeze except gained two +1 :-)The review url is: https://review.openstack.org/#/c/172875/Thanks a lot,Wei wang __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] The unbearable lightness of specs
+1 also Original Message From: Fox, Kevin M Sent: Friday, 26 June 2015 21:15 To: OpenStack Development Mailing List (not for usage questions) Reply To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs +1 From: Tim Bell [tim.b...@cern.ch] Sent: Friday, June 26, 2015 12:26 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs -Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: 26 June 2015 16:42 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] The unbearable lightness of specs On 2015-06-25 16:39:56 + (+), Tim Bell wrote: [...] One of the problems that I’ve seen is with specs etiquette where people -1 because they have a question. This is a question of education rather than a fundamental issue with the process. http://docs.openstack.org/infra/manual/developers.html#peer-review has been updated with a 7th entry addressing this in particular. Hopefully that will help realign reviewers on acceptable vs. unacceptable use of -1 for certain types of questions over time. I also feel that stackalytics should credit people of a 0 review comment on specs. Currently, I think that only non-zero reviews are considered as a contribution. My understanding of the workflow is that a 0 is in many cases is the constructive way to respond and therefore should be considered as a contribution. Tim -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev- requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Stuck on VIF plugin script?
It seems like we're possibly stuck now on the VIF plugin script spec [1]; there being core comments in apparently conflicting directions. I wonder if it's still feasible for a version of this to land during Liberty? [1] https://review.openstack.org/#/c/162468/ I plan to reread everyone's comments and see if I can propose a way forward - but thought I'd circulate this email first in case anyone wants to say that it's already too late... If VIF plugin script doesn't happen this cycle, can we continue processing VIF type additions/changes/deletions in the traditional way? Regards, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project
Great initiative, IMO. I favour going directly to openstack-, rather than
stackforge-, for the migration reason that you mention.
Original Message
From: Thomas Goirand
Sent: Wednesday, 27 May 2015 09:17
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [packaging] Adding packaging as an OpenStack project
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
tl;dr:
- - We'd like to push distribution packaging of OpenStack on upstream
gerrit with reviews.
- - The intention is to better share the workload, and improve the overall
QA for packaging *and* upstream.
- - The goal is *not* to publish packages upstream
- - There's an ongoing discussion about using stackforge or openstack.
This isn't, IMO, that important, what's important is to get started.
- - There's an ongoing discussion about using a distribution specific
namespace, my own opinion here is that using /openstack-pkg-{deb,rpm} or
/stackforge-pkg-{deb,rpm} would be the most convenient because of a
number of technical reasons like the amount of Git repository.
- - Finally, let's not discuss for too long and let's do it!!! :)
Longer version:
Before I start: some stuff below is just my own opinion, others are just
given facts. I'm sure the reader is smart enough to guess which is what,
and we welcome anyone involved in the project to voice an opinion if
he/she differs.
During the Vancouver summit, operation, Canonical, Fedora and Debian
people gathered and collectively expressed the will to maintain
packaging artifacts within upstream OpenStack Gerrit infrastructure. We
haven't decided all the details of the implementation, but spent the
Friday morning together with members of the infra team (hi Paul!) trying
to figure out what and how.
A number of topics have been raised, which needs to be shared.
First, we've been told that such a topic deserved a message to the dev
list, in order to let groups who were not present at the summit. Yes,
there was a consensus among distributions that this should happen, but
still, it's always nice to let everyone know.
So here it is. Suse people (and other distributions), you're welcome to
join the effort.
- - Why doing this
It's been clear to both Canonical/Ubuntu teams, and Debian (ie: myself)
that we'd be a way more effective if we worked better together, on a
collaborative fashion using a review process like on upstream Gerrit.
But also, we'd like to welcome anyone, and especially the operation
folks, to contribute and give feedback. Using Gerrit is the obvious way
to give everyone a say on what we're implementing.
As OpenStack is welcoming every day more and more projects, it's making
even more sense to spread the workload.
This is becoming easier for Ubuntu guys as Launchpad now understand not
only BZR, but also Git.
We'd start by merging all of our packages that aren't core packages
(like all the non-OpenStack maintained dependencies, then the Oslo libs,
then the clients). Then we'll see how we can try merging core packages.
Another reason is that we believe working with the infra of OpenStack
upstream will improve the overall quality of the packages. We want to be
able to run a set of tests at build time, which we already do on each
distribution, but now we want this on every proposed patch. Later on,
when we have everything implemented and working, we may explore doing a
package based CI on every upstream patch (though, we're far from doing
this, so let's not discuss this right now please, this is a very long
term goal only, and we will have a huge improvement already *before*
this is implemented).
- - What it will *not* be
===
We do not have the intention (yet?) to publish the resulting packages
built on upstream infra. Yes, we will share the same Git repositories,
and yes, the infra will need to keep a copy of all builds (for example,
because core packages will need oslo.db to build and run unit tests).
But we will still upload on each distributions on separate repositories.
So published packages by the infra isn't currently discussed. We could
get to this topic once everything is implemented, which may be nice
(because we'd have packages following trunk), though please, refrain to
engage in this topic right now: having the implementation done is more
important for the moment. Let's try to stay on tracks and be constructive.
- - Let's keep efficiency in mind
===
Over the last few years, I've been able to maintain all of OpenStack in
Debian with little to no external contribution. Let's hope that the
Gerrit workflow will not slow down too much the packaging work, even if
there's an unavoidable overhead. Hopefully, we can implement some
liberal ACL policies for the core reviewers so that the Gerrit workflow
don't slow down anyone too much. For example we may be able to create
new repositories very fast, and it may
Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers
How about retaining --dhcp-authoritative when dhcp_agents_per_network = 1? I would guess that that is the 90% case. I suppose that would require passing new information from the Neutron server to the DHCP agents; but maybe that's feasible, and it feels like the right thing to do.Also, what are the use cases for dhcp_agents_per_network = 2 ?Regards, Neil From: Doug WiegleySent: Tuesday, 26 May 2015 04:14To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Subject: Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers After a brief IRC conversation with Kevin, he pointed out that we already don’t allow any other ports on the subnet to send DHCP replies, so NAKs are completely unnecessary. I’d be fine just filtering them out for now.Thanks,dougOn May 25, 2015, at 7:54 PM, Kevin Benton blak...@gmail.com wrote:Here is the description of the behavior for --dhcp-authoritative from the dnsmasq page. [1]Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum).As far as I understand it, the original intent of the patch that caused the issue was to fix that refusal to answer lease renewals after a restart. So it wasn't added to get NAKs, it was added to make it respond to renewals before they timeout.1.http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.htmlOn Mon, May 25, 2015 at 7:44 PM, Doug Wiegley doug...@parksidesoftware.com wrote:Option 4, turn off authoritative if we don’t want NAK’s?dougOn May 25, 2015, at 7:35 PM, Kevin Benton blak...@gmail.com wrote:Hi,A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused DHCPNAK messages when multiple agents are scheduled to a network [2].This was back-ported to Icehouse and Juno so we need a fix that is compatible with both of them.I have two fixes for this so far and a third alternative if we don't like those.The first is hacky, but it's only a few-line change.[3] It adds an iptables rule that just stops the DHCPNAKs from making it to the client. This is clean to back-port but it doesn't protect clients that have filtering disabled (e.g. bare metal).The second persists the DHCP leases to a database.[4] The downside to this was always that being rescheduled to another agent would mean no entries in the lease file. This approach adds a work-around to generate an initial fake lease file based on all of the ports in the network.A third approach that I don't have a patch pushed for yet is very similar to the second. When dnsmasq is in the leasefile-ro mode, it will call the script passed to --dhcp-script to get a list of leases to start with. This script would be built with the same logic as the second one. The only difference between the second approach is that dnsmasq wouldn't persist leases to a database.I'm looking for feedback on how we want to go forward with this in a back-port friendly manner.Cheers,Kevin Benton1.https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z2.https://bugs.launchpad.net/neutron/+bug/14579003.https://review.openstack.org/#/c/185332/4.https://review.openstack.org/#/c/185486/-- Kevin Benton __OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __OpenStack Development Mailing List (not for usage questions)Unsubscribe:
Re: [openstack-dev] OpenStack 2015.1.0 for Debian Sid and Jessie
Out of interest, have you done this by re-releasing the Ubuntu packaging? Or have you taken an independent approach? Regards, Neil Original Message From: Thomas Goirand Sent: Thursday, 14 May 2015 22:21 To: OpenStack Operators; Openstack; OpenStack Development Mailing List (not for usage questions) Reply To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] OpenStack 2015.1.0 for Debian Sid and Jessie Hi, I am pleased to announce the general availability of OpenStack 2015.1.0 (aka Kilo) in Debian unstable (aka Sid) and through the official Debian backports repository for Debian 8.0 (aka Sid). Debian 8.0 Jessie just released === As you may know, Debian 8.0 was released on the 25th of April, just a few days before OpenStack Kilo (on the 30th of April). Just right after Debian Jessie got released, OpenStack Kilo was uploaded to unstable, and slowly migrated the usual way to the new Debian Testing, named Stretch. As a lot of new packages had to go through the Debian FTP master NEW queue for review (they check mainly for the copyright / licensing information, but also if the package is conform to the Debian policy). I'd like here to publicly thank Paul Tagliamonte from the Debian FTP team for his prompt work, which allowed Kilo to reach the Debian repositories just a few days after its release (in fact, Kilo was fully available in Unstable more than a week ago). Debian Jessie Backports === Previously, each release of OpenStack, as a backport for Debian Stable, was only available through private repositories. This wasn't a satisfying solution, and we wanted to address it by uploading to the official Debian backports. And the result is now available: all of OpenStack Kilo has been uploaded to Debian jessie-backports. If you want to use these repositories, just add them to your sources.list (note that the Debian installer proposes to add it by default): deb http://httpredir.debian.org/debian jessie-backports main (of course, you can use any Debian mirror, not just the httpredir) All of the usual OpenStack components are currently available in the official backports, but there's still some more to come, like for example Heat, Murano, Trove or Sahara. For Heat, it's because we're still waiting for python-oslo.versionedobjects 0.1.1-2 to migrate to Stretch (as a rule: we can't upload to backports unless a package is already in Testing). For the last 3, I'm not sure if they will be backported to Jessie. Please provide your feedback and tell the Debian packaging team if they are important for you in the official jessie-backports repository, or if Sid is enough. Also, at the time of writing of this message, Horizon and Designate are still in the backports FTP master NEW queue (but it should be approved very soon). Also, I have just uploaded a first version of Barbican (still in the NEW queue waiting for approval...), and there's a package for Manila that is currently on the work by a new contributor. Note on Neutron off-tree drivers The neutron-lbaas, neutron-fwaas and neutron-vpnaas packages have been uploaded and are part of Sid. If you need it through jessie-backports, please just let me know. All vendor-specific drivers have been separated from Neutron, and are now available as separate packages. I wrote packages for them all, but the issue is that most of them wouldn't even build due to failed unit tests. For most of them, it used to work in the Kilo beta 3 of Neutron (it's the case for all but 2 of them who were broken at the time), but they appeared broken with the Kilo final release, as they didn't update after the Kilo release. I have repaired some of them, but working on these packages has shown to be a very frustrating work, as they receive very few updates from upstream. I do not plan to work much on them unless one of the below condition: - My employer needs them - things are moving forward upstream, and that these unit tests are repaired in the stackforge repository. If you are a network hardware vendor and read this, please push for more maintenance, as it's in a really bad state ATM. You are welcome to get in touch with me, and I'll be happy to help you to help. Bug report == If you see any issue in the packages, please do report them to the Debian bug tracker. Instructions are available here: https://www.debian.org/Bugs/Reporting Happy installation, Thomas Goirand (zigo) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code
Thanks Russell and Kyle for explaining. I think I get the picture now, in particular of how these backend projects are mostly under separate management, but at the same time subject to PTL oversight and 'part of the wider Neutron effort'. May I drill down further on what is anticipated, though, by considering what this might mean for my own project, Calico? I don't mean to self-advertise, but it's obviously the example that I know best! :-) Calico is a (potential) way of using Neutron for networking in an OpenStack deployment. But it's also broader than that, because it also targets (non-OpenStack-based) container systems. So it wouldn't be right to propose moving the whole of project Calico to be one of these Neutron backend projects. When Calico is used with Neutron, it takes the form of an ML2 mechanism driver. So perhaps that mechanism driver might be what would go into a networking-calico project? However, - the wonderful workings of the entry_points mechanism, combined with the existence of a stable API for mechanism drivers, mean that we don't strongly need to do that; and - on its non-OpenStack-facing side, our mechanism driver's implementation shares common code with other pieces in the wider Calico project. So it's not really compelling to move the mechanism driver to a networking-calico project either - even though we do want to advertise and evangelise about Calico working with Neutron. So what then could go into a networking-calico project? Perhaps some OpenStack ecosystem documentation about using Calico in OpenStack, and/or perhaps some utilities that were specific to both Calico and the OpenStack environment? Perhaps I'm going down an unnecessary rabbit hole with this musing - but I'd really appreciate further comments and/or corrections to my understanding so far. I would guess that what I've raised might apply similarly to other big networking projects, for example Open Daylight. Many thanks, Neil PS. As I'm just about to send this, I wonder if our DHCP agent modifications might be a good example... Something that is definitely OpenStack-specific, but not yet clear if and how our changes should be folded into the main Neutron code. Perhaps that is the kind of thing that you have in mind? Original Message From: Russell Bryant Sent: Tuesday, 28 April 2015 18:57 To: openstack-dev@lists.openstack.org Reply To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code On 04/28/2015 01:17 PM, Neil Jerram wrote: Apologies for commenting so late, but I'm not clear on the concept of bringing all possible backend projects back inside Neutron. I think my question is similar to what Henry and Mathieu are getting at below - viz: We just recently decided to move a lot of vendor-specific ML2 mechanism driver code _out_ of the Neutron tree; and I thought that the main motivation for that was that it wasn't reasonably possible for most Neutron developers to understand, review and maintain that code to the same level as they can with the Neutron core code. How then does it now make sense to bring a load of vendor-specific code back into the Neutron fold? Has some important factor changed? Or have I misunderstood what is now being proposed? The suggestion is to recognize that these are all part of the larger Neutron effort. It is *not* to suggest that the same group of developers needs to be reviewing all of it. It's mostly an organizational thing. The way teams operate should not change too much. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Where can I find the neutron ml2 mechanism driver list?
Note also, though, that any third party package can add its own mechanism
driver to this list. So the effective complete list is the combination of:
- what you see in Neutron's setup.cfg, under neutron.ml2.mechanism_drivers
- further neutron.ml2.mechanism_drivers entries that are added by third party
packages.
You can see an example of the latter in the setup.py for my project, at
https://github.com/Metaswitch/calico/blob/master/setup.py
Regards,
Neil
Original Message
From: Sławek Kapłoński
Sent: Sunday, 19 April 2015 09:25
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Where can I find the neutron ml2 mechanism driver
list?
Hello,
Check setup.cfg file - there are entry points for all drivers in this
file.
--
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.pl
On Sun, Apr 19, 2015 at 12:13:30AM -0700, Sam Su wrote:
Hi,
I am learning the existing Neutron code (Juno) and am going to add a ML2
driver. I can see the following debug info in neutron.log:
*2015-04-18 23:21:13.729 11068 DEBUG stevedore.extension [-] found
extension EntryPoint.parse('hyperv =
neutron.plugins.ml2.drivers.mech_hyperv:HypervMechanismDriver')
_load_plugins
/usr/lib/python2.7/site-packages/stevedore/extension.py:1562015-04-18
23:21:13.729 11068 DEBUG stevedore.extension [-] found extension
EntryPoint.parse('l2population =
neutron.plugins.ml2.drivers.l2pop.mech_driver:L2populationMechanismDriver')
_load_plugins
/usr/lib/python2.7/site-packages/stevedore/extension.py:1562015-04-18
23:21:13.729 11068 DEBUG stevedore.extension [-] found extension
EntryPoint.parse('cisco_apic =
neutron.plugins.ml2.drivers.cisco.apic.mechanism_apic:APICMechanismDriver')
_load_plugins
/usr/lib/python2.7/site-packages/stevedore/extension.py:1562015-04-18
23:21:13.730 11068 DEBUG stevedore.extension [-] found extension
EntryPoint.parse('arista =
neutron.plugins.ml2.drivers.arista.mechanism_arista:AristaDriver')
_load_plugins
/usr/lib/python2.7/site-packages/stevedore/extension.py:156...( Click
http://pastebin.com/3ssdHGZf http://pastebin.com/3ssdHGZf for the detail
)*
From the above log we can see, neutron.plugins.ml2.managers can find all
driver extensions e.g. hyperv, l2population etc, as my understanding, there
should exist a driver list on somewhere. If I am right, where can I find
the driver list? If not, can someone give me a clue?
Any help will be much appreciated.
Thanks,
Sam
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Developer survey questions
To the extent that it's useful to those suggesting the questions, it feels to me like this could be an ongoing resource rather than a one-off survey.Hence, perhaps a web page that all OpenStack members should occasionally review and update for themselves; rather than a one time mailing.From: Dean TroyerSent: Tuesday, 7 April 2015 04:56To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Subject: Re: [openstack-dev] Developer survey questionsOn Mon, Apr 6, 2015 at 9:07 PM, Robert Collins robe...@robertcollins.net wrote:If you have any questions you'd like answered, please mail them to me (direct, or in reply to this) by the end of this week.I would love to learn a bit about how DevStack is used outside the gate:* Do you use DevStack as part of your everyday workflow?* If so, on what distribution(s)?* Do you run a non-default configuration WRT system services? ie, qpid or zmq, or psql* Do you run a gate-like environment using devstack-gate or something like it?* Do you regularly run a forked/branched DevStack* Do you run Grenade as part of your local workflow?I think it would be interesting to also ask about some of the other tools developed in our community, like gertty. Knowing the usefulness and adoption of these tools can help justify (or not) ongoing work in this area.dt-- Dean Troyerdtro...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [TripleO] [Ironic] Deprecating the use_namespaces option - Now's the time to speak up!
Thanks for your interest; following is a description of what Calico does in this area. Just to be clear, this is for interest and information only and I don't mean to suggest that this has any bearing on the use_namespaces deprecation discussion (especially since that change is now merged).Calico doesn't use namespaces because it transports VM IP data between compute hosts by routing it, instead of bridging and tunnelling it. The routing between compute hosts is established in the default namespace by BGP clients (BIRD), so to connect with that the TAP interfaces from VMs need to sit in the default namespace too.Then the question arises of how to provide DHCP for those TAP interfaces - unbridged, and in the default namespace. Calico does this by running dnsmasq in the default namespace, using dnsmasq's --bridge-interfaces option to treat those TAP interfaces as aliases of the dummy interface on which the DHCP context and subnet gateway IP address are provisioned.Now, to set all that up - i.e. to provision the dummy interface; create the config files that dnsmasq needs, and update those as VMs are added or removed; launch dnsmasq; etc. - is a lot of extra value, that neutron-dhcp-agent provides, and it's currently (in Icehouse and Juno) a relatively small patch on neutron-dhcp-agent to do all those things with the tweaks that Calico needs.I hope that makes sense, and is of some interest. Please do feel free to ask any further questions.Regards, NeilFrom: Miguel Ángel AjoSent: Monday, 23 March 2015 06:59To: OpenStack Development Mailing List (not for usage questions)Reply To: OpenStack Development Mailing List (not for usage questions)Cc: openstack-operat...@lists.openstack.orgSubject: Re: [openstack-dev] [Neutron] [TripleO] [Ironic]Deprecating the use_namespaces option - Now's the time to speak up!Looking at project Calico, I don’t know if what they do is similar to what the people fromtriple-o ironic do with the neutron-dhcp-agent. I believe we should ask thembefore deprecation.I added their tags to the subject. AFAIK TripleO/Ironic was patching neutron-dhcp-agent too.For project Calico, why do you need no netns and why do you patch it?Kevin, thanks for pointing that out.Best,Miguel Ángel Ajo On Monday, 23 de March de 2015 at 7:34, Miguel Ángel Ajo wrote: +1 for deprecation if people don’t have use cases / good reasons to keep it, I don’t know and I can’t think of any, but that doesn’t mean they don’t exist. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 2:34, shihanzhang wrote: +1 todeprecate this optionAt 2015-03-21 02:57:09, "Assaf Muller" amul...@redhat.com wrote: Hello everyone, The use_namespaces option in the L3 and DHCP Neutron agents controls if you can create multiple routers and DHCP networks managed by a single L3/DHCP agent, or if the agent manages only a single resource. Are the setups out there *not* using the use_namespaces option? I'm curious as to why, and if it would be difficult to migrate such a setup to use namespaces. I'm asking because use_namespaces complicates Neutron code for what I gather is an option that has not been relevant for years. I'd like to deprecate the option for Kilo and remove it in Liberty. Assaf Muller, Cloud Networking Engineer Red Hat __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __OpenStack Development Mailing List (not for usage questions)Unsubscribe:
