[openstack-announce] [0SSN-0090] Best practices when configuring Glance with COW backends

[Brian Rosmaita]

option, which includes a
"direct_url" field in the image-show response that can be used by
various OpenStack services to consume images directly from the storage
backend.  Exposing the 'direct_url' to end users leaks information
about the storage backend.  What exactly that information consists of
depends upon the backend in use and how it is configured, but in
general, it is not a good idea to provide hints that could be useful
to malicious actors in their attempts to compromise the backend
storage by some type of independent exploit.  The 'direct_url', being
read-only, may appear innocuous, but its use by services is usually to
perform some kind of optimized image data access that most likely does
not include computing a hash of the image data.

We therefore recommend that OpenStack services that require exposure
of the 'direct_url' image property be similarly configured to use an
internal-only-facing glance-api.  It is worth nothing that end users
who wish to download an image do not require access to the
'direct_url' image property because they can simply use the
image-data-download API call [5].

### Recommended Actions ###
A glance-api service with 'show_multiple_locations' enabled should
*never* be exposed directly to end users.  This setting should only be
enabled on an internal-only-facing glance-api that is used by
OpenStack services that require access to image locations.  This could
be done, for example, by running two glance-api services with
different configuration files and using the appropriate configuration
options for each service to specify the Image API endpoint to access,
and making sure the special internal endpoint is firewalled in such a
way that only the appropriate OpenStack services can contact it.

Similarly, enabling 'show_image_direct_url' exposes information about
the storage backend that could be of use to malicious actors in as yet
unknown exploits, so it should likewise only be enabled on an
internal-only-facing glance-api.

### Notes / References ###
[0] https://docs.openstack.org/api-ref/image/v2/index.html#show-image-schema
[1] Nova and Ironic use 'endpoint_override' in the '[glance]' section of
the configuration file; Cinder uses 'glance_api_servers' in the
'[DEFAULT]' section.
[2] OSSN-0065: https://wiki.openstack.org/wiki/OSSN/OSSN-0065
[3] The Glance "multihash" metadata pair of 'os_hash_algo' and
'os_hash_value' were introduced in Rocky to replace the legacy md5
'checksum' field.  The python-glanceclient has used multihash
checksumming for download verification since version 2.13.0.
[4] https://docs.openstack.org/releasenotes/glance/rocky.html#known-issues
[5] 
https://docs.openstack.org/api-ref/image/v2/index.html?#download-binary-image-data


### Contacts / References ###
Author: Brian Rosmaita, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0090
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1990157
Mailing List : [Security] tag on openstack-disc...@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg
CVE: none


OpenPGP_0xE834C62762D8856C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [OSSN-0086] erratum: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure

[Brian Rosmaita]

As you may recall, the fix for this issue required patches for both 
Cinder and the os-brick library.


The original patch for os-brick contained a flaw [0] that prevented the 
scaleio connector from operating when run under Python 2.7.  Thus for 
OpenStack releases supporting Python 2.7 (that is, Train and earlier), a 
second os-brick patch is required and is listed below.  (The Cinder and 
first os-brick patch are unchanged, but are listed below for completeness).


[0] https://bugs.launchpad.net/os-brick/+bug/1883654


 Patches 

Queens
* cinder: https://review.opendev.org/733110
* os-brick: https://review.opendev.org/733104
and https://review.opendev.org/736749

Rocky
* cinder: https://review.opendev.org/733109
* os-brick: https://review.opendev.org/733103
and https://review.opendev.org/736415

Stein
* cinder: https://review.opendev.org/733108
* os-brick: https://review.opendev.org/733102
and https://review.opendev.org/736395

Train
* cinder: https://review.opendev.org/733107
* os-brick: https://review.opendev.org/733100
and https://review.opendev.org/735989

Updated releases of os-brick incorporating the second patch are now 
available:

Stein: os-brick 2.8.6
Train: os-brick 2.10.4

Point releases of cinder for Stein and Train will be made as soon as 
possible.  These will be:

Stein: cinder 14.1.1, requires os-brick 2.8.6
Train: cinder 15.2.1, requires os-brick 2.10.4


### Contacts / References ###
Author: Brian Rosmaita, Red Hat
OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0086
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1823200
Mailing List : [Security] tag on openstack-disc...@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg
CVE: CVE-2020-10755

___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [OSSN-0086] Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure

[Brian Rosmaita]

Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
---

### Summary ###
This vulnerability is present when using Cinder with a Dell EMC
ScaleIO or VxFlex OS storage backend.

Note: The Dell EMC "ScaleIO" driver was rebranded as "VxFlex OS" in
the Train release.

### Affected Services / Software ###
Cinder / Ocata, Pike, Queens, Rocky, Stein, Train, Ussuri

This vulnerability applies only when using a Dell EMC ScaleIO/VxFlex
OS Backend with Cinder.  Other drivers are not impacted.

### Discussion ###
When using Cinder with the Dell EMC ScaleIO or VxFlex OS backend
storage driver, credentials for the entire backend are exposed in the
``connection_info`` element in all Block Storage v3 Attachments API
calls containing that element.  This enables an end user to create a
volume, make an API call to show the attachment detail information,
and retrieve a username and password that may be used to connect to
another user's volume.  Additionally, these credentials are valid for
the ScaleIO or VxFlex OS Management API, should an attacker discover
the Management API endpoint.

This issue was reported by David Hill and Eric Harney of Red Hat.

### Recommended Actions ###
Remediation of this issue consists of the following:

1. Patching the ScaleIO or VxFlex OS Cinder driver so that it no
   longer provides the password to Cinder when a Block Storage v3
   Attachments API response is constructed.

2. Patching the ScaleIO connector in the os-brick library so that it
   retrieves the password from a configuration file readable only by
   root.  (Note: the connector was not rebranded; both ScaleIO and
   VxFlex OS backends use the 'scaleio' os-brick connector.)

3. Patching the ScaleIO os-brick privileged file that allows the
   scaleio connector to escalate privileges for specific operations;
   this is necessary to allow the connector process to access the
   configuration file that is readable only by root.

4. Deploying a configuration file containing the password (and
   replication password, if applicable) to all compute nodes, cinder
   nodes, and anywhere you would perform a volume attachment in your
   deployment.

To refresh database information, all volumes should be detached and
reattached.

Because this remediation consists of deploying credentials in a
root-readable-only file, it is not suitable for the use case of
attaching a volume to a bare metal host.  Thus, the Dell EMC
ScaleIO/VxFlex OS storage backend for Cinder is *not recommended*
for use with bare metal hosts.

Note: The Ocata, Pike, Queens, and Rocky branches of OpenStack are in
the Extended Maintenance phase.  Point releases are no longer made
from these branches and security patches are produced only on a
reasonable effort basis.  Patches for Queens and Rocky are provided as
a courtesy.  Patches for Ocata and Pike are not available.

 Patches 

Both cinder and os-brick must be patched.  Documentation is provided
as part of the cinder patch concerning the new configuration file that
must be deployed to all compute nodes, cinder nodes, and anywhere you
would perform a volume attachment in your deployment.

Queens
* cinder: https://review.opendev.org/733110
* os-brick: https://review.opendev.org/733104

Rocky
* cinder: https://review.opendev.org/733109
* os-brick: https://review.opendev.org/733103

Stein
* cinder: https://review.opendev.org/733108
* os-brick: https://review.opendev.org/733102

Train
* cinder: https://review.opendev.org/733107
* os-brick: https://review.opendev.org/733100

Ussuri
* cinder: https://review.opendev.org/733106
* os-brick: https://review.opendev.org/733099

Alternatively, point releases for Stein, Train, and Ussuri will be
made as soon as possible.  These will be:

Stein: cinder 14.0.5, requires os-brick 2.8.5
Train: cinder 15.1.1, requires os-brick 2.10.3
Ussuri: cinder 16.0.1, requires os-brick 3.0.2

### Contacts / References ###
Author: Brian Rosmaita, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0086
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1823200
Mailing List : [Security] tag on openstack-disc...@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg
CVE: CVE-2020-10755

___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

[openstack-announce] [OSSN-0085] Cinder configuration option can leak secret key from Ceph backend

[Brian Rosmaita]

Cinder configuration option can leak secret key from Ceph backend
---

### Summary ###
This vulnerability is present only when Cinder has a Ceph backend
*and* the ``rbd_keyring_conf`` option in the Cinder configuration
file is set.  (The option is unset by default.)  Under these
circumstances, the keyring content may be leaked to a regular user.

### Affected Services / Software ###
Cinder, Pike, Queens, Rocky, Stein, Train

### Discussion ###
When the ``rbd_keyring_conf`` option is set, a user who creates a volume
and then does a local attach of that volume using the Cinder REST API,
may discover the keyring content for the Ceph cluster.  (This does not
apply to the normal Nova attach process.  The user must contact the
Cinder REST API directly for this exploit.)

If this user then gains access to the Ceph cluster independently of
Cinder, these credentials may be used to access any volume in the
cluster.

This issue was reported by Raphael Glon of OVH.

NOTE: This issue is different from OSSA-2019-003, through which Ceph
credentials could be leaked from the Nova REST API during error
conditions, but we suggest you take this opportunity to review that
security advisory and make sure your system has been updated or patched
to address it:

https://security.openstack.org/ossa/OSSA-2019-003.html

### Recommended Actions ###
Any installation currently using the ``rbd_keyring_conf`` option should
immediately stop using that option.  In order for Cinder backups to
continue working, the Ceph keyring secrets should be deployed directly
on cinder-backup hosts in their standard location:

/etc/ceph/.client..keyring

The ``rbd_keyring_conf`` is deprecated in the Ussuri release and will
be removed early in the 'V' development cycle.  There is no replacement
planned for this functionality.

### Contacts / References ###
Author: Brian Rosmaita, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0085
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1849624
Mailing List : [Security] tag on openstack-disc...@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg

___
OpenStack-announce mailing list
OpenStack-announce@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

Re: [openstack-dev] [glance] about use shared image with each other

[Brian Rosmaita]

On 11/21/18 7:16 AM, Rambo wrote:
> yes, but I also have a question, Do we have the quota limit for requests
> to share the image to each other? For example, someone shares the image
> with me without stop, how do we deal with it?

