settingsLogin | Registersettings

[openstack-dev] [nova] vendordata v2 ocata summit recap

0 votes

Michael Still led a session on completing the vendordata v2 work that
was started in the Newton release. The full etherpad is here:

https://etherpad.openstack.org/p/ocata-nova-summit-vendoradatav2

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).

The majority of the session was spent discussing a gap we have in
providing token information on the request to the vendordata server.

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:

  1. Stash the user's roles from the initial create in the nova database
    and re-use those on subsequent GET requests.

  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.

Other things that are needed at some point:

  1. Add some caching of the response using the Cache-Control header.

  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.

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Nov 9, 2016 in openstack-dev by Matt_Riedemann (48,320 points)   3 10 26
retagged Jan 26, 2017 by admin

1 Response

0 votes

This is a good summary, thanks. I finally uploaded the spec which describes
the decisions from the summit. Its here:

https://review.openstack.org/395959

Michael

On Thu, Nov 10, 2016 at 7:11 AM, Matt Riedemann mriedem@linux.vnet.ibm.com
wrote:

Michael Still led a session on completing the vendordata v2 work that was
started in the Newton release. The full etherpad is here:

https://etherpad.openstack.org/p/ocata-nova-summit-vendoradatav2

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).

The majority of the session was spent discussing a gap we have in
providing token information on the request to the vendordata server.

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:

  1. Stash the user's roles from the initial create in the nova database and
    re-use those on subsequent GET requests.

  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.

Other things that are needed at some point:

  1. Add some caching of the response using the Cache-Control header.

  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.

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Rackspace Australia


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Nov 10, 2016 by Michael_Still (16,180 points)   3 6 14
...