Open Stack

On Tue, Jun 07, 2016 at 03:10:24PM +0100, Daniel P. Berrange wrote:
> 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.

This is beyond the API though, right? The purpose of the spec here is to
reject the request if there isn't enough information to boot the
machine.

// jim

> 
> 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 :|
> 
> __________________________________________________________________________
> 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