[OpenStack-DefCore] Image APIs in Glance and Nova
Monty Taylor
mordred at inaugust.com
Fri Jun 26 12:07:47 UTC 2015
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.
> 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. :)
> 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.
> 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. 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.
Monty
More information about the Defcore-committee
mailing list