Open Stack

On 2/29/2016 2:54 PM, Sean Dague wrote:
> On 02/29/2016 11:59 AM, Sean Dague wrote:
>> The nova/hooks.py infrastructure has been with us since early Nova. It's
>> currently only annotated on a few locations - 'build_instance',
>> 'create_instance', 'delete_instance', and 'instance_network_info'. It's
>> got a couple of unit tests on it, but nothing that actually tests real
>> behavior of the hooks we have specified.
>>
>> It does get used in the wild, and we do break it with changes we didn't
>> ever anticipate would impact it -
>> https://bugs.launchpad.net/nova/+bug/1518321
>>
>> However, when you look into how that is used, it's really really odd and
>> fragile -
>> https://github.com/richm/rdo-vm-factory/blob/master/rdo-ipa-nova/novahooks.py#L248
>>
>>
>>      def pre(self, *args, **kwargs):
>>          # args[7] is the injected_files parameter array
>>          # the value is ('filename', 'base64 encoded contents')
>>          ipaotp = str(uuid.uuid4())
>>          ipainject = ('/tmp/ipaotp', base64.b64encode(ipaotp))
>>          args[7].extend(self.inject_files)
>>          args[7].append(ipainject)
>>
>> In our continued quest on being more explicit about plug points it feels
>> like we should other document the interface (which means creating
>> stability on the hook parameters) or we should deprecate this construct
>> as part of a bygone era.
>>
>> I lean on deprecation because it feels like a thing we don't really want
>> to support going forward, but I can go either way.
>>
>> 	-Sean
>>
>> P.S. I'm starting to look at in tree functional testing for all of this,
>> in the event that we decide not to deprecate it. It's definitely made a
>> little hard by the way all exceptions are caught when hooks go wrong.
>
> As there seemed to be some early enthusiasm for this from the core team,
> the deprecation patch is proposed here -
> https://review.openstack.org/#/c/286276/
>
> Unless there is a big reversal of sentiment I'd suggest we get that
> landed in Mitaka so that this is signalled to people going forward, and
> we can collect use cases for things that are currently using hooks that
> we may want to support in other ways in Newton.
>
> 	-Sean
>

I think you should probably also post this to the operators mailing list 
before we actually deprecate hooks.

-- 

Thanks,

Matt Riedemann