<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">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 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: jaypipes@gmail.com" data-digest="From: jaypipes@gmail.com"style=""><div class="bbg-rte-fold-summary">From: jaypipes@gmail.com </div><div>Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?<br></div></div><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 bbg-destination="rte:bind"spellcheck="false" href="https://review.openstack.org/#/c/288107/"data-destination="rte:bind">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 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></blockquote><br></div></div></div></body></html>