Open Stack

My concern with proliferating custom flavors is that it might play havoc with the underlying root-case for flavors.

My understanding of flavors is that they are used to solve the resource packing problem in elastic cloud scenarios. That way you know that 256 "tiny" VMs fit cleanly into your hardware layout and so do 128 "medium" VMs and 64 large VMs. If you allow "flavor of the week" then the packing problem re-asserts itself and scheduling becomes harder. 

Do I understand this right?

Given the root-use-case is to help solve VM packing problems, I would think that you could allow a "nonsense flavor" that would say: the Image provides sizing hints beyond flavors. So you would toggle a VM to be "nonsense flavor" and trigger different scheduling, packing, allocation behaviors.

tl;dr - I think that breaks flavors, but I think you should allow it by allowing a cloud to escape flavors all together if they want.

# Shawn Hartsock


----- Original Message -----
> From: "Steve Baker" <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org
> Sent: Tuesday, November 12, 2013 2:25:23 PM
> 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?
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>