Given that the producer-consumer notifications are not handled by
Glance, this is not a problem.  (Or, to be more precise, not a problem
for Glance.)  A producer can share an image with you multiple times, but
since the producer cannot change your member-status, it will remain in
'pending' (or 'rejected' if you've already rejected it).  So there is no
quota necessary for this operation.

>  
> -- Original --
> *From: * "Brian Rosmaita";
> *Date: * Mon, Nov 19, 2018 10:26 PM
> *To: * "OpenStack Developmen";
> *Subject: * Re: [openstack-dev] [glance] about use shared image with
> each other
>  
> On 11/19/18 7:58 AM, Rambo wrote:
>> Hi,all
>>
>>      Recently, I want to use the shared image with each other.I find it
>> isn't convenient that the producer notifies the consumer via email which
>> the image has been shared and what its UUID is. In other words, why the
>> image api v2 is no provision for producer-consumer communication?
> 
> The design goal for Image API v2 image sharing was to provide an
> infrastructure for an "image marketplace" in an OpenStack cloud by (a)
> making it easy for cloud end users to share images, and (b) making it
> easy for end users not to be spammed by other end users taking advantage
> of (a).  When v2 image sharing was introduced in the Grizzly release, we
> did not want to dictate how producer-consumer communication would work
> (because we had no idea how it would develop), so we left it up to
> operators and end users to figure this out.
> 
> The advantage of email communication is that client side message
> filtering is available for whatever client a particular cloud end-user
> employs, and presumably that end-user knows how to manipulate the
> filters without learning some new scheme (or, if the end-user doesn't
> know, learning how to filter messages will apply beyond just image
> sharing, which is a plus).
> 
> Also, email communication is just one way to handle producer-consumer
> communication.  Some operators have adjusted their web interfaces so
> that when an end-user looks at the list of images available, a
> notification pops up if the end-user has any images that have been
> shared with them and are still in "pending" status.  There are various
> other creative things you can do using the normal API calls with regular
> user credentials.
> 
> In brief, we figured that if an image marketplace evolved in a
> particular cloud, producers and consumers would forge their own
> relationships in whatever way made the most sense for their particular
> use cases.  So we left producer-consumer communication out-of-band.
> 
>>       To make it is more convenient,  if we can add a task to change the
>> member_status from "pending" to "accepted" when we share the image with
>> each other. It is similar to the resize_confirm in Nova, we can control
>> the time interval in config.
> 
> You could do this, but that would defeat the entire purpose of the
> member statuses implementation, and hence I do not recommend it.  See
> OSSN-0005 [1] for more about this issue.
> 
> Additionally, since the Ocata release, "community" images have been
> available.  These do not have to be accepted by an end user (but they
> also don't show up in the default image-list response).  Who can
> "communitize" an image is governed by policy.
> 
> See [2] for a discussion of the various types of image sharing currently
> available in the Image API v2.  The Image Service API v2 api-ref [3]
> contains a brief discussion of image visibility and image sharing that
> may also be useful.  Finally, the Glance Ocata release notes [4] have an
> extensive discussion of image visibility.
> 
>>        Can you tell me more about this?Thank you very much!
> 
> The original design page on the wiki [5] has a list of 14 use cases we
> wanted to address; looking through those will give you a better idea of
> why we made the design choices we did.
> 
> Hope this helps!
> 
> cheers,
> brian
> 
> [0]
> http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
> [1] https://wiki.openstack.org/wiki/OSSN/1226078
> [2]
> http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
> [3] https://developer.openstack.org/api-ref/image/v2/
> [4] https://docs.openstack.org/releasenotes/glance/ocata.html
> [5] https://wik

Re: [openstack-dev] [glance] about use shared image with each other

[Brian Rosmaita]

On 11/19/18 7:58 AM, Rambo wrote:
> Hi,all
> 
>      Recently, I want to use the shared image with each other.I find it
> isn't convenient that the producer notifies the consumer via email which
> the image has been shared and what its UUID is. In other words, why the
> image api v2 is no provision for producer-consumer communication?

The design goal for Image API v2 image sharing was to provide an
infrastructure for an "image marketplace" in an OpenStack cloud by (a)
making it easy for cloud end users to share images, and (b) making it
easy for end users not to be spammed by other end users taking advantage
of (a).  When v2 image sharing was introduced in the Grizzly release, we
did not want to dictate how producer-consumer communication would work
(because we had no idea how it would develop), so we left it up to
operators and end users to figure this out.

The advantage of email communication is that client side message
filtering is available for whatever client a particular cloud end-user
employs, and presumably that end-user knows how to manipulate the
filters without learning some new scheme (or, if the end-user doesn't
know, learning how to filter messages will apply beyond just image
sharing, which is a plus).

Also, email communication is just one way to handle producer-consumer
communication.  Some operators have adjusted their web interfaces so
that when an end-user looks at the list of images available, a
notification pops up if the end-user has any images that have been
shared with them and are still in "pending" status.  There are various
other creative things you can do using the normal API calls with regular
user credentials.

In brief, we figured that if an image marketplace evolved in a
particular cloud, producers and consumers would forge their own
relationships in whatever way made the most sense for their particular
use cases.  So we left producer-consumer communication out-of-band.

>       To make it is more convenient,  if we can add a task to change the
> member_status from "pending" to "accepted" when we share the image with
> each other. It is similar to the resize_confirm in Nova, we can control
> the time interval in config.

You could do this, but that would defeat the entire purpose of the
member statuses implementation, and hence I do not recommend it.  See
OSSN-0005 [1] for more about this issue.

Additionally, since the Ocata release, "community" images have been
available.  These do not have to be accepted by an end user (but they
also don't show up in the default image-list response).  Who can
"communitize" an image is governed by policy.

See [2] for a discussion of the various types of image sharing currently
available in the Image API v2.  The Image Service API v2 api-ref [3]
contains a brief discussion of image visibility and image sharing that
may also be useful.  Finally, the Glance Ocata release notes [4] have an
extensive discussion of image visibility.

>        Can you tell me more about this?Thank you very much!

The original design page on the wiki [5] has a list of 14 use cases we
wanted to address; looking through those will give you a better idea of
why we made the design choices we did.

Hope this helps!

cheers,
brian

[0]
http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
[1] https://wiki.openstack.org/wiki/OSSN/1226078
[2]
http://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html
[3] https://developer.openstack.org/api-ref/image/v2/
[4] https://docs.openstack.org/releasenotes/glance/ocata.html
[5] https://wiki.openstack.org/wiki/Glance-api-v2-image-sharing


> 
> Best Regards
> Rambo
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack] [glance] task in pending state, image in uploading state

[Brian Rosmaita]

On 11/12/18 7:29 PM, Bernd Bausch wrote:
> Thanks Brian. It's great to get an email from Mr. Glance.
> 
> I managed to patch Devstack, and a first test was successful. Perfect!

Glad it worked!

> A bit late, I then found numerous warnings in release notes and other
> documents that UWSGI should not be used when deploying Glance. My
> earlier web searches flew by these documents without noticing them.

We haven't made it easy for you in devstack, though.  As you can see
from the patch, it requires coordination across a few different teams to
make the appropriate changes to get all tests passing and the patch
merged.  When everyone's back from the summit, I'll see if I can get a
coordinated push across teams to get this done for Stein milestone 2.

This won't solve the larger problem of Glance not running in uWSGI,
though.  I'd refer people interested in having that happen to my
statement about this issue in the Queens release notes [0]; the
situation described there still stands.

[0]
https://docs.openstack.org/releasenotes/glance/queens.html#relnotes-16-0-0-stable-queens-known-issues


> Bernd
> 
> On 11/12/2018 11:27 PM, Brian Rosmaita wrote:
>> On 11/12/18 5:07 AM, Bernd Bausch wrote:
>>> Trying Glance's new import process, my images are all stuck in status
>>> uploading (both methods glance-direct and web-download).
>>>
>>> I can see that there are tasks for those images; they are pending. The
>>> Glance API log doesn't contain anything that clues me in (debug logging
>>> is enabled).
>>>
>>> The source code is too involved for my feeble Python and OpenStack
>>> Internals skills.
>>>
>>> *How can I find out what blocks the tasks? *
>>>
>>> This is a stable Rocky Devstack without any customization of the Glance
>>> config.
>>>
>> The tasks engine Glance uses to facilitate the "new" (experimental in
>> Pike, current in Queens) image import process does not work when Glance
>> is deployed as a WSGI application using uWSGI [0]; as you observed, the
>> tasks remain stuck in 'pending'.  You can apply this patch [1] to your
>> devstack Glance and restart devstack@g-api and image import should work
>> without additional glance api-changes (the patch applied cleanly last
>> time I checked, which was a Stein-1 milestone devstack; it should apply
>> cleanly to your stable Rocky devstack).  You may also want to take a
>> look at the Glance admin guide [2] to see what configuration options are
>> available.
>>
>> [0]
>> https://docs.openstack.org/releasenotes/glance/queens.html#relnotes-16-0-0-stable-queens-known-issues
>>
>> [1] https://review.openstack.org/#/c/545483/
>> [2]
>> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html
>>
>>
>>> ___
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [glance] Rocky image import stuck

[Brian Rosmaita]

On 11/7/18 8:46 AM, Bernd Bausch wrote:
> Does the new image import process work? Am I missing something? Uploaded
> images stay in an intermediate state, either /uploading/ or /importing/,
> and never become /active.///Where should I look?

Apologies for the late reply to your question.  For anyone else with a
similar question, I replied to your thread on the general list:

http://lists.openstack.org/pipermail/openstack/2018-November/047186.html

> 
> On a stable/Rocky Devstack, I do:
> 
> openstack image create --disk-format qcow2 myimg
> 
> Image status is /queueing/, as expected.
> 
> glance image-stage --file devstack/files/Fedora...qcow2 --progress
> IMAGE_ID
> 
> Image status is /uploading/. A copy of the image is on
> /tmp/staging/IMAGE_ID.
> 
> glance image-import --import-method glance-direct IMAGE_ID
> 
> Sometimes, the status remains /uploading, /sometimes it turns
> /importing, /never /active./
> 
> glance-api log grep'd for the image ID:
> 
> Nov 07 18:51:36 rocky devstack@g-api.service[1033]: INFO
> glance.common.scripts.image_import.main [None
> req-7a747213-c160-4423-b703-c6cad15b9217 admin admin] Task
> ec4b36fd-dece-4f41-aa8d-337d01c239f1: Got image data uri
> file:///tmp/staging/72a6d7d0-a538-4922-95f2-1649e9702eb2 to be imported
> Nov 07 18:51:37 rocky devstack@g-api.service[1033]: DEBUG
> glance_store._drivers.swift.store [None
> req-7a747213-c160-4423-b703-c6cad15b9217 admin admin] Adding image
> object '72a6d7d0-a538-4922-95f2-1649e9702eb2' to Swift {{(pid=2250) add
> /usr/local/lib/python2.7/dist-packages/glance_store/_drivers/swift/store.py:941}}
> Nov 07 18:51:45 rocky devstack@g-api.service[1033]: DEBUG swiftclient
> [None req-7a747213-c160-4423-b703-c6cad15b9217 admin admin] REQ: curl -i
> http://192.168.1.201:8080/v1/AUTH_9495609cff044252965f8c3e5e86f8e0/glance/72a6d7d0-a538-4922-95f2-1649e9702eb2-1
> -X PUT -H "X-Auth-Token: gABb4rWowjLQ..." {{(pid=2250) http_log
> /usr/local/lib/python2.7/dist-packages/swiftclient/client.py:167}}
> Nov 07 18:51:45 rocky devstack@g-api.service[1033]: DEBUG
> glance_store._drivers.swift.store [None
> req-7a747213-c160-4423-b703-c6cad15b9217 admin admin] Wrote chunk
> 72a6d7d0-a538-4922-95f2-1649e9702eb2-1 (1/?) of length 20480 to
> Swift returning MD5 of content: 5139500edbb5814a1351100d162db333
> {{(pid=2250) add
> /usr/local/lib/python2.7/dist-packages/glance_store/_drivers/swift/store.py:1024}}
> 
> And then nothing. So it does send a 200MB chunk to Swift. I can see it
> on Swift, too. But it stops after the first chunk and forgets to send
> the rest.
> 
> After I tried that a few times, now it doesn't even upload the first
> chunk. Nothing in Swift at all. No error in the Glance API log either.
> 
> Same problem with the /image-upload-via-import /command. I also tried
> the /web-download /import method; same result.
> 
> In all these cases, the image remains in an non-active state forever,
> i.e. an hour or so, when I lose patience and delete it.
> 
> "Classic" upload works (/openstack image create --file /). The log
> file then shows the expected chunk uploads to Swift.
> 
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [glance] task in pending state, image in uploading state

[Brian Rosmaita]

On 11/12/18 5:07 AM, Bernd Bausch wrote:
> Trying Glance's new import process, my images are all stuck in status
> uploading (both methods glance-direct and web-download).
> 
> I can see that there are tasks for those images; they are pending. The
> Glance API log doesn't contain anything that clues me in (debug logging
> is enabled).
> 
> The source code is too involved for my feeble Python and OpenStack
> Internals skills.
> 
> *How can I find out what blocks the tasks? *
> 
> This is a stable Rocky Devstack without any customization of the Glance
> config.
> 

The tasks engine Glance uses to facilitate the "new" (experimental in
Pike, current in Queens) image import process does not work when Glance
is deployed as a WSGI application using uWSGI [0]; as you observed, the
tasks remain stuck in 'pending'.  You can apply this patch [1] to your
devstack Glance and restart devstack@g-api and image import should work
without additional glance api-changes (the patch applied cleanly last
time I checked, which was a Stein-1 milestone devstack; it should apply
cleanly to your stable Rocky devstack).  You may also want to take a
look at the Glance admin guide [2] to see what configuration options are
available.

[0]
https://docs.openstack.org/releasenotes/glance/queens.html#relnotes-16-0-0-stable-queens-known-issues
[1] https://review.openstack.org/#/c/545483/
[2]
https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html

> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [glance] next python-glanceclient release

[Brian Rosmaita]

Hello Glancers,

I was looking at a Cinder patch [0] and it made me realize that we
should do a glanceclient release that includes the
multihash-download-verification [1] before the next scheduled Stein
release (which was to be 3.0.0, basically Rocky with v1 support removed;
see [2]).  I think it would be good to have the new verification change
released so other projects can consume the code and we can find out
sooner if it breaks anyone.  (I'm worried about allow_md5_fallback=False
[6], which I think is definitely the right thing for the CLI client, but
the discussion about allowing users to pick an os_hash_algo on Iain's
spec-lite [4] is making me worry about the effect that default value
could have on other services.)

Here are the options:
(1) backport [1] to stable/rocky and cut 2.12.1
(2) cut 2.13.0 from master and make it the first Stein glanceclient,
leaving legacy md5 checksum verification the only validation option in Rocky
(3) wait for 3.0.0 to include [1]
(4) change the default for allow_md5_fallback to True for the data()
function [6] (the CLI code already explicitly sets it and won't need to
be adjusted [5]) and then do (1) or (2) or (3)

Obviously, I don't like (3).  Not sure I like (4) either, but figured we
should at least think about it.

If we pick (1), we should merge the periodic tips job change [3] to
master and immediately backport it to stable/rocky before cutting the
release.  That way we won't have any unreleased patches sitting in
stable/rocky.

Let me know what you think.

cheers,
brian

[0] https://review.openstack.org/#/c/611081/
[1]
http://git.openstack.org/cgit/openstack/python-glanceclient/commit/?id=a4ea9f0720214bd4aa6d72e81776e1260b30ad2f
[2] https://launchpad.net/python-glanceclient/+series
[3] https://review.openstack.org/#/c/599844/
[4] https://review.openstack.org/#/c/597648/
[5]
http://git.openstack.org/cgit/openstack/python-glanceclient/tree/glanceclient/v2/shell.py?id=a4ea9f0720214bd4aa6d72e81776e1260b30ad2f#n521
[6]
http://git.openstack.org/cgit/openstack/python-glanceclient/tree/glanceclient/v2/images.py?id=a4ea9f0720214bd4aa6d72e81776e1260b30ad2f#n201

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][upgrade-checkers] Question about glance rocky upgrade release note

[Brian Rosmaita]

On 9/24/18 3:13 PM, Matt Riedemann wrote:
> On 9/24/2018 2:06 PM, Matt Riedemann wrote:
>> Are there more specific docs about how to configure the 'image import'
>> feature so that I can be sure I'm careful? In other words, are there
>> specific things a "glance-status upgrade check" check could look at
>> and say, "your image import configuration is broken, here are details
>> on how you should do this"
Apologies for this delayed reply.
> I guess this answers the question about docs:
> 
> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html

Yes, you found the correct docs.  They could probably use a revision to
eliminate some of the references to Pike and Queens, but I think the
content is accurate with respect to proper configuration of image import.
> Would a basic upgrade check be such that if glance-api.conf contains
> enable_image_import=False, you're going to have issues since that option
> is removed in Rocky?

I completely missed this question when I saw this email a few weeks ago.

Yes, if a Queens glance-api.conf has enable_image_import=False, then it
was disabled on purpose since the default in Queens was True.  Given the
Rocky defaults for import-related config (namely, all import_methods are
enabled), the operator may need to make some kind of adjustment.

As a side point, although the web-download import method is enabled by
default in Rocky, it has whitelist/blacklist configurability to restrict
what kind of URIs end-users may access.  By default, end users are only
able to access URIs using the http or https scheme on the standard ports.

Thanks for working on the upgrade-checker goal for Glance!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][glance][cinder][keystone][requirements] blocking oslo.messaging 9.0.0

[Brian Rosmaita]

On 10/8/18 11:59 PM, Matthew Thode wrote:
> several projects have had problems with the new release, some have ways
> of working around it, and some do not.  I'm sending this just to raise
> the issue and allow a place to discuss solutions.
> 
> Currently there is a review proposed to blacklist 9.0.0, but if this is
> going to still be an issue somehow in further releases we may need
> another solution.
> 
> https://review.openstack.org/#/c/608835/

As indicated in the commit message on the above patch, 9.0.0 contains a
bug that's been fixed in oslo.messaging master, so I don't think there's
any question that 9.0.0 has to be blacklisted.

As far as the timing/content of 9.0.1, however, that may require further
discussion.

(In other words, I'm saying that when you say 'another solution', my
position is that we should take 'another' to mean 'additional', not
'different'.)

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] spec-lite: Embed validation data in locations

[Brian Rosmaita]

I put together an etherpad outlining the changes to Iain's spec-lite
[0] that we discussed at today's glance meeting:

https://etherpad.openstack.org/p/glance-spec-lite-stein-locations-with-checksum

It's probably best to leave comments on the etherpad.

cheers,
brian

[0] https://review.openstack.org/#/c/597648/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][glance] Heat image resource support issue

[Brian Rosmaita]

On Wed, Sep 5, 2018 at 11:12 AM Rico Lin  wrote:

>
> On Wed, Sep 5, 2018 at 8:47 PM Brian Rosmaita 
> wrote:
>
> Since Queens, Glance has had a 'web-download' import method that takes a
>> URL [0].  It's enabled by default, but operators do have the ability to
>> turn it off.  (There's an API call to see what methods are enabled in a
>> particular cloud.)  Operators also have the ability to restrict what URLs
>> are acceptable [1], but that's probably a good thing.
>>
>> In short, Glance does have the ability to do what you need since Queens,
>> but there's no guarantee that it will be available in all clouds and for
>> all URLs.  If you foresee that as a problem, it would be a good idea to get
>> together with the Glance team at the PTG to discuss this issue.  Please add
>> it as a topic to the Glance PTG planning etherpad [3] as soon as you can.
>>
> Cool! Thank Brian.
> Sounds like something we can use, just one small question in my mind. In
> order to use `web-download` in image resource, we need to create an empty
> image than use import to upload that imge. I have try that scenrio by
> myself now (I'm not really diving into detail yet) by:
> 1. create an empty image(like `openstack image create --container-format
> bare --disk-format qcow2 img_name`)
> 2. and than import image  (like `glance image-import --import-method
> web-download --uri
> https://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img `)
> But that image stuck in queued after first step.
> dose this scenario supported by glance? Or where did I do wrong?
>

That scenario should work, unless you are running glance under uwsgi, in
which case the task engine (used to import the image) does not run.  You
can tell that's the problem if as an admin user you use the command 'glance
task-list'.  You should see a task of type 'api_image_import' with status
'pending'.  (You can do 'glance task-show ' to see the details of
the task.)

If you are using devstack, you can apply this patch before you call
stack.sh: https://review.openstack.org/#/c/545483/  .  It will allow
everything except Glance to run under uwsgi.


>
>
>>
>> [0]
>> https://developer.openstack.org/api-ref/image/v2/index.html#interoperable-image-import
>> [1]
>> https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html#configuring-the-web-download-method
>> [3] https://etherpad.openstack.org/p/stein-ptg-glance-planning
>>
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][glance] Heat image resource support issue

[Brian Rosmaita]

