Hi Soren,
Had a quick look at the quote and your question below.
From reading the mailing list, it appears that Scott Mosen and possibly Jay
Pipes are the experts on 'container type'.
I'll let them step in and field this question...
DL
-Original Message-
From: Soren Hansen
2011/12/6 Jay Pipes jaypi...@gmail.com:
On Fri, Dec 2, 2011 at 3:48 AM, Soren Hansen so...@linux2go.dk wrote:
2011/12/1 Jay Pipes jaypi...@gmail.com:
There are basically two things that are relevant: The image type and the
container format.
The image type can be either of kernel, ramdisk,
2011/12/2 Donal Lafferty donal.laffe...@citrix.com:
I simply don't think adding a vendor part to the container type
string is going to be a very good way to encode this.
Can this even be done with a MIME-style categorization?
Perhaps the finer details of what MIME-style categorization is are
-Original Message-
2011/12/2 Donal Lafferty donal.laffe...@citrix.com:
I simply don't think adding a vendor part to the container type
string is going to be a very good way to encode this.
Can this even be done with a MIME-style categorization?
Perhaps the finer details of
On Fri, 2 Dec 2011, Soren Hansen wrote:
2011/12/1 Jay Pipes jaypi...@gmail.com:
structure tar'd up. However, I think this can be more easily
accomplished by consolidating the disk and container formats in the
2.0 API to just a single format field with the possible values:
ova - This
2011/12/5 Donal Lafferty donal.laffe...@citrix.com:
Perhaps the finer details of what MIME-style categorization is are lost on
me.
Can you elaborate? Your original example was vhd/x-ms-tools which, to my
eye, is simply a container type string with a vendor part added. What am I
missing?
On Dec 5, 2011, at 12:12 PM, Scott Moser wrote:
Is anything actually using OVA from glance?
Yes, it is used in XenServer | Xen Cloud Platform fairly commonly (IMHO -- OVA
with VHD for Windows images).
http://wiki.openstack.org/XenServerDevelopment
/k
---
Ken Pepple
2011/12/1 Jay Pipes jaypi...@gmail.com:
structure tar'd up. However, I think this can be more easily
accomplished by consolidating the disk and container formats in the
2.0 API to just a single format field with the possible values:
ova - This indicates the data stored in Glance is an OVF
During October I noticed that Microsoft's vhdtool.exe creates VHDs that
XenServer can't understand. Boy was that painful. The underlying problem is
that some vhd's should be described as VM specific.
Does this suggest we adopt MIME-like syntax for category specialization? E.g.
in the same
2011/12/2 Donal Lafferty donal.laffe...@citrix.com:
During October I noticed that Microsoft's vhdtool.exe creates VHDs that
XenServer can't understand. Boy was that painful.
The underlying problem is that some vhd's should be described as VM specific.
Can you elaborate on this, please? I
2011/12/2 Donal Lafferty donal.laffe...@citrix.com:
The key in my email was to ask whether MIME-like specialisations were
appropriate either for combining characteristics of an image into a
single property.
E.g. container_type/image_type. The example I provided was
Hey all,
OK, so I'm almost done with Draft 3 of the OpenStack Images API 2.0
Proposal. While doing this, however, I have come to the conclusion
that the container_format we added in the Cactus timeframe just makes
things more confusing and should probably be removed.
We have two fields in the
On Dec 1, 2011, at 10:52 AM, Jay Pipes wrote:
What do people think of this proposal to combine the two into a single
format field?
I think it's a good idea. When I was trying to figure out how to migrate the
glance-upload examples to glance add, I found it confusing that there were
two
13 matches
Mail list logo
