You can achieve this by simply making the image as private "--is-public 0"
You have it in the admin tenant, and can use member to share it if needed. On Saturday, February 7, 2015, Igor Bolotin <igor_bolo...@symantec40.com> 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? > > Best regards, > Igor > > On Thu, Feb 5, 2015 at 5:34 AM, Tim Bell <tim.b...@cern.ch > <javascript:_e(%7B%7D,'cvml','tim.b...@cern.ch');>> wrote: > >> > -----Original Message----- >> > From: George Shuklin [mailto:george.shuk...@gmail.com >> <javascript:_e(%7B%7D,'cvml','george.shuk...@gmail.com');>] >> > Sent: 05 February 2015 14:10 >> > To: openstack-operators@lists.openstack.org >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','OpenStack-operators@lists.openstack.org');> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> _______________________________________________ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> <javascript:_e(%7B%7D,'cvml','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