Open Stack

oops, continued...

On 17 June 2015 at 17:56, John Garbutt <john at johngarbutt.com> wrote:
> Hi,
>
> So this was raised in the cross project meeting, and thank you for that.
>
> I keep mentioning use cases, so here we go...
> * create from cloud base image for ubuntu 12.04
> * above but with boot from volume
> * create a snapshot
> * download snapshot
> * upload image into another openstack cloud
> * boot server from uploaded image
>
> Now, at a higher level:
> * user does above using custom script for Cloud A and Cloud B
> * user keeps to just the APIs that are defcore tested
> * user gets access to Cloud C and Cloud D
> * user wants to point script at new clouds, and everything should just work
>
> So I think thats where we want to be. Now lets dig in...
>
> To list images, the user could:
> * use nova to list images (stable, but project wants to delete it)
> * use glance v1 (should never be exposed to end users, was designed as
> internal only API)
> * use glance v2 (only just fully released (kilo?), not deployed everywhere, yet)
> * glance is building a new v3 API (user could help implement that, I suppose)

Now I think the best way forward here is to pick the Nova list images,
for the moment.

Problem 2:
Upload an image

I would argue there is no truly interoperable way to do this right
now. Glance currently has three ways to upload an image, and no way to
know which the deployer has picked.

For details see (20 mins in):
https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/liberty-product-management-and-openstack-technology

Now there should be a way, long term, but that needs fixing before
defcore can test that. I would chose fixing the glance v2 upload, over
the glance v2 tasks or glance v1)

Problem 3:
Pick the Ubuntu 12.04 base image

We don't have a standard way to pick these that all clouds have
adopted. We should create one of these.

So I am going to stop there, for the moment. The defcore effort
highlights some difficulties that the project need to go and work on,
and I think thats awesome.


There was talk about the current state of Nova and image APIs, here is
a summary...

Nova currently talks to an internal glance v1 API, and if thats not
available you can't boot from a glance image. It could be a public
glance v1, but that is not how glance v1 was designed, it was meant to
be an internal API (although not sure everyone got the memo, or it
never got written, I am unsure)

Users are able to run both Glance v1 and Glance v2 talking to the same
datastore, thats how Rackspace has Glance v1 for Nova (internal only)
and Glance v2 for public use.

Nova has a glance v1 proxy API. That API will always implement the
glance v1 API, currently it does that by talking to the glance v1 API,
it may do that in the future by talking to the glance v2 API. Nova has
no plans to add a glance v2 proxy API, because proxy APIs suck (with
timeouts), and the glance v2 API was built to be exposed to end users.

There were plans to make Nova talk to glance v2, but the kilo effort
never got complete. Largely because of some features that are still
missing in glance v2 (and the patch never got reviewed, largely as
everyone though it was still a work in progress). I am told there are
plans to get those features added into glance v2 during liberty.
However that means Nova will require a liberty glance v2, if
configured to use glance v2.

I don't see how any of this Nova work should really block the defcore
effort in terms of picking which image API to depend on. But its very
possible I am missing something.


Thanks,
John