<div dir="ltr"><div><br></div>Well it's nice to fix, but I really don't know if we should be fixing it.  As discussed in one of the Ironic meetings before, we might need to define what is our driver API or SDK or DDK or whatever we choose to call it .  Please see inline for my thoughts.<div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 5:54 AM, Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">tldr; the boot / deploy interface split we did broke an out of tree driver. I've proposed a patch. We should get a fix into stable/liberty too.<div><br></div><div>Longer version...</div><div><br></div><div>I was rebasing my AMTTool driver [0] on top of master because the in-tree one still does not work for me, only to discover that my driver suddenly failed to deploy. I have filed this bug</div><div>  <a href="https://bugs.launchpad.net/ironic/+bug/1502980" target="_blank">https://bugs.launchpad.net/ironic/+bug/1502980</a><br></div><div>because we broke at least one out of tree driver (mine). I highly suspect we've broken many other out of tree drivers that relied on either the PXEDeploy or AgentDeploy interfaces that were present in Kilo release. Both classes in Liberty are making explicit calls to "task.driver.boot" -- and kilo-era driver classes did not define this interface.</div></div></blockquote><div><br></div><div><br></div><div>I would like to think more about what really our driver API is ? We have a couple of well defined interfaces in ironic/drivers/base.py which people may follow, implement an out-of-tree driver, make it a stevedore entrypoint and get it working with Ironic. </div><div><br></div><div>But </div><div><br></div><div>1) Do we promise them that in-tree implementations of these interfaces will always exist.  For example in boot/deploy work done in Liberty, we removed the class PxeDeploy [1].  It actually got broken down to PXEBoot and ISCSIDeploy.  In the first place, do we guarantee that they will exist for ever in the same place with the same name ? :)<br></div><div><br></div><div>2) Do we really promise the in-tree implementations of these interfaces will behave the same way ? For example, the broken stuff AgentDeploy which is an implementation of our DeployInterface.  Do we guarantee that this implementation will always keep doing what ever it was every time code is rebased ?</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/166513/19/ironic/drivers/modules/pxe.py">https://review.openstack.org/#/c/166513/19/ironic/drivers/modules/pxe.py</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I worked out a patch for the AgentDeploy driver and have proposed it here:</div><div>  <a href="https://review.openstack.org/#/c/231215/1" target="_blank">https://review.openstack.org/#/c/231215/1</a></div><div><br></div><div>I'd like to ask folks to review it quickly -- we should fix this ASAP and backport it to stable/liberty before the next release, if possible. We should also make a similar fix for the PXEDeploy class. If anyone gets to this before I do, please reply here and let me know so we don't duplicate effort.</div></div></blockquote><div><br></div><div><br></div><div>This isn't going to be as same as above as there is no longer a PXEDeploy class any more.  We might need to create a new class PXEDeploy which probably inherits from ISCSIDeploy and has task.driver.boot worked around in the same way as the above patch.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Also, Jim already spotted something in the review that is a bit concerning. It seems like the IloVirtualMediaAgentVendorInterface class expects the driver it is attached to *not* to have a boot interface and *not* to call boot.clean_up_ramdisk. Conversely, other drivers may be expecting AgentVendorInterface to call boot.clean_up_ramdisk -- since that was its default behavior in Kilo. I'm not sure what the right way to fix this is, but I lean towards updating the in-tree driver so we remain backwards-compatible for out of tree drivers.</div><div><br></div><div><br></div><div>-Devananda<br></div><div><br></div><div>[0] <a href="https://github.com/devananda/ironic/tree/new-amt-driver" target="_blank">https://github.com/devananda/ironic/tree/new-amt-driver</a></div><div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>