On Thu, Aug 30, 2018 at 5:55 AM Rico Lin  wrote:

> Hi Glance team
>

Hi Rico, sorry about the delay in answering your email.


> Glance V1 image API been deprecated for a long while, and V2 has been used
> widely. Heat image resource would like to change to use V2 as well, but
> there is an unsolved issue, which blocks us from adopting V2. Right now, to
> image create require Heat to download the image to Heat service and
> re-upload it to Glance. This behavior causes heat service a great burden
> which in a heat team discussion (years ago), we decide to deprecated V1
> Image resource in Heat and will add V2  image resource once this is
> resolved.
> So I have been wondering if there's some workaround for this issue? Or if
> glance can support accept URL as image import (and then reuse client lib
> to download to glance side)? Or if anyone got a better solution for this?
>

Since Queens, Glance has had a 'web-download' import method that takes a
URL [0].  It's enabled by default, but operators do have the ability to
turn it off.  (There's an API call to see what methods are enabled in a
particular cloud.)  Operators also have the ability to restrict what URLs
are acceptable [1], but that's probably a good thing.

In short, Glance does have the ability to do what you need since Queens,
but there's no guarantee that it will be available in all clouds and for
all URLs.  If you foresee that as a problem, it would be a good idea to get
together with the Glance team at the PTG to discuss this issue.  Please add
it as a topic to the Glance PTG planning etherpad [3] as soon as you can.

cheers,
brian

[0]
https://developer.openstack.org/api-ref/image/v2/index.html#interoperable-image-import
[1]
https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html#configuring-the-web-download-method
[3] https://etherpad.openstack.org/p/stein-ptg-glance-planning


>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] [glance] share image with domain

[Brian Rosmaita]

On Tue, Jul 10, 2018 at 8:04 AM Christian Berendt
 wrote:

> It is possible to add a domain as a member, however this is not taken in 
> account. It should be mentioned that you can also add non-existing project 
> ids as a member.

Yes, you can add any string as an image member.  Back when image
sharing was implemented, it was thought that making an extra call to
keystone to verify the member_id would be too expensive because people
would be sharing so many images all the time, but AFAIK, that hasn't
turned out to be the case.  So it may be worth revisiting this issue.

> For me it looks like it is not possible to share a image with visibility 
> “shared” with a domain.

That is correct, the items in the member-list are treated as project
IDs.  (Actually, that's not entirely true, but will be completely true
very early in the Stein development cycle.[0])

> Are there known workarounds or scripts for that use case?

I'm not aware of any.  You could write a script that took a domain ID,
got the list of projects in that domain, and shared the image with all
those projects, but then you'd have a synchronization problem when
projects were added to/removed from the domain, so that's probably not
a good idea.

If this is an important use case, please consider proposing a Glance
spec [1] or proposing it as a topic for the upcoming PTG [2].

cheers,
brian

[0] 
https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/spec-lite-deprecate-owner_is_tenant.html
[1] http://git.openstack.org/cgit/openstack/glance-specs
[2] https://etherpad.openstack.org/p/stein-ptg-glance-planning

> Christian.
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [glance] FFE for multihash

[Brian Rosmaita]

I'm asking for a Feature Freeze Exception for the glance-side work for
the Secure Hash Algorithm Support (multihash) feature [0].  The work
is underway and should be completed early next week.

cheers,
brian

[0] 
https://specs.openstack.org/openstack/glance-specs/specs/rocky/approved/glance/multihash.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] bug smash today

[Brian Rosmaita]

Today (Friday, 8 June UTC time) is our Rocky-2 bug smash.  Hang out in
#openstack-glance and keep the etherpad updated:

https://etherpad.openstack.org/p/glance-rocky-bug-smash

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] Rocky-2 milestone release

[Brian Rosmaita]

Status:

glanceclient - released 2.11.1 today

glance_store - one outstanding patch that would be worth including in
the release:
- https://review.openstack.org/#/c/534745/  (use only exceptions for
uri validations)

glance - two patches we should get in:
- https://review.openstack.org/#/c/514114/ (refactor exception
handling in cmd.api) (has one +2)
- https://review.openstack.org/#/c/572534/ (remove deprecated
'enable_image_import' option)
- note: will need to regenerate the config files before proposing a release


cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] python-glanceclient release status

[Brian Rosmaita]

On Mon, Apr 2, 2018 at 6:28 PM, Brian Rosmaita
<rosmaita.foss...@gmail.com> wrote:
> These need to be reviewed in master:
> - https://review.openstack.org/#/c/50/
> - https://review.openstack.org/#/c/556292/

Thanks for the reviews.  The requested changes have been made and Zuul
has given a +1, so ready for reviews again!

> Backports needing review:
> - https://review.openstack.org/#/c/555436/

This has a +2 from Sean; it's up to Erno now.

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] python-glanceclient release status

[Brian Rosmaita]

These need to be reviewed in master:
- https://review.openstack.org/#/c/50/
- https://review.openstack.org/#/c/556292/

Backports needing review:
- https://review.openstack.org/#/c/555436/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] python-glanceclient release status

[Brian Rosmaita]

Adding another review to the list:
https://review.openstack.org/#/c/556292/

Also, https://review.openstack.org/50 has been updated with more tests.

Once those are approved, they'll need to be backported to
stable/queens so we can release 2.10.0

On Thu, Mar 22, 2018 at 8:55 PM, Brian Rosmaita
<rosmaita.foss...@gmail.com> wrote:
> As promised at today's Glance meeting, here's an update on the release
> status for the glanceclient bugfix release for stable/queens.
>
> There's another bug I think needs to be addressed:
> https://bugs.launchpad.net/python-glanceclient/+bug/1758149
>
> I've got a patch up so I can get feedback (particularly on the error 
> messages):
> https://review.openstack.org/50
>
> I'll be adding more tests to the patch (it needs them).
>
> It's already Friday UTC, so we won't be releasing 2.10.0 until Monday
> at the earliest.  Here are the backports that still require approval:
>
> https://review.openstack.org/#/c/555277/
> https://review.openstack.org/#/c/555390/
> https://review.openstack.org/#/c/555436/
>
> and a cherry-pick of 50 when that's done.
>
>
> cheers,
> brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] python-glanceclient release status

[Brian Rosmaita]

As promised at today's Glance meeting, here's an update on the release
status for the glanceclient bugfix release for stable/queens.

There's another bug I think needs to be addressed:
https://bugs.launchpad.net/python-glanceclient/+bug/1758149

I've got a patch up so I can get feedback (particularly on the error messages):
https://review.openstack.org/50

I'll be adding more tests to the patch (it needs them).

It's already Friday UTC, so we won't be releasing 2.10.0 until Monday
at the earliest.  Here are the backports that still require approval:

https://review.openstack.org/#/c/555277/
https://review.openstack.org/#/c/555390/
https://review.openstack.org/#/c/555436/

and a cherry-pick of 50 when that's done.


cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] bug squad meetings start Monday

[Brian Rosmaita]

The Glance Bug Squad will meet biweekly on Monday of even-numbered ISO
weeks at 10:00 UTC in #openstack-glance.  The meeting will last 45
minutes.

The first meeting will be 19 March 2018.

Agenda and notes: https://etherpad.openstack.org/p/glance-bug-squad-meeting

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] OSSN-0076 brainstorming session Friday 16 March

[Brian Rosmaita]

I'm working on a spec to alleviate OSSN-0076 that would follow up the
OSSN-0075 proposal [0], but have run into some problems.  It would be
helpful to lay them out and get some feedback.  I'll be in the
#openstack-glance channel at 16:30 UTC tomorrow (Friday) to discuss.
Will take less than 1/2 hour.

cheers,
brian

[0] https://review.openstack.org/#/c/468179/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] bi-weekly bug team meeting

[Brian Rosmaita]

To anyone interested in attending the bug team meetings:

I'm proposing a 45 minute meeting every other week beginning the week
of March 19.  Time is 10:00 UTC (unless that turns out to be
unworkable for everybody).  Please indicate your preference for day of
the week on this Doodle poll:

https://doodle.com/poll/39xbzeu8nh4bgkhq

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [glance] proposal to deprecate owner_is_tenant option

[Brian Rosmaita]

Hello Operators,

There's a spec-lite up to deprecate the owner_is_tenant option, with
the goal being to eliminate the option so that the owner of an image
is always the project (tenant).  Based on a survey of operators in
March 2017, no one is using the option in its non-default
configuration, so no migration path is proposed.

Please leave comments on the gerrit review before 12:00 UTC on Tuesday 13 March:
https://review.openstack.org/#/c/550096/

Thanks!

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [glance] fixing OSSN-0075

[Brian Rosmaita]

Hello Operators,

The spec for a fix of OSSN-0075, "Deleted Glance image IDs may be
reassigned", has been revised after discussions at the PTG last week
and is ready for your comments.  As you may be aware, the spec has
been held up over disagreement about the proper way to fix the issue,
but the Glance team has agreed on a way forward in which the
interoperability and backward compatibility aspects win out.

Please read through the spec and leave comments before Tuesday 13
March at 12:00 UTC:
https://review.openstack.org/#/c/468179/

Thanks!

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Glance] Changes to Glance core team

[Brian Rosmaita]

+1 to all the above.

Thanks for Flavio and Mike for all they've done for Glance, and
looking forward to working more with Sean in the future.

cheers,
brian

On Thu, Mar 1, 2018 at 7:09 AM, Erno Kuvaja  wrote:
> Hi all,
>
> At the start of the cycle is good time to have a look of the Glance
> reviewers and based on the discussions amongs the group during and
> before the PTG I'd like to propose following changes:
>
> 1) Adding Sean McGinnis to Glance core. The current active core team
> has been very positive about including Sean and he feels like he is
> comfortable to take the +2 responsibility on. It might take some more
> time for him to get fully familiar with Glance code base so we will
> leave him room to approve changes to the parts of Glance he feels to
> be ready and grow his expertise across.
>
> 2) Removing Flavio Percoco from Glance core. Flavio requested to be
> removed already couple of cycles ago and we did beg him to stick
> around to help with the Interoperable Image Import which of he has
> been integral part of designing since the very beginning and due to
> his knowledge of the internals of the Glance tasks. The majority of
> this work is finished and we would like to thank Flavio for his help
> and hard work for Glance community.
>
> 3) removing Mike Fedosin from glance core. Mike joined back to glance
> ocre when we did desperately need help reviewing changes and we are
> definitely grateful for his efforts to help us out when needed. By the
> looks of it, Mike has moved on to different responsibilities.
>
> As usual, if the circumstances changes and Flavio or Mike will find
> time and interest to serve our community again, we would be more than
> happy to fast-track them back to the core team.
>
> I'd like to take the opportunity to give big thanks for all of them
> for their help and contributions to Glance and I do hope seeing them
> all around for the cycles to come.
>
> I'll leave until next week before doing these changes in case I have
> missed something that has changed in the situation recently.
>
> best,
> Erno jokke_ Kuvaja
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (23 Feb - 1 March)

[Brian Rosmaita]

Hello Glancers,

RC-3 was released today [0] and we expect it to be the final release
candidate (unless someone finds a critical problem in the next 3
hours).

Priority for this week is preparing for the PTG.  If you can't attend,
Erno has posted a topic list [1] you can look at.  For topics without
specs, feel free to leave questions and comments for items you would
like to see addressed.  For topics with specs proposed, please read
and comment on the gerrit reviews.

Erno has also posted a rough schedule of what we'll be discussing when
[2].  We'll keep an eye on the #openstack-glance IRC channel during
the PTG, but your best bet for getting our attention is to put
comments on the etherpad [1].

The Glance meeting is cancelled on 1 March due to the PTG.

Best wishes for safe travels for those attending the PTG, and for
those at home ... stay safe out there!

cheers,
brian

[0] http://lists.openstack.org/pipermail/openstack-dev/2018-February/127642.html
[1] https://etherpad.openstack.org/p/glance-rocky-ptg
[2] https://ethercalc.openstack.org/5ow7tkekq151

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (16 Feb - 21 Feb)

[Brian Rosmaita]

Hello Glancers,

(1)  Queens RC-2 was tagged Thursday (late Thursday night Pacific
time, but Thursday nonetheless).  A good place to concentrate testing
effort is on the URI filtering feature of the web-download import
method.  Remember that if you build a devstack, set WSGI_MODE=mod_wsgi
in your local.conf so that the import task will be processed.

(2)  We're aiming for RC-3 for Monday.  There will be some
documentation and releasenote update patches, and patches for the
glance-manage tool.  (And any image import bugs found during testing.)
 Keep an eye on the etherpad for stuff to review:
https://etherpad.openstack.org/p/glance-queens-rc1-patches
(yes, that's "rc1" in the url, I didn't want to waste a perfectly good etherpad)

(3)  Reminder: Erno will be making final decisions on what will happen
for Glance at the PTG on Monday morning.  So get your topic proposals
and votes for the stuff you want to discuss (or have discussed, if
unfortunately you won't be there) on the etherpad before 0900 UTC
Monday:
https://etherpad.openstack.org/p/glance-rocky-ptg-planning

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (9 Feb - 15 Feb)

[Brian Rosmaita]

Congratulations to Erno for his election as the Rocky PTL!  Erno is
taking over PTG planning, so don't forget to add ideas to the planning
etherpad:
https://etherpad.openstack.org/p/glance-rocky-ptg-planning

The first Release Candidate for the Queens edition of Glance was
released today and the stable/queens branch was cut.

Our focus is still on Queens this week.  It would be a good idea to
give RC-1 a workout, paying particular attention to interoperable
image import and the glance-manage and glance-scrubber tools, which
underwent some refactoring and enhancements this cycle.

We'll continue to track the development toward RC-2 on this etherpad:
https://etherpad.openstack.org/p/glance-queens-rc1-patches

Add any bugs you find that are release critical to that etherpad so
that the core team can verify that they need to be backported to
stable/queens.

There will definitely be an RC-2, which will contain whatever we come
up with to address https://bugs.launchpad.net/glance/+bug/1747869

But don't let that stop you from testing out RC-1!

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] glance-manage db check feature needs reviews

[Brian Rosmaita]

Hello Glancers,

Please take a look at Bhagyashri's patch, which was given a FFE.

There's a slight deviation from the spec, so I need feedback about
whether this is acceptable (spoiler alert: I think it's OK).  So
please comment on that aspect of the patch even if you don't have time
at the moment to review the code thoroughly.  See my comment on PS11
for details.

thanks,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] FFE request for --check feature

[Brian Rosmaita]

Thanks for following up on this, Abhishek.  After our discussion
approving this at the weekly meeting, I completely forgot to send out
an update.  As Abhishek indicated, the discussion was positive, and
this FFE is APPROVED.

cheers,
brian


On Mon, Feb 5, 2018 at 3:56 AM, Abhishek Kekane  wrote:
> Sorry, Forgot to add meeting logs link in previous mail.
>
> Here it is;
> http://eavesdrop.openstack.org/meetings/glance/2018/glance.2018-02-01-14.01.log.html#l-164
>
> Thank you,
>
> Abhishek Kekane
>
> On Mon, Feb 5, 2018 at 12:30 PM, Abhishek Kekane  wrote:
>>
>> We have discussed this in glance weekly meeting [1] and most of the core
>> reviewers are inclined towards accepting this FFE.
>>
>> +1 from my side as this --check command will be very helpful for
>> operators.
>>
>> Thank you Bhagyashri for working on this.
>>
>> Abhishek Kekane
>>
>> On Wed, Jan 31, 2018 at 7:29 PM, Shewale, Bhagyashri
>>  wrote:
>>>
>>> Hi Glance Folks,
>>>
>>> I'm requesting an Feature Freeze Exception for the lite-spec
>>> http://specs.openstack.org/openstack/glance-specs/specs/untargeted/glance/lite-spec-db-sync-check.html
>>> which is implemented by https://review.openstack.org/#/c/455837/8/
>>>
>>> Regards,
>>> Bhagyashri Shewale
>>>
>>> __
>>> Disclaimer: This email and any attachments are sent in strictest
>>> confidence
>>> for the sole use of the addressee and may contain legally privileged,
>>> confidential, and proprietary data. If you are not the intended
>>> recipient,
>>> please advise the sender by replying promptly to this email and then
>>> delete
>>> and destroy this email and any attachments without any further use,
>>> copying
>>> or forwarding.
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] how to update published pike docs

