<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 1, 2016 at 2:14 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 02/29/2016 05:23 PM, Matt Riedemann wrote:<br>
><br>
><br>
> On 2/29/2016 2:54 PM, Sean Dague wrote:<br>
>> On 02/29/2016 11:59 AM, Sean Dague wrote:<br>
>>> The nova/hooks.py infrastructure has been with us since early Nova. It's<br>
>>> currently only annotated on a few locations - 'build_instance',<br>
>>> 'create_instance', 'delete_instance', and 'instance_network_info'. It's<br>
>>> got a couple of unit tests on it, but nothing that actually tests real<br>
>>> behavior of the hooks we have specified.<br>
>>><br>
>>> It does get used in the wild, and we do break it with changes we didn't<br>
>>> ever anticipate would impact it -<br>
>>> <a href="https://bugs.launchpad.net/nova/+bug/1518321" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1518321</a><br>
>>><br>
>>> However, when you look into how that is used, it's really really odd and<br>
>>> fragile -<br>
>>> <a href="https://github.com/richm/rdo-vm-factory/blob/master/rdo-ipa-nova/novahooks.py#L248" rel="noreferrer" target="_blank">https://github.com/richm/rdo-vm-factory/blob/master/rdo-ipa-nova/novahooks.py#L248</a><br>
>>><br>
>>><br>
>>><br>
>>>      def pre(self, *args, **kwargs):<br>
>>>          # args[7] is the injected_files parameter array<br>
>>>          # the value is ('filename', 'base64 encoded contents')<br>
>>>          ipaotp = str(uuid.uuid4())<br>
>>>          ipainject = ('/tmp/ipaotp', base64.b64encode(ipaotp))<br>
>>>          args[7].extend(self.inject_files)<br>
>>>          args[7].append(ipainject)<br>
>>><br>
>>> In our continued quest on being more explicit about plug points it feels<br>
>>> like we should other document the interface (which means creating<br>
>>> stability on the hook parameters) or we should deprecate this construct<br>
>>> as part of a bygone era.<br>
>>><br>
>>> I lean on deprecation because it feels like a thing we don't really want<br>
>>> to support going forward, but I can go either way.<br>
>>><br>
>>>     -Sean<br>
>>><br>
>>> P.S. I'm starting to look at in tree functional testing for all of this,<br>
>>> in the event that we decide not to deprecate it. It's definitely made a<br>
>>> little hard by the way all exceptions are caught when hooks go wrong.<br>
>><br>
>> As there seemed to be some early enthusiasm for this from the core team,<br>
>> the deprecation patch is proposed here -<br>
>> <a href="https://review.openstack.org/#/c/286276/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/286276/</a><br>
>><br>
>> Unless there is a big reversal of sentiment I'd suggest we get that<br>
>> landed in Mitaka so that this is signalled to people going forward, and<br>
>> we can collect use cases for things that are currently using hooks that<br>
>> we may want to support in other ways in Newton.<br>
>><br>
>>     -Sean<br>
>><br>
><br>
> I think you should probably also post this to the operators mailing list<br>
> before we actually deprecate hooks.<br>
<br>
</div></div>I'm not sure that's really true. As a team we have to decide we're going<br>
to deprecate or document this facility. The status quo is really not a<br>
thing.<br></blockquote><div><br></div><div>I'm not sure what you mean by status quo, it's just asking the actual users of<br>the software what they think and if this will affect their implementations.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So unless we've got folks that believe we should crystalize this<br>
interface, and are signing up for doing that (which means you can't<br>
change build_instance internal function parameters ever), then I think<br>
it's fine to deprecate. We can measure our removal timeframe based on<br>
reaction to that.<br></blockquote><div><br></div><div>So then, would it be acceptable to come up with a blueprint trying to formalize<br>the interfaces for the hooks, and make those standard (and better tested and<br>documented)? We could base the deprecation on the outcome of that blueprint.<br><br></div><div>I think everybody agrees that the current solution is not ideal, but I think it covers<br>a valid use-case.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="im HOEnZb"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2">Juan Antonio Osorio R.<br>e-mail: <a href="mailto:jaosorior@gmail.com" target="_blank">jaosorior@gmail.com</a><br></font><font style="font-family:arial narrow,sans-serif;color:rgb(102,102,102)" size="2"><br></font></div></div></div>
</div></div>