Open Stack

On Tue, Jun 07, 2016 at 09:37:25AM -0400, Jim Rollenhagen wrote:
> On Tue, Jun 07, 2016 at 08:31:35AM +1000, Michael Still wrote:
> > On Tue, Jun 7, 2016 at 7:41 AM, Clif Houck <me at clifhouck.com> wrote:
> > 
> > > 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.
> > >
> > 
> > What about images where the authentication information is inside the image?
> > For example, there's just a standard account baked in that everyone knows
> > about? In that case Nova doesn't need to inject anything into the instance,
> > and therefore the metadata doesn't need to supply anything.
> 
> Right, so that's a third case. How I'd see this working is maybe an
> image property called "auth_requires" that could be one of ["none",
> "ssh_key", "x509_cert", "password"]. Or maybe it could be multiple
> values that are OR'd, so for example an image could require an ssh key
> or an x509 cert. If the "auth_requires" property isn't found, default to
> "none" to maintain compatibility, I guess.

NB, even if you have an image that requires an SSH key to be provided in
order to enable login, it is sometimes valid to not provide one. Not least
during development, I'm often testing images which would ordinarily require
an SSH key, but I don't actually need the ability to login, so I don't bother
to provide one.

So if we provided this ability to tag images as needing an ssh key, and then
enforced that, we would then also need to extend the API to provide a way to
tell nova to explicitly ignore this and not bother enforcing it, despite what
the image metadata says.

I'm not particularly convinced the original problem is serious enough to
warrant building such a solution. It feels like the kind of mistake that
people would do once, and then learn their mistake thereafter. IOW the
consequences of the mistake don't seem particularly severe really.

> The bigger question here is around hitting the images API syncronously
> during a boot request, and where/how/if to cache the metadata that's
> returned so we don't have to do it so often. I don't have a good answer
> for that, though.

Nova already uses image metadata for countless things during the VM boot
request, so there's nothin new in this respect. We only query glance
once, thereafter the image metadata is cached by Nova in the DB on a per
instance basis, because we need to be isolated from later changes to the
metadata in glance after the VM boots.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|