Open Stack

On 7 June 2016 at 17:41, Jim Rollenhagen <jim at jimrollenhagen.com> wrote:
> 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:
>> > 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.

That sounds reasonable to me.

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

So the problem this is trying to resolve is reducing support calls /
reducing user frustration.

Doing that by making it harder to use our API in the "wrong" way seems
fine to me. It seems similar to the checks we do on neutron ports, to
make sure you have something that looks useful, to help avoid user
confusion.

By default, you would have no image_metadata, so there would be no
restriction, so I don't think it should impact most people's testing.
Once we get this spec done, the override should be simple:
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/virt-image-props-boot-override.html

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

+1

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

Its normal to access it anywhere you need it form the instance object.
Random example:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1585

Thanks,
johnthetubaguy