On 11/13/2013 07:50 AM, Steven Dake wrote: > On 11/12/2013 10:25 AM, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - > FI/Espoo) wrote: >> Hi, >> >> In Telecom Cloud applications, the requirements for every application >> are different. One application might need 10 CPUs, 10GB RAM and no >> disk. Another application might need 1 CPU, 512MB RAM and 100GB Disk. >> This varied requirements directly affects the flavors which need to >> be created for different applications (virtual instances). Customer >> has his own custom requirements for CPU, RAM and other hardware >> requirements. So, based on the requests from the customers, we >> believe that the flavor creation should be done along with the >> instance creation, just before the instance is created. Most of the >> flavors will be specific to that application and therefore will not >> be suitable by other instances. >> >> The obvious way is to allow users to create flavors and boot >> customized instances through Heat. As of now, users can launch >> instances through heat along with predefined nova flavors only. We >> have made some changes in our setup and tested it. This change allows >> creation of customized nova flavors using heat templates. We are also >> using extra-specs in the flavors for use in our private cloud deployment. >> This gives an option to the user to mention custom requirements for >> the flavor in the heat template directly along with the instance >> details. There is one problem in the nova flavor creation using heat >> templates. Admin privileges are required to create nova flavors. >> There should be a way to allow a normal user to create flavors. >> >> Your comments and suggestions are most welcome on how to handle this >> problem !!! >> >> Regards, >> Vijaykumar Kodam >> > Vjaykumar, > > I have long believed that an OS::Nova::Flavor resource would make a > good addition to Heat, but as you pointed out, this type of resource > requires administrative priveleges. I generally also believe it is > bad policy to implement resources that *require* admin privs to > operate, because that results in yet more resources that require > admin. We are currently solving the IAM user cases (keystone doesn't > allow the creation of users without admin privs). > > It makes sense that cloud deployers would want to control who could > create flavors to avoid DOS attacks against their inrastructure or > prevent trusted users from creating a wacky flavor that the physical > infrastructure can't support. I'm unclear if nova offers a way to > reduce permissions required for flavor creation. One option that may > be possible is via the keystone trusts mechanism. > > Steve Hardy did most of the work integrating Heat with the new > keystone trusts system - perhaps he has some input. > I would be happy for you to submit your OS::Nova::Flavor resource to heat. There are a couple of nova-specific issues that will need to be addressed: * Is there optimization in nova required to handle the proliferation of flavors? Nova may currently make the assumption that the flavor list is short and static. * How to provide an authorization policy that allows non-admins to create flavors. Maybe something role-based?
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