[Brian Rosmaita]

On Wed, Jan 31, 2018 at 1:47 PM, Andreas Jaeger <a...@suse.com> wrote:
> On 2018-01-31 18:22, Jeremy Stanley wrote:
>> On 2018-01-31 12:07:30 -0500 (-0500), Brian Rosmaita wrote:
>> [...]
>
> That fixed it - thanks,
>

Yes! Thanks for the quick work.  All fixed now!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [docs] how to update published pike docs

[Brian Rosmaita]

Hello Docs people,

The glance install docs currently published on docs.o.o don't include
a correction we merged a while back, and I get a few bug reports filed
on this particular problem every week.  (It's great that people are
willing to file corrections, but the duplicates are really piling up!)
 Anyway, here's what's happening:

published docs:
https://docs.openstack.org/glance/pike/install/install-debian.html
(can't see the create db stuff -- you may need to look at the next
link first to see what I mean)

docs in github:
https://github.com/openstack/glance/blob/stable/pike/doc/source/install/install-debian.rst
(can see the create db stuff)

glance stable/pike in the repo:
http://git.openstack.org/cgit/openstack/glance?h=stable%2Fpike
You can see stable/pike head is at the fix.

What do we need to do to get the docs.o.o to show the fixed docs?  Is
it something we need to do on the glance side, or does it have to be
fixed somewhere else?

thanks,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Q-3 milestone released

[Brian Rosmaita]

On Tue, Jan 30, 2018 at 11:39 PM, Brian Rosmaita
<rosmaita.foss...@gmail.com> wrote:
[snip]
> Glance cores, please do not merge any patches until after
> https://review.openstack.org/#/c/536630/ has merged.

The patch merged at 08:15UTC today.  Merge away (subject to common
sense and the fact that we're in RC time).

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] Q-3 milestone released

[Brian Rosmaita]

Glance 16.0.0.0b3 was released today,  The tag was created at this commit:
http://git.openstack.org/cgit/openstack/glance/commit/?id=631add1ba849eac67ecb36ea4c90b57a300a96fa
which is dated Thu, 18 Jan 2018 12:09:11 +

As you'll notice, that was about 2 weeks ago.  Which prompts the
question, why did we wait so long to release it.

Q: Why that commit?
A: It's the last commit when the glance functional gates jobs were
still working.

Q: Why didn't we release it 2 weeks ago?
A: The Q-3 release marks the feature freeze.  Any code committed after
that point should be either a release-critical bug or something with a
Feature Freeze Exception.  So you really don't want to release Q-3
early.

Q: What's the deal with the glance functional gate jobs?
A: There are two patches fixing them, but they have to go through the
'integrated' queue before they can merge, and we've had some bad luck
over the past few days ... they've made it to the top of the queue to
be processed when something bad happened and they had to start over.
They're being processed again right now (keep your fingers crossed).

Q: What about my commits that show up after
631add1ba849eac67ecb36ea4c90b57a300a96fa?
A: I will be sending out FFEs or marking the bugs for RC1, as appropriate.

Glance cores, please do not merge any patches until after
https://review.openstack.org/#/c/536630/ has merged.


thanks,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] PTL non-candidacy

[Brian Rosmaita]

I've been PTL of Glance through some rocky times, but have decided not
to stand for election for the Rocky cycle.  My plan is to stick
around, attend to my duties as a glance core contributor, and support
my successor in whatever way I can to make for a smooth transition.
After three consecutive cycles of me, it's time for some new ideas and
new approaches.

For anyone out there who hasn't contributed to Glance yet, the Glance
community is friendly and welcoming, and we've got a backlog of
"untargeted" specs ready for you to pick up.  Weekly meetings are
14:00 UTC on Thursdays in #openstack-meeting-4.

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ptg] [glance] Dublin PTG planning

[Brian Rosmaita]

We've been talking about this at the weekly glance meeting, but I
forgot to put out a wider shout on the ML.  The Glance planning
etherpad is here:
  https://etherpad.openstack.org/p/glance-rocky-ptg-planning

Right now it contains some excellent proposals*, but we could use some more.

cheers,
brian

*They're all from me, so YMMV in terms of excellence.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements] [vitrage][glance][ironic] global requirements update for python-vitrageclient

[Brian Rosmaita]

Sorry for the late reply.  https://review.openstack.org/#/c/537453/
merged a few hours ago and the "can't copy" error should no longer
occur.

On Fri, Jan 26, 2018 at 10:22 AM, Matthew Thode
 wrote:
> On 18-01-26 10:47:38, Mark Goddard wrote:
>> Looks like this should be resolved by
>> https://review.openstack.org/#/c/537453/.
>> Mark
>>
>> On 26 January 2018 at 10:33, Mark Goddard  wrote:
>>
>> > Also seeing this for the u-c [1] and g-r [2] bumps for python-ironicclient
>> > 2.2.0. These are required in order to use the ironic node traits feature in
>> > nova.
>> >
>> > [1] https://review.openstack.org/#/c/538093
>> > [2] https://review.openstack.org/#/c/538066/3
>> >
>> > On 25 January 2018 at 11:15, Afek, Ifat (Nokia - IL/Kfar Sava) <
>> > ifat.a...@nokia.com> wrote:
>> >
>> >> Adding Glance team.
>> >> Any idea what could be wrong?
>> >>
>> >> Thanks,
>> >> Ifat.
>> >>
>> >>
>> >> On 25/01/2018, 9:09, "Afek, Ifat (Nokia - IL/Kfar Sava)" <
>> >> ifat.a...@nokia.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I tried to update the version of python-vitrageclient [1], but the
>> >> legacy-requirements-integration-dsvm test failed with an error that does
>> >> not seem related to my changes:
>> >>
>> >> error: can't copy 'etc/glance-image-import.conf': doesn't exist or
>> >> not a regular file
>> >>
>> >> I noticed that two other changes [2][3] failed with the same error.
>> >>
>> >> Can you please help?
>> >>
>> >> Thanks,
>> >> Ifat.
>> >>
>> >>
>> >> [1] https://review.openstack.org/#/c/537307
>> >> [2] https://review.openstack.org/#/c/535460/
>> >> [3] https://review.openstack.org/#/c/536142/
>
> yep, requirements is hard blocked on that atm
>
> --
> Matthew Thode (prometheanfire)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Issue with eventlet monkey patching

[Brian Rosmaita]

Thanks Slawek, this indeed looks like the problem we are having with
Glance.  Searchlight, too.


On Thu, Jan 25, 2018 at 10:53 AM, Sławomir Kapłoński
 wrote:
> Hi,
>
> Recently we found in Neutron errors with starting our agents which uses 
> eventlet.monkey_patch() method. Bug is described in [1].
>
> I heard on IRC that it's not related only to Neutron so here is what we found 
> about that.
> It looks that this issue happens on Ubuntu with python2.7 
> 2.7.12-1ubuntu0~16.04.3 with eventlet < 0.22.0 (in OpenStack requirements it 
> is set to 0.20.0).
> There is no this issue with python2.7.12-1ubuntu0~16.04.2 and eventlet 0.20.0
>
> Something similar was already reported for monotonic in [2]. From one of 
> comments there we found that problem can be caused because:
> "ctypes.util.find_library is now using subprocess.Popen, instead of os.popen 
> (python/cpython@eb063011), and eventlet monkey-patches subprocess.Popen but 
> not os.popen."
>
> It looks that eventlet patch [3] fixes/workaround this issue.
> I pushed similar patch to Neutron [4] and it looks that our issue is solved 
> for now.
>
> I hope that maybe this info will be helpful for You :)
>
> [1] https://bugs.launchpad.net/neutron/+bug/1745013
> [2] 
> https://www.bountysource.com/issues/43892421-new-monotonic-broken-on-docker
> [3] 
> https://github.comhttps://review.openstack.org/#/c/537863/1/eventlet/eventlet/commit/b756447bab51046dfc6f1e0e299cc997ab343701
> [4] https://review.openstack.org/#/c/537863
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] functional gate situation

[Brian Rosmaita]

Update on the 24 hours since the last update:

tl;dr: glance cores, do not approve any substantial code changes until
after the functional tests are restored.  See below for details.

On Tue, Jan 23, 2018 at 8:09 PM, Brian Rosmaita
<rosmaita.foss...@gmail.com> wrote:
> Update on the last 24 hours:
>
> (1) Sean's patch splitting the unit and functional tests in tox has merged.

Still good.

> (2) My patch to restore the functional test gate jobs ran into a
> problem, namely, that one of the py35 tests suddenly begun failing in
> the gate, and I haven't been able to reproduce it locally.  I started
> looking into it, but this problem doesn't make any sense at all
> (you'll see what I mean when you get a chance to look at it), so I put
> up a patch to skip the failing test:
> https://review.openstack.org/#/c/536939/
> It's passed the check and I ninja-approved it, so it's in the gate now.

It's still in the gate.  Due to an unfortunate concatenation of
circumstances, today's gerrit restart occurred at the same time zuul
had passed this patch, and the success was not recorded, and it had to
be rechecked.  I believe it was moved up in the queue (thanks, infra
team!), but nonetheless it's been in the integrated queue for > 7
hours now, with zuul projecting completion in 58 minutes.

> (3) I edited the patch restoring the functional gate jobs to not run
> the py27 tests at all (no sense wasting any time until we know they
> have a chance of working).  At least we can run the py35 functional
> tests (except for the one being skipped):
> https://review.openstack.org/#/c/536630/
> (I rebased it on the skip-test patch, it's in the check now.)

This one still depends on #2, so no action yet.

> I'd prefer that nothing else be merged for glance until we get the
> functional gate restored, which will hopefully happen sometime this
> evening.  I'll keep an eye on (2) and (3) for the next few hours.

I'm still hopeful, though less hopeful than I was.  In any case, do
not approve any substantial changes until the functional tests have
been restored.

> (4) With Sean's patch merged, I put up a patch to the requirements
> repo reverting the change that made the cross-glance-py27 test
> non-voting:
> https://review.openstack.org/#/c/536946/
> That's been approved and is in the gate now.

This patch got caught in the gerrit restart, too, and is being
re-processed (and it looks like it's going to fail, although not
because of glance ... the cross-glance-py* jobs were both successful.

> So, we've got 2 outstanding bugs:
> py27 functional test failures: https://bugs.launchpad.net/glance/+bug/1744824
> py35 functional test failure: https://bugs.launchpad.net/glance/+bug/1745003
>
> ... and of course the regular stuff that was mentioned on the priority
> email for this week:
> http://lists.openstack.org/pipermail/openstack-dev/2018-January/126353.html

These continue to be areas of active interest.

On the plus side, we did release the python-glanceclient 2.9.1 today.

> cheers,
> brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] functional gate situation

[Brian Rosmaita]

Update on the last 24 hours:

(1) Sean's patch splitting the unit and functional tests in tox has merged.

(2) My patch to restore the functional test gate jobs ran into a
problem, namely, that one of the py35 tests suddenly begun failing in
the gate, and I haven't been able to reproduce it locally.  I started
looking into it, but this problem doesn't make any sense at all
(you'll see what I mean when you get a chance to look at it), so I put
up a patch to skip the failing test:
https://review.openstack.org/#/c/536939/
It's passed the check and I ninja-approved it, so it's in the gate now.

(3) I edited the patch restoring the functional gate jobs to not run
the py27 tests at all (no sense wasting any time until we know they
have a chance of working).  At least we can run the py35 functional
tests (except for the one being skipped):
https://review.openstack.org/#/c/536630/
(I rebased it on the skip-test patch, it's in the check now.)

I'd prefer that nothing else be merged for glance until we get the
functional gate restored, which will hopefully happen sometime this
evening.  I'll keep an eye on (2) and (3) for the next few hours.

(4) With Sean's patch merged, I put up a patch to the requirements
repo reverting the change that made the cross-glance-py27 test
non-voting:
https://review.openstack.org/#/c/536946/
That's been approved and is in the gate now.

So, we've got 2 outstanding bugs:
py27 functional test failures: https://bugs.launchpad.net/glance/+bug/1744824
py35 functional test failure: https://bugs.launchpad.net/glance/+bug/1745003

... and of course the regular stuff that was mentioned on the priority
email for this week:
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126353.html


cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] py27 gate situation

[Brian Rosmaita]

Looks like something changed in a distro dependency over the weekend
and the glance py27 gate is failing.

I did a dist-upgrade in a new Ubuntu 16.04.3 vm, and was able to
reproduce the failures locally.  I'll continue looking, but it's EOD
where I am, so I wanted to make sure this info is available to the
people whose day is about to begin.  The failures are confined to the
py27 functional tests.  Unit tests pass, as do all the py35 tests.

The requirements team has merged a change making the cross-glance-py27
job non-voting:
https://review.openstack.org/#/c/536082/
Thus, this issue isn't holding up requirements changes, but it's still
pretty urgent for us to figure out because I don't like us running
around naked with respect to requirements changes that could affect
glance running under py27.

Here's what I think we should do:

(1) Sean has had a patch up for a while separating out the unit tests
from the functional tests.  I think it's a good idea.  If you are
aware of a reason why they should NOT be separated, please comment on
the patch:
https://review.openstack.org/#/c/474816/
I'd like to merge this soon so we can at least restore py27 unit tests
to the requirements gate.  We can always revert if it turns out that
there is a really good reason for not separating out the functional
tests.

(2) I've got a patch up that depends on Sean's patch and restores the
functional test gate jobs to the glance .zuul.yaml file (though it
makes the py27 functional tests non-voting):
https://review.openstack.org/#/c/536630/

(3) Continue to work on https://bugs.launchpad.net/glance/+bug/1744824
to figure out why the py27 functional tests are failing.  As far as I
can tell, it looks like a distro package issue.


thanks,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (18 Jan - 24 Jan)

[Brian Rosmaita]

As discussed at today's Glance meeting, the Q-3 milestone is next
week.  Please focus on the following:

(1) image metadata injection
https://review.openstack.org/#/c/527635/

(2) interoperable image import
https://review.openstack.org/532502
https://review.openstack.org/532501
may be some more, watch the ML

(3) use only E-M-C strategy in glance-manage tool
not sure the patch is up yet, will leave a note on
https://review.openstack.org/#/c/433934

Have a good week!
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] current priorities

[Brian Rosmaita]

Reminder: the Glance team has fewer than usual number of reviewers
available until after the new year.

The weekly Glance meeting is cancelled on Thursday, December 28.

Here's what we're working on between now and the next Glance meeting
on January 4, 2018:

* Glanceclient
We're aiming for a glanceclient release from the stable/pike branch on
January 2.  This depends on several patches:
- https://review.openstack.org/#/c/529834/ - this is the backport of
the changes to the functional test jobs in master to stable/pike.  At
the moment, it has two patches to devstack stable/pike as
dependencies:
- https://review.openstack.org/#/c/529878/ - backports some changes in
devstack/master needed to run the functional jobs under zuul3
- https://review.openstack.org/#/c/530138/ - backports a fix from
devstack/master of another issue the functional test jobs have run
into

* Glance scrubber refactor
- https://review.openstack.org/#/c/510449/

* Metadata injection
- https://review.openstack.org/#/c/527635/
- https://review.openstack.org/#/c/527907/

* hooks for import plugins (needed for metadata injection)
- https://review.openstack.org/#/c/528754/


Happy holidays if you're celebrating, and happy new year.
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the week (12/08-12/14)

[Brian Rosmaita]

Let's get the scrubber refactor and anything that got postponed from
Q-2 merged before the meeting on Thursday.

scrubber:
https://review.openstack.org/#/c/510449/ (time zone bug has been addressed)

others:
https://review.openstack.org/#/c/524060/
https://review.openstack.org/#/c/521457/
https://review.openstack.org/#/c/523029/
https://review.openstack.org/#/c/523028/
https://review.openstack.org/#/c/523179/

Have a productive week!
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the week (12/01-12/07)

[Brian Rosmaita]

Hello Glancers,

As discussed at yesterday's Glance meeting, the priority for this week
is getting ready for the release of the Q-2 milestone, so:

1. the scrubber refactor
2. bugs scheduled for Q-2
3. enhanced tests for interoperable image import ("IIR")

I've put a list of patches and their current status on an etherpad:
  https://etherpad.openstack.org/p/glance-queens-Q2

Please keep it updated as you work through the items.  Several of the
bugs impact the same file, so there may be a need to rebase and
re-approve a few of these patches.

All changes must be approved by 12:00 UTC on Wednesday 6 December to
make it into the Q-2 milestone release.

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] nominating Nikhil Komawar for glance core

[Brian Rosmaita]

Having heard only positive responses, I'm happy to reinstate Nikhil
Komawar as a glance core, with all the rights and privileges
pertaining thereto.

Welcome back, Nikhil!

cheers,
brian

On Thu, Nov 16, 2017 at 8:20 PM, Abhishek Kekane <akek...@redhat.com> wrote:
> Big +2
> Glad you are back :)
>
> Abhishek
>
> On 17-Nov-2017 4:59 AM, "Brian Rosmaita" <rosmaita.foss...@gmail.com> wrote:
>>
>> I'm sure I don't need to introduce Nikhil Komawar (nikhil in IRC), who
>> was Glance PTL for the Kilo, Liberty, and Newton releases and who was
>> a long time Glance core until he stepped down at the end of June this
>> year.  Nikhil has informed me that he now has time to do Glance code
>> reviews again, and I will be happy to have his experience and
>> knowledge of the Glance code base available to inform our code
>> reviews, and I propose to reinstate him as a member of the glance core
>> team.
>>
>> I discussed this with the other cores present at today's weekly Glance
>> meeting, and they support reinstating Nikhil, so I don't see any
>> reason to have a long waiting period.  I'd like to add Nikhil to the
>> core list on Monday, November 20, so if anyone has any comments or
>> concerns, please let me know before then.
>>
>> thanks!
>> brian
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the week (11/17-11/23)

