Open Stack

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.Jerram at 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 <blak111 at gmail.com >> <mailto:blak111 at 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.openstack at gmail.com >> <mailto:madhusudhan.openstack at gmail.com>> wrote:
> >>
> >>
> >>
> >>     On Wed, Jul 15, 2015 at 9:25 AM, Kyle Mestery
> >>     <mestery at mestery.com <mailto:mestery at mestery.com>> wrote:
> >>
> >>         On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram
> >>         <Neil.Jerram at metaswitch.com
> >>         <mailto:Neil.Jerram at 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 <oda at valinux.co.jp>