Open Stack

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/4805f24e/attachment.html>