<html><head><title></title></head><body><!-- rte-version 0.2 9947551637294008b77bce25eb683dac --><div class="rte-style-maintainer" style="white-space: pre-wrap; font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);"data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width">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.<br><div class="rte-style-maintainer" style="font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);"data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><br><div class="bbg-rte-fold-content" data-header="From: sean@dague.net At: Apr 18 2016 10:34:24" data-digest="From: sean@dague.net At: Apr 18 2016 10:34:24" style=""><div class="bbg-rte-fold-summary">From: sean@dague.net At: Apr 18 2016 10:34:24</div><div>Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?<br></div></div><blockquote>On 04/18/2016 10:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:<br>> Requiring users to remember to pass specific userdata through to their<br>> instance at every launch in order to replace functionality that<br>> currently works invisible to them would be a step backwards. It's an<br>> alternative, yes, but it's an alternative that adds burden to our users<br>> and is not one we would pursue.<br>> <br>> What is the rationale for desiring to remove this functionality?<br><br>The Nova team would like to remove every config option that specifies an<br>arbitrary out of tree class file at a function point. This has been the<br>sentiment for a while and we did a wave of deprecations at the end of<br>Mitaka to signal this more broadly, because as an arbitrary class loader<br>it completely impossible to even understand who might be using it and how.<br><br>These interfaces are not considered stable or contractual, so exposing<br>them as raw class loader is something that we want to stop doing, as<br>we're going to horribly break people at some point. It's fine if there<br>are multiple implementations for these things, however those should all<br>be upstream, and selected by a symbolic name CONF option.<br><br>One of the alternatives is to propose your solution upstream.<br><br> -Sean<br><br>-- <br>Sean Dague<br><a bbg-destination="rte:bind"spellcheck="false" href="http://dague.net" data-destination="rte:bind">http://dague.net</a><br><br>_______________________________________________<br>OpenStack-operators mailing list<br><a spellcheck="false"bbg-destination="mailto:rte:bind" href="mailto:OpenStack-operators@lists.openstack.org" data-destination="mailto:rte:bind">OpenStack-operators@lists.openstack.org</a><br><a bbg-destination="rte:bind"spellcheck="false" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators"data-destination="rte:bind">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br><br></blockquote></div></div></body></html>