Open Stack

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/8e501599/attachment.html>