Along the same lines and while we're talking crazy ideas, one use case
where a user might want to allocate entire nodes would be if TripleO
were used to manage an ARM rack. The use cases aren't identical between
cloud and ARM, but they are similar.
So for a rack of 1000 nodes, there is benefit in certain cases for a
user not only taking an entire node, but a collection of nodes
co-located in the same rack to take advantage of the rack fabric.
Again, crazy ideas and probably outside of the scope of things we want
to bite off immediately. But as we're in the early stages of the Tuskar
data and security models, it might make sense to at least keep in mind
how we could play in this area as well.
On 12/05/2013 08:11 PM, Fox, Kevin M wrote:
I think the security issue can be handled by not actually giving the underlying
resource to the user in the first place.
So, for example, if I wanted a bare metal node's worth of resource for my own
containering, I'd ask for a bare metal node and use a "blessed" image that
contains docker+nova bits that would hook back to the cloud. I wouldn't be able to login
to it, but containers started on it would be able to access my tenant's networks. All
access to it would have to be through nova suballocations. The bare resource would count
against my quotas, but nothing run under it.
Come to think of it, this sounds somewhat similar to what is planned for
Neutron service vm's. They count against the user's quota on one level but not
all access is directly given to the user. Maybe some of the same implementation
bits could be used.
Thanks,
Kevin
________________________________________
From: Mark McLoughlin [mar...@redhat.com]
Sent: Thursday, December 05, 2013 1:53 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][TripleO] Nested resources
Hi Kevin,
On Mon, 2013-12-02 at 12:39 -0800, Fox, Kevin M wrote:
Hi all,
I just want to run a crazy idea up the flag pole. TripleO has the
concept of an under and over cloud. In starting to experiment with
Docker, I see a pattern start to emerge.
* As a User, I may want to allocate a BareMetal node so that it is
entirely mine. I may want to run multiple VM's on it to reduce my own
cost. Now I have to manage the BareMetal nodes myself or nest
OpenStack into them.
* As a User, I may want to allocate a VM. I then want to run multiple
Docker containers on it to use it more efficiently. Now I have to
manage the VM's myself or nest OpenStack into them.
* As a User, I may want to allocate a BareMetal node so that it is
entirely mine. I then want to run multiple Docker containers on it to
use it more efficiently. Now I have to manage the BareMetal nodes
myself or nest OpenStack into them.
I think this can then be generalized to:
As a User, I would like to ask for resources of one type (One AZ?),
and be able to delegate resources back to Nova so that I can use Nova
to subdivide and give me access to my resources as a different type.
(As a different AZ?)
I think this could potentially cover some of the TripleO stuff without
needing an over/under cloud. For that use case, all the BareMetal
nodes could be added to Nova as such, allocated by the "services"
tenant as running a nested VM image type resource stack, and then made
available to all tenants. Sys admins then could dynamically shift
resources from VM providing nodes to BareMetal Nodes and back as
needed.
This allows a user to allocate some raw resources as a group, then
schedule higher level services to run only in that group, all with the
existing api.
Just how crazy an idea is this?
FWIW, I don't think it's a crazy idea at all - indeed I mumbled
something similar a few times in conversation with random people over
the past few months :)
With the increasing interest in containers, it makes a tonne of sense -
you provision a number of VMs and now you want to carve them up by
allocating containers on them. Right now, you'd need to run your own
instance of Nova for that ... which is far too heavyweight.
It is a little crazy in the sense that it's a tonne of work, though.
There's not a whole lot of point in discussing it too much until someone
shows signs of wanting to implement it :)
One problem is how the API would model this nesting, another problem is
making the scheduler aware that some nodes are only available to the
tenant which owns them but maybe a bigger problem is the security model
around allowing a node managed by an untrusted become a compute node.
Mark.
_______________________________________________
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
