Open Stack

On 06/29/2015 05:43 AM, John Garbutt wrote:
> 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.

Nope. I agree. In fact, (just while we're listing fun anecdotes) - we
just had an issue where an image in one of our cloud providers changed
the kernel parameters it had been booting with. Even if we were running
containers on top of our VMs - kernel parameters, it turns out, are
sticky. :)

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

TOTALLY