openstack team mailing list archive

[Clint Byrum <clint@xxxxxxxxxx>]

First off, welcome! :)

FYI, this is the development mailing list. Questions like the one below
may find more helpful answers on the general OpenStack users' mailing list.
I have CC'd that list so that this response can be seen there, too, I suggest
you re-send your original message there as well.

See https://launchpad.net/~openstack for that list.

Some info in-line.

Excerpts from Zsolt Haraszti's message of 2013-07-23 10:00:59 -0700:
> Hi,
> 
> We are very interested to set up a small OpenStack cloud with a portion of
> the servers used as bare-metal servers and the rest used as "normal" KVM
> hypervisor compute nodes. We are using grizzly, and launch with devstack
> for simplicity.
> 

I hope you are just trying to develop and not running in production. Devstack
is not meant for production, and you will spend more time fighting with it
to get it production ready than you would manually deploying everything.

Also baremetal is not meant to be multi-tenant. The nodes are not wiped when
a server is deleted, and thus the next tenant may very well be able to read
unused disk contents. Also there are other places to hide "evil" in a machine
than just the local disks.

> For a proof-of-concept, I set up an all-in-one node (also acting as KVM
> compute node). Now I am trying to attach a second compute node running in
> baremetal mode.
> 
> Is this known to work?
> 

It is known to not work. One hypervisor per cloud is all that is allowed.

> As a side note, devstack did not seem to support very well our case, i.e.,
> when the control node is not the baremetal node. A number of the automated
> steps were skipped. We worked around this by manually creating the nova_bm
> database, db sync-ing it, creating and uploading the deploy and test
> images, and adding a bare-metal flavor. If there were interest, I would be
> willing to look into modifying devstack to support our case.
> 

Devstack is meant for rapid development of OpenStack. You haven't actually
stated your end use case, but if it is anything other than development of
OpenStack, you need a new tool.

> After this, I was able to enroll an IPMI-enabled 3rd server as a
> baremetal-node, but I am unable to create a BM instance on it. The instance
> gets created in the DB, but the scheduler errors out with NoValidHost. I
> started debugging the issue by investigating the logs and looking into the
> code. I see a few things that I suspect may not be right:
> 
> If I add the second compute node as a normal KVM node, I can see the
> scheduler on the all-in-one node to show both compute nodes refreshing
> every 60 seconds. If I re-add the 2nd compute node in BM mode, I can see no
> more updates coming from that node in the scheduler.
> 
> Also, I dug into the scheduler code a bit, and I can see that in the
> scheduler/host_manager.HostManager.get_all_host_states() the call
> to db.compute_node_get_all(context) returns only one node, the all-in-one.
> 
> Both of the above suggests that the scheduler may have no visibility of the
> BM compute node, hence my troubles.
> 

Right, that is because you can only have one hypervisor type.

> I can debug this further, but I though I ask first. Any pointers would be
> much appreciated.
> 

You may be interested in the OpenStack Deployment program (aka TripleO):

https://github.com/openstack/tripleo-incubator

And the current steps to deploy a development centric OpenStack:

https://github.com/openstack/tripleo-incubator/blob/master/devtest.md

(These steps, unlike devstack, are meant to be a framework for deploying
production clouds.)