Open Stack

Good day Ironicers.

I do not want to discuss questions like "Is feature X good for release 
Y?" or "Is feature Z in Ironic scope or not?".
I want to get an answer for this: Is Ironic a flexible, easy extendable 
and user-oriented solution for deployment?
Yes, it is I think. IPA is the great software, but Fuel Agent proposes a 
different and alternative way for deploying.
Devananda wrote about "pets" and "cattle", and maybe some want to manage 
"pets" rather than "cattle"? Let
users do a choice.
We do not plan to change any Ironic API for the driver, internal or 
external (as opposed to IPA, this was done for it).
If there will be no one for Fuel Agent's driver support I think this 
driver should be removed from Ironic tree (I heard
this practice is used in Linux kernel).

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/20141209/28ad7725/attachment.html>