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 and it is > >> not stored in the db as well. It is something to do in the future > >> and documented the same in the blueprint. > >> > >> > >> How does it differ from provider:network-type? (I guess, > >> because the latter is supposed to be for implementation > >> consumption only - but is that correct?) > >> > >> > >> Flavors are created and curated by operators, and consumed by > >> API users. > >> > >> +1 > >> > > Many thanks, > Neil > -- Itsuro ODA <o...@valinux.co.jp> __________________________________________________________________________ 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
