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 <sla...@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
sla...@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 <sla...@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
sla...@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.shuk...@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 <
bere...@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: bere...@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@lists.openstack.org <javascript:;>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org <javascript:;>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org <javascript:;>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
