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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
