Re: [openstack-dev] [Ironic]Communication between Nova and Ironic
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" 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 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
Re: [openstack-dev] [Ironic]Communication between Nova and Ironic
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 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
Re: [openstack-dev] [Ironic]Communication between Nova and Ironic
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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
Re: [openstack-dev] [Ironic]Communication between Nova and Ironic
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" 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 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. >> >> >> >> Can anyone please answer this question? Your input is highly appreciated. >> >> Best Regards >> Leslie >> >> ___ >> 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
