Open Stack

On Tue, Mar 1, 2016 at 2:14 PM, Sean Dague <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.


>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> 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/20160302/39ddc58c/attachment.html>