Open Stack

On 06/17/2015 01:15 PM, John Garbutt wrote:
> 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

Omg. A video to one of my talks is linked.

Slides are here:

http://inaugust.com/talks/product-management.html#/

The image-related stuff starts here:

http://inaugust.com/talks/product-management.html#/17

BTW - if you want more fun, you can enjoy the part in a follow up talk
about networking issues:

http://inaugust.com/talks/now-what.html#/31



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

Yes please. It's the sanest of the three.

> 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
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>