Open Stack

Excerpts from LeslieWang's message of 2013-12-24 03:01:51 -0800:
> Hi Oleg,
> 
> Thanks for your promptly reply and detail explanation. Merry Christmas and wish you have a happy new year!
> 
> At the same time, I think we can discuss more on Ironic is for backend driver for nova. I'm new in ironic. Per my understanding, the purpose of bare metal as a backend driver is to solve the problem that some appliance systems can not be virtualized, but operator still wants same cloud management system to manage these systems. With the help of ironic, operator can achieve the goal, and use one openstack to manage these systems as VMs, create, delete, deploy image etc. this is one typical use case.
> 
> In addition, actually I'm thinking another interesting use case. Currently openstack requires ops to pre-install all servers. TripleO try to solve this problem and bootstrap openstack using openstack. However, what is missing here is dynamic power on VM/switches/storage only. Imagine initially lab only had one all-in-one openstack controller. The whole work flow can be:
>   1. Users request one VM or baremetal server through portal.
>   2. Horizon sends request to nova-scheduler
>   3. Nova-scheduler finds no server, then invoke ironic api to power on one through IPMI, and install either hyper visor or appliance directly.
>   4. If it need create VM, Nova-scheduler will find one compute node, and send message for further processing.
> 
> Based on this use case, I'm thinking whether it makes sense to embed this ironic invokation logic in nova-scheduler, or another approach is as overall orchestration manager, TripleO project has a TripleO-scheduler to firstly intercept the message, invoke ironic api, then heat api which calls nova api, neutron api, storage api.  In this case, TripleO only powers on baremetal server running VM, nova is responsible to power on baremetal server running appliance system. Sounds like latter one is a good solution, however the prior one also works. So can you please comment on it? Thanks!
> 

I think this basically already works the way you desire. The scheduler
_does_ decide to call ironic, it just does so through nova-compute RPC
calls. That is important, as this allows the scheduler to hand-off the
entire work-flow of provisioning a machine to nova-compute in the exact
same way as is done for regular cloud workloads.