[Brian Rosmaita]

Hello Glancers,

Due to the Thanksgiving holidays in the USA next week, we are
tentatively cancelling the meeting on November 23.  However, most of
our developers these days are outside the USA, so if someone has a
pressing issue and puts the same on the meeting agenda before the
usual deadline (24 hours before the meeting, so before 14:00 on
Wednesday, Nov 22), we will hold the meeting.  Erno has volunteered to
keep an eye on the agenda and send out an email to the dev list if the
November 23 meeting will be held.  (So the default setting is: no
meeting next week.)

Patches needing review:

https://review.openstack.org/#/c/510449/
https://review.openstack.org/#/c/520945/
https://review.openstack.org/#/c/510424/
https://review.openstack.org/#/c/519514/
https://review.openstack.org/#/c/520644/

Except for the first patch, they're small changes that will be quick
to review and good to get merged.

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] nominating Nikhil Komawar for glance core

[Brian Rosmaita]

I'm sure I don't need to introduce Nikhil Komawar (nikhil in IRC), who
was Glance PTL for the Kilo, Liberty, and Newton releases and who was
a long time Glance core until he stepped down at the end of June this
year.  Nikhil has informed me that he now has time to do Glance code
reviews again, and I will be happy to have his experience and
knowledge of the Glance code base available to inform our code
reviews, and I propose to reinstate him as a member of the glance core
team.

I discussed this with the other cores present at today's weekly Glance
meeting, and they support reinstating Nikhil, so I don't see any
reason to have a long waiting period.  I'd like to add Nikhil to the
core list on Monday, November 20, so if anyone has any comments or
concerns, please let me know before then.

thanks!
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the week (11/03 - 11/09)

[Brian Rosmaita]

As discussed at yesterday's Glance meeting, here's what's going on
this coming week:

- Due to Summit travel, vacation, and/or life stuff, core reviewers
will not be available except for emergencies.  This may affect the
timeliness of your patches being reviewed and/or merged.  Thank you
for your patience.

- I've put up a revised version of the spec to fix OSSN-0075 [0],
please look it over and leave comments.  It is slightly controversial
(Erno doesn't like it), but I think it's the correct way to fix this
issue.  We've already done an operators' survey, but I'll discuss it
at the Glance Operators Feedback session at the Summit/Forum to
hopefully widen the range of operators addressed.

- If you are aiming to do reviews, remember that bugs marked for the
Q-2 milestone and patches associated with features listed in the
Queens priorities [1] have priority.

- If you are looking for some coding to do, you can't go wrong by
picking up any unassigned bugs marked for the Q-2 milestone [2].

- There is an unassigned spec on the priorities list for the
glanceclient [3], you may care to look it over and perhaps pick it up
if it interests you.

- There will be no Glance meeting on Thursday, November 9.  We will
resume our usual weekly meeting cadence on Thursday, November 16.

cheers,
brian

[0] https://review.openstack.org/468179
[1] 
http://git.openstack.org/cgit/openstack/glance-specs/tree/priorities/queens-priorities.rst
[2] https://launchpad.net/glance/+milestone/queens-2
[3] 
http://git.openstack.org/cgit/openstack/glance-specs/tree/specs/queens/approved/python-glanceclient/no-schema-validation.rst

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the week (10/13-10/19)

[Brian Rosmaita]

Hello Glancers,

The Q-1 milestone is just around the corner.  As discussed at the
weekly Glance meeting, the review priorities for this week are:

1  patches associated with Q-1 milestone targeted bugs
https://launchpad.net/glance/+milestone/queens-1

2  patches associated with Q-1 targeted specs
https://review.openstack.org/#/c/509154/
https://review.openstack.org/#/c/510449/

This is what we need to concentrate on this week, so if you have a
patch that doesn't fall into this category, please be patient.  (You
could always review some of the above while you wait.)

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] [glance-survey] specify-an-image-ID-at-image-creation survey

[Brian Rosmaita]

Here are the results of the survey:

OpenStack Glance specify-an-image-ID-at-image-creation survey

This is a quick survey to find out how many people use the ability to
specify a specific image_id at the time of image creation in Glance.

Note that if you manage multiple clouds, you can fill this out
multiple times with information about each.  We encourage you to do so
to help us get an accurate idea of how widely this feature is used.

Thanks in advance for your help!

This survey closes at 23:59 UTC on Tuesday 3 October 2017.

Responses: 8 (1 response == 12.5%)

Size of deployment (in tenants):
small (1-10): 0%
medium (11-100): 12.5%
large (101-1000): 62.5%
XL (1001+): 25%

As an operator, do you use the functionality that allows you to set an
image to a specific image_id upon image creation?
yes: 12.5%
no: 87.5%

Do you know if your end users use this functionality?
yes: 12.5%
no: 50%
don't know: 37.5%

Are you aware of OSSN-0075, that explains how this functionality is a
security problem?
Yes, I already knew about it: 50%
No, I wasn't aware (but I am now!): 50%

If a policy were introduced to govern this functionality, what would you do?
Leave the policy unrestricted, I don't need to purge my database: 0%
Leave the policy unrestricted, I can trust my users not to try the
OSSN-0075 exploit: 0%
Leave the policy unrestricted because my users rely on this functionality: 0%
Restrict usage to admin users only: 12.5%
Restrict usage to admin users and other specific trusted users: 50%
Restrict usage completely (allow none), we don't need this functionality: 37.5%

Does it bother you that if a policy were introduced to govern this
functionality, it could present an interoperability problem?
It bothers me, but I don't think this is a widely-used functionality,
so it's OK: 12.5%
It bothers me, but security trumps interoperability in this case, so
it's OK: 75%
It bothers me enough that I'd prefer that this not be fixed by
introducing a policy, even if that means not fixing it at all: 0%
It bothers me enough that I'd prefer this be fixed by disallowing the
functionality completely so that it could not be used by any user
(even an admin) in any cloud: 12.5%

-- end --


On Thu, Sep 28, 2017 at 6:48 PM, Brian Rosmaita
<rosmaita.foss...@gmail.com> wrote:
> The Glance spec freeze is coming up soon and we could use operator
> input on a proposal to govern a currently unrestricted functionality
> by policy.  The survey is 6 multiple choice questions and closes at
> 23:59 UTC on Tuesday 3 October 2017, so please fill it out right away.
>
> The purpose of the survey is to gather data concerning how many people
> use the ability to specify a specific image_id at the time of image
> creation in Glance -- so even if you've never heard of this
> functionality (and hence have never used it), it would be helpful for
> you to fill out the survey because you will give us a data point.
>
> https://goo.gl/forms/1dATtCW6V0xExRc22
>
> Thanks for your help!
> The Glance Team

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Oslo][oslo.policy][glance] Bug: Glance doesn't send correctly authorization request to Oslo policy

[Brian Rosmaita]

Thanks Doug.

Ruan, please put an item on the Glance meeting agenda.  The meeting is
14:00 UTC on Thursday [0].

thanks,
brian

[0] http://eavesdrop.openstack.org/#Glance_Team_Meeting

On Fri, Sep 29, 2017 at 11:49 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> The Glance team has weekly meetings just like the Oslo team. You’ll find the
> details about the time and agenda on eavesdrop.openstack.org. I think it
> would make sense to add an item to the agenda for their next meeting to
> discuss this issue, and ask for someone to help guide you in fixing it. If
> the Oslo team needs to get involved after there is someone from Glance
> helping, then we can find the right person.
>
> Brian Rosmaita (rosmaita on IRC) is the Glance team PTL. I’ve copied him on
> this email to make sure he notices this thread.
>
> Doug
>
> On Sep 29, 2017, at 11:24 AM, ruan...@orange.com wrote:
>
> Not yet, we are not familiar with the Glance team.
> Ruan
>
> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: vendredi 29 septembre 2017 16:26
> To: openstack-dev
> Subject: Re: [openstack-dev] [Oslo][oslo.policy][glance] Bug: Glance doesn't
> send correctly authorization request to Oslo policy
>
> Excerpts from ruan.he's message of 2017-09-29 12:56:12 +:
>
> Hi folks,
> We are testing the http_check function in Oslo policy, and we figure out a
> bug: https://bugs.launchpad.net/glance/+bug/1720354.
> We believe that this is due to the Glance part since it doesn't well prepare
> the authorization request (body) to Oslo policy.
> Can we put this topic for the next Oslo meeting?
> Thanks,
> Ruan HE
>
>
> Do you have someone from the Glance team helping already?
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance][Security] Secure Hash Algorithm Spec

[Brian Rosmaita]

On Fri, Sep 29, 2017 at 1:38 PM, Jeremy Stanley  wrote:
> On 2017-09-29 12:31:21 -0400 (-0400), Jay Pipes wrote:
> [...]
>> Can someone please inform me how changing the checksum algorithm
>> for this operation to SHA-1 or something else would improve the
>> security of this operation?
> [...]
[...]
> The simpler explanation is that people hear "MD5 is broken" and so
> anyone writing policies and auditing security/compliance just tells
> you it's verboten. That, and uninformed alarmists who freak out when
> they find uses of MD5 and think that means the software will be
> hax0red the moment you put it into production. Sometimes it's easier
> to just go through the pain of replacing unpopular cryptographic
> primitives so you can avoid having this same discussion over and
> over with people whose eyes glaze over as soon as you start to try
> and tell them anything which disagrees with their paranoid
> sensationalist media experts.

This is the primary motivator.  Regardless of whether it makes sense
for the particular use of md5 in Glance or not, operators have to fill
in checkboxes in security compliance documentation that will be
consumed by increasingly less-well-informed people.  This way, rather
than try to justify Glance's use of md5 in 140 chars or less (assuming
there even is a "comment" field), operators can just answer "no" to
the question "does the system rely on md5" and be done with it.  I
think that's why the general reaction to this spec is a sigh of relief
that Glance is eliminating a dependency on md5.

Additionally, there's a use case of locating the same image in
different regions served by different Glance installations.  The
'checksum' property was indexed back in Folsom or Grizzly so that a
user could do an image-list call filtered by a particular checksum
value to find the same image they were using in one region in another
region.  But with an md5 checksum, we really can't recommend this
strategy of locating an image.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api-wg][glance] call for comments on Glance spec for Queens

[Brian Rosmaita]

Hello API WG,

I've got a patch up for a proposal to fix OSSN-0075 by introducing a
new policy.  There are concerns that this will introduce an
interoperability problem in that an API call that works in one
OpenStack cloud may not work in other OpenStack clouds.  As author of
the spec, I think this is an OK trade-off to fix the security issue,
but not all members of the Glance community agree, so we're trying to
get some wider perspective.  We'd appreciate it if some API-WG members
could take a look and leave a comment:

https://review.openstack.org/#/c/468179/

If you could respond by Tuesday 3 October, that would give us time to
get this worked out before the spec freeze (6 October).

thanks,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [glance-survey] specify-an-image-ID-at-image-creation survey

[Brian Rosmaita]

The Glance spec freeze is coming up soon and we could use operator
input on a proposal to govern a currently unrestricted functionality
by policy.  The survey is 6 multiple choice questions and closes at
23:59 UTC on Tuesday 3 October 2017, so please fill it out right away.

The purpose of the survey is to gather data concerning how many people
use the ability to specify a specific image_id at the time of image
creation in Glance -- so even if you've never heard of this
functionality (and hence have never used it), it would be helpful for
you to fill out the survey because you will give us a data point.

https://goo.gl/forms/1dATtCW6V0xExRc22

Thanks for your help!
The Glance Team

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [glance] priorities for the week (09/21-09/27)

[Brian Rosmaita]

Hello Glancers,

As discussed at today's Glance weekly meeting, priorities are:

1  patches associated with Q-1 milestone targeted bugs
https://launchpad.net/glance/+milestone/queens-1

2  specs
https://review.openstack.org/#/q/status:open+project:openstack/glance-specs


Have a productive week!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] upcoming spec-related deadlines

[Brian Rosmaita]

Hello Glance Community,

We came up with a fairly aggressive roadmap for Queens, particularly
given Glance's current personnel situation.  Thus, it's unlikely that
much more can be added, and thus, we can freeze spec proposals early
to eliminate distractions.  So here are the relevant deadlines:

28 September 2017: Glance Spec Proposal Freeze
All Glance, python-glanceclient, and glance_store specs must be
proposed as patches to the glance-specs repository by 13:00 UTC on
Thursday 28 September 2017 (that is, one hour before the weekly Glance
meeting begins).  While this only allows one week for review and
revisions before the Glance Spec Freeze, you can make sure you have
extra review time by submitting your patch early.

