[openstack-dev] [nova][glance] Future of nova's image API

Mark Washenberger mark.washenberger at markwash.net
Mon Aug 5 19:11:31 UTC 2013

On Mon, Aug 5, 2013 at 7:26 AM, John Garbutt <john at johngarbutt.com> wrote:

> On 3 August 2013 03:07, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> > Some people had concerns about exposing the glance api publicly and so
> > wanted to retain the images support in Nova.
> > So the consensus seemed to be to leave the images support in, but to
> demote
> > it from core. So people who don't want it exclude the os-images
> extension.
> I think a lot of the concern was around RBAC, but seems most of that
> will be fixed by the end of Havana:
> https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection

I don't think this is a big issue. The RBAC approach to properties is just
an attempt to formalize what large public clouds are already doing in their
forks to manage info about image billing. Its not really a critical blocker
for public adoption.

> Given v3 is will not be "finished" till Icehouse, maybe we should look
> at removing os-images extension for now, and putting it back in for
> Icehouse if it causes people real headaches?
> > Just as I write this I've realised that the servers api currently returns
> > links to the image used for the instance. And that won't be valid if the
> > images extension is not loaded. So probably have some work to do there to
> > support  that properly.
> Have we decided a good strategy for this in v3? Referring to image in
> glance, and networks and ports in neutron.
> The pragmatic part of me says:
> * just use the uuid, its what the users will input when booting servers
> But I wonder if a REST purest would say:
> * an image is a REST resource, so we should have a URL pointing to the
> exposed glance service?

> What do you think? I just want to make sure we make a deliberate choice.
> John
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130805/2e9af7ae/attachment.html>

More information about the OpenStack-dev mailing list