Open Stack

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 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/145fc413/attachment.html>