Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-10 Thread Vladimir Kozhukalov
Devananda,

Thank you for such a constructive letter,

First of all, just to make sure we are on the same page, we are totally +1
for using any tool which meets our requirements and we are totally +1 for
working together on the same problems. As you remember we suggested to add
advanced partition capabilities (md and lvm) into IPA. I see that it is
layer violation for Ironic, I see it is not in cloud scope,  but we need
these features, because our users want them and because our use case is
deployment. For me it is seems OK when some tool has some feature which is
not mandatory to use.

And we didn't start Fuel Agent until these features were rejected to be
merged into IPA. If we had a chance to implement them in terms of IPA that
would be a preferred way for us.

Some details:

* Power management

For power management Cobbler uses so called 'fence agents'. It is just a OS
package which provides a bunch of scripts using ILO, IPMI, DRAC clients.
Currently we extended this set of agents with so called 'ssh' agent. This
ssh agent is able to run 'reboot' command inside OS via ssh. We use this
agent by default because many of our users do their experiments on BMC-free
hardware. That is why this spec
https://review.openstack.org/#/c/138115/ refers to SSH power driver.

I know Ironic already has SSH power driver which runs 'virsh' (a little bit
confusing) command via ssh and it is supposed to use it for experimental
envs. The suggestion to implement another SSH power driver can confuse
people. My suggestion is to extend Ironic SSH power driver so as to make it
able to run any command (virsh, vbox or even reboot) from a set. And maybe
renaming this driver into something like 'experimental' or 'development' is
not a very bad idea. I am aware that Ironic wants to remove this driver at
all as it is used for tests only. But there are lots of different power
cases (including w/o BMC) hardware and we definitely need to have a place
where to put this non standard power related stuff. I believe many people
are interested in having such a workaround.

And we certainly need other Ironic power management capabilities like ILO,
DRAC, IPMI. We are also potentially very interested in developing other
hardware management capabilities like configuring hardware RAIDs,
BIOS/UEFI, etc.

* DHCP, TFTP, DNS management

We are aware of the way how Ironic manages DHCP (not directly). As you
mentioned,  currently Ironic has a pluggable framework for DHCP and the
only in-tree driver is neutron. And we are aware that implementing kind of
dnsmasq wrapper immediately breaks Ironic scaling scheme (many conductors).
When I wrote 'it is planned to implement dnsmasq plugin' in this spec
https://review.openstack.org/#/c/138301 I didn't mean Ironic is planning to
do this. I meant Fuel team is planning to implement this dnsmasq plugin out
of Ironic tree (will point it out explicitly) just to be able to fit Fuel
release cycle (iterative development). Maybe in the future we will consider
to switch to Neutron for managing networks (out of scope of this
discussion). This Ironic Fuel Agent driver is supposed to use Ironic
abstractions to configure DHCP, i.e. call plugin methods
 update_port_dhcp_opts, update_port_address,
update_dhcp_opts, get_ip_addresses NOT changing Ironic core (again, we will
point it out explicitly).

* IPA vs. Fuel Agent

My suggestion here is to stop think of Fuel Agent as Fuel only related
stuff. I hope it is clear by now that Fuel Agent is just a generic tool
which is about 'operator == user within traditional IT shop' use case. And
this use case requires all that stuff like LVM and enormous flexibility
which does not even have a chance to be considered as a part of IPA next
few months. A good decision here might be implementing Fuel Agent driver
and then working on distinguishing common IPA and Fuel Agent parts and
putting them into one tree (long term perspective). If it is a big deal we
can even rename Fuel Agent into something which sounds more neutrally (not
related to Fuel) and put it into a separate git.

If this is what FuelAgent is about, why is there so much resistance to
 contributing that functionality to the component which is already
 integrated with Ironic? Why complicate matters for both users and
 developers by adding *another* deploy agent that does (or will soon do) the
 same things?


Briefly, we are glad to contribute to IPA but let's do things iteratively.
I need somehow to deliver power and dhcp management + image based
provisioning by March 2015. According to my previous experience of
contributing to IPA it is almost impossible to merge everything I need by
that time. It is possible to implement Fuel Agent driver by that time. It
is also possible to implement something on my own not integrating Ironic
into Fuel at all. As a long term perspective if it's OK to land MD and LVM
into IPA we definitely can do that.

In summary, if I understand correctly, it seems as though you're trying to
 fit Ironic into 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-10 Thread Yuriy Zveryanskyy

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 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Roman Prykhodchenko
It is true that IPA and FuelAgent share a lot of functionality in common. 
However there is a major difference between them which is that they are 
intended to be used to solve a different problem.

IPA is a solution for provision-use-destroy-use_by_different_user use-case and 
is really great for using it for providing BM nodes for other OS services or in 
services like Rackspace OnMetal. FuelAgent itself serves for 
provision-use-use-…-use use-case like Fuel or TripleO have.

Those two use-cases require concentration on different details in first place. 
For instance for IPA proper decommissioning is more important than advanced 
disk management, but for FuelAgent priorities are opposite because of obvious 
reasons.

Putting all functionality to a single driver and a single agent may cause 
conflicts in priorities and make a lot of mess inside both the driver and the 
agent. Actually previously changes to IPA were blocked right because of this 
conflict of priorities. Therefore replacing FuelAgent by IPA in where FuelAgent 
is used currently does not seem like a good option because come people (and I’m 
not talking about Mirantis) might loose required features because of different 
priorities.

Having two separate drivers along with two separate agents for those different 
use-cases will allow to have two independent teams that are concentrated on 
what’s really important for a specific use-case. I don’t see any problem in 
overlapping functionality if it’s used differently.


P. S.
I realise that people may be also confused by the fact that FuelAgent is 
actually called like that and is used only in Fuel atm. Our point is to make it 
a simple, powerful and what’s more important a generic tool for provisioning. 
It is not bound to Fuel or Mirantis and if it will cause confusion in the 
future we will even be happy to give it a different and less confusing name.

P. P. S.
Some of the points of this integration do not look generic enough or nice 
enough. We look pragmatic on the stuff and are trying to implement what’s 
possible to implement as the first step. For sure this is going to have a lot 
more steps to make it better and more generic.


 On 09 Dec 2014, at 01:46, Jim Rollenhagen j...@jimrollenhagen.com wrote:
 
 
 
 On December 8, 2014 2:23:58 PM PST, Devananda van der Veen 
 devananda@gmail.com mailto:devananda@gmail.com 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/
 
 I think it's clear from the review that I share the opinions expressed in 
 this email.
 
 That said (and hopefully without derailing the thread too much), I'm curious 
 how this driver could do software RAID or LVM without modifying Ironic's API 
 or data model. How would the agent know how these should be built? How would 
 an operator or user tell Ironic what the disk/partition/volume layout would 
 look like?
 
 And before it's said - no, I don't think vendor passthru API calls are an 
 appropriate answer here.
 
 // jim
 
 
 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 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Vladimir Kozhukalov
Just a short explanation of Fuel use case.

