Open Stack

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_bolotin at 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.Bell at cern.ch
> <javascript:_e(%7B%7D,'cvml','Tim.Bell at cern.ch');>> wrote:
>
>> > -----Original Message-----
>> > From: George Shuklin [mailto:george.shuklin at gmail.com
>> <javascript:_e(%7B%7D,'cvml','george.shuklin at gmail.com');>]
>> > Sent: 05 February 2015 14:10
>> > To: openstack-operators at lists.openstack.org
>> <javascript:_e(%7B%7D,'cvml','openstack-operators at 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 at lists.openstack.org
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','OpenStack-operators at lists.openstack.org');>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
>
> --
> Best regards,
> Igor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150207/6993319d/attachment.html>