<div>Thank you for explaining in detail what Fuel's use case is. I was lacking this information, and taking the FuelAgent proposal in isolation. Allow me to respond to several points inline...</div><div></div><br><div class="gmail_quote">On Tue Dec 09 2014 at 4:08:45 AM Vladimir Kozhukalov <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Just a short explanation of Fuel use case.</div><div><br></div><div>Fuel use case is not a cloud. </div></div></blockquote><div><br></div><div><div>This is a fairly key point, and thank you for bringing it up. Ironic's primary aim is to better OpenStack, and as such, to be part of an "Open Source Cloud Computing platform." [0]</div><div><br></div><div>Meeting a non-cloud use case has not been a priority for the project as a whole. It is from that perspective that my initial email was written, and I stand by what I said there -- FuelAgent does not appear to be significantly different from IPA when used within a "cloudy" use case. But, as you've pointed out, that's not your use case :)</div><div><br></div><div>Enabling use outside of OpenStack has been generally accepted by the team, though I don't believe anyone on the core team has put a lot of effort into developing that yet. As I read this thread, I'm pleased to see more details about Fuel's architecture and goals -- I think there is a potential fit for Ironic here, though several points need further discussion.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Fuel is a deployment tool. We install OS on bare metal servers and on VMs</div><div>and then configure this OS using Puppet. We have been using Cobbler as our OS provisioning tool since the beginning of Fuel.</div><div>However, Cobbler assumes using native OS installers (Anaconda and Debian-installer). For some reasons we decided to</div><div>switch to image based approach for installing OS.</div><div><br></div><div>One of Fuel features is the ability to provide advanced partitioning schemes (including software RAIDs, LVM).</div><div>Native installers are quite difficult to customize in the field of partitioning</div><div>(that was one of the reasons to switch to image based approach). Moreover, we'd like to implement even more</div><div>flexible user experience. </div></div></blockquote><div><br></div><div><div><span style="line-height:19.7999992370605px">The degree of customization and flexibility which you describe is very understandable within traditional IT shops. Don't get me wrong -- there's nothing inherently bad about wanting to give such flexibility to your users. However, infinite flexibility is counter-productive to two of the primary benefits of cloud computing: repeatability, and consistency.</span></div></div><div><span style="line-height:19.7999992370605px"><br></span></div><div>[snip] </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>According Fuel itself, our nearest plan is to get rid of Cobbler because<br></div><div>in the case of image based approach it is huge overhead. The question is</div><div>which tool we can use instead of Cobbler. We need power management,</div><div>we need TFTP management, we need DHCP management. That is</div><div>exactly what Ironic is able to do. </div></div></blockquote><div><br></div><div><div><span style="line-height:19.7999992370605px">You're only partly correct here. Ironic provides a vendor-neutral abstraction for power management and image deployment, but Ironic does not implement any DHCP management - Neutron is responsible for that, and Ironic calls out to Neutron's API only to adjust dhcpboot parameters. At no point is Ironic responsible for IP or DNS assignment.</span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">This same view is echoed in the spec [1] which I have left comments on:</span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div><span style="line-height:19.7999992370605px">> Cobbler manages DHCP, DNS, TFTP services ... </span></div><div><span style="line-height:19.7999992370605px">> OpenStack has Ironic in its core which is capable to do the same ...</span></div><div><span style="line-height:19.7999992370605px">> Ironic can manage </span><span style="line-height:19.7999992370605px">DHCP and it is planned to implement dnsmasq plugin.</span></div><div><span style="line-height:19.7999992370605px"><br></span></div><div>To reiterate, Ironic does not manage DHCP or DNS, it never has, and such is not on the roadmap for Kilo [2]. Two specs related to this were proposed last month [3] -- but a spec proposal does not equal project plans. One of the specs has been abandoned, and I am still waiting for the author to rewrite the other one. Neither are approved nor targeted to Kilo.</div></div><div><br></div><div><br></div><div>In summary, if I understand correctly, it seems as though you're trying to fit Ironic into Cobbler's way of doing things, rather than recognize that Ironic approaches provisioning in a fundamentally different way.</div><div><br></div><div>Your use case:</div><div>* is not cloud-like</div><div>* does not include Nova or Neutron, but will duplicate functionality of both (you need a scheduler and all the logic within nova.virt.ironic, and something to manage DHCP and DNS assignment)</div><div>* would use Ironic to manage diverse hardware, which naturally requires some operator-driven customization, but still exposes the messy configuration bits^D^Dchoices to users at deploy time</div><div>* duplicates some of the functionality already available in other drivers</div><div><br></div><div>There are certain aspects of the proposal which I like, though:</div><div>* using SSH rather than HTTP for remote access to the deploy agent</div><div>* support for putting the root partition on a software RAID</div><div>* integration with another provisioning system, without any API changes</div><div><br></div><div>Regards,</div><div>-Devananda<br></div><div><br></div><div><div><br class="Apple-interchange-newline">[0] <a href="https://wiki.openstack.org/wiki/Main_Page">https://wiki.openstack.org/wiki/Main_Page</a></div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/138301/8/specs/6.1/substitution-cobbler-with-openstack-ironic.rst">https://review.openstack.org/#/c/138301/8/specs/6.1/substitution-cobbler-with-openstack-ironic.rst</a></div><div><br></div><div>[2] <a href="https://launchpad.net/ironic/kilo">https://launchpad.net/ironic/kilo</a></div><div><br></div><div>[3] <a href="https://review.openstack.org/#/c/132511/">https://review.openstack.org/#/c/132511/</a> and  <a href="https://review.openstack.org/#/c/132744/">https://review.openstack.org/#/c/132744/</a></div></div></div>