Fuel use case is not a cloud. 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. We'd like to allow user to choose which hard
drives to use for root FS, for
allocating DB. We'd like user to be able to put root FS over LV or MD
device (including stripe, mirror, multipath).
We'd like user to be able to choose which hard drives are bootable (if
any), which options to use for mounting file systems.
Many many various cases are possible. If you ask why we'd like to support
all those cases, the answer is simple:
because our users want us to support all those cases.
Obviously, many of those cases can not be implemented as image internals,
some cases can not be also implemented on
configuration stage (placing root fs on lvm device).

As far as those use cases were rejected to be implemented in term of IPA,
we implemented so called Fuel Agent.
Important Fuel Agent features are:

* It does not have REST API
* it has executable entry point[s]
* It uses local json file as it's input
* It is planned to implement ability to download input data via HTTP (kind
of metadata service)
* It is designed to be agnostic to input data format, not only Fuel format
(data drivers)
* It is designed to be agnostic to image format (tar images, file system
images, disk images, currently fs images)
* It is designed to be agnostic to image compression algorithm (currently
gzip)
* It is designed to be agnostic to image downloading protocol (currently
local file and HTTP link)

So, it is clear that being motivated by Fuel, Fuel Agent is quite
independent and generic. And we are open for
new use cases.

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. Frankly, we can implement power/TFTP/DHCP
management tool independently, but as Devananda said, we're all working on
the same problems,
so let's do it together.  Power/TFTP/DHCP management is where we are
working on the same problems,
but IPA and Fuel Agent are about different use cases. This case is not just
Fuel, any mature
deployment case require advanced partition/fs management. However, for me
it is OK, if it is easily possible
to use Ironic with external drivers (not merged to Ironic and not tested on
Ironic CI).

AFAIU, this spec https://review.openstack.org/#/c/138115/ does not assume
changing Ironic API and core.
Jim asked about how Fuel Agent will know about advanced disk partitioning
scheme if API is not
changed. The answer is simple: Ironic is supposed to send a link to
metadata service (http or local file)
where Fuel Agent can download input json data.

As Roman said, we try to be pragmatic and suggest something which does not
break anything. All changes
are supposed to be encapsulated into a driver. No API and core changes. We
have resources to support, test
and improve this driver. This spec is just a zero step. Further steps are
supposed to improve driver
so as to make it closer to Ironic abstractions.

For Ironic that means widening use cases and user community. But, as I
already said,
we are OK if Ironic does not need this feature.

Vladimir Kozhukalov

On Tue, Dec 9, 2014 at 1:09 PM, Roman Prykhodchenko 
rprikhodche...@mirantis.com wrote:

 It is true that IPA and FuelAgent share a lot of functionality in common.
 However there is a major difference between them which is that they are
 intended to be used to solve a different problem.

 IPA is a solution for provision-use-destroy-use_by_different_user use-case
 and is really great for using it for providing BM nodes for other OS
 services or in services like Rackspace OnMetal. FuelAgent itself serves for
 provision-use-use-…-use use-case like Fuel or TripleO have.

 Those two use-cases require concentration on different details in first
 place. For instance for IPA proper decommissioning is more important than
 advanced disk management, but for FuelAgent priorities are opposite because
 of obvious reasons.

 Putting all functionality to a single driver and a single agent may cause
 conflicts in priorities and make a lot of mess inside both the driver and
 the agent. Actually previously changes to IPA 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Yuriy Zveryanskyy

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 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Dmitry Tantsur

Hi folks,

Thank you for additional explanation, it does clarify things a bit. I'd 
like to note, however, that you talk a lot about how _different_ Fuel 
Agent is from what Ironic does now. I'd like actually to know how well 
it's going to fit into what Ironic does (in additional to your specific 
use cases). Hence my comments inline:


On 12/09/2014 01:01 PM, Vladimir Kozhukalov wrote:

Just a short explanation of Fuel use case.

Fuel use case is not a cloud. 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. We'd like to allow user to choose which hard
drives to use for root FS, for
allocating DB. We'd like user to be able to put root FS over LV or MD
device (including stripe, mirror, multipath).
We'd like user to be able to choose which hard drives are bootable (if
any), which options to use for mounting file systems.
Many many various cases are possible. If you ask why we'd like to
support all those cases, the answer is simple:
because our users want us to support all those cases.
Obviously, many of those cases can not be implemented as image
internals, some cases can not be also implemented on
configuration stage (placing root fs on lvm device).

As far as those use cases were rejected to be implemented in term of
IPA, we implemented so called Fuel Agent.
Important Fuel Agent features are:

* It does not have REST API

I would not call it a feature :-P

Speaking seriously, if you agent is a long-running thing and it gets 
it's configuration from e.g. JSON file, how can Ironic notify it of any 
changes?



* it has executable entry point[s]
* It uses local json file as it's input
* It is planned to implement ability to download input data via HTTP
(kind of metadata service)
* It is designed to be agnostic to input data format, not only Fuel
format (data drivers)
* It is designed to be agnostic to image format (tar images, file system
images, disk images, currently fs images)
* It is designed to be agnostic to image compression algorithm
(currently gzip)
* It is designed to be agnostic to image downloading protocol (currently
local file and HTTP link)
Does it support Glance? I understand it's HTTP, but it requires 
authentication.




So, it is clear that being motivated by Fuel, Fuel Agent is quite
independent and generic. And we are open for
new use cases.
My favorite use case is hardware introspection (aka getting data 
required for scheduling from a node automatically). Any ideas on this? 
(It's not a priority for this discussion, just curious).




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. Frankly, we can implement power/TFTP/DHCP
management tool independently, but as Devananda said, we're all working
on the same problems,
so let's do it together.  Power/TFTP/DHCP management is where we are
working on the same problems,
but IPA and Fuel Agent are about different use cases. This case is not
just Fuel, any mature
deployment case require advanced partition/fs management.
Taking into consideration that you're doing a generic OS installation 
tool... yeah, it starts to make some sense. For cloud advanced partition 
is definitely a pet case.


However, for

me it is OK, if it is easily possible
to use Ironic with external drivers (not merged to Ironic and not tested
on Ironic CI).

AFAIU, this spec https://review.openstack.org/#/c/138115/ does not
assume changing Ironic API and core.
Jim asked about how Fuel Agent will know about advanced disk
partitioning scheme if API is not
changed. The answer is simple: Ironic is supposed to send a link to
metadata service (http or local file)
where Fuel Agent can download input json data.
That's not about not changing Ironic. Changing Ironic is ok for 
reasonable use cases - we do a huge change right now to accommodate 
zapping, hardware introspection and RAID configuration.


I actually have problems with this particular statement. It does not 
sound like Fuel Agent will integrate enough with Ironic. This JSON file: 
who is going to generate it? In the most popular use case we're driven 
by Nova. Will Nova generate this file?


If the answer is generate it manually for every 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Vladimir Kozhukalov
Vladimir Kozhukalov

On Tue, Dec 9, 2014 at 3:51 PM, Dmitry Tantsur dtant...@redhat.com wrote:

 Hi folks,

 Thank you for additional explanation, it does clarify things a bit. I'd
 like to note, however, that you talk a lot about how _different_ Fuel Agent
 is from what Ironic does now. I'd like actually to know how well it's going
 to fit into what Ironic does (in additional to your specific use cases).
 Hence my comments inline:



 On 12/09/2014 01:01 PM, Vladimir Kozhukalov wrote:

 Just a short explanation of Fuel use case.

 Fuel use case is not a cloud. 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. We'd like to allow user to choose which hard
 drives to use for root FS, for
 allocating DB. We'd like user to be able to put root FS over LV or MD
 device (including stripe, mirror, multipath).
 We'd like user to be able to choose which hard drives are bootable (if
 any), which options to use for mounting file systems.
 Many many various cases are possible. If you ask why we'd like to
 support all those cases, the answer is simple:
 because our users want us to support all those cases.
 Obviously, many of those cases can not be implemented as image
 internals, some cases can not be also implemented on
 configuration stage (placing root fs on lvm device).

 As far as those use cases were rejected to be implemented in term of
 IPA, we implemented so called Fuel Agent.
 Important Fuel Agent features are:

 * It does not have REST API

 I would not call it a feature :-P

 Speaking seriously, if you agent is a long-running thing and it gets it's
 configuration from e.g. JSON file, how can Ironic notify it of any changes?

 Fuel Agent is not long-running service. Currently there is no need to have