6 October 2017: Glance Spec Freeze
All Glance, python-glanceclient, and glance_store specs must be merged
into the glance-specs repository by 23:59 on Friday 6 October 2017.
This is a necessary but not sufficient condition for inclusion in the
Queens release.

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brian Rosmaita]

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.li...@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.foss...@gmail.com>
> wrote:
>>
>> On Mon, Sep 18, 2017 at 7:47 AM, Belmiro Moreira
>> <moreira.belmiro.email.li...@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
>> >
>> &g

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

[Brian Rosmaita]

On Mon, Sep 18, 2017 at 7:47 AM, Belmiro Moreira
<moreira.belmiro.email.li...@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.foss...@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 l

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

[Brian Rosmaita]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Brian Rosmaita]

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.


Strategic plan for Glance (Q, R, S, T, U)
-
https://etherpad.openstack.org/p/glance-queens-ptg-strategic-plan

No major surprises here, but some things to note:
- Q will be focused on completing interoperable image import and
making 2.6 the CURRENT API version
- The Images v1 API will be removed in Q (necessary condition is 2.6
becoming current, though)
- The Glance Registry API v1 will be removed in Q (necessary condition
is removal of Images v1 API)
- The Glance Registry API v2 will be DEPRECATED in Q and scheduled for
removal in S


Interoperable image import: where we are now and what testing needs to be added
---
https://etherpad.openstack.org/p/glance-queens-ptg-iir-testing

Basically, we need a lot more tests.  Abhishek is going to run a
coverage analysis to give us a list of items to work on.  Everyone is
going to investigate what QA resources are available, and we'll
discuss how to divide up the work at the September 28 Glance meeting.


Can the v1 API be removed in Queens?

https://etherpad.openstack.org/p/glance-queens-ptg-remove-v1-API

Yes, it can!  Assuming other goals are met, namely:
- implementing a safe 'copy-from' import-method (i.e., completing the
2.6 API and making it current).  ("Safe" copy-from addresses
OSSN-0078).
- removing any remaining Images API v1 tempest tests
- notify the Horizon team that the Images API v1 is scheduled for
removal in Queens

Plans for the python-glanceclient are:
- announce deprecation of Images v1 API support
- Q release of glanceclient will be the last one with v1 support
- Images API v1 support will be removed from the python-glanceclient in R
- notify OSC team about this timeline
- notify Shade team (though I don't think they use the glanceclient)


Community goal: policy-in-code: where we are

https://etherpad.openstack.org/p/glance-queens-ptg-policy-in-code

The conclusion of the discussion is that the proposed advantages to
this effort don't appear to apply to Glance, but it's a bit late to
bring that up now.  The primary advantage will be documentation of the
policies, which will eat reviewer time, but it will be good to do
(though inconvenient given the size of the development team right
now).

A complicating factor is that Glance also allows the use of policies
to define property protections.  We'll have to improve the
documentation around this feature.


Remove show_image_locations config option
-
https://etherpad.openstack.org/p/glance-queens-ptg-remove-sml-config-opt

The show_image_locations config option was deprecated in Newton and
scheduled for removal in Ocata.  It has become problematic to remove
this option because of OSSN-0065, as it gives operators a one-step way
to make sure the exploit described in that OSSN doesn't apply to their
installation (rather than properly configuring 3 related policies).

One suggestion is to rename the policy to something like
'insecure_location_access' (default value False) and then it will be a
bit more clear to operators what the config option allows.


Interoperable image import: next steps
--
https://etherpad.openstack.org/p/glance-queens-ptg-iir-next-steps

See the etherpad for the list of to-do items for Queens.


Adding microversion support to the Glance APIs
--
https://etherpad.openstack.org/p/glance-queens-ptg-microversions

Matt Treinish led an interesting discussion of why Glance should do
this.  We'll revisit this after the 2.6 API becomes CURRENT and the
Images API v1 has been removed.



See the scheduling etherpad for what we'll be discussing on Thursday:
https://etherpad.openstack.org/p/glance-queens-ptg

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] confirming Abhishek Kekane for glance core

[Brian Rosmaita]

Back in June, I asked Abhishek Kekane to serve as glance core during
the Pike cycle [0].  His contributions exceeded all expectations.
Abhishek's careful reviews, bug fixes, patches, and general
contributions to the community were instrumental in Glance completing
the Pike release.  I'm happy to announce that Abhishek has agreed to
continue to serve the OpenStack community as a Glance core
contributor, and this note confirms his status as a "regular" member
of the Glance core group, with all the rights and privileges
pertaining thereto.

(I just want it to be completely clear before our Queens design
discussions begin this morning that there's nothing provisional about
Abhishek's glance core status -- he's a full-fledged glance core.)

Thanks again to Abhishek for his hard work during the Pike cycle, and
I look forward to working with him for many cycles to come.

cheers,
brian


[0] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118503.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] [glance] Glance at the Denver PTG

[Brian Rosmaita]

The Glance design discussions on Wednesday and Thursday will roughly
adhere to the schedule on this etherpad:
https://etherpad.openstack.org/p/glance-queens-ptg

There's a place on the etherpad for Monday and Tuesday events; any
other teams having discussions that would benefit from having a Glance
representative there, feel free to put info on the etherpad.

The etherpad linked to above has links to etherpads for each session.
If you cannot attend the PTG but are interested in a session, please
put questions/comments on the appropriate etherpad.  We won't be
livecasting the sessions, but we will have IRC open to
#openstack-glance and #openstack-ptg, and we'll be taking live notes
on each session's etherpad.

Finally, we're aiming to have a Glance team dinner at 18:30 Denver
time on Tuesday (location TBA; will be posted on the etherpad linked
to above).  If you're interested in attending, please put your
name/irc nick on the etherpad so we can get a count.  Having
contributed to the Pike release of Glance is *not* a requirement for
having dinner with the Glance team! If you're interested in Glance, or
just want to meet the culprits responsible, feel free to join us.

Looking forward to a productive PTG!

brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (09/08-09/14)

[Brian Rosmaita]

Hello Glancers,

1. No meeting on Sept 14 due to PTG.

2. The PTG schedule for Glance is available.  There are etherpads
associated with each session.  If you cannot attend the PTG but are
interested in a session, please put questions/comments on the
appropriate etherpad.  We won't be livecasting the sessions, but we
will have IRC open to  #openstack-glance and #openstack-ptg, and we'll
be taking notes on the session etherpad
- https://etherpad.openstack.org/p/glance-queens-ptg

3. We have bugs targeted to Q-1, so you can't go wrong this week by
reviewing any patches associated with them:
- https://launchpad.net/glance/+milestone/queens-1
- also https://review.openstack.org/#/c/493654/ and
https://review.openstack.org/#/c/492651/

4. We'll be triaging and prioritizing bugs on Thursday (22:30-23:30
UTC) and having a bugfix session Friday, Sept 15 (15:00-18:00 UTC).
Feel free to join in!

Have a good week, everyone!

brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-upstream-institute][all] Get together at the PTG

[Brian Rosmaita]

Monday or Tuesday for me, too.

On Fri, Aug 25, 2017 at 10:36 AM, Ildiko Vancsa  wrote:
> Hi Training Team and All,
>
> As we have our next PTG coming up shortly I think that would be a great 
> opportunity for the team and everyone who’s interested to meet and check 
> where we are and what our future plans are. :)
>
> I would like to ask you to raise your hand by replying to this mail if you 
> will be around during the PTG week in Denver and would be interested in 
> joining. Please also indicate your availability for the week.
>
> Based on the responses we will pick a day and a time that works best for most 
> to have our gathering.
>
> Please let me know if you have any questions.
>
> Thanks and Best Regards,
> Ildikó
> (IRC: ildikov)
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for THURSDAY (24 aug) and FRIDAY (25 aug)

[Brian Rosmaita]

Glance Pike RC-2 is available.  Our current priorities are to test it
out and report any critical bugs immediately (use the RC etherpad).
We basically have Thursday and Friday to find, fix, and merge any
changes for Pike.

https://etherpad.openstack.org/p/glance-pike-RC-critical

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] docs: architecture or hw_architecture

[Brian Rosmaita]

On Wed, Aug 23, 2017 at 10:54 AM, Markus Zoeller
<mzoel...@linux.vnet.ibm.com> wrote:
> On 23.08.2017 14:47, Brian Rosmaita wrote:
>> 'architecture' is one of the "common image properties" that was
>> introduced in Folsom in an effort to standardize use of image
>> metadata.  It's not a mistake in the Glance docs, it's just that Nova
>> is looking for a differently named property.
>>
>> Glance has had a metadata definitions service [0,1] since Juno.  It
>> provides a common API for vendors, admins, services, and users to
>> meaningfully define available key / value pair metadata that can be
>> used on different types of resources (images, artifacts, volumes,
>> flavors, aggregates, and other resources). A definition includes a
>> property’s key, its description, its constraints, and the resource
>> types to which it can be associated.  It's probably a better place to
>> store this kind of information than in documentation.  I think it's
>> under-utilized.
>>
>> [0] https://developer.openstack.org/api-ref/image/v2/metadefs-index.html
>> [1] https://docs.openstack.org/glance/latest/user/metadefs-concepts.html
>
>
> OK, I agree that the information to do it right is available:
>
> "The keys have different prefixes on images than on flavors.
> On flavors keys are prefixed with hw:, but on images the keys
> are prefixed with hw_."
>
> It's just not *that* easy to find and to deduct. I was looking for that
> information as an operator, to allow the Nova scheduler to do its work
> in a mixed arch environment (x86 + s390x) based on image properties.
>
> I still don't fully get it. In which use-case is `architecture` the
> correct property to set?

It depends on what you mean by "correct". If you're just describing
what's in the image, it works fine.  If you expect it to actually do
something, then you need to use the hw_ one.

My point is just that Glance went one way on this, Nova went a
different way, and users are left hanging.  My secondary point is that
it might be useful to catalog these things in the metadata definitions
service so that we all stay on the same page better.

cheers,
brian

> Regards, Markus Zoeller (markus_z)
>
>> On Wed, Aug 23, 2017 at 5:45 AM, Markus Zoeller
>> <mzoel...@linux.vnet.ibm.com> wrote:
>>> On 22.08.2017 17:10, Markus Zoeller wrote:
>>>> I'm wondering if there is an issue in the docs which describe the
>>>> possible image metadata properties:
>>>> https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html#
>>>>
>>>> This document says to use `architecture` (e.g. x86_64 or s390x or ppc64)
>>>> but the Nova scheduler image properties filter uses `hw_architecture`
>>>> (note the *hw_* prefix):
>>>> https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44
>>>>
>>>> Is that simply a mistake in the Glance docs or do I miss some kind of
>>>> conversion between those metadata keys?
>>>>
>>>
>>> Looks like only `hw_architecture` works in my x86 + s390x environment.
>>> I'm going to push an update to the Glance docs + an update to the
>>> `os_image` Ansible module which uses `cpu_arch` in its documentation:
>>> http://docs.ansible.com/ansible/latest/os_image_module.html
>>>
>>> --
>>> Regards, Markus Zoeller (markus_z)
>>>
>>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] docs: architecture or hw_architecture

[Brian Rosmaita]

'architecture' is one of the "common image properties" that was
introduced in Folsom in an effort to standardize use of image
metadata.  It's not a mistake in the Glance docs, it's just that Nova
is looking for a differently named property.

Glance has had a metadata definitions service [0,1] since Juno.  It
provides a common API for vendors, admins, services, and users to
meaningfully define available key / value pair metadata that can be
used on different types of resources (images, artifacts, volumes,
flavors, aggregates, and other resources). A definition includes a
property’s key, its description, its constraints, and the resource
types to which it can be associated.  It's probably a better place to
store this kind of information than in documentation.  I think it's
under-utilized.

[0] https://developer.openstack.org/api-ref/image/v2/metadefs-index.html
[1] https://docs.openstack.org/glance/latest/user/metadefs-concepts.html

On Wed, Aug 23, 2017 at 5:45 AM, Markus Zoeller
 wrote:
> On 22.08.2017 17:10, Markus Zoeller wrote:
>> I'm wondering if there is an issue in the docs which describe the
>> possible image metadata properties:
>> https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html#
>>
>> This document says to use `architecture` (e.g. x86_64 or s390x or ppc64)
>> but the Nova scheduler image properties filter uses `hw_architecture`
>> (note the *hw_* prefix):
>> https://github.com/openstack/nova/blob/4a7502a5c9e84a8c8cef7f355d72425b26b8c379/nova/scheduler/filters/image_props_filter.py#L44
>>
>> Is that simply a mistake in the Glance docs or do I miss some kind of
>> conversion between those metadata keys?
>>
>
> Looks like only `hw_architecture` works in my x86 + s390x environment.
> I'm going to push an update to the Glance docs + an update to the
> `os_image` Ansible module which uses `cpu_arch` in its documentation:
> http://docs.ansible.com/ansible/latest/os_image_module.html
>
> --
> Regards, Markus Zoeller (markus_z)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for Wednesday, August 23

[Brian Rosmaita]

Hello Glancers,

Two new bugs.

1) https://launchpad.net/bugs/1712462  is release-critical; I have a patch
up for it:
https://review.openstack.org/#/c/496477/  .  Erno and anyone else
knowledgeable about taskflow please look it over.

2) https://bugs.launchpad.net/glance/+bug/1712463 is confirmed, but I'm not
sure whether it's a simple configuration fix or something more sinister.
Matt and anyone else knowledgeable about the running-glance-as-a-wsgi-app
work please take a look.

Please keep an eye on the etherpad in case anything else pops up:
https://etherpad.openstack.org/p/glance-pike-RC-critical

cheers,
brian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities NOW!

[Brian Rosmaita]

Thanks to everyone who's been bugfixing and reviewing RC-2 changes this
week, particularly, Flavio, Abhishek, and Sean.

We didn't get everything merged into master that's RC-critical yesterday,
and while I guess we could have released an RC-2 anyway, that didn't seem
right knowing that there were critical fixes missing.  But I digress.

I hate to ask people to work on a weekend, but with the solar eclipse on
Monday and Ganesh Chaturthi on Friday, this coming week is likely to be a
short one.  If you can make some time, please review the patches listed on
the etherpad:
  https://etherpad.openstack.org/p/glance-pike-RC-critical

There's one new patch on the list, most of the rest already have one +2.

I'd like to get RC-2 released as early in the week as possible because the
gate situation will probably be pretty bad later in the week.

thanks,
brian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for THURSDAY (17 aug) and FRIDAY (18 aug)

[Brian Rosmaita]

Glancers (and other people interested in the Pike release of Glance),

We need a RC-2, and the sooner we can release it, the better.  So we really
need a review push today and tomorrow.

Glance cores: please direct your attention to the patches listed on this
etherpad:
https://etherpad.openstack.org/p/glance-pike-RC-critical
They are mostly related to the new interoperable image import functionality.

Abhishek and I can only +2 each others work, and Erno is on a well-deserved
vacation, so we need some more eyes on those patches.  Even if you're not a
glance core, your careful review on these patches will be helpful.

thanks,
brian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (08/11-08/17)

[Brian Rosmaita]

The first glance pike Release Candidate was released yesterday.

As discussed at yesterday's Glance meeting, we're going to definitely need
an RC-2.  Watch the etherpad for release-critical bugs/patches:
https://etherpad.openstack.org/p/glance-pike-RC-critical
More stuff will be added as the week progresses.  We want to have
everything merged so that we can release RC-2 on Wednesday 16 August.

The focus this week is on finding and fixing release-critical bugs.  Since
stable/pike has been cut, fixes will be made in master and cherry-picked
into stable/pike.  To keep the cherry-picks clean and easy, hold off on
merging any extraneous stuff into master this week.

