Open Stack

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

I don’t think it does, but it does bring up a point that folks really need to be aware of (and I’m not sure everyone is).  Namely:  DefCore in it’s current form is intentionally a *lagging* indicator.  E.g. something can’t become DefCore-required until (among other things) it shows proven usage out in the wild [1] and has a level of API stability [2].  DefCore Guidelines typically cover three OpenStack releases [3].  DefCore can’t just “pick a winner” among the available methods that exist today.  The impact of that on the current image upload predicament goes something like this:

> * use glance v2 (only just fully released (kilo?), not deployed everywhere, yet)

Assuming you’re correct about Kilo, this would be grounds for v2 image upload to not be DefCore-required for now.  The next DefCore guideline would cover Juno, Kilo, and Liberty, and Glance v2 image upload has neither met the >2 releases bar yet nor was it available in Juno.  I’ll note that it’s also been pointed out that the Glance task API for importing images is incomplete even in Kilo, so it can’t really be DefCore-required either (and can’t be until 2017 at the earliest).

> * glance is building a new v3 API (user could help implement that, I suppose)

Assuming this lands in Liberty, we wouldn’t be able to DefCore-require it until 2017 (the first time it could conceivably meet the >2 releases bar and the first time Liberty would be the eldest release covered by a Guideline).

> * use glance v1 (should never be exposed to end users, was designed as internal only API)

Assuming a lot of other operators have come to the same conclusion and if we assume for a moment that Glance is thinking of deprecating it soonish (since they’re already working on v3), then this fails to meet the bars for future direction and wide deployment, so we can’t DefCore-require it either.

> I would argue there is no truly interoperable way to do this right now. 

That sure seems to be the case, which stinks. =/  

The good news is, the process is working to the degree that we’re spotlighting major interoperability pain points like this now.  The next test is to prove that we as a community aren’t just paying lip service to interoperability by figuring out how to solve these problems sooner rather than later, because it’s going to be a while before users of OpenStack Powered (TM) clouds can depend on the solutions even if we wizarded up a magical set of patches that solved this today.

IMHO hashing out a solution will likely require some discussion and agreement among a couple of different groups within the community (Nova, Glance, & DefCore all seem to have skin in the game here).  What do you think is the best way to start tackling these sorts of things?  Cross-project specs?  Start nailing items to the TC meeting agendas?  Let ML discussions like this start driving priority lists [4] for the relevant projects?  Have inter-project liaisons [5] take it up?

[1] http://git.openstack.org/cgit/openstack/defcore/tree/process/CoreCriteria.rst#n36
[2] http://git.openstack.org/cgit/openstack/defcore/tree/process/CoreCriteria.rst#n50
[3] http://git.openstack.org/cgit/openstack/defcore/tree/HACKING.rst#n38
[4] Nova has nicely laid out http://specs.openstack.org/openstack/nova-specs/priorities/liberty-priorities.html but most projects unfortunately don’t.
[5] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons

At Your Service,

Mark T. Voelker

> On Jun 17, 2015, at 1:15 PM, John Garbutt <john at johngarbutt.com> 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
> 
> 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
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee