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