So, after a series of hallway track chats this week, I wrote this:
https://review.openstack.org/#/c/310904/
Which is a proposal for how to implement vendordata in a way which would
(probably) be acceptable to nova, whilst also meeting the needs of
operators. I should reinforce that because this week is so hectic nova core
hasn't really talked about this yet, but I am pretty sure I understand and
have addressed Sean's concerns.
I'd be curious as to if the proposed solution actually meets your needs.
Michael
On Mon, Apr 18, 2016 at 10:55 AM, Fox, Kevin M <kevin....@pnnl.gov> wrote:
> 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 [openst...@medberry.net]
> *Sent:* Monday, April 18, 2016 7:16 AM
> *To:* Ned Rhudy
> *Cc:* openstack-operators@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) <
> 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
>
>
--
Rackspace Australia
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