REST API. If we deal with kind of keep alive stuff of inventory/discovery
then we probably add API. Frankly, IPA REST API is not REST at all. However
that is not a reason to not to call it a feature and through it away. It is
a reason to work on it and improve. That is how I try to look at things
(pragmatically).

Fuel Agent has executable entry point[s] like /usr/bin/provision. You can
run this entry point with options (oslo.config) and point out where to find
input json data. It is supposed Ironic will  use ssh (currently in Fuel we
use mcollective) connection and run this waiting for exit code. If exit
code is equal to 0, provisioning is done. Extremely simple.


  * it has executable entry point[s]
 * It uses local json file as it's input
 * It is planned to implement ability to download input data via HTTP
 (kind of metadata service)
 * It is designed to be agnostic to input data format, not only Fuel
 format (data drivers)
 * It is designed to be agnostic to image format (tar images, file system
 images, disk images, currently fs images)
 * It is designed to be agnostic to image compression algorithm
 (currently gzip)
 * It is designed to be agnostic to image downloading protocol (currently
 local file and HTTP link)

 Does it support Glance? I understand it's HTTP, but it requires
 authentication.


 So, it is clear that being motivated by Fuel, Fuel Agent is quite
 independent and generic. And we are open for
 new use cases.

 My favorite use case is hardware introspection (aka getting data required
 for scheduling from a node automatically). Any ideas on this? (It's not a
 priority for this discussion, just curious).


That is exactly what we do in Fuel. Currently we use so called 'Default'
pxelinux config and all nodes being powered on are supposed to boot with so
called 'Bootstrap' ramdisk where Ohai based agent (not Fuel Agent) runs
periodically and sends hardware report to Fuel master node.
User then is able to look at CPU, hard drive and network info and choose
which nodes to use for controllers, which for computes, etc. That is what
nova scheduler is supposed to do (look at hardware info and choose a
suitable node).

Talking about future, we are planning to re-implement inventory/discovery
stuff in terms of Fuel Agent (currently, this stuff is implemented as Ohai
based independent script).  Estimation for that is March 2015.




 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 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Vladimir Kozhukalov
s/though/throw/g

Vladimir Kozhukalov

On Tue, Dec 9, 2014 at 5:40 PM, Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:



 Vladimir Kozhukalov

 On Tue, Dec 9, 2014 at 3:51 PM, Dmitry Tantsur dtant...@redhat.com
 wrote:

 Hi folks,

 Thank you for additional explanation, it does clarify things a bit. I'd
 like to note, however, that you talk a lot about how _different_ Fuel Agent
 is from what Ironic does now. I'd like actually to know how well it's going
 to fit into what Ironic does (in additional to your specific use cases).
 Hence my comments inline:



 On 12/09/2014 01:01 PM, Vladimir Kozhukalov wrote:

 Just a short explanation of Fuel use case.

 Fuel use case is not a cloud. 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. We'd like to allow user to choose which hard
 drives to use for root FS, for
 allocating DB. We'd like user to be able to put root FS over LV or MD
 device (including stripe, mirror, multipath).
 We'd like user to be able to choose which hard drives are bootable (if
 any), which options to use for mounting file systems.
 Many many various cases are possible. If you ask why we'd like to
 support all those cases, the answer is simple:
 because our users want us to support all those cases.
 Obviously, many of those cases can not be implemented as image
 internals, some cases can not be also implemented on
 configuration stage (placing root fs on lvm device).

 As far as those use cases were rejected to be implemented in term of
 IPA, we implemented so called Fuel Agent.
 Important Fuel Agent features are:

 * It does not have REST API

 I would not call it a feature :-P

 Speaking seriously, if you agent is a long-running thing and it gets it's
 configuration from e.g. JSON file, how can Ironic notify it of any changes?

 Fuel Agent is not long-running service. Currently there is no need to
 have REST API. If we deal with kind of keep alive stuff of
 inventory/discovery then we probably add API. Frankly, IPA REST API is not
 REST at all. However that is not a reason to not to call it a feature and
 through it away. It is a reason to work on it and improve. That is how I
 try to look at things (pragmatically).

 Fuel Agent has executable entry point[s] like /usr/bin/provision. You can
 run this entry point with options (oslo.config) and point out where to find
 input json data. It is supposed Ironic will  use ssh (currently in Fuel we
 use mcollective) connection and run this waiting for exit code. If exit
 code is equal to 0, provisioning is done. Extremely simple.


  * it has executable entry point[s]
 * It uses local json file as it's input
 * It is planned to implement ability to download input data via HTTP
 (kind of metadata service)
 * It is designed to be agnostic to input data format, not only Fuel
 format (data drivers)
 * It is designed to be agnostic to image format (tar images, file system
 images, disk images, currently fs images)
 * It is designed to be agnostic to image compression algorithm
 (currently gzip)
 * It is designed to be agnostic to image downloading protocol (currently
 local file and HTTP link)

 Does it support Glance? I understand it's HTTP, but it requires
 authentication.


 So, it is clear that being motivated by Fuel, Fuel Agent is quite
 independent and generic. And we are open for
 new use cases.

 My favorite use case is hardware introspection (aka getting data required
 for scheduling from a node automatically). Any ideas on this? (It's not a
 priority for this discussion, just curious).


 That is exactly what we do in Fuel. Currently we use so called 'Default'
 pxelinux config and all nodes being powered on are supposed to boot with so
 called 'Bootstrap' ramdisk where Ohai based agent (not Fuel Agent) runs
 periodically and sends hardware report to Fuel master node.
 User then is able to look at CPU, hard drive and network info and choose
 which nodes to use for controllers, which for computes, etc. That is what
 nova scheduler is supposed to do (look at hardware info and choose a
 suitable node).

 Talking about future, we are planning to re-implement inventory/discovery
 stuff in terms of Fuel Agent (currently, this stuff is implemented as Ohai
 based independent script).  Estimation for that is March 2015.




 According Fuel itself, our nearest plan is to get rid of Cobbler because
 in 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Dmitry Tantsur

