Re: [Openstack-operators] How to handle updates of public images?
Going back to the idea of archiving images and not allowing launch of new VMs and hiding archived images by default in Horizon/CLI (maybe still can list/show if requested, possibly admin function only). Would it make sense to propose this as a blueprint for the next release? Best regards, Igor On Thu, Feb 5, 2015 at 5:34 AM, Tim Bell tim.b...@cern.ch wrote: -Original Message- From: George Shuklin [mailto:george.shuk...@gmail.com] Sent: 05 February 2015 14:10 To: openstack-operators@lists.openstack.org Subject: [Openstack-operators] How to handle updates of public images? Hello everyone. We are updating our public images regularly (to provide them to customers in up-to-date state). But there is a problem: If some instance starts from image it becomes 'used'. That means: * That image is used as _base for nova * If instance is reverted this image is used to recreate instance's disk * If instance is rescued this image is used as rescue base * It is redownloaded during resize/migration (on a new compute node) One more (our specific): We're using raw disks with _base on slow SATA drives (in comparison to fast SSD for disks), and if that SATA fails, we replace it (and nova redownloads stuff in _base). If image is deleted, it causes problems with nova (nova can't download _base). The second part of the problem: glance disallows to update image (upload new image with same ID), so we're forced to upload updated image with new ID and to remove the old one. This causes problems described above. And if tenant boots from own snapshot and removes snapshot without removing instance, it causes same problem even without our activity. How do you handle public image updates in your case? We have a similar problem. For the Horizon based end users, we've defined a panel using image meta data. Details are at http://openstack-in-production.blogspot.ch/2015/02/choosing-right-image.html . For the CLI users, we propose to use the sort options from Glance to find the latest image of a particular OS. It would be good if there was a way of marking an image as hidden so that it can still be used for snapshots/migration but would not be shown in image list operations. Thanks! ___ 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 -- Best regards, Igor ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] How to handle updates of public images?
On 02/07/2015 08:36 PM, Igor Bolotin wrote: Going back to the idea of archiving images and not allowing launch of new VMs and hiding archived images by default in Horizon/CLI (maybe still can list/show if requested, possibly admin function only). Would it make sense to propose this as a blueprint for the next release? Yes, it sounds nice. But more important - I want to have '_base' gone away when raw disks are used in nova. Why it's needed? ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] How to handle updates of public images?
I'm not sure making image private or downgrading to community sharing is the right concept for this. I agree with community sharing. I think being able to distinguish between public officially supported provider images and public, but not supported by cloud provider is definitely needed. However - retiring/hiding/archiving/deactivating (pick your term) outdated public or community image (especially when it has known vulnerabilities) - is part of managing image life-cycle vs. image sharing that public/private/shared/community addresses. There is another bp that seem to be very similar to this idea, but it focused on disabling download rather than hiding image: https://review.openstack.org/#/c/132717/ Best regards, Igor On Sat, Feb 7, 2015 at 12:35 PM, Louis Taylor krag...@gmail.com wrote: On Sat, Feb 07, 2015 at 10:36:55AM -0800, Igor Bolotin wrote: Going back to the idea of archiving images and not allowing launch of new VMs and hiding archived images by default in Horizon/CLI (maybe still can list/show if requested, possibly admin function only). Would it make sense to propose this as a blueprint for the next release? There is currently a spec under review [1] for a new type of image which covers some of the usecases in this thread. Momentumn has fallen off on working on it, but with a little luck it should be in the Kilo release. Further comments and feedback on that spec may be helpful in moving it along and getting it ready in time. The basic idea is that the old images are moved from being public images to 'community' images, which remain bootable, but not visible in normal user listings. Louis [1] https://review.openstack.org/#/c/124050/11 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- Best regards, Igor ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
