Re: [Openstack-operators] [glance] how to update the contents of an image
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.shuk...@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 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
Re: [Openstack-operators] [glance] how to update the contents of an image
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 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 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 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 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [glance] how to update the contents of an image
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
Re: [Openstack-operators] [glance] how to update the contents of an image
It would be nice to have an archive status for images, where brand new instances may not be launched off it, but where it may be used as a reference for existing instances and snapshots. Not sure about other folks, but we just keep piling up the old images, and they have to remain public. There's no preventing folks from launching off those old crusty images. Warren On Tue, Oct 7, 2014 at 2:21 PM, Abel Lopez alopg...@gmail.com wrote: 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 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 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 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 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 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
Re: [Openstack-operators] [glance] how to update the contents of an image
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 signature.asc Description: This is a digitally signed message part. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [glance] how to update the contents of an image
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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org
Re: [Openstack-operators] [glance] how to update the contents of an image
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
