<div dir="auto">My main question here would be this: If you feel there are deficiencies in Ironic, why not contribute to improving Ironic rather than spawning a whole new project?<div dir="auto"><br></div><div dir="auto">I am happy to take a look at it, and I'm by no means trying to contradict your assumptions here. I just get concerned with the overhead and confusion that comes with competing projects. </div><div dir="auto"><br></div><div dir="auto">Also, if you'd like to discuss this in detail with a room full of bodies, I suggest proposing a session for the Forum in Sydney. If some of the contributors will be there, it would be a good opportunity for you to get feedback.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Erik</div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sep 26, 2017 8:41 PM, "Matt Riedemann" <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/25/2017 6:27 AM, Zhenguo Niu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks,<br>
<br>
First of all, thanks for the audiences for Mogan project update in the TC room during Denver PTG. Here we would like to get more suggestions before we apply for inclusion.<br>
<br>
Speaking only for myself, I find the current direction of one API+scheduler for vm/baremetal/container unfortunate. After containers management moved out to be a separated project Zun, baremetal with Nova and Ironic continues to be a pain point.<br>
<br>
#. API<br>
Only part of the Nova APIs and parameters can apply to baremetal instances, meanwhile for interoperable with other virtual drivers, bare metal specific APIs such as deploy time RAID, advanced partitions can not  be included. It's true that we can support various compute drivers, but the reality is that the support of each of hypervisor is not equal, especially for bare metals in a virtualization world. But I understand the problems with that as Nova was designed to provide compute resources(virtual machines) instead of bare metals.<br>
<br>
#. Scheduler<br>
Bare metal doesn't fit in to the model of 1:1 nova-compute to resource, as nova-compute processes can't be run on the inventory nodes themselves. That is to say host aggregates, availability zones and such things based on compute service(host) can't be applied to bare metal resources. And for grouping like anti-affinity, the granularity is also not same with virtual machines, bare metal users may want their HA instances not on the same failure domain instead of the node itself. Short saying, we can only get a rigid resource class only scheduling for bare metals.<br>
<br>
<br>
And most of the cloud providers in the market offering virtual machines and bare metals as separated resources, but unfortunately, it's hard to achieve this with one compute service. I heard people are deploying seperated Nova for virtual machines and bare metals with many downstream hacks to the bare metal single-driver Nova but as the changes to Nova would be massive and may invasive to virtual machines, it seems not practical to be upstream.<br>
<br>
So we created Mogan [1] about one year ago, which aims to offer bare metals as first class resources to users with a set of bare metal specific API and a baremetal-centric scheduler(with Placement service). It was like an experimental project at the beginning, but the outcome makes us believe it's the right way. Mogan will fully embrace Ironic for bare metal provisioning and with RSD server [2] introduced to OpenStack, it will be a new world for bare metals, as with that we can compose hardware resources on the fly.<br>
<br>
Also, I would like to clarify the overlaps between Mogan and Nova, I bet there must be some users who wants to use one API for the compute resources management as they don't care about whether it's a virtual machine or a bare metal server. Baremetal driver with Nova is still the right choice for such users to get raw performance compute resources. On the contrary, Mogan is for real bare metal users and cloud providers who wants to offer bare metals as a separated resources.<br>
<br>
Thank you for your time!<br>
<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Mogan" rel="noreferrer" target="_blank">https://wiki.openstack.org/wik<wbr>i/Mogan</a><br>
[2] <a href="https://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-design-overview.html" rel="noreferrer" target="_blank">https://www.intel.com/content/<wbr>www/us/en/architecture-and-tec<wbr>hnology/rack-scale-design-over<wbr>view.html</a><br>
<br>
-- <br>
Best Regards,<br>
Zhenguo Niu<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
Cross-posting to the operators list since they are the community that you'll likely need to convince the most about Mogan and whether or not they want to start experimenting with it.<br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
</blockquote></div></div>