<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Depends on what its used for... I can see it potentially being used with Chef or Puppet, for calling hooks into AD to bind to a domain. etc. Probably at the same time. We use it
with our keyserver (something similar to Barbican but created before Barbican was a thing) to relay trust info between Nova and the Keyserver through the Instance.<br>
<br>
I've done some careful inheriting of our vendor_data plug-in to get all the features in one plugin, but I could see it being difficult for some folks when more features are added.<br>
<br>
I think I see at least one use case for minimum 2 hooks...<br>
<br>
Cloud provider wants to inject some stuff.<br>
<br>
Cloud tenant wants their own hook called to inject stuff to point to the Config Management server in their own tenant.<br>
<br>
Maybe that's not vendor_data but tenant_data or something...<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF573757"><font face="Tahoma" color="#000000" size="2"><b>From:</b> mikalstill@gmail.com [mikalstill@gmail.com] on behalf of Michael Still [mikal@stillhq.com]<br>
<b>Sent:</b> Tuesday, May 03, 2016 2:37 PM<br>
<b>To:</b> Fox, Kevin M<br>
<b>Cc:</b> David Medberry; Ned Rhudy; openstack-operators@lists.openstack.org; Sean Dague<br>
<b>Subject:</b> Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">Hey,
<div><br>
</div>
<div>I just wanted to let people know that the review is progressing, but we have a question.</div>
<div><br>
</div>
<div>Do operators really need to call more than one external REST service to collect vendordata? We can implement that in nova, but it would be nice to reduce the complexity to only having one external REST service. If you needed to call more than one service
you could of course write a REST service that aggregated REST services.</div>
<div><br>
</div>
<div>Does anyone in the operator community have strong feelings either way? Should nova be able to call more than one external vendordata REST service?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Michael</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Apr 30, 2016 at 4:11 AM, Michael Still <span dir="ltr">
<<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div dir="ltr">So, after a series of hallway track chats this week, I wrote this:
<div><br>
</div>
<div> <a href="https://review.openstack.org/#/c/310904/" target="_blank">https://review.openstack.org/#/c/310904/</a></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I'd be curious as to if the proposed solution actually meets your needs.</div>
<div><br>
</div>
<div>Michael</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra">
<div>
<div class="h5"><br>
<div class="gmail_quote">On Mon, Apr 18, 2016 at 10:55 AM, Fox, Kevin M <span dir="ltr">
<<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">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.<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family:Times New Roman; color:#000000; font-size:16px">
<hr>
<div style="direction:ltr"><font face="Tahoma" color="#000000" size="2"><b>From:</b> David Medberry [<a href="mailto:openstack@medberry.net" target="_blank">openstack@medberry.net</a>]<br>
<b>Sent:</b> Monday, April 18, 2016 7:16 AM<br>
<b>To:</b> Ned Rhudy<br>
<b>Cc:</b> <a href="mailto:openstack-operators@lists.openstack.org" target="_blank">
openstack-operators@lists.openstack.org</a>
<div>
<div><br>
<b>Subject:</b> Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?<br>
</div>
</div>
</font><br>
</div>
<div>
<div>
<div></div>
<div>
<div dir="ltr">Hi Ned, Jay,
<div><br>
</div>
<div>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?</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Apr 18, 2016 at 8:13 AM, Ned Rhudy (BLOOMBERG/ 731 LEX)
<span dir="ltr"><<a href="mailto:erhudy@bloomberg.net" target="_blank">erhudy@bloomberg.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div style="white-space:pre-wrap; font-size:small; font-family:'Courier New',Courier; color:rgb(0,0,0)">
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.
<div><br>
</div>
<div>What is the rationale for desiring to remove this functionality?<br>
<div style="font-size:small; font-family:'Courier New',Courier; color:rgb(0,0,0)">
<br>
<div>
<div>From: <a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>
</div>
<div>Subject: Re: [Openstack-operators] Anyone else use vendordata_driver in nova.conf?<br>
</div>
</div>
<div>
<div>
<blockquote>On 04/18/2016 09:24 AM, Ned Rhudy (BLOOMBERG/ 731 LEX) wrote:<br>
> I noticed while reading through Mitaka release notes that<br>
> vendordata_driver has been deprecated in Mitaka<br>
> (<a href="https://review.openstack.org/#/c/288107/" target="_blank">https://review.openstack.org/#/c/288107/</a>) and is slated for removal at<br>
> some point. This came as somewhat of a surprise to me - I searched<br>
> openstack-dev for vendordata-related subject lines going back to January<br>
> and found no discussion on the matter (IRC logs, while available on<br>
> eavesdrop, are not trivially searchable without a little scripting to<br>
> fetch them first, so I didn't check there yet).<br>
><br>
> We at Bloomberg make heavy use of this particular feature to inject<br>
> dynamically generated JSON into the metadata service of instances; the<br>
> content of the JSON differs depending on the instance making the request<br>
> to the metadata service. The functionality that adds the contents of a<br>
> static JSON file, while remaining around, is not suitable for our use case.<br>
><br>
> Please let me know if you use vendordata_driver so that I/we can present<br>
> an organized case for why this option or equivalent functionality needs<br>
> to remain around. The alternative is that we end up patching the<br>
> vendordata driver directly in Nova when we move to Mitaka, which I'd<br>
> like to avoid; as a matter of principle I would rather see more<br>
> classloader overrides, not fewer.<br>
<br>
Wouldn't an alternative be to use something like Chef, Puppet, Ansible, <br>
Saltstack, etc and their associated config variable storage services <br>
like Hiera or something similar to publish custom metadata? That way, <br>
all you need to pass to your instance (via userdata) is a URI or <br>
connection string and some auth details for your config storage service <br>
and the instance can grab whatever you need.<br>
<br>
Thoughts?<br>
-jay<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
</div>
</div>
<span class="HOEnZb"><font color="#888888">-- <br>
<div>Rackspace Australia</div>
</font></span></div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">Rackspace Australia</div>
</div>
</div>
</div>
</div>
</body>
</html>