Open Stack

I think nova should completely ignore this issue and boot the image no matter what. This is an operational 'workflow', and nova doesn't need to know about the image internals at all. If it boots, then is not nova problem. 

Ghe Rivero


Quoting Clif Houck (2016-06-06 23:41:12)
> Hello all,
> 
> At Rackspace we're running into an interesting problem: Consider a user
> who boots an instance in Nova with an image which only supports SSH
> public-key authentication, but the user doesn't provide a public key in
> the boot request. As far as I understand it, today Nova will happily
> boot that image and it may take the user some time to realize their
> mistake when they can't login to the instance.
> 
> I've been thinking about a solution to this problem. Ideally, the Nova
> API would quickly return an HTTP code indicating a problem with the
> request and reject the `create` or `recreate` request if the proper
> credentials were not included as part of the request.
> 
> So in the example above, instead of Nova accepting the create request,
> Nova would check the requested image's meta-data and ensure at least
> one form of authentication is supported AND has credentials available
> to place on the image during provisioning. Basically, ensure the
> requester has a way to login remotely.
> 
> I've put up a short specification on this proposed addition here:
> https://review.openstack.org/#/c/326073/
> and the blueprint is here:
> https://blueprints.launchpad.net/nova/+spec/auth-based-on-image-metadat
> a
> 
> I think one of the glaring weaknesses of this proposal is it would
> require a call to the image API to get image meta-data during `create`
> or `recreate`. This could be alleviated by caching image meta-data in
> Nova, since I wouldn't expect image meta-data to change often.
> 
> There's also the question of the image meta-data itself. I don't think
> there is any existing standard to describe, using metadata, what remote
> login/authentication methods a particular image supports. One way could
> be to provide a set of configuration options for the operator to
> define. That way, each operator could define their own metadata
> describing each authentication method supported by their images.
> 
> Hoping this will elicit some opinions on how to go about solving this,
> or if I've missed something that already exists that solves this
> problem.
> 
> Any thoughts welcome.
> 
> Thanks,
> Clif Houck
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev