[Openstack-operators] [glance] how to update the contents of an image
George Shuklin
george.shuklin at gmail.com
Thu Oct 9 19:43:50 UTC 2014
Yep. Migration is just a resize (from flavor to same flavor). Instance
disk transferred by scp/rsync.
On 10/09/2014 05:36 AM, Joe Topjian wrote:
> Ah - so it sounds like the issue might be local to just non-live/cold
> migration? The type that requires SSH key exchange? That's what
> resizing uses behind the scenes, so it makes sense that it would fail
> as well.
>
> On Wed, Oct 8, 2014 at 8:30 PM, George Shuklin
> <george.shuklin at gmail.com <mailto:george.shuklin at gmail.com>> wrote:
>
> We using Havana, with raw images and non-live migration (rsync/scp
> on halted VMs).
>
> Migration happens, but during instance start nova-compute fail to
> find image locally and in glance.
>
> I saw Icehouse patch to made a copy of image from original host
> but it looks too slow for me (for the raw disk of instance booted
> from snapshot it gonna be double migration time).
>
> On Oct 8, 2014 8:19 PM, "Joe Topjian" <joe at topjian.net
> <mailto:joe at topjian.net>> wrote:
>
> We just ran some tests on our production Icehouse environment
> and can confirm that:
>
> * Snapshotting an instance based on a deleted image works
> * Snapshotting an instance based on a public-turned-private
> image works
> * Block migration of an instance based on a deleted image works
>
> This environment does not utilize _base images.
>
> We didn't do any resizing tests as we do not have our
> environment configured to allow it. At the moment, if a user
> tries resizing they receive an error message. It's not a
> friendly way to disable an action so we plan on just removing
> the option from Horizon altogether.
>
> We also tested the following with an older Grizzly environment
> that supports live migration:
>
> * Snapshotting an instance based on a deleted image (and base
> image) works
> * Live migrating an instance based on a deleted image (and
> base image) works
>
> Resizing is not supported in this environment as well.
>
> I'm curious about your environment where these actions are
> failing for you?
>
> Thanks,
> Joe
>
> On Tue, Oct 7, 2014 at 3:03 PM, George Shuklin
> <george.shuklin at gmail.com <mailto:george.shuklin at gmail.com>>
> wrote:
>
> Yep, this bug is still actual. Resize, migration and so on
> does not work if original image is deleted. And 'I will
> never remove any public image' will not helps, because if
> user restore instance from snapshot and remove snapshot it
> will cause error too. That looks stupid in the light of
> (our) raw disk format, where 'base copy' just never used.
>
> Error is harmless and can be fixed by
>
> nova reset-state --active UUID
> (optionally)
> nova stop UUID
> nova start UUID
>
> But it's still annoying because user can not fix it own
> instance without administrator intervention.
>
> We have plans to fix it for havana (it cause disturbance
> for as and inconvenience for our customers), but fix will
> not be accepted by upstream (they drops upstream support
> ASAP), so I think we should switch to old-style maillist
> based patch RFC.
>
> On 10/07/2014 10:16 PM, Jan van Eldik wrote:
>
> Hi,
>
> Please note the issue reported in
> https://bugs.launchpad.net/nova/+bug/1160773: "Cannot
> resize instance if base image is not available"
>
> AFAIK it is still the case that instances cannot be
> resized or migrated
> once the image from which it has been created has been
> deleted.
>
> cheers, Jan
>
> On 10/07/2014 09:01 PM, Abel Lopez wrote:
>
> Right, and I think the best thing about marking a
> deprecated image private is that
> new instances can’t select that image unless the
> tenant is an image-member of it.
> So if a specific tenant has some “real valid” need
> to use the old version (I can’t imagine why), they
> could find it in “Project Images” instead of “Public”.
>
> On Oct 7, 2014, at 11:57 AM, Sławek Kapłoński
> <slawek at kaplonski.pl <mailto:slawek at kaplonski.pl>>
> wrote:
>
> Hello,
>
> Yes, I agree that this is not big problem when
> there is info "Image not found"
> in horizon but I saw this discussion and I
> thought that I will ask about that
> :) It would be nice to have some other info
> like for example: "Image 1
> (archived)" or something like that :)
>
> ---
> Best regards
> Sławek Kapłoński
> slawek at kaplonski.pl <mailto:slawek at kaplonski.pl>
>
> Dnia wtorek 07 październik 2014 18:21:13 piszesz:
>
> I've never worried about "Image not
> Found", as its only a UI concern. IMO
> it lets the users know something has
> changed. Totally optional, and the
> same effect can be gained by just renaming
> it -OLD and leaving it public.
> At some point, it still needs to be removed.
>
> On Tuesday, October 7, 2014, Sławek
> Kapłoński <slawek at kaplonski.pl
> <mailto:slawek at kaplonski.pl>> wrote:
>
> Hello,
>
> I use Your solution and I made old
> images as private in such change but
> then
> there is one more problem: all
> instances spawned from that old images are
> have
> in horizon info about image: "not found".
> Do You maybe know how to solve that?
>
> ---
> Best regards
> Sławek Kapłoński
> slawek at kaplonski.pl
> <mailto:slawek at kaplonski.pl>
> <javascript:;>
>
> Dnia wtorek, 7 października 2014
> 10:05:57 Abel Lopez pisze:
>
> You are correct, deleted images
> are not deleted from the DB, rather
> their
> row has ‘deleted=1’, so specifying
> the UUID of another image already in
> glance for a new image being
> upload will end in tears.
>
> What I was trying to convey was,
> when Christian is uploading a new
> image
>
>
> of
>
> the same name as an existing
> image, the UUID will be different.
> IMO, the
> correct process should be:
> 1. Make desired changes to your image.
> 2. Rename the existing image (e.g.
> Fedora-20-OLD)
> 3. (optional) Make the old image
> private ( is-public 0 )
> 4. Upload the new image using the
> desired name (e.g. Fedora-20 or like
> Fedora-20-LATEST )
>
> Obviously I assume there was
> testing for viability of the image
> before
> it
> was uploaded to glance.
>
> For more information, be sure to
> catch my talk on Tuesday 9am at the
>
>
> summit.
>
> On Oct 7, 2014, at 9:58 AM, George
> Shuklin <george.shuklin at gmail.com
> <mailto:george.shuklin at gmail.com>
>
>
> <javascript:;>> wrote:
>
> As far as I know, it is not
> possible to assign uuid from
> deleted image
>
>
> to
>
> the new one, because deleted
> images keeps their metadata in
> DB.>
>
> On 09/26/2014 04:43 PM, Abel
> Lopez wrote:
>
> Glance images are
> immutable. In order to
> update it, you should do as
>
>
> you
>
> are doing, but then rename
> the old image, then upload
> the updated
> one.
> Take note of the UUID as well.
>
> On Friday, September 26,
> 2014, Christian Berendt <
>
>
> berendt at b1-systems.de
> <mailto:berendt at b1-systems.de>
> <javascript:;>>
>
> wrote: I'm trying to
> update the contents of an
> image, but it looks
>
>
> like
>
> it is not working at all.
>
> First I upload a test image:
>
> ---snip---
> # dd if=/dev/urandom
> of=testing.img bs=1M count=10
> # glance image-create
> --disk-format raw
> --container-format bare
> --name
> TESTING --file testing.img
> ---snap---
>
> Now I want to overwrite
> the contents of this image:
>
> ---snip---
> # dd if=/dev/urandom
> of=testing.img bs=1M count=20
> # glance image-update
> --file testing.img TESTING
> ---snap---
>
> After this call the size
> of the image is still the
> same like before
> (10485760 bytes).
>
> I do not have issues in
> the logfiles of glance-api and
>
>
> glance-registry.
>
> What am I doing wrong?
>
> Is it not possible to
> update the contents of an
> image?
>
> Christian.
>
> --
> Christian Berendt
> Cloud Solution Architect
> Mail:
> berendt at b1-systems.de
> <mailto:berendt at b1-systems.de>
> <javascript:;>
>
> B1 Systems GmbH
> Osterfeldstraße 7 / 85088
> Vohburg /
> http://www.b1-systems.de
> GF: Ralph Dehner /
> Unternehmenssitz: Vohburg
> / AG: Ingolstadt,HRB
> 3537
>
> _______________________________________________
> OpenStack-operators
> mailing list
> OpenStack-operators at lists.openstack.org
> <mailto:OpenStack-operators at lists.openstack.org>
> <javascript:;>
>
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators
> mailing list
> OpenStack-operators at lists.openstack.org
> <mailto:OpenStack-operators at lists.openstack.org>
> <javascript:;>
>
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> <mailto:OpenStack-operators at lists.openstack.org>
> <javascript:;>
>
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> <mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> <mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> <mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> <mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141009/16417821/attachment.html>
More information about the OpenStack-operators
mailing list