On 12/09/2014 03:40 PM, Vladimir Kozhukalov wrote:



Vladimir Kozhukalov

On Tue, Dec 9, 2014 at 3:51 PM, Dmitry Tantsur dtant...@redhat.com
mailto:dtant...@redhat.com wrote:

Hi folks,

Thank you for additional explanation, it does clarify things a bit.
I'd like to note, however, that you talk a lot about how _different_
Fuel Agent is from what Ironic does now. I'd like actually to know
how well it's going to fit into what Ironic does (in additional to
your specific use cases). Hence my comments inline:



On 12/09/2014 01:01 PM, Vladimir Kozhukalov wrote:

Just a short explanation of Fuel use case.

Fuel use case is not a cloud. 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. We'd like to allow user to choose
which hard
drives to use for root FS, for
allocating DB. We'd like user to be able to put root FS over LV
or MD
device (including stripe, mirror, multipath).
We'd like user to be able to choose which hard drives are
bootable (if
any), which options to use for mounting file systems.
Many many various cases are possible. If you ask why we'd like to
support all those cases, the answer is simple:
because our users want us to support all those cases.
Obviously, many of those cases can not be implemented as image
internals, some cases can not be also implemented on
configuration stage (placing root fs on lvm device).

As far as those use cases were rejected to be implemented in term of
IPA, we implemented so called Fuel Agent.
Important Fuel Agent features are:

* It does not have REST API

I would not call it a feature :-P

Speaking seriously, if you agent is a long-running thing and it gets
it's configuration from e.g. JSON file, how can Ironic notify it of
any changes?

Fuel Agent is not long-running service. Currently there is no need to
have REST API. If we deal with kind of keep alive stuff of
inventory/discovery then we probably add API. Frankly, IPA REST API is
not REST at all. However that is not a reason to not to call it a
feature and through it away. It is a reason to work on it and improve.
That is how I try to look at things (pragmatically).

Fuel Agent has executable entry point[s] like /usr/bin/provision. You
can run this entry point with options (oslo.config) and point out where
to find input json data. It is supposed Ironic will  use ssh (currently
in Fuel we use mcollective) connection and run this waiting for exit
code. If exit code is equal to 0, provisioning is done. Extremely simple.

* it has executable entry point[s]
* It uses local json file as it's input
* It is planned to implement ability to download input data via HTTP
(kind of metadata service)
* It is designed to be agnostic to input data format, not only Fuel
format (data drivers)
* It is designed to be agnostic to image format (tar images,
file system
images, disk images, currently fs images)
* It is designed to be agnostic to image compression algorithm
(currently gzip)
* It is designed to be agnostic to image downloading protocol
(currently
local file and HTTP link)

Does it support Glance? I understand it's HTTP, but it requires
authentication.


So, it is clear that being motivated by Fuel, Fuel Agent is quite
independent and generic. And we are open for
new use cases.

My favorite use case is hardware introspection (aka getting data
required for scheduling from a node automatically). Any ideas on
this? (It's not a priority for this discussion, just curious).


That is exactly what we do in Fuel. Currently we use so called 'Default'
pxelinux config and all nodes being powered on are supposed to boot with
so called 'Bootstrap' ramdisk where Ohai based agent (not Fuel Agent)
runs periodically and sends hardware report to Fuel master node.
User then is able to look at CPU, hard drive and network info and choose
which nodes to use for controllers, which for computes, etc. That is
what nova scheduler is supposed to do 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Jim Rollenhagen
On Tue, Dec 09, 2014 at 04:01:07PM +0400, Vladimir Kozhukalov wrote:
 Just a short explanation of Fuel use case.
 
 Fuel use case is not a cloud. 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. We'd like to allow user to choose which hard
 drives to use for root FS, for
 allocating DB. We'd like user to be able to put root FS over LV or MD
 device (including stripe, mirror, multipath).
 We'd like user to be able to choose which hard drives are bootable (if
 any), which options to use for mounting file systems.
 Many many various cases are possible. If you ask why we'd like to support
 all those cases, the answer is simple:
 because our users want us to support all those cases.
 Obviously, many of those cases can not be implemented as image internals,
 some cases can not be also implemented on
 configuration stage (placing root fs on lvm device).
 
 As far as those use cases were rejected to be implemented in term of IPA,
 we implemented so called Fuel Agent.

This is *precisely* why I disagree with adding this driver.

Nearly every feature that is listed here has been talked about before,
within the Ironic community. Software RAID, LVM, user choosing the
partition layout. These were reected from IPA because they do not fit in
*Ironic*, not because they don't fit in IPA.

If the Fuel team can convince enough people that Ironic should be
managing pets, then I'm almost okay with adding this driver (though I
still think adding those features to IPA is the right thing to do).

// jim

 Important Fuel Agent features are:
 
 * It does not have REST API
 * it has executable entry point[s]
 * It uses local json file as it's input
 * It is planned to implement ability to download input data via HTTP (kind
 of metadata service)
 * It is designed to be agnostic to input data format, not only Fuel format
 (data drivers)
 * It is designed to be agnostic to image format (tar images, file system
 images, disk images, currently fs images)
 * It is designed to be agnostic to image compression algorithm (currently
 gzip)
 * It is designed to be agnostic to image downloading protocol (currently
 local file and HTTP link)
 
 So, it is clear that being motivated by Fuel, Fuel Agent is quite
 independent and generic. And we are open for
 new use cases.
 
 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. Frankly, we can implement power/TFTP/DHCP
 management tool independently, but as Devananda said, we're all working on
 the same problems,
 so let's do it together.  Power/TFTP/DHCP management is where we are
 working on the same problems,
 but IPA and Fuel Agent are about different use cases. This case is not just
 Fuel, any mature
 deployment case require advanced partition/fs management. However, for me
 it is OK, if it is easily possible
 to use Ironic with external drivers (not merged to Ironic and not tested on
 Ironic CI).
 
 AFAIU, this spec https://review.openstack.org/#/c/138115/ does not assume
 changing Ironic API and core.
 Jim asked about how Fuel Agent will know about advanced disk partitioning
 scheme if API is not
 changed. The answer is simple: Ironic is supposed to send a link to
 metadata service (http or local file)
 where Fuel Agent can download input json data.
 
 As Roman said, we try to be pragmatic and suggest something which does not
 break anything. All changes
 are supposed to be encapsulated into a driver. No API and core changes. We
 have resources to support, test
 and improve this driver. This spec is just a zero step. Further steps are
 supposed to improve driver
 so as to make it closer to Ironic abstractions.
 
 For Ironic that means widening use cases and user community. But, as I
 already said,
 we are OK if Ironic does not need this feature.
 
 Vladimir Kozhukalov
 
 On Tue, Dec 9, 2014 at 1:09 PM, Roman Prykhodchenko 
 rprikhodche...@mirantis.com wrote:
 
  It is true that IPA and FuelAgent share a lot of functionality in common.
  However there is a major difference between them which is that they are
  intended to be used to solve a different problem.
 
  IPA is a solution for 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Yuriy Zveryanskyy

