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 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
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 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
