Open Stack

On 03/02/2016 03:01 AM, Juan Antonio Osorio wrote:
> 
> 
> On Tue, Mar 1, 2016 at 2:14 PM, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
> 
>     On 02/29/2016 05:23 PM, Matt Riedemann 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'm not sure that's really true. As a team we have to decide we're going
>     to deprecate or document this facility. The status quo is really not a
>     thing.
> 
> 
> I'm not sure what you mean by status quo, it's just asking the actual
> users of
> the software what they think and if this will affect their implementations.
>  
> 
> 
>     So unless we've got folks that believe we should crystalize this
>     interface, and are signing up for doing that (which means you can't
>     change build_instance internal function parameters ever), then I think
>     it's fine to deprecate. We can measure our removal timeframe based on
>     reaction to that.
> 
> 
> So then, would it be acceptable to come up with a blueprint trying to
> formalize
> the interfaces for the hooks, and make those standard (and better tested and
> documented)? We could base the deprecation on the outcome of that blueprint.
> 
> I think everybody agrees that the current solution is not ideal, but I
> think it covers
> a valid use-case.

I think the sentiment is pretty clear that formalizing hooks is not the
right way forward. The specific feature you are looking for should come
in via a nova-spec.

	-Sean

-- 
Sean Dague
http://dague.net