Hi Client, 
Current ironic call is for add/delete baremetl server, not with auto-scale. As 
we discussed in another thread. What I'm thinking is related with auto-scale 
baremetal server. In my mind, the logic can be   1. Nova scheduler determines 
scale up one baremetal server.  2. Nova scheduler notify ironic (or other API?) 
to power up the server.  3. if ironic (or other service?) returns success, nova 
scheduler can call ironic to add the baremetal server into cluster.
Of course, this is not a sole way for auto-scale. As you specified in another 
thread, auto-scale can be triggered from under-cloud or other monitoring 
service. Just try to bring up the interesting discussion. :-)
Best RegardsLeslie

> From: cl...@fewbar.com
> To: openstack-dev@lists.openstack.org
> Date: Sat, 28 Dec 2013 13:40:08 -0800
> Subject: Re: [openstack-dev] [Ironic]Communication between Nova and Ironic
> 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.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
OpenStack-dev mailing list

Reply via email to