On 12/09/2014 05:00 PM, Jim Rollenhagen wrote:

On Tue, Dec 09, 2014 at 04:01:07PM +0400, Vladimir Kozhukalov wrote:

Just a short explanation of Fuel use case.

Fuel use case is not a cloud. 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. We'd like to allow user to choose which hard
drives to use for root FS, for
allocating DB. We'd like user to be able to put root FS over LV or MD
device (including stripe, mirror, multipath).
We'd like user to be able to choose which hard drives are bootable (if
any), which options to use for mounting file systems.
Many many various cases are possible. If you ask why we'd like to support
all those cases, the answer is simple:
because our users want us to support all those cases.
Obviously, many of those cases can not be implemented as image internals,
some cases can not be also implemented on
configuration stage (placing root fs on lvm device).

As far as those use cases were rejected to be implemented in term of IPA,
we implemented so called Fuel Agent.

This is *precisely* why I disagree with adding this driver.

Nearly every feature that is listed here has been talked about before,
within the Ironic community. Software RAID, LVM, user choosing the
partition layout. These were reected from IPA because they do not fit in
*Ironic*, not because they don't fit in IPA.


Yes, they do not fit in Ironic *core* but this is a *driver*.
There is iLO driver for example. Good or bad is iLO management technology?
I don't know. But it is an existing vendor's solution. I should buy or rent
HP server for tests or experiments with iLO driver. Fuel is widely used
solution for deployment, and it is open-source. I think to have Fuel Agent
driver in Ironic will be better than driver for rare hardware XYZ for
example.


If the Fuel team can convince enough people that Ironic should be
managing pets, then I'm almost okay with adding this driver (though I
still think adding those features to IPA is the right thing to do).

// jim


Important Fuel Agent features are:

* It does not have REST API
* it has executable entry point[s]
* It uses local json file as it's input
* It is planned to implement ability to download input data via HTTP (kind
of metadata service)
* It is designed to be agnostic to input data format, not only Fuel format
(data drivers)
* It is designed to be agnostic to image format (tar images, file system
images, disk images, currently fs images)
* It is designed to be agnostic to image compression algorithm (currently
gzip)
* It is designed to be agnostic to image downloading protocol (currently
local file and HTTP link)

So, it is clear that being motivated by Fuel, Fuel Agent is quite
independent and generic. And we are open for
new use cases.

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. Frankly, we can implement power/TFTP/DHCP
management tool independently, but as Devananda said, we're all working on
the same problems,
so let's do it together.  Power/TFTP/DHCP management is where we are
working on the same problems,
but IPA and Fuel Agent are about different use cases. This case is not just
Fuel, any mature
deployment case require advanced partition/fs management. However, for me
it is OK, if it is easily possible
to use Ironic with external drivers (not merged to Ironic and not tested on
Ironic CI).

AFAIU, this spec https://review.openstack.org/#/c/138115/ does not assume
changing Ironic API and core.
Jim asked about how Fuel Agent will know about advanced disk partitioning
scheme if API is not
changed. The answer is simple: Ironic is supposed to send a link to
metadata service (http or local file)
where Fuel Agent can download input json data.

As Roman said, we try to be pragmatic and suggest something which does not
break anything. All changes
are supposed to be encapsulated into a driver. No API and core changes. We
have resources to support, test
and improve this driver. This spec is just a zero step. Further steps are
supposed to improve driver
so as to make it closer to Ironic abstractions.

For Ironic that means widening use cases and user community. But, as I
already 

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Vladimir Kozhukalov
We assume next step will be to put provision data (disk partition
 scheme, maybe other data) into driver_info and make Fuel Agent driver
 able to serialize those data (special format) and implement a
 corresponding data driver in Fuel Agent for this format. Again very
 simple. Maybe it is time to think of having Ironic metadata service
 (just maybe).


I'm ok with the format, my question is: what and how is going to collect
 all the data and put into say driver_info?


Fuel has a web service which stores nodes info in its database. When user
clicks Deploy button, this web service serializes deployment task and
puts this task into task runner (another Fuel component). Then this task
runner parses task and adds a node into Ironic via REST API (including
driver_info). Then it calls Ironic deploy method and Ironic uses Fuel Agent
driver to deploy a node. Corresponding Fuel spec is here
https://review.openstack.org/#/c/138301/. Again it is zero step
implementation.


Honestly, I think writing roadmap right now is not very rational as far as
 I am not even sure people are interested in widening Ironic use cases. Some
 of the comments were not even constructive like I don't understand what
 your use case is, please use IPA.



 Please don't be offended by this. We did put a lot of effort into IPA and
 it's reasonable to look for a good use cases before having one more smart
 ramdisk. Nothing personal, just estimating cost vs value :)
 Also why not use IPA is a fair question for me and the answer is about
 use cases (as you stated it before), not about missing features of IPA,
 right?


You are right it is a fair question, and answer is exactly about *missing
features*.


Nova is not our case. Fuel is totally about deployment. There is some in
 common


Here when we have a difficult point. Major use case for Ironic is to be
 driven by Nova (and assisted by Neutron). Without these two it's hard to
 understand how Fuel Agent is going to fit into the infrastructure. And
 hence my question above about where your json comes from. In the current
 Ironic world the same data is received partly from Nova flavor, partly
 managed by Neutron completely.
 I'm not saying it can't change - we do want to become more stand-alone.
 E.g. we can do without Neutron right now. I think specifying the source of
 input data for Fuel Agent in the Ironic infrastructure would help a lot
 understand, how well Ironic and Fuel Agent could play together.


According to the information I have, correct me if I'm wrong, Ironic
currently is on the stage of becoming stand-alone service. That is the
reason why this spec has been brought up. Again we need something to manage
power/tftp/dhcp to substitute Cobbler. Ironic looks like a suitable tool,
but we need this driver. We are not going to break anything. We have
resources to test and support this driver. And I can not use IPA *right
now* because it does not have features I need. I can not wait for next half
a year for these features to be implemented. Why can't we add this (Fuel
Agent) driver and then if IPA implements what we need we can switch to IPA.
The only alternative for me right now is to implement my own
power/tftp/dhcp management solution like I did with Fuel Agent when I did
not get approve for including advanced disk partitioning.

Questions are: Is Ironic interested in this use case or not? Is Ironic
interested to get more development resources? The only case when it's
rational for us to spend our resources to develop Ironic is when we get
something back. We are totally pragmatic, we just address our user's wishes
and issues. It is ok for us to use any tool which provides what we need
(IPA, Fuel Agent, any other).

