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 OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev