Open Stack

We've used it too to work around the lack of instance users in nova. Please keep it until a viable solution can be reached.

Thanks,
Kevin
________________________________
From: David Medberry [openstack at medberry.net]
Sent: Monday, April 18, 2016 7:16 AM
To: Ned Rhudy
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?

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<mailto: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<mailto: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<mailto: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<mailto: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/c119e719/attachment.html>