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