Ah, read the bug, we are using the default, not a custom driver. so NEVERMIND.
On Mon, Apr 18, 2016 at 8:16 AM, David Medberry <openst...@medberry.net> wrote: > Hi Ned, Jay, > > 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? > > On Mon, Apr 18, 2016 at 8:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) < > erh...@bloomberg.net> 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? >> >> From: jaypi...@gmail.com >> Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in >> nova.conf? >> >> On 04/18/2016 09:24 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote: >> > I noticed while reading through Mitaka release notes that >> > vendordata_driver has been deprecated in Mitaka >> > (https://review.openstack.org/#/c/288107/) and is slated for removal at >> > some point. This came as somewhat of a surprise to me - I searched >> > openstack-dev for vendordata-related subject lines going back to January >> > and found no discussion on the matter (IRC logs, while available on >> > eavesdrop, are not trivially searchable without a little scripting to >> > fetch them first, so I didn't check there yet). >> > >> > We at Bloomberg make heavy use of this particular feature to inject >> > dynamically generated JSON into the metadata service of instances; the >> > content of the JSON differs depending on the instance making the request >> > to the metadata service. The functionality that adds the contents of a >> > static JSON file, while remaining around, is not suitable for our use >> case. >> > >> > Please let me know if you use vendordata_driver so that I/we can present >> > an organized case for why this option or equivalent functionality needs >> > to remain around. The alternative is that we end up patching the >> > vendordata driver directly in Nova when we move to Mitaka, which I'd >> > like to avoid; as a matter of principle I would rather see more >> > classloader overrides, not fewer. >> >> Wouldn't an alternative be to use something like Chef, Puppet, Ansible, >> Saltstack, etc and their associated config variable storage services >> like Hiera or something similar to publish custom metadata? That way, >> all you need to pass to your instance (via userdata) is a URI or >> connection string and some auth details for your config storage service >> and the instance can grab whatever you need. >> >> Thoughts? >> -jay >> >> _______________________________________________ >> 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 >> >> >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators