[Openstack-operators] Anyone else use vendordata_driver in nova.conf?

David Medberry openstack at medberry.net
Mon Apr 18 14:17:03 UTC 2016


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 <openstack at 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) <
> erhudy at 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: jaypipes at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160418/69503789/attachment.html>


More information about the OpenStack-operators mailing list