There are two items to focus on in testing RC-1:
1  image import
2  trusts: see
https://review.openstack.org/#q,I233883dc6a37f282eb8e024c059c6a12ebb7e9f1,n,z
for what I'm talking about

Both of these are optional features, but it's important that they be
working correctly.

cheers,
brian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the week 08/06-08/10

[Brian Rosmaita]

The priority for this week is to get ready for RC-1, which we should cut on
Wednesday 08/09

Please look over the following patches:

https://review.openstack.org/#/c/491249/
-- and be on the lookout for other image-import related patches
https://review.openstack.org/#/c/431709/
https://review.openstack.org/#/c/479047/
https://review.openstack.org/#/c/490651/
https://review.openstack.org/#/c/486674/
https://review.openstack.org/#/c/451449/

These are devstack patches, but you might want to take a quick look for
awareness:
https://review.openstack.org/#/c/490903
https://review.openstack.org/#/c/490904

Don't merge other stuff (except maybe doc changes) without checking first
in #openstack-glance.

cheers,
brian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api-wg][glance] introducing Images API v2.6

[Brian Rosmaita]

We've decided to introduce the MVP of the new image import functionality as
an EXPERIMENTAL version 2.6 of the Images API.  The CURRENT version will
remain at 2.5 (introduced in Ocata).

Why we're doing this and what this means for deployers/users is explained
in the releasenote on the patch that bumps the API version:

https://review.openstack.org/#/c/490651/

We plan to get this into RC-1, so please leave comments on the patch at
your earliest convenience.

cheers,
brian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [election][glance] Queens PTL candidacy

[Brian Rosmaita]

I just submitted https://review.openstack.org/#/c/489834/ , which
announces my candidacy as Glance PTL for the Queens cycle.  This is
what it says:

Hello everyone,

I'm asking for the opportunity to continue to serve as the PTL of
Glance into the Queens cycle.

Things looked good for Glance at the start of Pike.  We had a strong
set of active cores, and discussed plans at the PTG for recruiting
more developers to the team through holding bugsmash events and
developing a more organized approach to triaging bugs to a point where
they could be worked on by developers not yet experienced in working
with Glance.  We were interested in attracting new talent because we
had recently lost our team:diverse-affiliation tag [0] which was a
warning that Glance had become too reliant on two companies.  And in
fact when those companies decided to change direction early in the
cycle, the impact on Glance was devastating.  However, due to the hard
work of those who remained and developers from the wider community who
pitched in [1], we were able to complete a revised list of priorities
for Pike and did not require any kind of drastic intervention (such as
going into maintenance mode, which looked like a real possibility in
April).  And, on the plus side, we'll definitely be receiving the
team:diverse-affiliation tag the next time it's assessed.

The point of mentioning the above history is that I'd like to continue
the reorganization and recruitment work we'd discussed at the
beginning of Pike, which should improve the project's health for the
Rocky PTL, who will most likely not be me.  Or at least there's no
reason why it should be me, as some of my goals for Queens are to help
grow the Glance community and help any Glancer who's interested
(hopefully, more than one) get themselves into a position to become an
effective PTL.

So that's the general nature of what I think we should focus on in
Queens.  There are a few specifics that I should probably mention:

* Image import continued -- thanks to Erno's hard work, a minimal
viable product of image import has landed in Pike.  There are a few
obvious Glance-side improvements we can make, but at Pike RC-1 time, I
plan to notify operators that the MVP of image import is available,
they should look it over, and give us feedback on what enhancements
are necessary, and think about how they can direct development
resources to Glance to make those changes happen.

* Rolling upgrades -- we released zero-downtime upgrades as an
experimental feature in Ocata, but further work planned for Pike
(primarily, in-gate testing of upgrades) did not happen.  It's
important to get this completed in Queens.

* Operator communication -- the popular operator surveys that we were
using to gather usage information about Glance were another casuality
of the personnel situation in Pike; I'd like to get those going again.

Additionally, there are some small worthwhile features among the
untargeted approved specs that would be nice to land, and new specs
are already showing up in the Queens directory.  And of course Glance
will participate in the Queens community goals.  We'll sort out the
priorities at the PTG [2].

Finally, there's been some discussion on the ML about whether Glance
has outlived its usefulness and should be replaced [3,4].  I'm willing
to discuss that at the PTG, but as you can tell from the fact that I
listed it last, I think there's still a role for Glance in the Queens
cycle.

Thanks for reading, and thanks for your consideration,
brian

[0] 
https://git.openstack.org/cgit/openstack/governance/commit/?id=c0359e95153c3d3688d4ef6902a058204913a87a
[1] http://lists.openstack.org/pipermail/openstack-tc/2017-July/001444.html
[2] https://etherpad.openstack.org/p/glance-queens-ptg-planning
[3] http://lists.openstack.org/pipermail/openstack-dev/2017-June/118228.html
[4] http://lists.openstack.org/pipermail/openstack-dev/2017-July/119442.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for this week (07/31 - 08/03)

[Brian Rosmaita]

Congratulations for getting P-3 tagged, and version 2.8.0 of the
glanceclient released!

As you know, we have one FFE for Pike, namely Erno's proposal to add
"copy-from" to the new image import process.  Erno is headed out for a
well-deserved vacation in a few days, so the priority for this week is
to review quickly any patches he gets up around copy-from.

Other than that, your usual dutiful attention to current patches and
bugfixes is appreciated.

Also, if you'd like to attend the PTG but aren't sure about funding,
the travel grant program is open until August 6.  Details are at the
bottom of the PTG planning etherpad:
https://etherpad.openstack.org/p/glance-queens-ptg-planning

Have a good week!
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] Pike Feature Freeze Exception

[Brian Rosmaita]

Hello Glancers,

As you are aware, the Feature Freeze happened at the time of P-3
tagging.  As discussed at the Glance weekly meeting on 27 July 2017,
the Glance team has decided to recognize exactly one FFE, namely,
Erno's request to add a "copy-from" capability to the Pike image
import functionality.  Given Erno's vacation schedule, this will have
to land within the next day or two if it's going to land at all, so if
it does land, we'll have plenty of time to test and make sure the
feature is stable.

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (07/21-07/27)

[Brian Rosmaita]

As discussed at today's Glance meeting, here are the priorities for
the coming week.

(1)  The Pike release of the python-glanceclient
We'd like to have the release ready to go by Wednesday.
The list of patches to review is here:
https://etherpad.openstack.org/p/glance-client-priority-reviews-pike

(2)  The P-3 milestone for Glance
Note that the P-3 release is also marks the Pike feature freeze.
- As we discussed at today's meeting, it looks like the only feature
work being done at the moment is associated with image import.  Watch
the mailing list for a notice of any patches that need reviews.
- A patch that needs review for clarity and correctness is the
releasenote for support for running Glance as a WSGI application in a
web server:
https://review.openstack.org/485913

And, of course, continue working on bugs!

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (07/13 - 07/20)

[Brian Rosmaita]

As discussed at today's Glance meeting, here are the priorities for
the coming week.

(1) The uwsgi problem that abhishekk is working on:
https://bugs.launchpad.net/glance/+bug/1703856
Keep an eye on #openstack-glance in case he needs help, and keep an
eye on the bug to see what patches need to be looked at.

(2) The final release for non-client libraries is next week, so this
is our last chance to whip glance_store into shape for Pike.  List of
patches to review is here:
https://etherpad.openstack.org/p/glance-store-priority-reviews-pike

(3) Image import refactor: please review
https://review.openstack.org/#/c/482182/


Have a productive week!
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (06/30-07/06)

[Brian Rosmaita]

(Light list this week because of a long holiday weekend in the USA.)

As discussed at today's Glance meeting, the review priorities for this week are:

1  image download error
https://review.openstack.org/#/c/460280

2  weirdness on the 'protected' property filter patch
Strange test failure error (see Abhishek's comment on the patch).
https://review.openstack.org/#/c/449108/

3  glance bugs
Let's get some action on open bugs.


cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] stepping down from glance core and other related groups

[Brian Rosmaita]

On Thu, Jun 29, 2017 at 12:09 AM, Nikhil Komawar  wrote:
> I am thankful to the community for such amazing experience over the past few
> years.

And the Glance community is thankful for your service, which includes
three cycles as the Glance PTL!

> For the changes required for glance personnel in the active cycle, I
> would like to step down from core as I cannot commit as much time upstream.
> I was hanging out to help in general but even that time commitment will be
> difficult in the coming months. This should effectively mean, me stepping
> down from the release, core-sec, specs core groups too. I am happy to help
> where needed on case by case basis but I do not think +2/-2 rights or me
> being subscribed to glance-core-sec is needed for such.

We will certainly appreciate any help you can continue to give on open issues.

> Good luck to glancers and all those who form (ionic or covalent) bonds with
> the glance community. Cheers.

On behalf of the entire Glance community, thank you for your extensive
past service to Glance, and we sincerely hope that you find time to
work on Glance again in the future!

cheers,
brian

>
> --
> --
> Thanks,
> Nikhil
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Stepping down from core

[Brian Rosmaita]

Fei Long:

On behalf of the entire Glance team, thank you for your extensive past
service to Glance.  We hope that you'll be able to find time to work
on Glance again in the future.

cheers,
brian


On Wed, Jun 21, 2017 at 9:18 AM, Erno Kuvaja  wrote:
> On Tue, Jun 20, 2017 at 11:07 AM, Flavio Percoco  wrote:
>> On 20/06/17 09:31 +1200, feilong wrote:
>>>
>>> Hi there,
>>>
>>> I've been a Glance core since 2013 and been involved in the Glance
>>> community even longer, so I care deeply about Glance. My situation right now
>>> is such that I cannot devote sufficient time to Glance, and while as you've
>>> seen elsewhere on the mailing list, Glance needs reviewers, I'm afraid that
>>> keeping my name on the core list is giving people a false impression of how
>>> dire the current Glance personnel situation is. So after discussed with
>>> Glance PTL, I'd like to offer my resignation as a member of the Glance core
>>> reviewer team. Thank you for your understanding.
>>
>>
>> Thanks for being honest and open about the situation. I agree with you that
>> this
>> is the right move.
>>
>> I'd like to thank you for all these years of service and I think it goes
>> without
>> saying that you're welcome back in the team anytime you want.
>>
>> Flavio
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>
>
> Just want to reinforce what Flavio said. Big thanks for all your time
> and expertise! You're always welcome back if your time so permits.
>
> - Erno
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] nominating Abhishek Kekane for glance core

[Brian Rosmaita]

Having heard only affirmative responses, I've added Abhishek Kekane to
the Glance core group, with all the rights and privileges pertaining
thereto.

Welcome to the Glance core team, Abhishek!

cheers,
brian

On Tue, Jun 20, 2017 at 1:35 PM, Mikhail Fedosin <mfedo...@gmail.com> wrote:
> Wasn't Abhishek a glance core before? What a surprise for me o_O
> I thought that he was just being modest and did not put -2 on the patches.
>
> Undoubtedly, we need to correct this misunderstanding as quickly as
> possible and invite Abhishek to the core team.
>
> On Mon, Jun 19, 2017 at 5:40 PM, Erno Kuvaja <ekuv...@redhat.com> wrote:
>>
>> On Fri, Jun 16, 2017 at 3:26 PM, Brian Rosmaita
>> <rosmaita.foss...@gmail.com> wrote:
>> > I'm nominating Abhishek Kekane (abhishekk on IRC) to be a Glance core
>> > for the Pike cycle.  Abhishek has been around the Glance community for
>> > a long time and is familiar with the architecture and design patterns
>> > used in Glance and its related projects.  He's contributed code,
>> > triaged bugs, provided bugfixes, and done quality reviews for Glance.
>> >
>> > Abhishek has been proposed for Glance core before, but some members of
>> > the community were concerned that he wasn't able to devote sufficient
>> > time to Glance.  Given the current situation with the project,
>> > however, it would be an enormous help to have someone as knowledgeable
>> > about Glance as Abhishek to have +2 powers.  I discussed this with
>> > Abhishek, he's aware that some in the community have that concern, and
>> > he's agreed to be a core reviewer for the Pike cycle.  The community
>> > can revisit his status early in Queens.
>> >
>> > Now that I've written that down, that puts Abhishek in the same boat
>> > as all core reviewers, i.e., their levels of participation and
>> > commitment are assessed at the beginning of each cycle and adjustments
>> > made.
>> >
>> > In any case, I'd like to put Abhishek to work as soon as possible!  So
>> > please reply to this message with comments or concerns before 23:59
>> > UTC on Monday 19 June.  I'd like to confirm Abhishek as a core on
>> > Tuesday 20 June.
>> >
>> > thanks,
>> > brian
>> >
>>
>> +2 from me! This sounds like a great solution for our immediate
>> staffing issues and I'm happy to hear Abhishek would have the cycles
>> to help us. Lets hope we get to enjoy his knowledge and good quality
>> reviews on many cycles forward.
>>
>> - Erno
>>
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] nominating Abhishek Kekane for glance core

[Brian Rosmaita]

I'm nominating Abhishek Kekane (abhishekk on IRC) to be a Glance core
for the Pike cycle.  Abhishek has been around the Glance community for
a long time and is familiar with the architecture and design patterns
used in Glance and its related projects.  He's contributed code,
triaged bugs, provided bugfixes, and done quality reviews for Glance.

Abhishek has been proposed for Glance core before, but some members of
the community were concerned that he wasn't able to devote sufficient
time to Glance.  Given the current situation with the project,
however, it would be an enormous help to have someone as knowledgeable
about Glance as Abhishek to have +2 powers.  I discussed this with
Abhishek, he's aware that some in the community have that concern, and
he's agreed to be a core reviewer for the Pike cycle.  The community
can revisit his status early in Queens.

Now that I've written that down, that puts Abhishek in the same boat
as all core reviewers, i.e., their levels of participation and
commitment are assessed at the beginning of each cycle and adjustments
made.

In any case, I'd like to put Abhishek to work as soon as possible!  So
please reply to this message with comments or concerns before 23:59
UTC on Monday 19 June.  I'd like to confirm Abhishek as a core on
Tuesday 20 June.

thanks,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (06/16-06/22)

[Brian Rosmaita]

As discussed at today's Glance meeting, the priorities for this week are:

1  WSGI community goal
- 
https://review.openstack.org/#/q/status:open+project:openstack/glance+branch:master+topic:goal-deploy-api-in-wsgi
- https://review.openstack.org/#/c/459451/

Just one priority, let's knock this out this week.  It will clear the
deck for next week, so we can focus on the image import refactor work
Erno's got underway.

In other news:

Thanks to Erno, the Glance Release Czar, for getting the P-2 milestone
release out on time!


cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][qa][glance] some recent tempest problems

[Brian Rosmaita]

This isn't a glance-specific problem though we've encountered it quite
a few times recently.

Briefly, we're gating on Tempest jobs that tempest itself does not
gate on.  This leads to a situation where new tests can be merged in
tempest, but wind up breaking our gate. We aren't claiming that the
added tests are bad or don't provide value; the problem is that we
have to drop everything and fix the gate.  This interrupts our current
work and forces us to prioritize bugs to fix based not on what makes
the most sense for the project given current priorities and resources,
but based on whatever we can do to get the gates un-blocked.

As we said earlier, this situation seems to be impacting multiple projects.

One solution for this is to change our gating so that we do not run
any Tempest jobs against Glance repositories that are not also gated
by Tempest.  That would in theory open a regression path, which is why
we haven't put up a patch yet.  Another way this could be addressed is
by the Tempest team changing the non-voting jobs causing this
situation into voting jobs, which would prevent such changes from
being merged in the first place.  The key issue here is that we need
to be able to prioritize bugs based on what's most important to each
project.

