Open Stack

Mark, can you share the image-workers concept/docs with me?
For now, I'm just worry those remote/linked image such as HTTP backend
stored images.
It seems we should download it firstly for inspect headers.

On Wed, Apr 10, 2013 at 8:43 AM, Mark Washenberger
<mark.washenberger at markwash.net> wrote:
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev