Open Stack

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!

B.R.
Leslie

Sent from my iPhone

> On Dec 24, 2013, at 5:02 PM, "Oleg Gelbukh" <ogelbukh at mirantis.com> wrote:
> 
> Hello, Leslie
> 
> There seem to be some misnotation in this picture, in steps #2 and #4-7. In #2, the 'node' means 'instance of nova-compute' which should handle the request, and nova-scheduler selects that instance of nova-compute.
> 
> In #4 and #7, however, the 'node' means bare-metal server under management of that compute node. That server is actually provisioned as an instance of bare-metal cloud. It is assumed that all servers under management of single instance of nova-compute are equal. Ironic does not perfrom any scheduling or selection of bare-metal servers on its side, just picks the first one.
> 
> Ironic is considered to be a back-end to virt driver of Nova. That is why nova-compute service talks to Ironic API, just as it talks to vCenter API, for example, when VMWare is used as a virt back-end.
> 
> Hope it helps to clarify the picture.
> 
> --
> Best regards,
> Oleg Gelbukh
> 
> 
>> On Tue, Dec 24, 2013 at 12:28 PM, LeslieWang <wqyuwss at hotmail.com> wrote:
>> Hi All,
>> 
>> I'm investigating Ironic recently, and found below diagram describing the workflow between nova and ironic. I have one questions about step #4, #7. Why it is invoked by Nova Compute, not Nova Scheduler. Ironic is used to power on baremetal server, and deploy image. Seems like nova compute should be installed after this call. So I guess this call should be initiated from Nova Scheduler through either synchronous ironic API call, or asynchronous message queue. 
>> 
>>  <wentian2-1024x415.png> 
>> 
>> Can anyone please answer this question? Your input is highly appreciated.
>> 
>> Best Regards
>> Leslie
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131224/f7e4a2ce/attachment.html>
-------------- next part --------------
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev