This topic has already been discussed last year and a use-case was described (see [1]). Here's a Heat blueprint for a new OS::Nova::Flavor resource: [2]. Several issues have been brought up after posting my implementation for review [3], all related to how flavors are defined/implemented in nova:
* Only admin tenants can manage flavors due to the default admin rule in policy.json. * Per-stack flavor creation will pollute the global flavor list * If two stacks create a flavor with the same name, collision will occur, which will lead to the following error: ERROR (Conflict): Flavor with name dupflavor already exists. (HTTP 409) These and the ones described by Steven Hardy in [4] are related to the flavor scoping in Nova. Is there any plan/discussion to allow project scoped flavors in nova, similar to the Steven’s proposal for role-based scoping (see [4])? Currently the only purpose of the is_public flag is to hide the flavor from users without the admin role, but it’s still visible in all projects. Any plan to change this? Having project-scoped flavors will rid us of the identified issues, and will allow a more fine-grained way of managing physical resources. Dimitri [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018744.html [2] https://wiki.openstack.org/wiki/Heat/Blueprints/dynamic-flavors [3] https://review.openstack.org/#/c/90029 [4] http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
