Open Stack

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 <
vkozhukalov at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/7f1deab5/attachment.html>