Open Stack

Generalizing beyond the context of ISOs makes a lot of sense to me,
and it could dovetail nicely with efforts to auto-detect the container
and disk formats of an image.

We might want to resurrect last summit's image-workers concept (which
didn't gain much traction in grizzly when it came time to actually
code things up) in order to handle this work.

I don't imagine we'll ever be in a place where we can make strong
guarantees that these kinds of properties are set across all relevant
images, however.

On Tue, Apr 9, 2013 at 1:37 AM, lzy.dev at gmail.com <lzy.dev at gmail.com> wrote:
> On Tue, Apr 9, 2013 at 4:18 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> On Mon, Apr 08, 2013 at 10:59:32AM -0700, Mark Washenberger wrote:
>>> Sorry I missed this earlier, but, couldn't you just run "isoinfo" on
>>> the image data before you upload it to Glance, and add the properties
>>> you care about during image creation? We could document those property
>>> names and values (and maybe even validate them) to make sure they
>>> retain their canonical meaning.
>>
>> You need to have something that apps can rely on existing for all
>> images and more importantly being correct. I don't think requiring
>> the users to manually set this is satisfactory. You also can't
>> assume that the user actually has the ISO locally - you can tell
>> Glance to pull images straight from a remote HTTP url, which makes
>> running isoinfo impossible.
>>
> I consider this make sense also so far.
>
>>> Otherwise, adding a hook to "inspect image and add relevant
>>> properties" doesn't really have a good place to fit into Glance at the
>>> moment, IMO.
>>
>> Well that will have to be dealt with as part of the development
>> of this feature.
>>
> +1
>
>>> On Fri, Apr 5, 2013 at 3:04 PM, Mark Atwood <mark.atwood at hp.com> wrote:
>>> > Instead of just for ISO9660, I know that other filesystem images and also
>>> > various VM storage images also define various metadata.  (I know that I've
>>> > read and written metadata for Virtual Box images using the GUI tool, for
>>> > example.)
>>> >
>>> > I think it makes sense to do this in such a way that Glance can make all
>>> > these metadatas from all image formats discoverable and displayable.
>>
>> Yep, it of course makes sense to design it as a pluggable facility
>> to allow for different file types to have different default metadata.
>>
> I'm interested on this pluggable facility, it should be an image type
> awarable discovery pip/chain.
>
>>> > On Wed, Jan 30, 2013 at 2:55 AM, Daniel P. Berrange <berrange at redhat.com>
>>> > wrote:
>>> >>
>>> >> Some apps have a need to be able to obtain ISO filesystem headers from
>>> >> images stored in glance. Now obviously they can just download the image
>>> >> (or part of it) and run 'isoinfo' on it, but this is really horrifically
>>> >> inefficient/wasteful of bandwidth. It would be desirable for glance to
>>> >> have explicit support for this in some way.
>>> >>
>>> >> I've written a short wiki page describing one approach, which is to
>>> >> make glance extract the data upon upload of an ISO and store it in
>>> >> some well-defined metadata properties against the image.
>>> >>
>>> >>     http://wiki.openstack.org/GlanceISOHeaders
>>> >>     https://blueprints.launchpad.net/glance/+spec/iso-image-metadata
>>> >>
>>> >> A completely different approach we be to ignore metadata properties
>>> >> and add an explicit API to glance which would extract it on-demand,
>>> >> but I feel this is a needlessly large amount of work & less convenient
>>> >> and flexible than simply using existing metadata properties.
>>
>> Daniel
>> --
>> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
>> |: http://libvirt.org              -o-             http://virt-manager.org :|
>> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
>> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev