[openstack-dev] [Ironic] Fuel agent proposal
Yuriy Zveryanskyy
yzveryanskyy at mirantis.com
Wed Dec 10 19:33:44 UTC 2014
New version of the spec:
https://review.openstack.org/#/c/138115/
Problem description updated.
Power interface part removed (not in scope of deploy driver).
On 12/09/2014 12:23 AM, Devananda van der Veen wrote:
>
> I'd like to raise this topic for a wider discussion outside of the
> hallway track and code reviews, where it has thus far mostly remained.
>
>
> In previous discussions, my understanding has been that the Fuel team
> sought to use Ironic to manage "pets" rather than "cattle" - and doing
> so required extending the API and the project's functionality in ways
> that no one else on the core team agreed with. Perhaps that
> understanding was wrong (or perhaps not), but in any case, there is
> now a proposal to add a FuelAgent driver to Ironic. The proposal
> claims this would meet that teams' needs without requiring changes to
> the core of Ironic.
>
>
> https://review.openstack.org/#/c/138115/
>
>
> The Problem Description section calls out four things, which have all
> been discussed previously (some are here [0]). I would like to address
> each one, invite discussion on whether or not these are, in fact,
> problems facing Ironic (not whether they are problems for someone,
> somewhere), and then ask why these necessitate a new driver be added
> to the project.
>
>
> They are, for reference:
>
>
> 1. limited partition support
>
> 2. no software RAID support
>
> 3. no LVM support
>
> 4. no support for hardware that lacks a BMC
>
>
> #1.
>
> When deploying a partition image (eg, QCOW format), Ironic's PXE
> deploy driver performs only the minimal partitioning necessary to
> fulfill its mission as an OpenStack service: respect the user's
> request for root, swap, and ephemeral partition sizes. When deploying
> a whole-disk image, Ironic does not perform any partitioning -- such
> is left up to the operator who created the disk image.
>
>
> Support for arbitrarily complex partition layouts is not required by,
> nor does it facilitate, the goal of provisioning physical servers via
> a common cloud API. Additionally, as with #3 below, nothing prevents a
> user from creating more partitions in unallocated disk space once they
> have access to their instance. Therefor, I don't see how Ironic's
> minimal support for partitioning is a problem for the project.
>
>
> #2.
>
> There is no support for defining a RAID in Ironic today, at all,
> whether software or hardware. Several proposals were floated last
> cycle; one is under review right now for DRAC support [1], and there
> are multiple call outs for RAID building in the state machine
> mega-spec [2]. Any such support for hardware RAID will necessarily be
> abstract enough to support multiple hardware vendor's driver
> implementations and both in-band creation (via IPA) and out-of-band
> creation (via vendor tools).
>
>
> Given the above, it may become possible to add software RAID support
> to IPA in the future, under the same abstraction. This would closely
> tie the deploy agent to the images it deploys (the latter image's
> kernel would be dependent upon a software RAID built by the former),
> but this would necessarily be true for the proposed FuelAgent as well.
>
>
> I don't see this as a compelling reason to add a new driver to the
> project. Instead, we should (plan to) add support for software RAID to
> the deploy agent which is already part of the project.
>
>
> #3.
>
> LVM volumes can easily be added by a user (after provisioning) within
> unallocated disk space for non-root partitions. I have not yet seen a
> compelling argument for doing this within the provisioning phase.
>
>
> #4.
>
> There are already in-tree drivers [3] [4] [5] which do not require a
> BMC. One of these uses SSH to connect and run pre-determined commands.
> Like the spec proposal, which states at line 122, "Control via SSH
> access feature intended only for experiments in non-production
> environment," the current SSHPowerDriver is only meant for testing
> environments. We could probably extend this driver to do what the
> FuelAgent spec proposes, as far as remote power control for cheap
> always-on hardware in testing environments with a pre-shared key.
>
>
> (And if anyone wonders about a use case for Ironic without external
> power control ... I can only think of one situation where I would
> rationally ever want to have a control-plane agent running inside a
> user-instance: I am both the operator and the only user of the cloud.)
>
>
> ----------------
>
>
> In summary, as far as I can tell, all of the problem statements upon
> which the FuelAgent proposal are based are solvable through
> incremental changes in existing drivers, or out of scope for the
> project entirely. As another software-based deploy agent, FuelAgent
> would duplicate the majority of the functionality which
> ironic-python-agent has today.
>
>
> Ironic's driver ecosystem benefits from a diversity of
> hardware-enablement drivers. Today, we have two divergent software
> deployment drivers which approach image deployment differently:
> "agent" drivers use a local agent to prepare a system and download the
> image; "pxe" drivers use a remote agent and copy the image over iSCSI.
> I don't understand how a second driver which duplicates the
> functionality we already have, and shares the same goals as the
> drivers we already have, is beneficial to the project.
>
>
> Doing the same thing twice just increases the burden on the team;
> we're all working on the same problems, so let's do it together.
>
>
> -Devananda
>
>
>
> [0]
> https://blueprints.launchpad.net/ironic/+spec/ironic-python-agent-partition
>
>
> [1] https://review.openstack.org/#/c/107981/
>
>
> [2]
> https://review.openstack.org/#/c/133828/11/specs/kilo/new-ironic-state-machine.rst
>
>
> [3]
> http://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/snmp.py
>
> [4]
> http://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/iboot.py
>
> [5]
> http://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/ssh.py
>
>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141210/a5e6aefa/attachment.html>
More information about the OpenStack-dev
mailing list