We want to be clear that we appreciate the work the Tempest team does.
We abhor bugs and want to squash them too.  The problem is just that
we're stretched pretty thin with resources right now, and being forced
to prioritize bug fixes that will get our gate un-blocked is
interfering with our ability to work on issues that may have a higher
impact on end users.

The point of this email is to find out whether anyone has a better
suggestion for how to handle this situation.

Thanks!

Erno Kuvaja
Glance Release Czar

Brian Rosmaita
Glance PTL

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc][glance] Glance needs help, it's getting critical

[Brian Rosmaita]

I take a week off and look at what happens ...

Sorry for top-posting, but I just have some general comments.  Mike
raises some good points, but I think it's too late in the cycle to
swap Glance out for Glare and expect everything to work properly.  (I
don't mean to imply anything about the quality of the Glare code base
by this, the concern is whether we can get sufficient testing and code
changes completed so that we could be sure that the substitution of
Glare + Images API would be unnoticed by deployers.  I just don't see
that as realistic given our current personnel situation).  I think for
Pike we need to work within the Glance code base and focus on the
limited set of priorities that we've more or less agreed on [0], and
seriously discuss Mike's proposal at the PTG.

I'm glad Mike brought this up now, because it would be a big change,
and as you can see in the previous messages in this thread, there are
pluses and minuses that need to be carefully considered. So I think
that discussing this issue could be constructive, if our goal is to
have a successful resolution at the next PTG.  However, I personally
don't think it's a good development strategy for the OpenStack Pike
release, which is what we need to concentrate on in the short term.

cheers,
brian

[0] https://review.openstack.org/#/c/468035/



On Mon, Jun 12, 2017 at 9:43 PM, Flavio Percoco  wrote:
>
>
> On Mon, Jun 12, 2017, 19:47 Mikhail Fedosin  wrote:
>>
>> On Tue, Jun 13, 2017 at 12:01 AM, Flavio Percoco 
>> wrote:
>>>
>>> On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:

 My opinion is that Glance stagnates and it's really hard to implement
 new
 features there. In two years, only one major improvement was developed
 (Image Import Refactoring), and no one has tested it in production yet.
 And
 this is in the heyday of the community, as you said!
>>>
>>>
>>> You're skipping 2 important things here:
>>>
>>> The first one is that focusing on the image import refactor (IIR) was a
>>> community choice. It's fixing a bigger problem that requires more focus.
>>> The
>>> design of the feature took a couple of cycles too, not the
>>> implementation. The
>>> second thing is that the slow pace may also be caused by the lack of
>>> contributors.
>>
>>
>> It's exactly what I'm talking about - implementing medium-size feature
>> (IIR is about 600 lines of code [1][2]) took 1 year of discussions and 1
>> year for implementation of 5 full-time developers. And most importantly, it
>> took all the community attention. What if we need to implement more serious
>> features? How much time will it take, given that there are not so many
>> developers left?
>
>
>
> What I was referring to is that this is not the normal case. The IIR was a
> special case, which doesn't mean implementing features is easy, as you
> mentioned.
>
 On the other hand OpenStack users have been requesting for new features
 for
 a long time: I'm talking about mutistore support, versioning of images,
 image slicing (like in docker), validation and conversion of uploading
 data
 and so on. And I can say that it is impossible to implement them without
 breaking Glance. But all this stuff is already done in Glare (multistore
 support is implemented partially, because modifications of glance_store
 are
 required). And if we switch OpenStack to Glare users will get these
 features out of the box.
>>>
>>>
>>> Some of these features could be implemented in Glance. As you mentioned,
>>> the
>>> code base is over-engineered but it could be simplified.
>>
>>
>> Everything is possible, I know that. But at what cost?
>
>
>
> Exactly! This is what I'm asking you to help me out with. I'm trying to have
> a constructive discussion on the cost of this and find a sohort term
> solution and then a long term one.
>
>>> I don't think the current problem is caused by Glance's lack of
>>> "exciting"
>>> features and I certainly don't think replacing it with Glare would be of
>>> any
>>> help now. It may be something we want to think about in the future (and
>>> this is
>>> not the first time I say this) but what you're proposing will be an
>>> expensive
>>> distraction from the real problem.
>>
>>
>> And for the very last time - I don't suggest to replace Glance now or even
>> in a year. At the moment, an email with the title "Glance needs help, it's
>> getting critical" is enough.
>> I call to think about the distant future, probably two years or near that.
>> What can prevent Flavio from writing of such emails in T cycle? Bringing
>> people from Nova and Cinder part-time will not work, because, as we
>> discussed above, even medium-size feature requires years of dedicated work,
>> and having their +1 on typo fixes... what's the benefit of that?
>
>
> Fully agree here. What I think we need is a short term and a long term
> solution. Would you agree with this?
>
> I mentioned in my 

[openstack-dev] [glance] priorities for the coming week (06/02-06-08)

[Brian Rosmaita]

As discussed at today's Glance meeting, the priorities for this week
are to prepare for the P-2 milestone release.  The changes below must
be merged by 12:00 UTC Wednesday 7 June 2017.  Please give them your
full attention.

1  Image import refactor MVP
- https://review.openstack.org/#/c/443636/
- https://review.openstack.org/#/c/443633/
- https://review.openstack.org/#/c/468835/

2  WSGI community goal
- 
https://review.openstack.org/#/q/status:open+project:openstack/glance+branch:master+topic:goal-deploy-api-in-wsgi
- https://review.openstack.org/#/c/459451/

Have a productive week!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] nominating Mike Fedosin for glance core

[Brian Rosmaita]

Having heard only affirmative responses, I've added Mikhail Fedosin to
the Glance core group, with all the rights and privileges pertaining
thereto.

Welcome back to the Glance core team, Mike!

I'd also like to express my personal thanks to you for stepping up to
help out the Glance project in these difficult times.

cheers,
brian

On Mon, May 29, 2017 at 10:01 AM, Mikhail Fedosin <mfedo...@gmail.com> wrote:
> Thank you very much for your trust! I will try not to let you down, and be
> with the project in these difficult times.
>
> Despite the fact that most of the time I'm involved in the Glare project, I
> agree that they have much in common. And at least they both share
> glance_store library. For this reason, I'm thinking of implementing the
> multi-storage support, where operators can create various settings for
> different stores. For instance, having multiple connected ceph data stores.
> The rest of the time I plan to review the code, write tests and fix minor
> bugs.
>
> I'm glad to be a part of the community!
>
> Best,
> Mike
>
> On Fri, May 26, 2017 at 7:28 AM, feilong <feil...@catalyst.net.nz> wrote:
>>
>> Welcome back, Mike.
>>
>>
>> On 26/05/17 16:21, Kekane, Abhishek wrote:
>>
>> +1, agree with Nikhil.
>>
>>
>>
>> Abhishek
>>
>>
>>
>> From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
>> Sent: Friday, May 26, 2017 6:04 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [glance] nominating Mike Fedosin for glance
>> core
>>
>>
>>
>> This is great news. Always +2 for Mike, he's been great (dev, glancer,
>> stacker ..) all the years.  Let's not wait so long for reinstatement if
>> folks are on-board, as having another core will only help.
>>
>>
>>
>> On Thu, May 25, 2017 at 11:53 AM, Brian Rosmaita
>> <rosmaita.foss...@gmail.com> wrote:
>>
>> As you've no doubt read elsewhere on the ML, we've lost several glance
>> cores recently due to employment changes.  Luckily, Mike Fedosin
>> informed me at today's Glance weekly meeting that he will have time
>> for the next few months to devote some time to Glance reviewing.
>>
>> For those who don't know Mike (mfedosin on IRC), he was a Glance core
>> for several years.  He provided a lot of notes that were used to write
>> the Glance architecture documentation that is so helpful to new
>> contributors, so he's extremely knowledgeable about the design
>> patterns used in Glance.
>>
>> Most recently, Mike's been working on the Glare project, which has a
>> lot in common with Glance.  While Mike says he can't commit much time
>> to Glance development, he has proposed porting some of the Glare tests
>> over to Glance, which will certainly help with our code coverage, and
>> would be a helpful addition to Glance.
>>
>> (Mike agreed at today's Glance meeting not to propose re-integrating
>> Glare into the Glance project until the Queens PTG (if at all), so I'm
>> not worried about that being a distraction during the Pike cycle when
>> we are so short-handed.)
>>
>> I'd like to reinstate Mike as a Glance core contributor at the next
>> Glance weekly meeting.  Please reply to this message with any comments
>> or concerns before 23:59 UTC on Wednesday 31 May 2017.
>>
>> cheers,
>> brian
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>>
>> --
>>
>> Thanks,
>>
>> Nikhil
>>
>>
>> __
>> Disclaimer: This email and any attachments are sent in strictest
>> confidence
>> for the sole use of the addressee and may contain legally privileged,
>> confidential, and proprietary data. If you are not the intended recipient,
>> please advise the sender by replying promptly to this email and then
>> delete
>> and destroy this email and any attachments without any further use,
>> copying
>> or forwarding.
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/ope

Re: [openstack-dev] [glance] priorities for the coming week (05/26-06/01)

[Brian Rosmaita]

One new patch added for the Glanceclient release:
https://review.openstack.org/#/c/467592/

On Thu, May 25, 2017 at 12:23 PM, Brian Rosmaita
<rosmaita.foss...@gmail.com> wrote:
> As discussed at today's Glance meeting, here are the priorities for this week:
>
> 0  Glanceclient release
> We plan to cut a release of the python-glanceclient on Wednesday 31
> May.  There are two patches outstanding that would be good to have in
> the release.  They need to be merged by 12:00 UTC on Tuesday 30 May.
> Please give them your attention:
> - https://review.openstack.org/444104
> - https://review.openstack.org/445318
and https://review.openstack.org/#/c/467592/
>
> 1  WSGI community goal
> Matt Treinish has patches up implementing the "control plane API
> endpoints deployment via WSGI" community goal.  Let's get them
> reviewed and merged this week so they'll be in the P-2 milestone
> release:
> - 
> https://review.openstack.org/#/q/status:open+project:openstack/glance+branch:master+topic:goal-deploy-api-in-wsgi
> - https://review.openstack.org/#/c/459451/
>
> 2  Image import refactor
> Erno has two patches stalled if anyone has time to help troubleshoot:
> - https://review.openstack.org/#/c/391442/
> - https://review.openstack.org/#/c/443632/
>
> Other items:
> I'm proposing reinstating Mike Fedosin as a Glance core:
> - http://lists.openstack.org/pipermail/openstack-dev/2017-May/117489.html
> Please reply to the above message if you have comments or concerns.
>
>
> Have a productive week, and happy towel day!
> brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [glance] comments requested on spec to fix security issue

[Brian Rosmaita]

Hello Operators,

There's a Glance spec up for fixing OSSN-0075.  It would be really
helpful to know how operators feel about the impact of the proposal
and the alternatives described in the spec:

https://review.openstack.org/#/c/468179/

(Something you may not know is that if you click on the
'gate-glance-specs-docs-ubuntu-xenial' link in the "Jenkins check"
table near the top of the page, you can see the HTML rendered version
of the spec, which may be easier to read than the raw .rst file.)

The Glance Project Team would appreciate your reviews on the spec,
because otherwise we're just guessing about the likely impact on
operators and end users.

thanks,
brian

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [glance] spec to fix a security issue

[Brian Rosmaita]

Hello Glancers,

As discussed in today's meeting, I've put up a spec to address
OSSN-0075, which is an issue I'd really like to see fixed (or at least
better mitigated) in Pike.  Please take a look at the patch and leave
some comments:

https://review.openstack.org/#/c/468179/

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] priorities for the coming week (05/26-06/01)

[Brian Rosmaita]

As discussed at today's Glance meeting, here are the priorities for this week:

0  Glanceclient release
We plan to cut a release of the python-glanceclient on Wednesday 31
May.  There are two patches outstanding that would be good to have in
the release.  They need to be merged by 12:00 UTC on Tuesday 30 May.
Please give them your attention:
- https://review.openstack.org/444104
- https://review.openstack.org/445318

1  WSGI community goal
Matt Treinish has patches up implementing the "control plane API
endpoints deployment via WSGI" community goal.  Let's get them
reviewed and merged this week so they'll be in the P-2 milestone
release:
- 
https://review.openstack.org/#/q/status:open+project:openstack/glance+branch:master+topic:goal-deploy-api-in-wsgi
- https://review.openstack.org/#/c/459451/

2  Image import refactor
Erno has two patches stalled if anyone has time to help troubleshoot:
- https://review.openstack.org/#/c/391442/
- https://review.openstack.org/#/c/443632/

Other items:
I'm proposing reinstating Mike Fedosin as a Glance core:
- http://lists.openstack.org/pipermail/openstack-dev/2017-May/117489.html
Please reply to the above message if you have comments or concerns.


Have a productive week, and happy towel day!
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] nominating Mike Fedosin for glance core

[Brian Rosmaita]

As you've no doubt read elsewhere on the ML, we've lost several glance
cores recently due to employment changes.  Luckily, Mike Fedosin
informed me at today's Glance weekly meeting that he will have time
for the next few months to devote some time to Glance reviewing.

For those who don't know Mike (mfedosin on IRC), he was a Glance core
for several years.  He provided a lot of notes that were used to write
the Glance architecture documentation that is so helpful to new
contributors, so he's extremely knowledgeable about the design
patterns used in Glance.

Most recently, Mike's been working on the Glare project, which has a
lot in common with Glance.  While Mike says he can't commit much time
to Glance development, he has proposed porting some of the Glare tests
over to Glance, which will certainly help with our code coverage, and
would be a helpful addition to Glance.

(Mike agreed at today's Glance meeting not to propose re-integrating
Glare into the Glance project until the Queens PTG (if at all), so I'm
not worried about that being a distraction during the Pike cycle when
we are so short-handed.)

I'd like to reinstate Mike as a Glance core contributor at the next
Glance weekly meeting.  Please reply to this message with any comments
or concerns before 23:59 UTC on Wednesday 31 May 2017.

cheers,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Stepping Down

[Brian Rosmaita]

Dharini, on behalf of the Glance community, thank you for your service
to the project.  You were always willing to help out in any way
necessary, and your good work is much appreciated.

We all wish you luck in your future endeavors, and we hope you'll find
some time for Glance again at some point.

cheers,
brian

On Mon, May 22, 2017 at 8:46 PM, Chandrasekar, Dharini
 wrote:
> Hello Glancers,
>
>
>
> Due to a change in my job role with my employer, I unfortunately do not have
> the bandwidth to contribute to Glance in the capacity of a Core Contributor.
>
> I hence would have to step down from my role of a Core Contibutor in Glance.
>
>
>
> I had a great experience working in OpenStack Glance. Thank you all for your
> help and support. I wish you all, good luck in all your endeavors.
>
>
>
> Thanks,
>
> Dharini.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Stepping Down

[Brian Rosmaita]

Hemanth, on behalf of the Glance community, thank you for your long
and very productive service to the project.

We all wish you luck in your future endeavors, and we hope you'll find
some time for Glance again at some point.

cheers,
brian

On Fri, May 19, 2017 at 5:49 PM, Hemanth Makkapati  wrote:
> Glancers,
> Due to a significant change to my job description, I wouldn't be able to
> contribute to Glance in the capacity of a core reviewer going forward.
> Hence, I'd like to step down from my role immediately.
> For the same reason, I'd like to step down from Glance coresec and release
> liaison roles as well.
>
> Thanks for all the help!
>
> Rooting for Glance to do great things,
> Hemanth Makkapati
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev