Open Stack

Hi Belmiro,

Thanks for the feedback about the "hidden" property.  To push this
along, would you mind reading through this patch and the comments on
it and responding?  Or if you think it's close to a working proposal,
you could grab the text, revise, make Fei Long a co-author, and
propose it for approved/queens, and the community can continue the
discussion there.

cheers,
brian


On Wed, Sep 20, 2017 at 4:58 AM, Belmiro Moreira
<moreira.belmiro.email.lists at gmail.com> wrote:
> Hi Brian,
>
> as we discussed in the past the image lifecycle has been a problem for us
>
> for a long time.
>
>
>
> However, I have some concerns in adding/maintaining a new project only to
> help the
>
> image discovery.
>
>
>
> At CERN we have a small set of images that we maintain and offer as "public"
> images
>
> to our users. Over the years this list has been growing because new image
> releases.
>
> We keep the old images releases with visibility "public" because old bugs in
> nova
>
> (already fixed) when live/resize/migrate instances and because we have some
> usecases
>
> that the user needs a very old release.
>
>
>
> Discovering the latest image release is hard. So we added an image property
> "recommended"
>
> that we update when a new image release is available. Also, we patched
> horizon to show
>
> the "recommended" images first.
>
>
>
> This helps our users to identify the latest image release but we continue to
> show for
>
> each project the full list of public images + all personal user images. Some
> projects
>
> have an image list of hundreds of images.
>
>
>
> Having a "hidden" property as you are proposing would be great!
>
>
>
> For now, we are planning to solve this problem using/abusing of the
> visibility "community".
>
> Changing the visibility of old images releases to "community" will hide them
> from the default
>
> "image-list" but they will continue discoverable and available.
>
>
>
>
> Belmiro
>
>
> On Tue, Sep 19, 2017 at 8:24 PM, Brian Rosmaita <rosmaita.fossdev at gmail.com>
> wrote:
>>
>> On Mon, Sep 18, 2017 at 7:47 AM, Belmiro Moreira
>> <moreira.belmiro.email.lists at gmail.com> wrote:
>> > Hi Brian,
>> > Thanks for the sessions summaries.
>> >
>> > We are really interested in the image lifecycle support.
>> > Can you elaborate how searchlight would help solving this problem?
>>
>> The role we see for searchlight is more on the image discovery end of
>> the problem. The context is that we were trying to think of a small
>> set of image metadata that could uniquely identify a series of images
>> (os_dist, os_version, local_version) so that it would be easy for end
>> users to discover the most recent revision with all the security
>> updates, etc.  For example, you might have:
>>
>> initial release of public image: os_distro=MyOS, os_version=3.2,
>> local_version=1
>> security update to package P1: os_distro=MyOS, os_version=3.2,
>> local_version=2
>> security update to package P2: os_distro=MyOS, os_version=3.2,
>> local_version=4
>>
>> The image_id would be different on each of these, and the operator
>> would prefer that users boot from the most recent.  Suppose an
>> operator also offers a pre-built database image built on each of
>> these, and a pre-built LAMP stack built on each of these, etc.  Each
>> would have the same os_distro and os_version value, so we'd need
>> another field to distinguish them, maybe os_content (values: bare, db,
>> lamp).  But then with the database image, for a particular (os_distro,
>> os_version, os_content) tuple, there might be several different images
>> built for the popular versions of that DB, so we'd need another field
>> for that as well.  So ultimately it looks like you'd need to make a
>> complicated query across several image properties, and searchlight
>> would easily allow you to do that.
>>
>> This still leaves us with the problem of making it simple to locate
>> the most recent version of each series of images, and that would be
>> where something like a 'hidden' property would come in.  It's been
>> proposed before, but was rejected, I think because it didn't cover
>> enough use cases.  But that was pre-searchlight, so introducing a
>> 'hidden' field may be a good move now.  It would be interesting to
>> hear what you think about that.
>>
>>
>> >
>> > thanks,
>> > Belmiro
>> > CERN
>> >
>> > On Fri, Sep 15, 2017 at 4:46 PM, Brian Rosmaita
>> > <rosmaita.fossdev at gmail.com>
>> > wrote:
>> >>
>> >> For those who couldn't attend, here's a quick synopsis of what was
>> >> discussed yesterday.
>> >>
>> >> Please consult the etherpad for each session for details.  Feel free
>> >> to put questions/comments on the etherpads, and then put an item on
>> >> the agenda for the weekly meeting on Thursday 21 September, and we'll
>> >> continue the discussion.
>> >>
>> >>
>> >> Complexity removal
>> >> ------------------
>> >> https://etherpad.openstack.org/p/glance-queens-ptg-complexity-removal
>> >>
>> >> In terms of a complexity contribution barrier, everyone agreed that
>> >> the domain model is the largest factor.
>> >>
>> >> We also agreed that simplifying it is not something that could happen
>> >> in the Queens cycle.  It's probably a two-cycle effort, one cycle to
>> >> ensure sufficient test coverage, and one cycle to refactor.  Given the
>> >> strategic planning session yesterday, we probably wouldn't want to
>> >> tackle this until after the registry is completely removed, which is
>> >> projected to happen in S.
>> >>
>> >>
>> >> Image lifecycle support
>> >> -----------------------
>> >> https://etherpad.openstack.org/p/glance-queens-ptg-lifecycle
>> >>
>> >> We sketched out several approaches, but trying to figure out a
>> >> solution that would work across different types of deployments and
>> >> various use cases gets complicated fast.  It would be better for
>> >> deployers to use Searchlight to configure complex queries that could
>> >> use all appropriate image metadata specified by the deployer.
>> >>
>> >> For interoperability, deployers could use the common image properties
>> >> with suggested values on their public images.
>> >>
>> >> We looked at two particular approaches that might help operators.  The
>> >> first would be introducing a kind of 'local_version' field that would
>> >> be auto-incremented by Glance, the idea being that an image-list query
>> >> that asked for the max value would yield the most recent version of
>> >> that image.  One problem, however, is what other metadata would be
>> >> used in the query, as there might be several versions of images with
>> >> the same os_distro and os_version properties (for example, the base
>> >> CentOS 7 image and the LAMP CentOS 7 image).
>> >>
>> >> The second approach is introducing a 'hidden' property which would
>> >> cause the image to be hidden from any image list calls (except for the
>> >> image owner or glance admin).  This has been requested before, but
>> >> hasn't been enthusiastically endorsed because it leaves out several
>> >> use cases.  But combined with Searchlight (with an updated glance
>> >> plugin to understand the 'hidden' field), it might be the best
>> >> solution.
>> >>
>> >>
>> >> Should Glance be replaced?
>> >> --------------------------
>> >> https://etherpad.openstack.org/p/glance-queens-ptg-glance-removal
>> >>
>> >> The short answer is No.  Glance is the best way for deployments to
>> >> provide the Images API v2.  The project team has recently regained the
>> >> team:diverse-affiliation tag and is in a healthier state that it was
>> >> immediately after the downsizing craze of 2017 that happened early in
>> >> the Pike cycle.  The Glance project team is committed to the long term
>> >> stability of Glance.
>> >>
>> >>
>> >> glance_store
>> >> ------------
>> >> https://etherpad.openstack.org/p/glance-queens-ptg-glance_store
>> >>
>> >> We had a combined session with the Glare team, who also consume the
>> >> glance_store library, and worked out a list of items to improve the
>> >> library.
>> >>
>> >>
>> >>
>> >> Multiple same store type support
>> >> --------------------------------
>> >> https://etherpad.openstack.org/p/glance-queens-ptg-multi-store
>> >>
>> >> This has been requested by operators, and the interoperable image
>> >> import introduced in v2.6 of the Images API can be used to allow end
>> >> users to request what store to use.  The Glance design will be
>> >> consistent (to the largest extent possible) with Cinder (at least as
>> >> far as configuration goes, to make it easy on operators).
>> >>
>> >>
>> >>
>> >> Queens Prioritization and Roadmapping
>> >> -------------------------------------
>> >> https://etherpad.openstack.org/p/glance-queens-ptg-roadmap
>> >>
>> >> See the etherpad for what we think we can get done.  I'll put up a
>> >> patch for the Queens priorities to the glance-specs repo before the
>> >> Glance meeting on Sept 21, and we can have a final discussion of any
>> >> outstanding issues.
>> >>
>> >>
>> >>
>> >> If you missed the Wednesday summary, here it is:
>> >>
>> >>
>> >> http://lists.openstack.org/pipermail/openstack-dev/2017-September/122156.html
>> >>
>> >> The scheduling etherpad has links to all the session etherpads:
>> >> https://etherpad.openstack.org/p/glance-queens-ptg
>> >>
>> >>
>> >> __________________________________________________________________________
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>