It makes a lot of sense. Thanks for your reply! B.R. Leslie
Sent from my iPhone > On Dec 30, 2013, at 3:39 AM, "Oleg Gelbukh" <ogelb...@mirantis.com> wrote: > > Leslie, > > This discussion is very interesting indeed :) > > The current approach to auto-scale is that it is decided upon by Heat > service. Heat templates have special mechanisms to trigger auto-scaling of > resources when certain conditions are met. > In combination with Ironic, it has powerful potential for > OpenStack-on-OpenStack use case you're describing. > > Baiscally, Heat has all orchestration functions in OpenStack. I see it as a > natural place for other interesting things like auto-migration of workloads > and so on. > > -- > Best regards, > Oleg Gelbukh > > >> On Sun, Dec 29, 2013 at 8:03 AM, LeslieWang <wqyu...@hotmail.com> wrote: >> 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 Regards >> Leslie >> >> > 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 >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
