<div dir="ltr">This is a good summary, thanks. I finally uploaded the spec which describes the decisions from the summit. Its here:<div><br></div><div>    <a href="https://review.openstack.org/395959">https://review.openstack.org/395959</a></div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 10, 2016 at 7:11 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Michael Still led a session on completing the vendordata v2 work that was started in the Newton release. The full etherpad is here:<br>
<br>
<a href="https://etherpad.openstack.org/p/ocata-nova-summit-vendoradatav2" rel="noreferrer" target="_blank">https://etherpad.openstack.org<wbr>/p/ocata-nova-summit-vendorada<wbr>tav2</a><br>
<br>
Michael started by advertising a bit what it is since it's a new feature and it's meant to replace the old class-path loading way of getting vendor metadata (and ultimately allows us to remove hooks).<br>
<br>
The majority of the session was spent discussing a gap we have in providing token information on the request to the vendordata server.<br>
<br>
For example, when creating a server we have a user content and token and can provide that information to the vendordata REST API, but on subsequent GETs from the guest itself we don't have a token. After quite a bit of discussion in the room, including with Adam and Dolph from the keystone team, we decided to:<br>
<br>
1. Stash the user's roles from the initial create in the nova database and re-use those on subsequent GET requests.<br>
<br>
2. Use a service token to pass the other information to the vendordata v2 REST API so that it knows the request is coming from Nova. This was considered a bug fix and not a new feature so we can backport the functionality.<br>
<br>
Other things that are needed at some point:<br>
<br>
1. Add some caching of the response using the Cache-Control header.<br>
<br>
2. Add a configuration option to toggle whether or not the server create should fail if a vendordata response is not 200. Today if we get a non-200 response we log a warning and return {} to the caller. Some vendordata scenarios require that the metadata get into the guest as soon as it's created or else it becomes essentially a zombie and cleaning it up later is painful. So provide an option to fail that server create if we can't get the necessary data into the guest on server create. Note that this would only fail the server build if using config drive since nova is the caller. When cloud-init is making the request from within the guest, nova has lost control at that point and any failures are going to have to be cleaned up separately.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Rackspace Australia</div>
</div>