Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/3213c2bf/attachment.html>