settingsLogin | Registersettings

[openstack-dev] [glance] Queens PTG: Thursday summary

0 votes

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 'localversion' 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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 27, 2017 in openstack-dev by rosmaita.fossdev_at_ (4,180 points)   1 2 2

8 Responses

0 votes

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?

thanks,
Belmiro
CERN

On Fri, Sep 15, 2017 at 4:46 PM, Brian Rosmaita rosmaita.fossdev@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 'localversion' 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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 18, 2017 by Belmiro_Moreira (2,620 points)   2 4
0 votes

On Mon, Sep 18, 2017 at 7:47 AM, Belmiro Moreira
moreira.belmiro.email.lists@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
(osdist, osversion, 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: osdistro=MyOS, osversion=3.2, localversion=1
security update to package P1: os
distro=MyOS, osversion=3.2, localversion=2
security update to package P2: osdistro=MyOS, osversion=3.2, local_version=4

The imageid 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 osversion 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 (osdistro,
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@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 'localversion' 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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 19, 2017 by rosmaita.fossdev_at_ (4,180 points)   1 2 2
0 votes

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@gmail.com
wrote:

On Mon, Sep 18, 2017 at 7:47 AM, Belmiro Moreira
moreira.belmiro.email.lists@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
(osdist, osversion, 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: osdistro=MyOS, osversion=3.2,
localversion=1
security update to package P1: os
distro=MyOS, osversion=3.2,
local
version=2
security update to package P2: osdistro=MyOS, osversion=3.2,
local_version=4

The imageid 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 osversion 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 (osdistro,
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@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 'localversion' 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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 20, 2017 by Belmiro_Moreira (2,620 points)   2 4
0 votes

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@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@gmail.com
wrote:

On Mon, Sep 18, 2017 at 7:47 AM, Belmiro Moreira
moreira.belmiro.email.lists@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
(osdist, osversion, 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: osdistro=MyOS, osversion=3.2,
localversion=1
security update to package P1: os
distro=MyOS, osversion=3.2,
local
version=2
security update to package P2: osdistro=MyOS, osversion=3.2,
local_version=4

The imageid 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 osversion 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 (osdistro,
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@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 'localversion' 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@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@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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 20, 2017 by rosmaita.fossdev_at_ (4,180 points)   1 2 2
0 votes

Hi Belmiro,

On 20 Sep. 2017 7:58 pm, "Belmiro Moreira" <
moreira.belmiro.email.lists@gmail.com> wrote:
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.

There is built in support in Horizon that allows displaying multiple image
category tabs where each takes contents from the list of images owned by a
specific project/tenant. In the Nectar research cloud this is what we rely
on to distinguish between "Public", "Project", "Nectar" (the base images we
maintain), and "Contributed" (images contributed by users who wish them to
be tested by us and effectively promoted as quality assured). When we
update a "Nectar" or "Contributed" image the old version stays public but
is moved into a project for deprecated images of that category, where
eventually we can clean it up.

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.

Could you use the same model as us?

Cheers,
b1airo


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 26, 2017 by Blair_Bethwaite (4,080 points)   1 3 5
0 votes

Hi Blair,
In the past we used the tabs but latest Horizon versions use the visibility
column/search instead.
The issue is that we would like the old images to continue to be
discoverable by everyone and have a image list that only shows the latest
ones.
If the images continue to be public they will be shown by the CLIs in the
default image-list. In our case the list was very long.

We are now using the “community” visibility to hide the old images from the
default image list. But it’s not ideal.
I will move the old spec about image lifecycle to glance.
https://review.openstack.org/#/c/327980/

Cheers,
Belmiro

On Wed, 27 Sep 2017 at 00:25, Blair Bethwaite blair.bethwaite@gmail.com
wrote:

Hi Belmiro,

On 20 Sep. 2017 7:58 pm, "Belmiro Moreira" <
moreira.belmiro.email.lists@gmail.com> wrote:

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.

There is built in support in Horizon that allows displaying multiple image
category tabs where each takes contents from the list of images owned by a
specific project/tenant. In the Nectar research cloud this is what we rely
on to distinguish between "Public", "Project", "Nectar" (the base images we
maintain), and "Contributed" (images contributed by users who wish them to
be tested by us and effectively promoted as quality assured). When we
update a "Nectar" or "Contributed" image the old version stays public but
is moved into a project for deprecated images of that category, where
eventually we can clean it up.

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.

Could you use the same model as us?

Cheers,
b1airo


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 27, 2017 by Belmiro_Moreira (2,620 points)   2 4
0 votes

On 27 September 2017 at 22:40, Belmiro Moreira
moreira.belmiro.email.lists@gmail.com wrote:
In the past we used the tabs but latest Horizon versions use the visibility
column/search instead.
The issue is that we would like the old images to continue to be
discoverable by everyone and have a image list that only shows the latest
ones.

Yeah I think we hit that as well and have a patch for category
listing. It's not something I have worked on but Sam can fill the
gaps... or it could be that this is actually the last problem we have
left with upgrading to a current version of the dashboard and so are
effectively in the same boat.

We are now using the “community” visibility to hide the old images from the
default image list. But it’s not ideal.

Not ideal because you don't want them discoverable at all?

I will move the old spec about image lifecycle to glance.
https://review.openstack.org/#/c/327980/

Looks like a useful spec!

--
Cheers,
~Blairo


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 27, 2017 by Blair_Bethwaite (4,080 points)   1 3 5
0 votes

Not ideal because we also have the real usecase for community images.
When users start to create/use community images these different use cases
(old public and real community) will be mixed.

Cheers,
Belmiro

On Wed, 27 Sep 2017 at 15:37, Blair Bethwaite blair.bethwaite@gmail.com
wrote:

On 27 September 2017 at 22:40, Belmiro Moreira
moreira.belmiro.email.lists@gmail.com wrote:

In the past we used the tabs but latest Horizon versions use the
visibility
column/search instead.
The issue is that we would like the old images to continue to be
discoverable by everyone and have a image list that only shows the latest
ones.

Yeah I think we hit that as well and have a patch for category
listing. It's not something I have worked on but Sam can fill the
gaps... or it could be that this is actually the last problem we have
left with upgrading to a current version of the dashboard and so are
effectively in the same boat.

We are now using the “community” visibility to hide the old images from
the
default image list. But it’s not ideal.

Not ideal because you don't want them discoverable at all?

I will move the old spec about image lifecycle to glance.
https://review.openstack.org/#/c/327980/

Looks like a useful spec!

--
Cheers,
~Blairo


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 27, 2017 by Belmiro_Moreira (2,620 points)   2 4
...