We need advanced disk partitioning and power/tftp/dhcp management by March
2015. Is it possible to get this from Ironic + IPA? I doubt it. Is it
possible to get this form Ironic + Fuel Agent? Yes it is. Is it possible to
get this from Fuel power/tftp/dhcp management + Fuel Agent? Yes it is. So,
I have two options right now: Ironic + Fuel Agent or Fuel power/tftp/dhcp
management + Fuel Agent.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Yuriy Zveryanskyy

Vladimir,
IMO there is more global problem. Anyone who wants to use baremetal deploy
service should resolve problems with power management, PXE/iPXE support,
DHCP, etc. Or he/she can use Ironic. User has his own vision of deploy 
workflow
and features needed for it. He hears from Ironic people: Feature X 
should be

only after release Y or This don't fit in Ironic at all.
Fuel Agent + driver is the answer. I see Fuel Agent + driver as a solution
for anyone who wants custom features.

On 12/09/2014 06:24 PM, Vladimir Kozhukalov wrote:


We assume next step will be to put provision data (disk partition
scheme, maybe other data) into driver_info and make Fuel Agent
driver
able to serialize those data (special format) and implement a
corresponding data driver in Fuel Agent for this format. Again
very
simple. Maybe it is time to think of having Ironic metadata
service
(just maybe).


I'm ok with the format, my question is: what and how is going to
collect all the data and put into say driver_info?


Fuel has a web service which stores nodes info in its database. When 
user clicks Deploy button, this web service serializes deployment 
task and puts this task into task runner (another Fuel component). 
Then this task runner parses task and adds a node into Ironic via REST 
API (including driver_info). Then it calls Ironic deploy method and 
Ironic uses Fuel Agent driver to deploy a node. Corresponding Fuel 
spec is here https://review.openstack.org/#/c/138301/. Again it is 
zero step implementation.



Honestly, I think writing roadmap right now is not very
rational as far as I am not even sure people are interested in
widening Ironic use cases. Some of the comments were not even
constructive like I don't understand what your use case is,
please use IPA.

Please don't be offended by this. We did put a lot of effort into
IPA and it's reasonable to look for a good use cases before having
one more smart ramdisk. Nothing personal, just estimating cost vs
value :)
Also why not use IPA is a fair question for me and the answer is
about use cases (as you stated it before), not about missing
features of IPA, right?

You are right it is a fair question, and answer is exactly about 
*missing features*.


Nova is not our case. Fuel is totally about deployment. There
is some in
common


Here when we have a difficult point. Major use case for Ironic is
to be driven by Nova (and assisted by Neutron). Without these two
it's hard to understand how Fuel Agent is going to fit into the
infrastructure. And hence my question above about where your json
comes from. In the current Ironic world the same data is received
partly from Nova flavor, partly managed by Neutron completely.
I'm not saying it can't change - we do want to become more
stand-alone. E.g. we can do without Neutron right now. I think
specifying the source of input data for Fuel Agent in the Ironic
infrastructure would help a lot understand, how well Ironic and
Fuel Agent could play together.


According to the information I have, correct me if I'm wrong, Ironic 
currently is on the stage of becoming stand-alone service. That is the 
reason why this spec has been brought up. Again we need something to 
manage power/tftp/dhcp to substitute Cobbler. Ironic looks like a 
suitable tool, but we need this driver. We are not going to break 
anything. We have resources to test and support this driver. And I can 
not use IPA *right now* because it does not have features I need. I 
can not wait for next half a year for these features to be 
implemented. Why can't we add this (Fuel Agent) driver and then if IPA 
implements what we need we can switch to IPA. The only alternative for 
me right now is to implement my own power/tftp/dhcp management 
solution like I did with Fuel Agent when I did not get approve for 
including advanced disk partitioning.


Questions are: Is Ironic interested in this use case or not? Is Ironic 
interested to get more development resources? The only case when it's 
rational for us to spend our resources to develop Ironic is when we 
get something back. We are totally pragmatic, we just address our 
user's wishes and issues. It is ok for us to use any tool which 
provides what we need (IPA, Fuel Agent, any other).


We need advanced disk partitioning and power/tftp/dhcp management by 
March 2015. Is it possible to get this from Ironic + IPA? I doubt it. 
Is it possible to get this form Ironic + Fuel Agent? Yes it is. Is it 
possible to get this from Fuel power/tftp/dhcp management + Fuel 
Agent? Yes it is. So, I have two options right now: Ironic + Fuel 
Agent or Fuel power/tftp/dhcp management + Fuel Agent.







___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Fox, Kevin M
We've been interested in Ironic as a replacement for Cobbler for some of our 
systems and have been kicking the tires a bit recently.

While initially I thought this thread was probably another Fuel not playing 
well with the community kind of thing, I'm not thinking that any more. Its 
deeper then that.

Cloud provisioning is great. I really REALLY like it. But one of the things 
that makes it great is the nice, pretty, cute, uniform, standard hardware the 
vm gives the user. Ideally, the physical hardware would behave the same. But, 
“No Battle Plan Survives Contact With the Enemy”.  The sad reality is, most 
hardware is different from each other. Different drivers, different firmware, 
different different different.

One way the cloud enables this isolation is by forcing the cloud admin's to 
install things and deal with the grungy hardware to make the interface nice and 
clean for the user. For example, if you want greater mean time between failures 
of nova compute nodes, you probably use a raid 1. Sure, its kind of a pet kind 
of thing todo, but its up to the cloud admin to decide what's better, buying 
more hardware, or paying for more admin/user time. Extra hard drives are dirt 
cheep...

So, in reality Ironic is playing in a space somewhere between I want to use 
cloud tools to deploy hardware, yay! and ewww.., physical hardware's nasty. 
you have to know all these extra things and do all these extra things that you 
don't have to do with a vm... I believe Ironic's going to need to be able to 
deal with this messiness in as clean a way as possible.  But that's my opinion. 
If the team feels its not a valid use case, then we'll just have to use 
something else for our needs. I really really want to be able to use heat to 
deploy whole physical distributed systems though.

Today, we're using software raid over two disks to deploy our nova compute. 
Why? We have some very old disks we recovered for one of our clouds and they 
fail often. nova-compute is pet enough to benefit somewhat from being able to 
swap out a disk without much effort. If we were to use Ironic to provision the 
compute nodes, we need to support a way to do the same.

We're looking into ways of building an image that has a software raid presetup, 
and expand it on boot. This requires each image to be customized for this case 
though. I can see Fuel not wanting to provide two different sets of images, 
hardware raid and software raid, that have the same contents in them, with 
just different partitioning layouts... If we want users to not have to care 
about partition layout, this is also not ideal...

Assuming Ironic can be convinced that these features really would be needed, 
perhaps the solution is a middle ground between the pxe driver and the agent?

Associate partition information at the flavor level. The admin can decide the 
best partitioning layout for a given hardware... The user doesn't have to care 
any more. Two flavors for the same hardware could be 4 9's or 5 9's or 
something that way.
Modify the agent to support a pxe style image in addition to full layout, and 
have the agent partition/setup raid and lay down the image into it.
Modify the agent to support running grub2 at the end of deployment.

