[openstack-dev] [neutron] What does flavor mean for a network?

Kevin Benton blak111 at gmail.com
Wed Jul 15 18:38:38 UTC 2015


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.

On Wed, Jul 15, 2015 at 10:40 AM, Madhusudhan Kandadai <
madhusudhan.openstack at gmail.com> wrote:

>
>
> On Wed, Jul 15, 2015 at 9:25 AM, Kyle Mestery <mestery at mestery.com> wrote:
>
>> On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram <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. 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
>
>>
>>
>>> Thanks,
>>>     Neil
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150715/8cc4df98/attachment.html>


More information about the OpenStack-dev mailing list