On Tue, Mar 1, 2016 at 2:14 PM, Sean Dague <s...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Juan Antonio Osorio R. e-mail: jaosor...@gmail.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev