Open Stack

On Thu, May 08, 2014 at 11:22:38AM +0100, Daniel P. Berrange wrote:
> On Mon, May 05, 2014 at 07:40:08PM +0000, Dimitri Mazmanov wrote:
> > This is good! Is there a blueprint describing this idea? Or any plans
> > describing it in a blueprint?
> > Would happily share the work.
> > 
> > Should we mix it with flavors in horizon though? I¹m thinking of having a
> > separate ³Resources² page,
> > wherein the user can ³define² resources. I¹m not a UX expert though.
> > 
> > But let me come back to the project-scoped flavor creation issues.
> > Why do you think it¹s such a bad idea to let tenants create flavors for
> > their project specific needs?
> > 
> > I¹ll refer again to the Steve Hardy¹s proposal:
> > - Normal user : Can create a private flavor in a tenant where they
> >   have the Member role (invisible to any other users)
> > - Tenant Admin user : Can create public flavors in the tenants where they
> >   have the admin role (visible to all users in the tenant)
> > - Domain admin user : Can create public flavors in the domains where they
> >   have the admin role (visible to all users in all tenants in that domain)
> 
> NB, flavours have an important role as a means of access control
> against limited compute resources. eg if you have a limited number
> of hosts which have provide a large page sizes, you don't want any
> normal user to be able to define their own flavour which lets them
> consume large pages.
> 
> This is why there is a distinction between properties set on images
> vs properties set on flavours. Image properties, which a normal user
> can set, are restricted to aspects of the VM which don't involve
> consumption of compute host resources. Flavour properties, which
> only a user with 'flavourmanage' permission can change, control
> aspects of the VM  config which consume finite compute resources.
> 
> If we were to allow a normal user to define flavours, we would need
> to come up with a way to deal with this access control requirement.
> 
> One possible option, would be to not allow a normal user to create
> completely new flavours. Instead allow them to take an existing
> flavour to which they have access, and reduce (but not increase)
> its allocated resources.
> 
> eg if the user wanted to create a flavour with 1.5 GB of RAM, they
> would have to have access to a pre-existing flavour which had more
> than 1.5 GB of RAM. eg they'd take a 2 GB flavour and override the
> RAM setting to be just 1.5 GB.  This opens up a question of billing
> for hosting providers - perhaps they would allow the user this
> customization, but still bill them for the original flavour specs.

Of course if you take this idea to its logical conclusion, you would
arguably not need to give users the ability to create flavours. If
you only permit them to reduce the resources associated with a flavour
they use, then you could just allow them to request a reduced set of
resources at time they boot the instance.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|