>>From: Steve Baker [mailto:sba...@redhat.com] 
    >>Sent: Tuesday, November 12, 2013 9:25 PM
    >>To: openstack-dev@lists.openstack.org
    >>Subject: Re: [openstack-dev] [nova] [heat] Custom Flavor creation through 
Heat
    >>
    >>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?

Thanks Steve Baker for the information. I am also waiting to hear from Steve 
Hardy, if keystone trust system will fix the nova flavors admin privileges 
issue.
One option to control the proliferation of nova flavors is to make them private 
to the tenant (using flavor-access?) who created them. This provides the needed 
privacy so that others tenants cannot view them.

Regards,
VijayKumar

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to