Or at least make the agent plugable to support adding these options.

This does seem a bit backwards from the way the agent has been going. the pxe 
driver was kind of linux specific. the agent is not... So maybe that does imply 
a 3rd driver may be beneficial... But it would be nice to have one driver, the 
agent, in the end that supports everything.

Anyway, some things to think over.

Thanks,
Kevin

From: Jim Rollenhagen [j...@jimrollenhagen.com]
Sent: Tuesday, December 09, 2014 7:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ironic] Fuel agent proposal

On Tue, Dec 09, 2014 at 04:01:07PM +0400, Vladimir Kozhukalov wrote:
 Just a short explanation of Fuel use case.

 Fuel use case is not a cloud. 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. We'd like to allow user to choose which hard
 drives to use for root FS, for
 allocating DB. We'd like user to be able to put root FS over LV or MD
 device (including stripe, mirror, multipath).
 We'd like user to be able to choose which hard

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Vladimir Kozhukalov
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Ironic] Fuel agent proposal

 On Tue, Dec 09, 2014 at 04:01:07PM +0400, Vladimir Kozhukalov wrote:
  Just a short explanation of Fuel use case.
 
  Fuel use case is not a cloud. 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. We'd like to allow user to choose which hard
  drives to use for root FS, for
  allocating DB. We'd like user to be able to put root FS over LV or MD
  device (including stripe, mirror, multipath).
  We'd like user to be able to choose which hard drives are bootable (if
  any), which options to use for mounting file systems.
  Many many various cases are possible. If you ask why we'd like to support
  all those cases, the answer is simple:
  because our users want us to support all those cases.
  Obviously, many of those cases can not be implemented as image internals,
  some cases can not be also implemented on
  configuration stage (placing root fs on lvm device).
 
  As far as those use cases were rejected to be implemented in term of IPA,
  we implemented so called Fuel Agent.

 This is *precisely* why I disagree with adding this driver.

 Nearly every feature that is listed here has been talked about before,
 within the Ironic community. Software RAID, LVM, user choosing the
 partition layout. These were reected from IPA because they do not fit in
 *Ironic*, not because they don't fit in IPA.

 If the Fuel team can convince enough people that Ironic should be
 managing pets, then I'm almost okay with adding this driver (though I
 still think adding those features to IPA is the right thing to do).

 // jim

  Important Fuel Agent features are:
 
  * It does not have REST API
  * it has executable entry point[s]
  * It uses local json file as it's input
  * It is planned to implement ability to download input data via HTTP
 (kind
  of metadata service)
  * It is designed to be agnostic to input data format, not only Fuel
 format
  (data drivers)
  * It is designed to be agnostic to image format (tar images, file system
  images, disk images, currently fs images)
  * It is designed to be agnostic to image compression algorithm (currently
  gzip)
  * It is designed to be agnostic to image downloading protocol (currently
  local file and HTTP link)
 
  So, it is clear that being motivated by Fuel, Fuel Agent is quite
  independent and generic. And we are open for
  new use cases.
 
  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. Frankly, we can implement
 power/TFTP/DHCP
  management tool independently, but as Devananda said, we're all working
 on
  the same problems,
  so let's do it together.  Power/TFTP/DHCP management is where we are
  working on the same problems,
  but IPA and Fuel Agent are about different use cases. This case is not
 just
  Fuel, any mature
  deployment case require advanced partition/fs management. However, for me
  it is OK, if it is easily possible
  to use Ironic with external drivers (not merged to Ironic and not tested
 on
  Ironic CI).
 
  AFAIU, this spec https://review.openstack.org/#/c/138115/ does not
 assume
  changing Ironic API and core.
  Jim asked about how Fuel Agent will know about advanced disk partitioning
  scheme if API is not
  changed. The answer is simple: Ironic is supposed to send a link to
  metadata service (http or local file)
  where Fuel Agent can download input json data.
 
  As Roman said, we try to be pragmatic and suggest something which does
 not
  break anything. All changes
  are supposed to be encapsulated into a driver. No API and core changes.
 We
  have resources to support, test
  and improve this driver. This spec is just a zero step. Further steps are
  supposed to improve driver
  so as to make it closer to Ironic abstractions.
 
  For Ironic that means widening use cases and user community. But, as I
  already said,
  we are OK if Ironic does not need this feature.
 
  Vladimir Kozhukalov
 
  On Tue, Dec 9, 2014 at 1:09 PM, Roman Prykhodchenko 
  rprikhodche...@mirantis.com wrote:
 
   It is true that IPA

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Clint Byrum
Excerpts from Yuriy Zveryanskyy's message of 2014-12-09 04:05:03 -0800:
 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?

I surely hope it is.

 Yes, it is I think. IPA is the great software, but Fuel Agent proposes a 
 different and alternative way for deploying.

It's not fundamentally different, it is just capable of other things.

 Devananda wrote about pets and cattle, and maybe some want to manage 
 pets rather than cattle? Let
 users do a choice.

IMO this is too high-level of a discussion for Ironic to get bogged
down in. Disks can have partitions and be hosted in RAID controllers,
and these things _MUST_ come before an OS is put on the disks, but after
power control happens. Since Ironic does put OS's on disks, and control
power, I believe it is obligated to provide an interface for rich disk
configuration.

There are valid use cases for _both_ of those things in cattle, which
is a higher level problem that should not cloud the low level interface
discussion.

So IMO, Ironic needs to provide an interface for agents to richly
configure disks, whether IPA supports it or not.

Would I like to see these things in IPA so that there isn't a mismatch
of features? Yes. Does that matter _now_? Not really. The FuelAgent can
prove out the interface while the features migrate into IPA.

 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).
 

We have a _hyperv_ driver in Nova.. I think we can have a something
we're not entirely 100% on board with in Ironic.

