Open Stack

On 26 June 2015 at 13:07, Monty Taylor <mordred at inaugust.com> wrote:
> On 06/26/2015 07:49 AM, John Garbutt wrote:
>> On 19 June 2015 at 17:25, Chris Hoge <chris at openstack.org> wrote:
>>>
>>>> On Jun 19, 2015, at 9:00 AM, John Garbutt <john at johngarbutt.com> wrote:
>>>>
>>>> On 17 June 2015 at 20:27, Mark Voelker <mvoelker at vmware.com> wrote:
>>>> <massive snip>++
>>>>
>>>>> 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 don't think Nova needs to be involved here, its a Glance API issue.
>>>> I hope the Glance folks correct me if I am talking rubbish.
>>>
>>> From the beginning Nova, Cinder, Glance, and even Neutron have been tightly coupled.
>>> It’s a Glance API issue, but it’s also pressing Nova API issue. Not my project/not my
>>> problems hurts end users.
>>>
>>> I just want to be able to boot an image on a VM and attach a network, and do it
>>> in a portable way. If any aspect of that is a problem for one project it becomes a
>>> problem for all projects.
>>
>> OK so this is why I sometimes hate email... and my dyslexia.
>>
>> The wider issues here, certainly involve everyone. I am not questioning that.
>>
>> I am just trying to say that the Nova project has no control over the
>> Glance v2 API, thats all. Adding Nikhil back to the thread, who I am
>> hoping was going to respond with a plan we discussed together.
>>
>> Currently Glance v2 doesn't have a single upload API that can be used
>> with all glance backends and deployment scenarios. That is a thing
>> that I feel needs urgent attention. Similar issues for
>> download/export, I think, but I have less info on the details there.
>
> Awesome. I couldn't possibly agree more.

Cool. Agreement on a problem here.

>> Similarly, there is no standard way to identify a particular OS image
>> across clouds, which I think is another issue we should really look
>> into. In Nova we are taking an interesting (but possibly distracting)
>> step in that direction by adopting this:
>> http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/libvirt-hardware-policy-from-libosinfo.html
>
> TOTALLY in favor of standard metadata. As an anecdote (and I picked on
> RAX last time, so I'll pick on HP this time) HP's Ubuntu images are
> marked "partner image" in their name. There is, of course, no way of
> knowing that that partner is Canonical - so as a consume, I have
> literally no way of knowing what the content is or where it came from.
> If you know those of us in Infra - you'll know that we actually manually
> verify the content against Canonical published checksums everytime a new
> rev is posted. :)

+1

Just being able to ask for the latest of a specific image "family"
would be good to. But lets not get distracted.

>> Nova is doing what we can to help Glance v2 API adoption, by actively
>> trying to get people to work on removing our dependency on Glance v1,
>> but that should have limited impact on interoperability and DefCore. I
>> just don't understand why this is considered so important to DefCore,
>> and I really want to find out why that is the case, because I am
>> clearly missing something here.
>
> It's important to me in the DefCore context because "upload an image to
> the cloud" is a _fundamental thing. Infra cannot use a cloud that does
> not support it, as a quick data point. So, while we know this isn't
> going to have a quick answer, it's an important thing to get right. It's
> also one of the clearest issues that the DefCore work has uncovered and
> shone light on - so I'd like to make sure that we don't lose that thread.
>
> One of the reasons that Image Upload is so important is that it's the
> only way you can, as a user, be sure you're running on the same OS
> across multiple providers. (This is, btw, the reason I get so annoyed
> when people suggest vendor-specific in-instance agents as solutions to
> things) Interoperability is in service of running workloads. I don't
> want to run Ubuntu-15.04-for-Dreamhost and Ubuntu-15.04-for-HP - I want
> to run Ubuntu-15.04-with-my-application.

+1

I know folks are trying to change the equation by using containers,
but thats not quite the fully story either.

>> The Nova image API is planned to stick around for good, to aid
>> interoperability. But its a proxy, so has some horrible error edge
>> cases, so we really want Glance v2 to be adopted, so people get the
>> best experience with using an OpenStack cloud.
>
> I appreciate that - but it doesn't really help the problem of there not
> being a consistent way to upload images.

Agreed. I was really just trying to say its irrelevant to this discussion.

For context, Nova's image API doesn't support upload (or download).

> The _other_ bits of the glance
> api aren't really a significant problem. Listing images works fine
> regardless of v1 or v2. Setting properties is _mostly_ fine (although
> the switch that some properties are sent as extra keywords and some as
> properties to all being properties is _mildly_ annoying) - but certainly
> not any worse than any of the other mid-range annoying inconsistencies.

I was really meaning the above issue, that you don't really know
(cross cloud) what the images are that you are listing.

Thanks,
John