<div dir="ltr">Hi Ned, Jay,<div><br></div><div>We use it also and I have to agree, it's onerous to require users to add that functionality back in. Where was this discussed?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 8:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) <span dir="ltr"><<a href="mailto:erhudy@bloomberg.net" target="_blank">erhudy@bloomberg.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="white-space:pre-wrap;font-size:small;font-family:'Courier New',Courier;color:rgb(0,0,0)">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.<div><br></div><div>What is the rationale for desiring to remove this functionality?<br><div style="font-size:small;font-family:'Courier New',Courier;color:rgb(0,0,0)"><br><div><div>From: <a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a> </div><div>Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?<br></div></div><div><div class="h5"><blockquote>On 04/18/2016 09:24 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:<br>> I noticed while reading through Mitaka release notes that<br>> vendordata_driver has been deprecated in Mitaka<br>> (<a href="https://review.openstack.org/#/c/288107/" target="_blank">https://review.openstack.org/#/c/288107/</a>) and is slated for removal at<br>> some point. This came as somewhat of a surprise to me - I searched<br>> openstack-dev for vendordata-related subject lines going back to January<br>> and found no discussion on the matter (IRC logs, while available on<br>> eavesdrop, are not trivially searchable without a little scripting to<br>> fetch them first, so I didn't check there yet).<br>><br>> We at Bloomberg make heavy use of this particular feature to inject<br>> dynamically generated JSON into the metadata service of instances; the<br>> content of the JSON differs depending on the instance making the request<br>> to the metadata service. The functionality that adds the contents of a<br>> static JSON file, while remaining around, is not suitable for our use case.<br>><br>> Please let me know if you use vendordata_driver so that I/we can present<br>> an organized case for why this option or equivalent functionality needs<br>> to remain around. The alternative is that we end up patching the<br>> vendordata driver directly in Nova when we move to Mitaka, which I'd<br>> like to avoid; as a matter of principle I would rather see more<br>> classloader overrides, not fewer.<br><br>Wouldn't an alternative be to use something like Chef, Puppet, Ansible, <br>Saltstack, etc and their associated config variable storage services <br>like Hiera or something similar to publish custom metadata? That way, <br>all you need to pass to your instance (via userdata) is a URI or <br>connection string and some auth details for your config storage service <br>and the instance can grab whatever you need.<br><br>Thoughts?<br>-jay<br><br>_______________________________________________<br>OpenStack-operators mailing list<br><a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br></blockquote><br></div></div></div></div></div></div><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div>