All of that said, I would admonish FuelAgent developers to work to
commit to combine their agent with IPA long term. I would admonish Ironic
developers to be receptive to things that users want. It doesn't always
mean taking responsibility for implementations, but you _do_ need to
consider the pain of not providing interfaces and of forcing people to
remain out of tree (remember when Ironic's driver wasn't in Nova's tree?)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Devananda van der Veen
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

Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Devananda van der Veen
On Tue Dec 09 2014 at 7:49:32 AM Yuriy Zveryanskyy 
yzveryans...@mirantis.com wrote:

 On 12/09/2014 05:00 PM, Jim Rollenhagen wrote:
  On Tue, Dec 09, 2014 at 04:01:07PM +0400, Vladimir Kozhukalov wrote:

  Many many various cases are possible. If you ask why we'd like to
 support
  all those cases, the answer is simple:
  because our users want us to support all those cases.
  Obviously, many of those cases can not be implemented as image
 internals,
  some cases can not be also implemented on
  configuration stage (placing root fs on lvm device).
 
  As far as those use cases were rejected to be implemented in term of
 IPA,
  we implemented so called Fuel Agent.
  This is *precisely* why I disagree with adding this driver.
 
  Nearly every feature that is listed here has been talked about before,
  within the Ironic community. Software RAID, LVM, user choosing the
  partition layout. These were reected from IPA because they do not fit in
  *Ironic*, not because they don't fit in IPA.

 Yes, they do not fit in Ironic *core* but this is a *driver*.
 There is iLO driver for example. Good or bad is iLO management technology?
 I don't know. But it is an existing vendor's solution. I should buy or rent
 HP server for tests or experiments with iLO driver. Fuel is widely used
 solution for deployment, and it is open-source. I think to have Fuel Agent
 driver in Ironic will be better than driver for rare hardware XYZ for
 example.


This argument is completely hollow. Fuel is not a vendor-specific
hardware-enablement driver. It *is* an open-source deployment driver
providing much the same functionality as another open-source deployment
driver which is already integrated with the project.

To make my point another way, could I use Fuel with HP iLO driver? (the
answer should be yes because they fill different roles within Ironic).
But, on the other hand, could I use Fuel with the IPA driver? (nope -
definitely not - they do the same thing.)

-Deva
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Devananda van der Veen
On Tue Dec 09 2014 at 10:13:52 AM Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:

 Kevin,

 Just to make sure everyone understands what Fuel Agent is about. Fuel
 Agent is agnostic to image format. There are 3 possibilities for image
 format
 1) DISK IMAGE contains GPT/MBR table and all partitions and metadata in
 case of md or lvm. That is just something like what you get when run 'dd
 if=/dev/sda of=disk_image.raw'


This is what IPA driver does today.


 2) FS IMAGE contains fs. Disk contains some partitions which then could be
 used to create md device or volume group contains logical volumes. We then
 can put a file system over plain partition or md device or logical volume.
 This type of image is what you get when run 'dd if=/dev/sdaN
 of=fs_image.raw'


This is what PXE driver does today, but it does so over a remote iSCSI
connection.

Work is being done to add support for this to IPA [0]


 3) TAR IMAGE contains files. It is when you run 'tar cf tar_image.tar /'

 Currently in Fuel we use FS images. Fuel Agent creates partitions, md and
 lvm devices and then downloads FS images and put them on partition devices
 (/dev/sdaN) or on lvm device (/dev/mapper/vgname/lvname) or md device
 (/dev/md0)


I believe the IPA team would welcome contributions that add support for
software RAID for the root partition.


 Fuel Agent is also able to install and configure grub.


Again, I think this would be welcomed by the IPA team...

If this is what FuelAgent is about, why is there so much resistance to
contributing that functionality to the component which is already
integrated with Ironic? Why complicate matters for both users and
developers by adding *another* deploy agent that does (or will soon do) the
same things?

-Deva

[0]
https://blueprints.launchpad.net/ironic/+spec/partition-image-support-for-agent-driver
https://review.openstack.org/137363
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ironic] Fuel agent proposal

2014-12-09 Thread Devananda van der Veen
On Tue Dec 09 2014 at 9:45:51 AM Fox, Kevin M kevin@pnnl.gov wrote:

 We've been interested in Ironic as a replacement for Cobbler for some of
 our systems and have been kicking the tires a bit recently.

 While initially I thought this thread was probably another Fuel not
 playing well with the community kind of thing, I'm not thinking that any
 more. Its deeper then that.


There are aspects to both conversations here, and you raise many valid
points.

Cloud provisioning is great. I really REALLY like it. But one of the things
 that makes it great is the nice, pretty, cute, uniform, standard hardware
 the vm gives the user. Ideally, the physical hardware would behave the
 same. But,
 “No Battle Plan Survives Contact With the Enemy”.  The sad reality is,
 most hardware is different from each other. Different drivers, different
 firmware, different different different.


Indeed, hardware is different. And no matter how homogeneous you *think* it
is, at some point, some hardware is going to fail^D^D^Dbehave differently
than some other piece of hardware.

One of the primary goals of Ironic is to provide a common *abstraction* to
all the vendor differences, driver differences, and hardware differences.
There's no magic in that -- underneath the covers, each driver is going to
have to deal with the unpleasant realities of actual hardware that is
actually different.


 One way the cloud enables this isolation is by forcing the cloud admin's
 to install things and deal with the grungy hardware to make the interface
 nice and clean for the user. For example, if you want greater mean time
 between failures of nova compute nodes, you probably use a raid 1. Sure,
 its kind of a pet kind of thing todo, but its up to the cloud admin to
 decide what's better, buying more hardware, or paying for more admin/user
 time. Extra hard drives are dirt cheep...

 So, in reality Ironic is playing in a space somewhere between I want to
 use cloud tools to deploy hardware, yay! and ewww.., physical hardware's
 nasty. you have to know all these extra things and do all these extra
 things that you don't have to do with a vm... I believe Ironic's going to
 need to be able to deal with this messiness in as clean a way as possible.


If by clean you mean, expose a common abstraction on top of all those
messy differences -- then we're on the same page. I would welcome any
feedback as to where that abstraction leaks today, and on both spec and
code reviews that would degrade or violate that abstraction layer. I think
it is one of, if not *the*, defining characteristic of the project.


 But that's my opinion. If the team feels its not a valid use case, then
 we'll just have to use something else for our needs. I really really want
 to be able to use heat to deploy whole physical distributed systems though.

 Today, we're using software raid over two disks to deploy our nova
 compute. Why? We have some very old disks we recovered for one of our
 clouds and they fail often. nova-compute is pet enough to benefit somewhat
 from being able to swap out a disk without much effort. If we were to use
 Ironic to provision the compute nodes, we need to support a way to do the
 same.


I have made the (apparently incorrect) assumption that anyone running
anything sensitive to disk failures in production would naturally have a
hardware RAID, and that, therefor, Ironic should be capable of setting up
that RAID in accordance with a description in the Nova flavor metadata --
but did not need to be concerned with software RAIDs.

Clearly, there are several folks who have the same use-case in mind, but do
not have hardware RAID cards in their servers, so my initial assumption was
incorrect :)

I'm fairly sure that the IPA team would welcome contributions to this
effect.

We're looking into ways of building an image that has a software raid
 presetup, and expand it on boot.


Awesome! I hope that work will make its way into diskimage-builder ;)

(As an aside, I suggested this to the Fuel team back in Atlanta...)


 This requires each image to be customized for this case though. I can see
 Fuel not wanting to provide two different sets of images, hardware raid
 and software raid, that have the same contents in them, with just
 different partitioning layouts... If we want users to not have to care
 about partition layout, this is also not ideal...


End-users are probably not generating their own images for bare metal
(unless user == operator, in which case, it should be fine).


 Assuming Ironic can be convinced that these features really would be
 needed, perhaps the solution is a middle ground between the pxe driver and
 the agent?


I've been rallying for a convergence between the feature sets of these
drivers -- specifically, that the agent should support partition-based
images, and also support copy-over-iscsi as a deployment model. In
parallel, Lucas had started working on splitting the deploy interface into
both boot and deploy, which point we