[Openstack-operators] Glance image 'visibility' migration in Ocata

[Brian Rosmaita]

Hello Operators,

Here are the results of the recent operators' poll concerning the
upcoming image visibility changes in Glance and the direction we plan to
take.  Thanks to all participants for helping us come to a data-driven
decision on a contentious issue.

(For background on the operators' poll, see [0].)

The operators' poll was taken to determine the migration strategy:
(A) All pre-Ocata 'private' images are migrated to 'shared'.
(B) 'private' images with no members stay 'private', 'private' images
with members are migrated to 'shared'.
(C) No strong preference as long as the documentation is clear.

The results were inconclusive:
9 total responses: 4 for (A), 4 for (B), 1 for (C)

I recommend that we go with option (A).  Here's why (in addition to the
arguments made in [2], and my arguments in the "outside" comments on [2]):

(1) There was a comment on the poll that 'private' creates an
expectation that we should meet.  This is basically my reason for
rejecting Hemanth's otherwise sensible comment on the patch that we
should remove 'shared' visibility from Timothy's patch [1] and deal with
the issue later.  This is a problem we should deal with now.

(2) We want to respect the principle of least surprise for users, in
other words, changes in API behavior as a consequence of changes
introduced in Timothy's community/shared images patch [1] are OK if
they're a result of something a user *does*, but not OK if they are
something that *happens to* a user.  To make this point concrete: if a
current image with no members is made 'private' during migration,
suddenly the add-member call can't be made on that image in either the
v1 or v2 API.  If the image is migrated to 'shared', on the other hand,
the current user workflow is not changed.  If the user decides to set
the visibility on the image to 'private', then the add-member calls will
return 409s, but that's OK because it's a result of an action the user took.

But, you say, all my previously 'private' images being listed as
'shared' could be a big surprise!  I think this is a trade-off we should
accept, and address by educating Ocata operators and users of what to
expect.  Here's the key thing people need to be aware of:

You can specify a visibility of 'private' at the time of image creation,
and it's respected.  An interface could (should?) make this choice clear
at the time of image creation.

So to be completely clear, my recommendation is that we go with
migration strategy (A) (i.e., the one specified in [2]) and Timothy's
current community/shared images patch [1].

What's missing in Glance is an easy way to list images that have
visibility 'shared' and no members (and hence, aren't consumable by
anyone other than the owner) from images with visibility 'shared' that
do have members.  This could be addressed by adding a 'has_members'
field to the Image object.  We could use some feedback on how useful
such a field would be.

This course of action is a compromise so that we can preserve backward
compatibility in the Image APIs.  Common to many compromises, no one is
going to be completely happy with the outcome.  But I really think it's
the best way to go.

thanks,
brian


[0]
http://lists.openstack.org/pipermail/openstack-operators/2016-November/012107.html
[1] https://review.openstack.org/#/c/369110/
[2] https://review.openstack.org/#/c/396919/

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

Re: [Openstack-operators] Discontinue multiple image location support in Glance?

[Brian Rosmaita]

Given that we announced this survey just before the Thanksgiving
holidays in the USA, I thought it would be a good idea to send a
reminder.  See below for info about the survey, and thanks to the 7
operators who have already responded.

survey: https://goo.gl/forms/Mt41MoAEGDR4RZTt1
closes: 23:59 UTC on Friday 9 December 2016

On 11/22/16, 4:34 PM, "Brian Rosmaita" 
wrote:

> Hello Operators,
>
> Glance has a "multiple image locations" feature that's been a pain point
> for developers and operators.
>
> The original developers have left the project and we are trying to
> determine the use cases people have that involve multiple image locations,
> because we'd like to either
> (a) discontinue the feature,
> (b) improve the feature so it's easier to use, or
> (c) replace it with something better that addresses the use cases.
>
> In order to do this, we need to know what your use case is.  So, if you
> are currently using Glance multiple image locations, please take a few
> minutes right now to fill out this extremely short 5 question form (3 are
> multiple choice!):
>
>https://goo.gl/forms/Mt41MoAEGDR4RZTt1
>
> Please answer by 23:59 UTC on Friday 9 December 2016.
>
>
> thanks,
> brian



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

Re: [Openstack-operators] [Fault Genes] WG Weekly Meeting Summary

[Nematollah Bidokhti]

General:
-   We had two new members (Ahmed & Zainab) joining our WG
-   Still plan to generate the white paper. Tentative target date is before 
the Operator mid cycle meeting.

Standard Agenda Items:
-   Launchpad data transformation to Fault Genes database
o   Michael: will send out the latest dataset to team members
o   Suli: will has create draft of the web based database and will complete 
after next week
-   Stack-overflow data capture
o   Michael: will send the output of the Stack-overflow script to the team 
for review
-   User Interface for Operators
o   Suli: will create the UI
o   Team discussed the format today
o   Need to finalize the interface
-   Machine learning analysis process
o   Jinzhong, Suli, Zainab & Michael: collaborate on the data analysis
-   Collaboration with other projects
o   Nemat: will continue to work with Eric Kao from Congress project
-   Open items
o   No open items discussed




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