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