<div dir="ltr"><div>Hi Brian,</div><div>Thanks for the sessions summaries.</div><div><br></div><div>We are really interested in the image lifecycle support. </div><div>Can you elaborate how searchlight would help solving this problem?</div><div><br></div><div>thanks,</div><div>Belmiro</div><div>CERN</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 15, 2017 at 4:46 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">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>
<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>
</blockquote></div><br></div>