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...
On Tue Dec 09 2014 at 4:08:45 AM Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Just a short explanation of Fuel use case. > > Fuel use case is not a cloud. > 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] 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 :) 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. > Fuel is a deployment tool. We install OS on bare metal servers and on VMs > and then configure this OS using Puppet. We have been using Cobbler as our > OS provisioning tool since the beginning of Fuel. > However, Cobbler assumes using native OS installers (Anaconda and > Debian-installer). For some reasons we decided to > switch to image based approach for installing OS. > > One of Fuel features is the ability to provide advanced partitioning > schemes (including software RAIDs, LVM). > Native installers are quite difficult to customize in the field of > partitioning > (that was one of the reasons to switch to image based approach). Moreover, > we'd like to implement even more > flexible user experience. > 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. [snip] According Fuel itself, our nearest plan is to get rid of Cobbler because > in the case of image based approach it is huge overhead. The question is > which tool we can use instead of Cobbler. We need power management, > we need TFTP management, we need DHCP management. That is > exactly what Ironic is able to do. > 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. This same view is echoed in the spec [1] which I have left comments on: > Cobbler manages DHCP, DNS, TFTP services ... > OpenStack has Ironic in its core which is capable to do the same ... > Ironic can manage DHCP and it is planned to implement dnsmasq plugin. 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. 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. Your use case: * is not cloud-like * 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) * 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 * duplicates some of the functionality already available in other drivers There are certain aspects of the proposal which I like, though: * using SSH rather than HTTP for remote access to the deploy agent * support for putting the root partition on a software RAID * integration with another provisioning system, without any API changes Regards, -Devananda [0] https://wiki.openstack.org/wiki/Main_Page [1] https://review.openstack.org/#/c/138301/8/specs/6.1/substitution-cobbler-with-openstack-ironic.rst [2] https://launchpad.net/ironic/kilo [3] https://review.openstack.org/#/c/132511/ and https://review.openstack.org/#/c/132744/
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
