Okay, if I propose something upstream what is it expected to look like? There is apparently a high level of opinionation around exposed class loaders I wasn't aware of, and I don't think there's any one-size-fits-all solution here. If I suggested something like adding additional instance metadata under /openstack/latest/meta_data.json, that might be suitable for us as private cloud operators but pose security risks to public cloud operators. I don't want to propose something that sucks and has Bloomberg pathologies all over it but gets jackhammered in anyway.
From: s...@dague.net At: Apr 18 2016 10:34:24 Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf? On 04/18/2016 10:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote: > Requiring users to remember to pass specific userdata through to their > instance at every launch in order to replace functionality that > currently works invisible to them would be a step backwards. It's an > alternative, yes, but it's an alternative that adds burden to our users > and is not one we would pursue. > > What is the rationale for desiring to remove this functionality? The Nova team would like to remove every config option that specifies an arbitrary out of tree class file at a function point. This has been the sentiment for a while and we did a wave of deprecations at the end of Mitaka to signal this more broadly, because as an arbitrary class loader it completely impossible to even understand who might be using it and how. These interfaces are not considered stable or contractual, so exposing them as raw class loader is something that we want to stop doing, as we're going to horribly break people at some point. It's fine if there are multiple implementations for these things, however those should all be upstream, and selected by a symbolic name CONF option. One of the alternatives is to propose your solution upstream. -Sean -- Sean Dague http://dague.net _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators