Open Stack

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.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>


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev