Open Stack

On 06/17/2015 03:27 PM, Mark Voelker wrote:
>> 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.

FWIW, all of the public clouds with I think 2 exceptions use glance v1
and expose it to the end users. However, the other cloud that uses v2
still uses PUT as the upload, so the v2-ness of the API exposed is minimal.

I'm not suggesting that it be defcore-required - you're right, it's  not
appropriate given the current state ... but image upload needs to be
required and there needs to be a fix to the absolute mess we have right
now where one cloud does it one way and is the only one that does, and
all of the others do it the other way, even if people sometimes say "you
shouldn't do that"

>> I would argue there is no truly interoperable way to do this right
>> now.
> 
> That sure seems to be the case, which stinks. =/

It's very painful - although we do have a library now in openstack that
knows how to do the right thing with each cloud. It's sad we had to
write it, but if you use python and/or ansible, you've got a workaround
for a while.

> The good news is, the process is working to the degree that we’re
> spotlighting major interoperability pain points like this now. 

Totally agree!

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

Agree even more.

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

I know there are several of these problems we talked about on the
technical side of the fence at the summit - specifically around the need
to at the very least provide clearer direction outbound from the tech
community as to what the intent is. As you say, it won't fix existing
deploys tomorrow - but yeah, I think starting to write some
cross-project specs here is a great choice.

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