Open Stack

On Tue, Mar 1, 2016 at 12:23 AM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

>
>
> 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.


I agree with Matt, I think this should get more visibility with the
operators first before deprecating it.


>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosorior at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160301/5609f134/attachment.html>