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.openst...@gmail.com> wrote: > > > On Wed, Jul 15, 2015 at 9:25 AM, Kyle Mestery <mest...@mestery.com> wrote: > >> On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram <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. 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ 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
