openstack team mailing list archive

[Shawn Starr <shawn.starr@xxxxxxxxxx>]

On Monday, February 25, 2013 04:29:58 PM Sylvain Bauza wrote:
> Hi Shawn,
> 
> Le 25/02/2013 06:20, Shawn Starr a écrit :
> > Hello folks,
> > 
> > I am starting to look at OpenStack and noticed there are some things it
> > doesn't seem to be able to do right now?
> > 
> > 1) Managing the nova-compute (hypervisor) - I see no options on how to
> > control what nova-compute nodes can be 'provisioned' into an OpenStack
> > cloud, I'd consider that a security risk (potentially) if any computer
> > could just register to become a nova-compute?
> 
> There are various ways for implementing security on Nova-compute. One
> would be to grant mysql access for keystone and nova to only some IPs,
> it would be enough for preventing nova-compute to start (and
> consequently avoiding this hypervisor to be elected for new instances).
> I do admit this is a very basic test which doesn't prevent the host to
> be compromised, of course.
> 

Hi Sylvain,

I was hoping in future we could have a mechanism via mac address to restrict 
which hypervisor/nova-computes are able to join the cluster.

However, your approach to do it by IP restriction would work, since the dhcp 
server would be IP : mac bound for nova-computes themselves.

> > The reason I ask this question is how do we handle hardware failures? How
> > can we manually move a instance/VM off a nova-compute? I see instructions
> > on setting up the hypervisor to move VM instances but no actual commands
> > to issue a move manually.
> > 
> > 2) Can we build a diskless nova-compute? just one kernel/initramfs with
> > the
> > various configurations, libvirt, file storage network mounts, openvswitch
> > setup etc inside it?
> 
> These two questions can be answered by implementing a shared resource
> system for Nova instances, like GlusterFS and allowing libvirt to
> perform live migrations.
> http://docs.openstack.org/trunk/openstack-compute/admin/content/live-migrati
> on-usage.html
> http://gluster.org/community/documentation//index.php/OSConnect

I'll take a look at those, but I'm hoping to have a completely diskless nova-
compute/hypervisor in this case rather than mounting an actual nova-compute 
filesystem over a distributed filesystem itself. This in theory should be 
possible to do so as much as all the OpenStack pieces are present in an 
initramfs during boot of the nova-compute.

> 
> > 3) keystone seems a lot of work to setup with all the various URLs, we
> > plan to streamline this somehow?
> 
> I don't get the point. There is only an initial setup to do for creating
> endpoints and services, but that's it.
> Even this step can be automated thanks to some 3rd-party tools, like Puppet.
> http://docs.openstack.org/trunk/openstack-compute/admin/content/ch_openstac
> k-compute-automated-installations.html

Well even in this case, if you compare OpenNebula it is still easier to setup 
the initial endpoints, user accounts etc. This isn't an issue though.

> > When I used OpenNebula I found the installation similar but simpler (a
> > clear distinction between hypervisors themselves and managing them and
> > managing the VM instances overall). While OpenStack is new I would expect
> > it to be missing functionality currently.
> 
> Could you please explain what is your need ?
> 
> Hope it helps,
> -Sylvain

I'd like to be able to have a fine grained cloud/cluster, for example, if I am 
testing something new such as a new nova-compute initramfs (updated kernel, 
latest libvirt/qemu etc) It would be nice to be able to tell nova to restrict 
what VMs/instances can run on a specific node rather than carve out of the 
cluster and be able to launch instances against that one nova-compute without 
disrupting the rest of the cluster/cloud.

I suppose all the use cases I have will probably be addressed as I continue to 
use OpenStack once I get it installed.

Thanks,
Shawn

> 
> > Thanks,
> > Shawn
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp