[openstack-dev] [keystone] Keystone Team Update - Week of 5 November 2018

[Colleen Murphy]

# Keystone Team Update - Week of 5 November 2018

## News

### Community Goals Status

Python3-first[1]: completed
Upgrade status check[2]: scaffolding is completed but we don't have actual 
checks yet
Mutable config[3] (goal from last cycle): review in progress but needs work

[1] https://governance.openstack.org/tc/goals/stein/python3-first.html
[2] https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html
[3] 
https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html

### Berlin Summit

The Berlin summit is next week so we won't be holding the weekly meeting or 
office hours. As mentioned last week, we a few keystone-related forum sessions 
and talks:

* Operator feedback 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22792/keystone-operator-feedback
* Keystone as an Identity Provider Proxy - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22791/keystone-as-an-identity-provider-proxy
* Keystone project update - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22728/keystone-project-updates
* Keystone project onboarding - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22727/keystone-project-onboarding
* Deletion of project and project resources - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22784/deletion-of-project-and-project-resources
* Enforcing quota consistently with Unified Limits - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22557/enforcing-quota-consistently-with-unified-limits
* Towards an Open Cloud Exchange - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22320/towards-an-open-cloud-exchange
* Pushing keystone over the edge - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22044/pushing-keystone-over-the-edge
* A seamlessly federated multi-cloud - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22607/a-seamlessly-federated-multi-cloud
* OpenStack policy 101 - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21977/openstack-policy-101
* Dynamic policy for OpenStack with Open Policy Agent - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21976/dynamic-policy-for-openstack-with-open-policy-agent
* Identity integration between OpenStack and Kubernetes -  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22123/identity-integration-between-openstack-and-kubernetes

## Open Specs

Stein specs: https://bit.ly/2Pi6dGj

Ongoing specs: https://bit.ly/2OyDLTh

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT

We merged 34 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2RLApdA

There are 40 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 4 new bugs and closed 3.

Bugs opened (4) 
Bug #1801873 (keystone:Undecided) opened by Izak A Eygelaar 
https://bugs.launchpad.net/keystone/+bug/1801873 
Bug #1802035 (keystone:Undecided) opened by Joshua Cornutt 
https://bugs.launchpad.net/keystone/+bug/1802035 
Bug #1802136 (keystone:Undecided) opened by Simon Reinkemeier 
https://bugs.launchpad.net/keystone/+bug/1802136 
Bug #1802357 (oslo.policy:Undecided) opened by Alfredo Moralejo 
https://bugs.launchpad.net/oslo.policy/+bug/1802357 

Bugs fixed (3) 
Bug #1800124 (keystone:Critical) fixed by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1800124 
Bug #1797584 (keystonemiddleware:Medium) fixed by Michael Johnson 
https://bugs.launchpad.net/keystonemiddleware/+bug/1797584
Bug #1361743 (keystonemiddleware:Wishlist) fixed by Morgan Fainberg 
https://bugs.launchpad.net/keystonemiddleware/+bug/1361743

## Milestone Outlook

https://releases.openstack.org/stein/schedule.html

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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]Naming the T release of OpenStack -- Poll open

[Colleen Murphy]

On Wed, Nov 7, 2018, at 11:12 AM, Lajos Katona wrote:
> Hi,
> 
> Maybe I missed something but I got the message: "Already voted
> A vote has already been cast using your voter key.
> 
> Poll results will be available only to the following users:
> 
> t...@bakeyournoodle.com"
> 
> Could you help me to have a correct link?

The public polling service limits voting to one vote per IP address. If someone 
in your office space has already voted, the poll won't let anyone else in the 
office vote. You need to find a different public IP address to vote from, 
either by tunneling through a proxy or physically going somewhere else with a 
different network.

Colleen

> 
> Regards
> Lajos
> 
> On 2018. 11. 06. 3:19, Tony Breeds wrote:
> 
> 
> Hi all,
> 
>Time is running out for you to have your say in the T release name
> poll.  We have just under 3 days left.  If you haven't voted please do!
> 
> On Tue, Oct 30, 2018 at 04:40:25PM +1100, Tony Breeds wrote:
> 
> 
> Hi folks,
> 
> It is time again to cast your vote for the naming of the T Release.
> As with last time we'll use a public polling option over per user private URLs
> for voting.  This means, everybody should proceed to use the following URL to
> cast their vote:
> 
>   
> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_aac97f1cbb6c61df=b9e448b340787f0e
> 
> We've selected a public poll to ensure that the whole community, not just 
> gerrit
> change owners get a vote.  Also the size of our community has grown such that 
> we
> can overwhelm CIVS if using private urls.  A public can mean that users
> behind NAT, proxy servers or firewalls may receive an message saying
> that your vote has already been lodged, if this happens please try
> another IP.
> 
> Because this is a public poll, results will currently be only viewable by 
> myself
> until the poll closes. Once closed, I'll post the URL making the results
> viewable to everybody. This was done to avoid everybody seeing the results 
> while
> the public poll is running.
> 
> The poll will officially end on 2018-11-08 00:00:00+00:00[1], and 
> results will be
> posted shortly after.
> 
> [1] https://governance.openstack.org/tc/reference/release-naming.html
> ---
> 
> According to the Release Naming Process, this poll is to determine the
> community preferences for the name of the T release of OpenStack. It is
> possible that the top choice is not viable for legal reasons, so the second or
> later community preference could wind up being the name.
> 
> Release Name Criteria
> -
> 
> Each release name must start with the letter of the ISO basic Latin alphabet
> following the initial letter of the previous release, starting with the
> initial release of "Austin". After "Z", the next name should start with
> "A" again.
> 
> The name must be composed only of the 26 characters of the ISO basic Latin
> alphabet. Names which can be transliterated into this character set are also
> acceptable.
> 
> The name must refer to the physical or human geography of the region
> encompassing the location of the OpenStack design summit for the
> corresponding release. The exact boundaries of the geographic region under
> consideration must be declared before the opening of nominations, as part of
> the initiation of the selection process.
> 
> The name must be a single word with a maximum of 10 characters. Words that
> describe the feature should not be included, so "Foo City" or "Foo Peak"
> would both be eligible as "Foo".
> 
> Names which do not meet these criteria but otherwise sound really cool
> should be added to a separate section of the wiki page and the TC may make
> an exception for one or more of them to be considered in the Condorcet poll.
> The naming official is responsible for presenting the list of exceptional
> names for consideration to the TC before the poll opens.
> 
> Exact Geographic Region
> ---
> 
> The Geographic Region from where names for the S release will come is Colorado
> 
> Proposed Names
> --
> 
> * Tarryall
> * Teakettle
> * Teller
> * Telluride
> * Thomas : the Tank Engine
> * Thornton
> * Tiger
> * Tincup
> * Timnath
> * Timber
> * Tiny Town
> * Torreys
> * Trail
> * Trinidad
> * Treasure
> * Troublesome
> * Trussville
> * Turret
> * Tyrone
> 
> Proposed Names that do not meet the criteria (accepted by the TC)
> -
> 
> * Train : Many Attendees of the first Denver PTG have a story to tell 
> about the trains near the PTG hotel.  We could celebrate those stories 
> with this name
> 
> Yours Tony.
> 
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?
> subject:unsubscribe
> 

[openstack-dev] [keystone] Keystone Team Update - Week of 29 October 2018

[Colleen Murphy]

# Keystone Team Update - Week of 29 October 2018

## News

### Berlin Summit

Somewhat quiet week as we've been getting into summit prep mode. We'll have two 
forum sessions, one for operator feedback[1] and one to discuss Keystone as an 
IdP Proxy[2]. We'll have our traditional project update[3] and project 
onboarding[4] along with many keystone-related talks from the 
team[5][6][7][8][9][10].

[1] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22792/keystone-operator-feedback
[2] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22791/keystone-as-an-identity-provider-proxy
[3] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22728/keystone-project-updates
[4] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22727/keystone-project-onboarding
[5] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22557/enforcing-quota-consistently-with-unified-limits
[6] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22320/towards-an-open-cloud-exchange
[7] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22044/pushing-keystone-over-the-edge
[8] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22607/a-seamlessly-federated-multi-cloud
[9] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21977/openstack-policy-101
[10] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21976/dynamic-policy-for-openstack-with-open-policy-agent

## Open Specs

Stein specs: https://bit.ly/2Pi6dGj

Ongoing specs: https://bit.ly/2OyDLTh

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT

We merged 31 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2PUk84S

There are 45 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 5 new bugs and closed 9.

Bugs opened (5) 
Bug #180 (keystone:Low) opened by Egor Panfilov 
https://bugs.launchpad.net/keystone/+bug/180 
Bug #1800651 (keystone:Undecided) opened by Ramon Heidrich 
https://bugs.launchpad.net/keystone/+bug/1800651 
Bug #1801095 (keystone:Undecided) opened by artem.v.vasilyev 
https://bugs.launchpad.net/keystone/+bug/1801095 
Bug #1801309 (keystone:Undecided) opened by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1801309 
Bug #1801101 (keystoneauth:Undecided) opened by Egor Panfilov 
https://bugs.launchpad.net/keystoneauth/+bug/1801101 

Bugs closed (5) 
Bug #1553224 (keystone:Wishlist) 
https://bugs.launchpad.net/keystone/+bug/1553224 
Bug #1642988 (keystone:Wishlist) 
https://bugs.launchpad.net/keystone/+bug/1642988 
Bug #1710329 (keystone:Undecided) 
https://bugs.launchpad.net/keystone/+bug/1710329 
Bug #1713574 (keystoneauth:Undecided) 
https://bugs.launchpad.net/keystoneauth/+bug/1713574 
Bug #1801101 (keystoneauth:Undecided) 
https://bugs.launchpad.net/keystoneauth/+bug/1801101 

Bugs fixed (4) 
Bug #1788415 (keystone:High) fixed by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1788415 
Bug #1797876 (keystone:High) fixed by Vishakha Agarwal 
https://bugs.launchpad.net/keystone/+bug/1797876 
Bug #1798716 (keystone:Low) fixed by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1798716 
Bug #1800017 (keystonemiddleware:Medium) fixed by Guang Yee 
https://bugs.launchpad.net/keystonemiddleware/+bug/1800017

## Milestone Outlook

https://releases.openstack.org/stein/schedule.html

Our spec proposal freeze for Stein was two weeks ago, so barring extraordinary 
circumstances we'll be working on refining our remaining three Stein specs for 
the spec freeze after the new year.

## Shout-outs

Thanks Nathan Kinder for all the ldappool fixes!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] [keystone] Keystone Team Update - Catch-up report 8 October - 28 October 2018

[Colleen Murphy]

# Keystone Team Update - Catch-up report 8 October - 28 October 2018

It's been a few weeks since I've been able to get one of these out, so here's a 
summary of what's been happening in that time.

## News

### Community Goals Status

Mutable config: Kristi has a patch under review[1].
Python3-first: Keystone has python3 functional tests completed, working our way 
through the remainder of our repositories.
Upgrade status checks: Scaffolding is in place[2] but we need to decide what 
checks should be included.

[1] https://review.openstack.org/585417
[2] https://review.openstack.org/608785

### Flask conversion complete

The last patch to migrate keystone to Flask has merged[3]. Thanks Morgan for 
pushing all this through! There is still some work to be done to migrate 
keystonemiddleware away from the Webob implementation.

With the migration to Flask, some users have noticed that the healthcheck 
middleware no longer works the same way[4]. Custom middleware is also no longer 
possible, but there are workarounds[5].

[3] https://review.openstack.org/609839
[4] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135696.html
[5] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-10-02.log.html#t2018-10-02T13:53:12

### Oath federation examples

Oath open-sourced their custom auth plugin for Athenz[6], which we may want to 
model our federated shadow user implementation after. We're analyzing the 
difference and collaborating on a path to move in this direction in keystone[7].

[6] 
https://github.com/yahoo/openstack-collab/tree/master/keystone-federation-ocata
[7] https://etherpad.openstack.org/p/keystone-shadow-mapping-athenz-delta

### Outreachy

I submitted two projects for Outreachy and there has been a lot of interest in 
both of them. Applicants now need to log a contribution so they can be eligible 
to apply for the project, so you may see a lot of new faces before the November 
6 deadline. If you have ideas for beginner-friendly tasks, let me know so I can 
hand them out to our newcomers.

## Open Specs

Search query: https://bit.ly/2Pi6dGj

In addition to the three Stein specs that have been open for a while, we opened 
and closed another to allow for explicit domain IDs upon domain creation[8]. 

There are also a number of "ongoing" specs proposed that need attention[9]

[8] https://bit.ly/2OyDLTh
[9] https://review.openstack.org/611201

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] Forum Schedule - Seeking Community Review

[Colleen Murphy]

On Mon, Oct 15, 2018, at 10:01 PM, Jimmy McArthur wrote:
> Hi -
> 
> The Forum schedule is now up 
> (https://www.openstack.org/summit/berlin-2018/summit-schedule/#track=262).  
> If you see a glaring content conflict within the Forum itself, please 
> let me know.
> 
> You can also view the Full Schedule in the attached PDF if that makes 
> life easier...
> 
> NOTE: BoFs and WGs are still not all up on the schedule.  No need to let 
> us know :)

Couple of things:

1. I noticed Julia's session "Community outreach when culture, time zones, and 
language differ" and Thierry's session "Getting OpenStack users involved in the 
project" are scheduled at the same time on Tuesday, but they're quite related 
topics and I think many people (especially in the TC) would want to attend both 
sessions.

2. The session "You don't know nothing about Public Cloud SDKs, yet" doesn't 
seem to have a moderator listed.

Colleen

__
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] [keystone] Keystone Team Update - Week of 1 October 2018

[Colleen Murphy]

# Keystone Team Update - Week of 1 October 2018

## News

### JSON-home

As Morgan works through the flaskification project, it's been clear that some 
of the JSON-home[1] code could use some refactoring and that the document 
itself is inconsistent[2], but we're unclear whether anyone uses this or cares 
if it changes. If you have ever used keystone's JSON-home implementation, come 
talk to us.

[1] https://adam.younglogic.com/2018/01/using-json-home-keystone/
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-10-02.log.html#t2018-10-02T18:22:25

## Open Specs

Search query: https://bit.ly/2Pi6dGj

We still only have three specs targeted at Stein, but Adam has revived several 
"ongoing" specs that can use some eyes, please take a look[3].

[3] https://bit.ly/2OyDLTh

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT

We merged 19 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2PUk84S

There are 41 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

One of these is a proposal to add rate-limiting to keystoneauth[4], would be 
good to get some more reactions to it.

Another is the flaskification patch of doom[5] which will definitely need some 
close attention.

[4] https://review.openstack.org/605043
[5] https://review.openstack.org/603461

## Bugs

This week we opened 5 new bugs and closed 7.

Bugs opened (5) 
Bug #1795487 (keystone:Undecided) opened by Amy Marrich 
https://bugs.launchpad.net/keystone/+bug/1795487 
Bug #1795800 (keystone:Undecided) opened by Andy Ngo 
https://bugs.launchpad.net/keystone/+bug/1795800 
Bug #1796077 (keystone:Undecided) opened by Ching Kuo 
https://bugs.launchpad.net/keystone/+bug/1796077 
Bug #1796247 (keystone:Undecided) opened by Yang Youseok 
https://bugs.launchpad.net/keystone/+bug/1796247 
Bug #1795496 (oslo.policy:Undecided) opened by Adam Young 
https://bugs.launchpad.net/oslo.policy/+bug/1795496 

Bugs closed (3) 
Bug #1782687 (keystone:Undecided) 
https://bugs.launchpad.net/keystone/+bug/1782687 
Bug #1796077 (keystone:Undecided) 
https://bugs.launchpad.net/keystone/+bug/1796077 
Bug #1796247 (keystone:Undecided) 
https://bugs.launchpad.net/keystone/+bug/1796247 

Bugs fixed (4) 
Bug #1794552 (keystone:Medium) fixed by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1794552 
Bug #1753585 (keystone:Low) fixed by Vishakha Agarwal 
https://bugs.launchpad.net/keystone/+bug/1753585 
Bug #1615076 (keystone:Undecided) fixed by Vishakha Agarwal 
https://bugs.launchpad.net/keystone/+bug/1615076 
Bug #1615076 (python-keystoneclient:Undecided) fixed by Vishakha Agarwal 
https://bugs.launchpad.net/python-keystoneclient/+bug/1615076

## Milestone Outlook

https://releases.openstack.org/stein/schedule.html

Now just 3 weeks away from the spec proposal freeze.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] [keystone] Keystone Team Update - Week of 24 September 2018

[Colleen Murphy]

# Keystone Team Update - Week of 24 September 2018

## News

A theme this week was enhancing keystone's federation implementation to better 
support Edge use cases. We talked about it some on IRC[1] and the mailing 
list[2].

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-25.log.html#t2018-09-25T16:37:42
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/135072.html

## Open Specs

Search query: https://bit.ly/2Pi6dGj

In addition to the Stein specs mentioned last week, Adam has been working on an 
untargeted spec for federation enhancements[3].

[3] https://review.openstack.org/313604

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT

We merged 15 changes this week, including lots of bugfixes and improvements to 
our Zuul config.

## Changes that need Attention

Search query: https://bit.ly/2PUk84S

There are 54 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 7 new bugs and closed 7.

Bugs opened (7) 
Bug #1794376 (keystone:High) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1794376
Bug #1794552 (keystone:High) opened by Adam Young 
https://bugs.launchpad.net/keystone/+bug/1794552
Bug #1794864 (keystone:Medium) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1794864 
Bug #1794527 (keystone:Wishlist) opened by Adam Young 
https://bugs.launchpad.net/keystone/+bug/1794527 
Bug #1794112 (keystone:Undecided) opened by fuckubuntu1 
https://bugs.launchpad.net/keystone/+bug/1794112 
Bug #1794726 (keystone:Undecided) opened by Colleen Murphy 
https://bugs.launchpad.net/keystone/+bug/1794726 
Bug #1794179 (keystonemiddleware:Undecided) opened by Tim Burke 
https://bugs.launchpad.net/keystonemiddleware/+bug/1794179 

Bugs closed (3) 
Bug #1794112 (keystone:Undecided) 
https://bugs.launchpad.net/keystone/+bug/1794112 
Bug #973681 (keystonemiddleware:Medium) 
https://bugs.launchpad.net/keystonemiddleware/+bug/973681 
Bug #1473042 (keystonemiddleware:Wishlist) 
https://bugs.launchpad.net/keystonemiddleware/+bug/1473042 

Bugs fixed (4) 
Bug #1750843 (keystone:Low) fixed by Matthew Thode 
https://bugs.launchpad.net/keystone/+bug/1750843 
Bug #1768980 (keystone:Low) fixed by Colleen Murphy 
https://bugs.launchpad.net/keystone/+bug/1768980 
Bug #1473292 (keystone:Wishlist) fixed by Vishakha Agarwal 
https://bugs.launchpad.net/keystone/+bug/1473292 
Bug #1275962 (keystonemiddleware:Wishlist) fixed by no one 
https://bugs.launchpad.net/keystonemiddleware/+bug/127596

## Milestone Outlook

https://releases.openstack.org/stein/schedule.html

Spec proposal freeze deadline is a month, if you would like to see a feature in 
keystone in Stein please propose it now so it can get feedback before the spec 
freeze deadline.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Colleen Murphy]

On Thu, Sep 27, 2018, at 5:09 AM, vishakha agarwal wrote:
> > From : Colleen Murphy 
> > To : 
> > Date : Tue, 25 Sep 2018 18:33:30 +0900
> > Subject : Re: [openstack-dev] [keystone] Domain-namespaced user attributes 
> > in SAML assertions from Keystone IdPs
> >  Forwarded message 
> >  > On Mon, Sep 24, 2018, at 8:40 PM, John Dennis wrote:
> >  > > On 9/24/18 8:00 AM, Colleen Murphy wrote:
> >  > > > This is in regard to https://launchpad.net/bugs/1641625 and the 
> > proposed patch https://review.openstack.org/588211 for it. Thanks Vishakha 
> > for getting the ball rolling.
> >  > > >
> >  > > > tl;dr: Keystone as an IdP should support sending 
> > non-strings/lists-of-strings as user attribute values, specifically lists 
> > of keystone groups, here's how that might happen.
> >  > > >
> >  > > > Problem statement:
> >  > > >
> >  > > > When keystone is set up as a service provider with an external 
> > non-keystone identity provider, it is common to configure the mapping rules 
> > to accept a list of group names from the IdP and map them to some property 
> > of a local keystone user, usually also a keystone group name. When keystone 
> > acts as the IdP, it's not currently possible to send a group name as a user 
> > property in the assertion. There are a few problems:
> >  > > >
> >  > > >  1. We haven't added any openstack_groups key in the creation of 
> > the SAML assertion 
> > (http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164).
> >  > > >  2. If we did, this would not be enough. Unlike other IdPs, in 
> > keystone there can be multiple groups with the same name, namespaced by 
> > domain. So it's not enough for the SAML AttributeStatement to contain a 
> > semi-colon-separated list of group names, since a user could theoretically 
> > be a member of two or more groups with the same name.
> >  > > > * Why can't we just send group IDs, which are unique? Because 
> > two different keystones are not going to have independent groups with the 
> > same UUID, so we cannot possibly map an ID of a group from keystone A to 
> > the ID of a different group in keystone B. We could map the ID of the group 
> > in in A to the name of a group in B but then operators need to create 
> > groups with UUIDs as names which is a little awkward for both the operator 
> > and the user who now is a member of groups with nondescriptive names.
> >  > > >  3. If we then were able to encode a complex type like a group 
> > dict in a SAML assertion, we'd have to deal with it on the service provider 
> > side by being able to parse such an environment variable from the Apache 
> > headers.
> >  > > >  4. The current mapping rules engine uses basic python string 
> > formatting to translate remote key-value pairs to local rules. We would 
> > need to change the mapping API to work with values more complex than 
> > strings and lists of strings.
> >  > > >
> >  > > > Possible solution:
> >  > > >
> >  > > > Vishakha's patch (https://review.openstack.org/588211) starts to 
> > solve (1) but it doesn't go far enough to solve (2-4). What we talked about 
> > at the PTG was:
> >  > > >
> >  > > >  2. Encode the group+domain as a string, for example by using 
> > the dict string repr or a string representation of some custom XML and 
> > maybe base64 encoding it.
> >  > > >  * It's not totally clear whether the AttributeValue class 
> > of the pysaml2 library supports any data types outside of the xmlns:xs 
> > namespace or whether nested XML is an option, so encoding the whole thing 
> > as an xs:string seems like the simplest solution.
> >  > > >  3. The SP will have to be aware that openstack_groups is a 
> > special key that needs the encoding reversed.
> >  > > >  * I wrote down "MultiDict" in my notes but I don't recall 
> > exactly what format the environment variable would take that would make a 
> > MultiDict make sense here, in any case I think encoding the whole thing as 
> > a string eliminates the need for this.
> >  > > >  4. We didn't talk about the mapping API, but here's what I 
> > think. If we were just talking about group names, the mapping API today 
> > would work like this (slight oversimplification for brevity):
> >  > > >

Re: [openstack-dev] RFC: Next minimum libvirt / QEMU versions for 'T' release

[Colleen Murphy]

On Mon, Sep 24, 2018, at 3:22 PM, Kashyap Chamarthy wrote:
> Hey folks,
> 
> Before we bump the agreed upon[1] minimum versions for libvirt and QEMU
> for 'Stein', we need to do the tedious work of picking the NEXT_MIN_*
> versions for the 'T' (which is still in the naming phase) release, which
> will come out in the autumn (Sep-Nov) of 2019.
> 
> Proposal
> 
> 
> Looking at the DistroSupportMatrix[2], it seems like we can pick the
> libvirt and QEMU versions supported by the next LTS release of Ubuntu --
> 18.04; "Bionic", which are:
> 
> libvirt: 4.0.0
> QEMU:2.11
> 
> Debian, Fedora, Ubuntu (Bionic), openSUSE currently already ship the
> above versions.  And it seems reasonable to assume that the enterprise
> distribtions will also ship the said versions pretty soon; but let's
> double-confirm below.
> 
> Considerations and open questions
> -
> 
> (a) KVM for IBM z Systems: John Garbutt pointed out[3] on IRC that:
> "IBM announced that KVM for IBM z will be withdrawn, effective March
> 31, 2018 [...] development will not only continue unaffected, but
> the options for users grow, especially with the recent addition of
> SuSE to the existing support in Ubuntu."
> 
> The message seems to be: "use a regular distribution".  So this is
> covered, if we a version based on other distributions.
> 
> (b) Oracle Linux: Can you please confirm if you'll be able to
> release libvirt and QEMU to 4.0.0 and 2.11, respectively?
> 
> (c) SLES: Same question as above.

Already responded on IRC and on the patch, but to close the loop here: these 
should be fine for the next versions of SLES, thanks for checking.

Colleen

> 
> Assuming Oracle Linux and SLES confirm, please let us know if there are
> any objections if we pick NEXT_MIN_* versions for the OpenStack 'T'
> release to be libvirt: 4.0.0 and QEMU: 2.11.
> 
> * * *
> 
> A refresher on libvirt and QEMU release schedules
> -
> 
>   - There will be at least 12 libvirt releases (_excluding_ maintenance
> releases) by Autumn 2019.  A new libvirt release comes out every
> month[4].
> 
>   - And there will be about 4 releases of QEMU.  A new QEMU release
> comes out once every four months.
> 
> [1] http://git.openstack.org/cgit/openstack/nova/commit/?h=master=28d337b
> -- Pick next minimum libvirt / QEMU versions for "Stein"
> [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
> [3] http://kvmonz.blogspot.com/2017/03/kvm-for-ibm-z-withdrawal.html
> [4] https://libvirt.org/downloads.html#schedule
> 
> -- 
> /kashyap
> 
> __
> 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] [cinder][glance][ironic][keystone][neutron][nova][edge] PTG summary on edge discussions

[Colleen Murphy]

Thanks for the summary, Ildiko. I have some questions inline.

On Tue, Sep 25, 2018, at 11:23 AM, Ildiko Vancsa wrote:



> 
> We agreed to prefer federation for Keystone and came up with two work 
> items to cover missing functionality:
> 
> * Keystone to trust a token from an ID Provider master and when the auth 
> method is called, perform an idempotent creation of the user, project 
> and role assignments according to the assertions made in the token

This sounds like it is based on the customizations done at Oath, which to my 
recollection did not use the actual federation implementation in keystone due 
to its reliance on Athenz (I think?) as an identity manager. Something similar 
can be accomplished in standard keystone with the mapping API in keystone which 
can cause dynamic generation of a shadow user, project and role assignments.

> * Keystone should support the creation of users and projects with 
> predictable UUIDs (eg.: hash of the name of the users and projects). 
> This greatly simplifies Image federation and telemetry gathering

I was in and out of the room and don't recall this discussion exactly. We have 
historically pushed back hard against allowing setting a project ID via the 
API, though I can see predictable-but-not-settable as less problematic. One of 
the use cases from the past was being able to use the same token in different 
regions, which is problematic from a security perspective. Is that that idea 
here? Or could someone provide more details on why this is needed?

Were there any volunteers to help write up specs and work on the 
implementations in keystone?



Colleen (cmurphy)

__
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] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Colleen Murphy]

On Mon, Sep 24, 2018, at 8:40 PM, John Dennis wrote:
> On 9/24/18 8:00 AM, Colleen Murphy wrote:
> > This is in regard to https://launchpad.net/bugs/1641625 and the proposed 
> > patch https://review.openstack.org/588211 for it. Thanks Vishakha for 
> > getting the ball rolling.
> > 
> > tl;dr: Keystone as an IdP should support sending 
> > non-strings/lists-of-strings as user attribute values, specifically lists 
> > of keystone groups, here's how that might happen.
> > 
> > Problem statement:
> > 
> > When keystone is set up as a service provider with an external non-keystone 
> > identity provider, it is common to configure the mapping rules to accept a 
> > list of group names from the IdP and map them to some property of a local 
> > keystone user, usually also a keystone group name. When keystone acts as 
> > the IdP, it's not currently possible to send a group name as a user 
> > property in the assertion. There are a few problems:
> >  
> >  1. We haven't added any openstack_groups key in the creation of the 
> > SAML assertion 
> > (http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164).
> >  2. If we did, this would not be enough. Unlike other IdPs, in keystone 
> > there can be multiple groups with the same name, namespaced by domain. So 
> > it's not enough for the SAML AttributeStatement to contain a 
> > semi-colon-separated list of group names, since a user could theoretically 
> > be a member of two or more groups with the same name.
> > * Why can't we just send group IDs, which are unique? Because two 
> > different keystones are not going to have independent groups with the same 
> > UUID, so we cannot possibly map an ID of a group from keystone A to the ID 
> > of a different group in keystone B. We could map the ID of the group in in 
> > A to the name of a group in B but then operators need to create groups with 
> > UUIDs as names which is a little awkward for both the operator and the user 
> > who now is a member of groups with nondescriptive names.
> >  3. If we then were able to encode a complex type like a group dict in 
> > a SAML assertion, we'd have to deal with it on the service provider side by 
> > being able to parse such an environment variable from the Apache headers.
> >  4. The current mapping rules engine uses basic python string 
> > formatting to translate remote key-value pairs to local rules. We would 
> > need to change the mapping API to work with values more complex than 
> > strings and lists of strings.
> >  
> > Possible solution:
> > 
> > Vishakha's patch (https://review.openstack.org/588211) starts to solve (1) 
> > but it doesn't go far enough to solve (2-4). What we talked about at the 
> > PTG was:
> >  
> >  2. Encode the group+domain as a string, for example by using the dict 
> > string repr or a string representation of some custom XML and maybe base64 
> > encoding it.
> >  * It's not totally clear whether the AttributeValue class of the 
> > pysaml2 library supports any data types outside of the xmlns:xs namespace 
> > or whether nested XML is an option, so encoding the whole thing as an 
> > xs:string seems like the simplest solution.
> >  3. The SP will have to be aware that openstack_groups is a special key 
> > that needs the encoding reversed.
> >  * I wrote down "MultiDict" in my notes but I don't recall exactly 
> > what format the environment variable would take that would make a MultiDict 
> > make sense here, in any case I think encoding the whole thing as a string 
> > eliminates the need for this.
> >  4. We didn't talk about the mapping API, but here's what I think. If 
> > we were just talking about group names, the mapping API today would work 
> > like this (slight oversimplification for brevity):
> >  
> > Given a list of openstack_groups like ["A", "B", "C"], it would work like 
> > this:
> >  
> > [
> >{
> >  "local":
> >  [
> >{
> >  "group":
> >  {
> >"name": "{0}",
> >"domain":
> >{
> >  "name": "federated_domain"
> >}
> >  }
> >}
> >  ], "remote":
> >  [
> >{
> >  "type": "openstack_groups"
> > 

Re: [openstack-dev] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Colleen Murphy]

On Mon, Sep 24, 2018, at 4:35 PM, Lance Bragstad wrote:
> On Mon, Sep 24, 2018 at 9:31 AM Colleen Murphy  wrote:
> 
> > On Mon, Sep 24, 2018, at 4:16 PM, Lance Bragstad wrote:
> > > On Mon, Sep 24, 2018 at 7:00 AM Colleen Murphy 
> > wrote:
> > >
> > > > This is in regard to https://launchpad.net/bugs/1641625 and the
> > proposed
> > > > patch https://review.openstack.org/588211 for it. Thanks Vishakha for
> > > > getting the ball rolling.
> > > >
> > > > tl;dr: Keystone as an IdP should support sending
> > > > non-strings/lists-of-strings as user attribute values, specifically
> > lists
> > > > of keystone groups, here's how that might happen.
> > > >
> > > > Problem statement:
> > > >
> > > > When keystone is set up as a service provider with an external
> > > > non-keystone identity provider, it is common to configure the mapping
> > rules
> > > > to accept a list of group names from the IdP and map them to some
> > property
> > > > of a local keystone user, usually also a keystone group name. When
> > keystone
> > > > acts as the IdP, it's not currently possible to send a group name as a
> > user
> > > > property in the assertion. There are a few problems:
> > > >
> > > > 1. We haven't added any openstack_groups key in the creation of the
> > > > SAML assertion (
> > > >
> > http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164
> > > > ).
> > > > 2. If we did, this would not be enough. Unlike other IdPs, in
> > keystone
> > > > there can be multiple groups with the same name, namespaced by domain.
> > So
> > > > it's not enough for the SAML AttributeStatement to contain a
> > > > semi-colon-separated list of group names, since a user could
> > theoretically
> > > > be a member of two or more groups with the same name.
> > > >* Why can't we just send group IDs, which are unique? Because two
> > > > different keystones are not going to have independent groups with the
> > same
> > > > UUID, so we cannot possibly map an ID of a group from keystone A to
> > the ID
> > > > of a different group in keystone B. We could map the ID of the group
> > in in
> > > > A to the name of a group in B but then operators need to create groups
> > with
> > > > UUIDs as names which is a little awkward for both the operator and the
> > user
> > > > who now is a member of groups with nondescriptive names.
> > > > 3. If we then were able to encode a complex type like a group dict
> > in
> > > > a SAML assertion, we'd have to deal with it on the service provider
> > side by
> > > > being able to parse such an environment variable from the Apache
> > headers.
> > > > 4. The current mapping rules engine uses basic python string
> > > > formatting to translate remote key-value pairs to local rules. We would
> > > > need to change the mapping API to work with values more complex than
> > > > strings and lists of strings.
> > > >
> > > > Possible solution:
> > > >
> > > > Vishakha's patch (https://review.openstack.org/588211) starts to solve
> > > > (1) but it doesn't go far enough to solve (2-4). What we talked about
> > at
> > > > the PTG was:
> > > >
> > > > 2. Encode the group+domain as a string, for example by using the
> > dict
> > > > string repr or a string representation of some custom XML and maybe
> > base64
> > > > encoding it.
> > > > * It's not totally clear whether the AttributeValue class of
> > the
> > > > pysaml2 library supports any data types outside of the xmlns:xs
> > namespace
> > > > or whether nested XML is an option, so encoding the whole thing as an
> > > > xs:string seems like the simplest solution.
> > > >
> > >
> > > Encoding this makes sense. We can formally support different SAML data
> > > types in the future if a better solution comes along. We would have to
> > make
> > > the service provider deal with both types of encoding, but we could
> > > eventually consolidate, and users shouldn't know the difference. Right?
> >
> > The only way this would make a difference to the user is if they need to
> > debug a request by actually looking at

Re: [openstack-dev] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Colleen Murphy]

On Mon, Sep 24, 2018, at 4:16 PM, Lance Bragstad wrote:
> On Mon, Sep 24, 2018 at 7:00 AM Colleen Murphy  wrote:
> 
> > This is in regard to https://launchpad.net/bugs/1641625 and the proposed
> > patch https://review.openstack.org/588211 for it. Thanks Vishakha for
> > getting the ball rolling.
> >
> > tl;dr: Keystone as an IdP should support sending
> > non-strings/lists-of-strings as user attribute values, specifically lists
> > of keystone groups, here's how that might happen.
> >
> > Problem statement:
> >
> > When keystone is set up as a service provider with an external
> > non-keystone identity provider, it is common to configure the mapping rules
> > to accept a list of group names from the IdP and map them to some property
> > of a local keystone user, usually also a keystone group name. When keystone
> > acts as the IdP, it's not currently possible to send a group name as a user
> > property in the assertion. There are a few problems:
> >
> > 1. We haven't added any openstack_groups key in the creation of the
> > SAML assertion (
> > http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164
> > ).
> > 2. If we did, this would not be enough. Unlike other IdPs, in keystone
> > there can be multiple groups with the same name, namespaced by domain. So
> > it's not enough for the SAML AttributeStatement to contain a
> > semi-colon-separated list of group names, since a user could theoretically
> > be a member of two or more groups with the same name.
> >* Why can't we just send group IDs, which are unique? Because two
> > different keystones are not going to have independent groups with the same
> > UUID, so we cannot possibly map an ID of a group from keystone A to the ID
> > of a different group in keystone B. We could map the ID of the group in in
> > A to the name of a group in B but then operators need to create groups with
> > UUIDs as names which is a little awkward for both the operator and the user
> > who now is a member of groups with nondescriptive names.
> > 3. If we then were able to encode a complex type like a group dict in
> > a SAML assertion, we'd have to deal with it on the service provider side by
> > being able to parse such an environment variable from the Apache headers.
> > 4. The current mapping rules engine uses basic python string
> > formatting to translate remote key-value pairs to local rules. We would
> > need to change the mapping API to work with values more complex than
> > strings and lists of strings.
> >
> > Possible solution:
> >
> > Vishakha's patch (https://review.openstack.org/588211) starts to solve
> > (1) but it doesn't go far enough to solve (2-4). What we talked about at
> > the PTG was:
> >
> > 2. Encode the group+domain as a string, for example by using the dict
> > string repr or a string representation of some custom XML and maybe base64
> > encoding it.
> > * It's not totally clear whether the AttributeValue class of the
> > pysaml2 library supports any data types outside of the xmlns:xs namespace
> > or whether nested XML is an option, so encoding the whole thing as an
> > xs:string seems like the simplest solution.
> >
> 
> Encoding this makes sense. We can formally support different SAML data
> types in the future if a better solution comes along. We would have to make
> the service provider deal with both types of encoding, but we could
> eventually consolidate, and users shouldn't know the difference. Right?

The only way this would make a difference to the user is if they need to debug 
a request by actually looking at the response to this request[1]. If we were to 
base64-encode the string that immediately obfuscates what the actual value is. 
I'm not really sure if we need to base64-encode it or just serialize it some 
other way.

[1] https://developer.openstack.org/api-ref/identity/v3-ext/index.html#id404
> 
> 
> > 3. The SP will have to be aware that openstack_groups is a special key
> > that needs the encoding reversed.
> > * I wrote down "MultiDict" in my notes but I don't recall exactly
> > what format the environment variable would take that would make a MultiDict
> > make sense here, in any case I think encoding the whole thing as a string
> > eliminates the need for this.
> > 4. We didn't talk about the mapping API, but here's what I think. If
> > we were just talking about group names, the mapping API today would work
> > like this (slight oversimplification for brevity):
> >
> > Given a list of openstack_groups 

[openstack-dev] [keystone] Domain-namespaced user attributes in SAML assertions from Keystone IdPs

[Colleen Murphy]

This is in regard to https://launchpad.net/bugs/1641625 and the proposed patch 
https://review.openstack.org/588211 for it. Thanks Vishakha for getting the 
ball rolling.

tl;dr: Keystone as an IdP should support sending non-strings/lists-of-strings 
as user attribute values, specifically lists of keystone groups, here's how 
that might happen.

Problem statement:

When keystone is set up as a service provider with an external non-keystone 
identity provider, it is common to configure the mapping rules to accept a list 
of group names from the IdP and map them to some property of a local keystone 
user, usually also a keystone group name. When keystone acts as the IdP, it's 
not currently possible to send a group name as a user property in the 
assertion. There are a few problems:

1. We haven't added any openstack_groups key in the creation of the SAML 
assertion 
(http://git.openstack.org/cgit/openstack/keystone/tree/keystone/federation/idp.py?h=14.0.0#n164).
2. If we did, this would not be enough. Unlike other IdPs, in keystone 
there can be multiple groups with the same name, namespaced by domain. So it's 
not enough for the SAML AttributeStatement to contain a semi-colon-separated 
list of group names, since a user could theoretically be a member of two or 
more groups with the same name.
   * Why can't we just send group IDs, which are unique? Because two different 
keystones are not going to have independent groups with the same UUID, so we 
cannot possibly map an ID of a group from keystone A to the ID of a different 
group in keystone B. We could map the ID of the group in in A to the name of a 
group in B but then operators need to create groups with UUIDs as names which 
is a little awkward for both the operator and the user who now is a member of 
groups with nondescriptive names.
3. If we then were able to encode a complex type like a group dict in a 
SAML assertion, we'd have to deal with it on the service provider side by being 
able to parse such an environment variable from the Apache headers.
4. The current mapping rules engine uses basic python string formatting to 
translate remote key-value pairs to local rules. We would need to change the 
mapping API to work with values more complex than strings and lists of strings.

Possible solution:

Vishakha's patch (https://review.openstack.org/588211) starts to solve (1) but 
it doesn't go far enough to solve (2-4). What we talked about at the PTG was:

2. Encode the group+domain as a string, for example by using the dict 
string repr or a string representation of some custom XML and maybe base64 
encoding it.
* It's not totally clear whether the AttributeValue class of the 
pysaml2 library supports any data types outside of the xmlns:xs namespace or 
whether nested XML is an option, so encoding the whole thing as an xs:string 
seems like the simplest solution.
3. The SP will have to be aware that openstack_groups is a special key that 
needs the encoding reversed.
* I wrote down "MultiDict" in my notes but I don't recall exactly what 
format the environment variable would take that would make a MultiDict make 
sense here, in any case I think encoding the whole thing as a string eliminates 
the need for this.
4. We didn't talk about the mapping API, but here's what I think. If we 
were just talking about group names, the mapping API today would work like this 
(slight oversimplification for brevity):

Given a list of openstack_groups like ["A", "B", "C"], it would work like this:

[
  {
"local": 
[
  {
"group": 
{
  "name": "{0}", 
  "domain":
  {
"name": "federated_domain"
  }
}
  }
], "remote": 
[
  {
"type": "openstack_groups"
  }
]
  }
]
(paste in case the spacing makes this unreadable: 
http://paste.openstack.org/show/730623/ )

But now, we no longer have a list of strings but something more like [{"name": 
"A", "domain_name": "Default"} {"name": "B", "domain_name": "Default", "name": 
"A", "domain_name": "domainB"}]. Since {0} isn't a string, this example doesn't 
really work. Instead, let's assume that in step (3) we converted the decoded 
AttributeValue text to an object. Then the mapping could look more like this:

[
  {
"local": 
[
  {
"group": 
{
  "name": "{0.name}", 
  "domain":
  {
"name": "{0.domain_name}"
  }
}
  }
], "remote": 
[
  {
"type": "openstack_groups"
  }
]
  }
]
(paste: http://paste.openstack.org/show/730622/ )

Alternatively, we could forget about the namespacing problem and simply say we 
only pass group names in the assertion, and if you have ambiguous group names 
you're on your own. We could also try to support both, e.g. have an 
openstack_groups mean a list of group names for simpler use cases, and 

[openstack-dev] [keystone] Keystone Team Update - Week of 17 September 2018

[Colleen Murphy]

# Keystone Team Update - Week of 17 September 2018

## News

### PTG recaps

The PTG was last week! Lance[1] and I[2] posted recaps of the keystone sessions.

[1] https://www.lbragstad.com/blog/openstack-stein-ptg-keystone-summary
[2] http://www.gazlene.net/denver-ptg-2.html

### No-op roles and default policy rules

adriant started a discussion[3][4] about the difficulty with creating limited 
or no-op roles due to the fact that most OpenStack services have default policy 
rules of just "" which translates to "any role on any project". This means if 
you wanted to give a user access only to, for example, Swift, which uses its 
own ACL model, you have to craft all of your policy files for every other 
OpenStack service to not use "" since those rules would allow the Swift-only 
users access to those other services. The default role work that has been 
ongoing since last cycle and that will eventually turn into a cross-project 
community effort will help to alleviate this hardship for operators by making 
default policies use explicit roles like "reader" and "member", but this will 
require a long transition period.

[3] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134886.html
[4] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-19.log.html#t2018-09-19T21:45:30

### Consistent policy names

lbragstad started a thread to come to consensus on standard policy name 
conventions so that we can come up with guidance when it comes time to start 
migrating policies to use default roles. Vote for your favorite bikeshed color 
on the thread[5].

[5] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134597.html

## Open Specs

Search query: https://bit.ly/2Pi6dGj

knikolla started working on a refreshable app creds proposal which will be 
useful for federation and Edge use cases[6]. wxy is working on the next 
iteration of hierarchical limit models by adding domains to the mix[7]. 
lbragstad reproposed the JWT spec with additional details that we discussed at 
the PTG[8].

[6] https://review.openstack.org/604201
[7] https://review.openstack.org/599491
[8] https://review.openstack.org/541903

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT (link updated to include oslo.limit)

We merged 15 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2PUk84S (link updated to include oslo.limit)

There are 50 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 6 new bugs and closed 3.

Bugs opened (5) 
Bug #1793027 (keystone:Critical) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1793027 
Bug #1793374 (keystone:Low) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1793374 
Bug #1793421 (keystone:Low) opened by fupingxie 
https://bugs.launchpad.net/keystone/+bug/1793421 
Bug #1792868 (keystone:Undecided) opened by Tao Li 
https://bugs.launchpad.net/keystone/+bug/1792868 
Bug #1793347 (keystone:Undecided) opened by Tobias Urdin 
https://bugs.launchpad.net/keystone/+bug/1793347 

Bugs fixed (3) 
Bug #1793027 (keystone:Critical) fixed by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1793027 
Bug #1754677 (keystone:High) fixed by Raildo Mascena de Sousa Filho 
https://bugs.launchpad.net/keystone/+bug/1754677 
Bug #1431987 (keystone:Wishlist) fixed by no one 
https://bugs.launchpad.net/keystone/+bug/1431987

## Milestone Outlook

https://releases.openstack.org/stein/schedule.html

Welcome to the Stein cycle! This cycle is a longer one so we have a bit of 
extra time between the spec freeze and feature freeze. lbragstad just updated 
the schedule so if you have issues with it we can probably still make 
adjustments.

## Shout-outs

Vishakha Agarwal has been doing a lot of work tackling our bug backlog, thanks 
a lot for your hard work!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] [placement] [infra] [qa] tuning some zuul jobs from "it works" to "proper"

[Colleen Murphy]

On Wed, Sep 19, 2018, at 4:23 PM, Monty Taylor wrote:
> On 09/19/2018 08:25 AM, Chris Dent wrote:
> > 

> also, cmurphy has been working on updating some of keystone's legacy 
> jobs recently:
> 
> https://review.openstack.org/602452
> 
> which might also be a source for copying from.
> 

Disclaimer before anyone blindly copies: https://bit.ly/2vq26SR

__
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] [keystone] Keystone Team Update - Week of 20 August 2018

[Colleen Murphy]

# Keystone Team Update - Week of 20 August 2018

## News

We ended up releasing an RC2 after all in order to include placeholder 
sqlalchemy migrations for Rocky, thanks wxy for catching it!

## Open Specs

Search query: https://bit.ly/2Pi6dGj

Lance reproposed the auth receipts and application credentials specs that we 
punted on last cycle for Stein.

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 13 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 75 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

If that seems like a lot more than last week, it's because someone has 
helpfully proposed many patches supporting the python3-first community goal[1]. 
However, they haven't coordinated with the goal champions and have missed some 
steps[2], like proposing the removal of jobs from project-config and proposing 
jobs to the stable branches. I would recommend coordinating with the 
python3-first goal champions on merging these patches. The good news is that 
all of our projects seem to work with python 3.6!

[1] https://governance.openstack.org/tc/goals/stein/python3-first.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2018-August/133610.html

## Bugs

This week we opened 4 new bugs and closed 1.

Bugs opened (4) 
Bug #1788415 (keystone:High) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1788415 
Bug #1788694 (keystone:High) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1788694 
Bug #1787874 (keystone:Medium) opened by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1787874 
Bug #1788183 (oslo.policy:Undecided) opened by Stephen Finucane 
https://bugs.launchpad.net/oslo.policy/+bug/1788183 

Bugs closed (1) 
Bug #1771203 (python-keystoneclient:Undecided) 
https://bugs.launchpad.net/python-keystoneclient/+bug/1771203 

Bugs fixed (0)

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

We're at the end of the RC period with the official release happening next week.

## Shout-outs

Thanks everyone for a great release!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] [keystone] Keystone Team Update - Week of 13 August 2018

[Colleen Murphy]

Forgot the [keystone] tag.

On Fri, Aug 17, 2018, at 4:11 PM, Colleen Murphy wrote:
> # Keystone Team Update - Week of 13 Auguest 2018
> 
> ## News
> 
> Relatively quiet week with minimal fires. Prepare for the PTG by adding 
> topics to the etherpad[1].
> 
> [1] https://etherpad.openstack.org/p/keystone-stein-ptg
> 
> ## Recently Merged Changes
> 
> Search query: https://bit.ly/2IACk3F
> 
> We merged 27 changes this week.
> 
> ## Changes that need Attention
> 
> Search query: https://bit.ly/2wv7QLK
> 
> There are 46 changes that are passing CI, not in merge conflict, have no 
> negative reviews and aren't proposed by bots.
> 
> ## Bugs
> 
> This week we opened 2 new bugs and closed 2.
> 
> Bugs opened (2) 
> Bug #1786594 (keystone:Undecided) opened by Egor Panfilov 
> https://bugs.launchpad.net/keystone/+bug/1786594 
> Bug #1787212 (keystone:Undecided) opened by tujiapeng 
> https://bugs.launchpad.net/keystone/+bug/1787212 
> 
> Bugs fixed (2) 
> Bug #1784536 (keystone:Low) fixed by Bi wei 
> https://bugs.launchpad.net/keystone/+bug/1784536 
> Bug #1785898 (ldappool:Undecided) fixed by Nick Wilburn 
> https://bugs.launchpad.net/ldappool/+bug/1785898
> 
> ## Milestone Outlook
> 
> https://releases.openstack.org/rocky/schedule.html
> 
> Next week will be the last week to release another RC if we need to.
> 
> ## Shout-outs
> 
> Congratulations to Nick Wilburn (orange_julius) whose first patch to 
> OpenStack landed this week[2] which fixed a major bug in the ldappool 
> library. Many thanks!
> 
> [2] https://review.openstack.org/591174
> 
> ## Help with this newsletter
> 
> Help contribute to this newsletter by editing the etherpad: 
> https://etherpad.openstack.org/p/keystone-team-newsletter
> 
> __
> 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] Keystone Team Update - Week of 13 Auguest 2018

[Colleen Murphy]

# Keystone Team Update - Week of 13 Auguest 2018

## News

Relatively quiet week with minimal fires. Prepare for the PTG by adding topics 
to the etherpad[1].

[1] https://etherpad.openstack.org/p/keystone-stein-ptg

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 27 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 46 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 2 new bugs and closed 2.

Bugs opened (2) 
Bug #1786594 (keystone:Undecided) opened by Egor Panfilov 
https://bugs.launchpad.net/keystone/+bug/1786594 
Bug #1787212 (keystone:Undecided) opened by tujiapeng 
https://bugs.launchpad.net/keystone/+bug/1787212 

Bugs fixed (2) 
Bug #1784536 (keystone:Low) fixed by Bi wei 
https://bugs.launchpad.net/keystone/+bug/1784536 
Bug #1785898 (ldappool:Undecided) fixed by Nick Wilburn 
https://bugs.launchpad.net/ldappool/+bug/1785898

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

Next week will be the last week to release another RC if we need to.

## Shout-outs

Congratulations to Nick Wilburn (orange_julius) whose first patch to OpenStack 
landed this week[2] which fixed a major bug in the ldappool library. Many 
thanks!

[2] https://review.openstack.org/591174

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone] Keystone Team Update - Week of 6 August 2018

[Colleen Murphy]

On Sat, Aug 11, 2018, at 11:14 AM, Lance Bragstad wrote:
> On Fri, Aug 10, 2018, 23:47 Colleen Murphy  wrote:
> 
> > # Keystone Team Update - Week of 6 August 2018
> >
> > ## News
> >
> > ### RC1
> >
> > We released RC1 this week[1]. Please try it out and be on the lookout for
> > critical bugs. As of yet we don't seem to have any showstoppers that would
> > require another RC.
> 
> 
> Should we rev the keystone version for the inclusion of the new default
> roles?
> 
> 
> > [1] https://releases.openstack.org/rocky/index.html#rocky-keystone

[snipped]

To close the loop on this, we discussed on IRC[2], Lance was talking about the 
API version, not the release version, and we decided that although the 
bootstrap change allows the new roles to be created at initialization, it 
doesn't guarantee that roles will be in every deployment, and so it's not a 
feature we can advertise with an API version bump.

Colleen

[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-13.log.html#t2018-08-13T07:56:22

__
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] [keystone] Keystone Team Update - Week of 6 August 2018

[Colleen Murphy]

# Keystone Team Update - Week of 6 August 2018

## News

### RC1

We released RC1 this week[1]. Please try it out and be on the lookout for 
critical bugs. As of yet we don't seem to have any showstoppers that would 
require another RC.

[1] https://releases.openstack.org/rocky/index.html#rocky-keystone

### Edge Discussions

The OpenNFV Edge Cloud group and the Edge Computing Group are ramping up 
implementations of proofs of concept for the potential keystone architectures 
for edge cloud scenarios. Some of the models under investigation or that we've 
suggested[2] are keystone-to-keystone federation, regular federation with an 
external identity provider, database synchronization via database 
replication[3] and database synchronization via an agent. One idea to enhance 
the federation-based models is to make application credentials refreshable, 
which Kristi is going to write a spec for[4]. I encourage the team to join the 
meeting calls[5][6], to help the people working on implementations, and 
volunteer for technical work items. It would be great to be at a point where we 
can discuss design details for the next cycle at the PTG.

[2] https://wiki.openstack.org/wiki/Keystone_edge_architectures
[3] https://review.openstack.org/566448
[4] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-07.log.html#t2018-08-07T15:34:54
[5] https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings
[6] https://wiki.opnfv.org/display/PROJ/Edge+cloud

### Flask Work

Morgan has been diligently working on converting our APIs to Flask, please see 
the many outstanding reviews[7]. Some of these conversions should be 
parallelizeable so if you'd like to help him out I'm sure he would appreciate 
it, just coordinate with him[8].

[7] https://review.openstack.org/#/q/status:open+topic:bug/1776504
[8] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-06.log.html#t2018-08-06T20:31:19

### Self-Service Keystone

At the weekly meeting Adam suggested we make self-service keystone a focus 
point of the PTG[9]. Currently, policy limitations make it difficult for an 
unprivileged keystone user to get things done or to get information without the 
help of an administrator. There are some other projects that have been created 
to act as workflow proxies to mitigate keystone's limitations, such as 
Adjutant[10] (now an official OpenStack project) and Ksproj[11] (written by 
Kristi). The question is whether the primitives offered by keystone are 
sufficient building blocks for these external tools to leverage, or if we 
should be doing more of this logic within keystone. Certainly improving our 
RBAC model is going to be a major part of improving the self-service user 
experience.

[9] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-08-07-16.00.log.html#l-121
[10] https://adjutant.readthedocs.io/en/latest/
[11] https://github.com/CCI-MOC/ksproj

### Standalone Keystone

Also at the meeting and during office hours, we revived the discussion of what 
it would take to have a standalone keystone be a useful identity provider for 
non-OpenStack projects[12][13]. First up we'd need to turn keystone into a 
fully-fledged SAML IdP, which it's not at the moment (which is a point of 
confusion in our documentation), or even add support for it to act as an OpenID 
Connect IdP. This would be relatively easy to do (or at least not impossible). 
Then the application would have to use keystonemiddleware or its own middleware 
to route requests to keystone to issue and validate tokens (this is one aspect 
where we've previously discussed whether JWT could benefit us). Then the 
question is what should a not-OpenStack application do with keystone's "scoped 
RBAC"? It would all depend on how the resources of the application are grouped 
and whether they care about multitenancy in some form. Likely each application 
would have different needs and it would be difficult to find a 
one-size-fits-all approach. We're interested to know whether anyone has a 
burning use case for something like this.

[12] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-08-07-16.00.log.html#l-192
[13] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-08-07.log.html#t2018-08-07T17:01:30

### PTG Planning

We're in the brainstorming phase for the PTG, please add topics to the 
etherpad[14]. Lance will organize these into an agenda soonish.

[14] https://etherpad.openstack.org/p/keystone-stein-ptg

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 16 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 54 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots. Special attention should be given 
to patches that close bugs, and we should make sure we backport any critical 
bugfixes to stable/rocky.

Re: [openstack-dev] PTG Denver Horns

[Colleen Murphy]

On Wed, Aug 8, 2018, at 12:18 PM, Adam Spiers wrote:
> Matthew Thode  wrote:
> >On 18-08-07 23:18:26, David Medberry wrote:
> >> Requests have finally been made (today, August 7, 2018) to end the horns on
> >> the train from Denver to Denver International airport (within the city
> >> limits of Denver.) Prior approval had been given to remove the FLAGGERS
> >> that were stationed at each crossing intersection.
> >>
> >> Of particular note (at the bottom of the article):
> >>
> >> There’s no estimate for how long it could take the FRA to approve quiet
> >> zones.
> >>
> >> ref:
> >> https://www.9news.com/article/news/local/next/denver-officially-asks-fra-for-permission-to-quiet-a-line-horns/73-581499094
> >>
> >> I'd recommend bringing your sleeping aids, ear plugs, etc, just in case not
> >> approved by next month's PTG. (The Renaissance is within Denver proper as
> >> near as I can tell so that nearby intersection should be covered by this
> >> ruling/decision if and when it comes down.)
> >
> >Thanks for the update, if you are up to it, keeping us informed on this
> >would be nice, if only for the hilarity.
> 
> Thanks indeed for the warning.
> 
> If the approval doesn't go through, we may need to resume the design
> work started last year; see lines 187 onwards of
> 
> https://etherpad.openstack.org/p/queens-PTG-feedback

Luckily the client work for this is already started: 
https://github.com/dtroyer/osc-choochoo

__
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] [keystone] Feature Status and Exceptions

[Colleen Murphy]

On Fri, Jul 13, 2018, at 9:19 PM, Lance Bragstad wrote:
> Hey all,
> 
> As noted in the weekly report [0], today is feature freeze for
> keystone-related specifications. I wanted to elaborate on each
> specification so that our plan is clear moving forward.
> 
> *Unified Limits**
> **
> *I propose that we issue a feature freeze exception for this work.
> Mainly because the changes are relatively isolated and low-risk. The
> majority of the feedback on the approach is being held up by an
> interface decision, which doesn't impact users, it's certainly more of a
> developer preference [1].
> 
> That said, I don't think it would be too ambitious to focus reviews on
> this next week and iron out the last few bits well before rocky-3.
> 
> *Default Roles**
> *
> The implementation to ensure each of the new defaults is available after
> installing keystone is complete. We realized that incorporating those
> new roles into keystone's default policies would be a lot easier after
> the flask work lands [2]. Instead of doing a bunch of work to
> incorporate those default and then re-doing it to accommodate flask, I
> think we have a safe checkpoint where we are right now. We can use free
> cycles during the RC period to queue up those implementation, mark them
> with a -2, and hit the ground running in Stein. This approach feels like
> the safest compromise between risk and reward.
> 
> *Capability Lists**
> *
> The capability lists involves a lot of work, not just within keystone,
> but also keystonemiddleware, which will freeze next week. I think it's
> reasonable to say that this will be something that has to be pushed to
> Stein [3].
> 
> *MFA Receipts**
> *
> Much of the code used in the existing approach uses a lot of the same
> patterns from the token provider API within keystone [4]. Since the UUID
> and SQL parts of the token provider API have been removed, we're also in
> the middle of cleaning up a ton of technical debt in that area [5].
> Adrian seems OK giving us the opportunity to finish cleaning things up
> before reworking his proposal for authentication receipts. IMO, this
> seems totally reasonable since it will help us ensure the new code for
> authentication receipts doesn't have the bad patterns that have plagued
> us with the token provider API.
> 
> 
> Does anyone have objections to any of these proposals? If not, I can
> start bumping various specs to reflect the status described here.

All sounds good to me, thanks for writing this up.

Colleen
> 
> 
> [0] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-July/132202.html
> [1]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/strict-two-level-model
> [2]
> https://review.openstack.org/#/q/(status:open+OR+status:merged)+project:openstack/keystone+branch:master+topic:bug/1776504
> [3]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/whitelist-extension-for-app-creds
> [4]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/mfa-auth-receipt
> [5]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1778945
> 
> __
> 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
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

__
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] [keystone] Keystone Team Update - Week of 9 July 2018

[Colleen Murphy]

# Keystone Team Update - Week of 9 July 2018

## News

### New Core Reviewer

We added a new core reviewer[1]: thanks to XiYuan for stepping up to take this 
responsibility and for all your hard work on keystone!

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132123.html

### Release Status

This week is our scheduled feature freeze week, but we did not have quite the 
tumult of activity we had at feature freeze last cycle. We're pushing the auth 
receipts work until after the token model refactor is finished[2], to avoid the 
receipts model having to carry extra technical debt. The fine-grained access 
control feature for application credentials is also going to need to be pushed 
to next cycle when more of us can dedicate time to helping with it it[3]. The 
base work for default roles was completed[4] but the auditing of the keystone 
API hasn't been completed yet and is partly dependent on the flask work, so it 
is going to continue on into next cycle[5]. The hierarchical limits work is 
pretty solid but we're (likely) going to let it slide into next week so that 
some of the interface details can be worked out[6].
  
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-07-10.log.html#t2018-07-10T01:39:27
[3] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-07-13.log.html#t2018-07-13T14:19:08
[4] https://review.openstack.org/572243
[5] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-07-13.log.html#t2018-07-13T14:02:03
[6] https://review.openstack.org/557696

### PTG Planning

We're starting to prepare topics for the next PTG in Denver[7] so please add 
topics to the planning etherpad[8].

[7] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132144.html
[8] https://etherpad.openstack.org/p/keystone-stein-ptg

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 20 changes this week, including several of the flask conversion 
patches.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 62 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots. The major efforts to focus on are 
the token model refactor[9], the flaskification work[10], and the hierarchical 
project limits work[11].

[9] https://review.openstack.org/#/q/is:open+topic:bug/1778945
[10] https://review.openstack.org/#/q/is:open+topic:bug/1776504
[11] https://review.openstack.org/#/q/is:open+topic:bp/strict-two-level-model

## Bugs

This week we opened 3 new bugs and closed 4.

Bugs opened (3) 
Bug #1780532 (keystone:Undecided) opened by zheng yan 
https://bugs.launchpad.net/keystone/+bug/1780532 
Bug #1780896 (keystone:Undecided) opened by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1780896 
Bug #1781536 (keystone:Undecided) opened by Pawan Gupta 
https://bugs.launchpad.net/keystone/+bug/1781536 

Bugs closed (0) 

Bugs fixed (4) 
Bug #1765193 (keystone:Medium) fixed by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1765193 
Bug #1780159 (keystone:Medium) fixed by Sami Makki 
https://bugs.launchpad.net/keystone/+bug/1780159 
Bug #1780896 (keystone:Undecided) fixed by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1780896 
Bug #1779172 (oslo.policy:Undecided) fixed by Lance Bragstad 
https://bugs.launchpad.net/oslo.policy/+bug/1779172

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

This week is our scheduled feature freeze. We are likely going to make an 
extension for the hierarchical project limits work, pending discussion on the 
mailing list.

Next week is the non-client final release date[12], so work happening in 
keystoneauth, keystonemiddleware, and our oslo libraries needs to be finished 
and reviewed prior to next Thursday so a release can be requested in time.

[12] https://review.openstack.org/572243

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] [keystone] Keystone Team Update - Week of 2 July 2018

[Colleen Murphy]

# Keystone Team Update - Week of 2 July 2018

## News

Fairly quiet week due to the holiday in the US. During the weekly meeting[1] we 
did some brainstorming about how to address the mutable config community 
goal[2], and extending oslo.policy types in order to be able to make 
finer-grained rules.

[1] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-07-03-16.00.log.html
[2] 
https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 11 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 71 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots. Many of these are for the flask 
migration and for the hierarchical limits work, so please have a look.

## Bugs

This week we opened 5 new bugs and also closed 5.

Bugs opened (5) 
Bug #1779889 (keystone:Medium) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1779889 
Bug #1779903 (keystone:Undecided) opened by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1779903 
Bug #1780159 (keystone:Undecided) opened by mchlumsky 
https://bugs.launchpad.net/keystone/+bug/1780159 
Bug #1780377 (keystone:Undecided) opened by Kristi Nikolla 
https://bugs.launchpad.net/keystone/+bug/1780377 
Bug #1780503 (keystone:Undecided) opened by Gage Hugo 
https://bugs.launchpad.net/keystone/+bug/1780503 

Bugs closed (2) 
Bug #1643301 (keystone:Wishlist) 
https://bugs.launchpad.net/keystone/+bug/1643301 
Bug #1780159 (keystone:Undecided) 
https://bugs.launchpad.net/keystone/+bug/1780159 

Bugs fixed (3) 
Bug #1711883 (keystone:Medium) fixed by Vishakha Agarwal 
https://bugs.launchpad.net/keystone/+bug/1711883 
Bug #1777892 (keystone:Medium) fixed by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1777892 
Bug #1777893 (keystone:Medium) fixed by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1777893

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

Our feature freeze is scheduled for next week. There is still a lot of ongoing 
work that needs to be completed and reviewed.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone] Keystone Team Update - Week of 25 June 2018

[Colleen Murphy]

# Keystone Team Update - Week of 25 June 2018

## News

### Policy Auditing

Auditing the keystone APIs and resolving what roles they need under which scope 
types is the next step in implementing basic default roles. This was already 
done for barbican but we still need to go through the exercise for keystone[1]. 
However, the ongoing Flask work[2] will have implications for our policy 
handling and we may want to wait to complete that work before proceeding so 
that we don't end up having to do it twice[3].

[1] 
https://docs.google.com/spreadsheets/d/1kd3OJCLMsIkPgULN31WFw9PA9-3-X99yaDnjWDGOvm0/edit?usp=sharing
[2] https://bugs.launchpad.net/keystone/+bug/1776504
[3] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-26-16.00.log.html#l-56

### Flask Work

The flaskification work has necessitated a new mechanism for policy 
enforcement[4] which will replace @protected. Take a look at the change that 
introduces the RBACEnforcer[5] and try to get familiar with it.

[4] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-26-16.00.log.html#l-229
[5] https://review.openstack.org/576639

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 10 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 57 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 6 new bugs and closed 2.

Bugs opened (6)
Bug #1778603 (keystone:High) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1778603 
Bug #1778945 (keystone:Medium) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1778945 
Bug #1778989 (keystone:Undecided) opened by Lars Kellogg-Stedman 
https://bugs.launchpad.net/keystone/+bug/1778989 
Bug #1779286 (keystone:Undecided) opened by Dmitry 
https://bugs.launchpad.net/keystone/+bug/1779286 
Bug #1778949 (oslo.policy:Undecided) opened by Lance Bragstad 
https://bugs.launchpad.net/oslo.policy/+bug/1778949 
Bug #1779172 (oslo.policy:Undecided) opened by Lance Bragstad 
https://bugs.launchpad.net/oslo.policy/+bug/1779172 

Bugs closed (0) 

Bugs fixed (2) 
Bug #1757022 (keystone:Undecided) fixed by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1757022 
Bug #1778109 (keystone:Undecided) fixed by Jeremy Freudberg 
https://bugs.launchpad.net/keystone/+bug/1778109

This report was generated with http://paste.openstack.org/show/724598/ and 
https://github.com/lbragstad/launchpad-toolkit#building-bug-reports

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

Keystone's feature freeze is in just two weeks. Please help out by reviewing 
our major feature work:

https://review.openstack.org/#/q/is:open+topic:bp/mfa-auth-receipt

https://review.openstack.org/#/q/is:open+topic:bp/whitelist-extension-for-app-creds
https://review.openstack.org/#/q/is:open+topic:bp/strict-two-level-model

As well as the flaskification work which will have a major impact on other 
ongoing work:

https://review.openstack.org/#/q/is:open+topic:bug/1776504

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] [keystone] Keystone Team Update - Week of 18 June 2018

[Colleen Murphy]

# Keystone Team Update - Week of 18 June 2018

## News

### Default Roles Fallout

Our change to automatically create the 'reader' and 'member' roles during 
bootstrap[1] caused some problems in the CI of other projects[2]. One problem 
was that projects were manually creating a 'Member' role, and with the database 
backend being case-insensitve, there would be a conflict with the 'member' role 
that keystone is now creating. The immediate fix is to ensure the clients in CI 
are checking for the 'member' role rather than the 'Member' role before trying 
to create either role, but in the longer term, clients would benefit from 
decoupling the API case sensitivity from the configuration of the database 
backend[3].

Another problem was a bug related to implied roles in trusts[4]. If a role 
implies another, but a trust is created with both roles explicitly, the token 
will contain duplicate role names, which breaks the usage of trusts and hit 
Sahara. This issue would have existed before, but was only discovered now that 
we have implied roles by default.

[1] https://review.openstack.org/572243
[2] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-24
[3] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-175
[4] https://bugs.launchpad.net/keystone/+bug/1778109

### Limits Schema Restructuring

Morgan discovered some problems with the database schemas[5] for registered 
limits and project limits and proposed that we can improve performance and 
reduce data duplication by doing some restructuring and adding some indexes. 
The migration path to the new schema is tricky[6] and we're still trying to 
come up with a strategy that avoids triggers[7].

[5] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-06-19-16.00.log.html#l-184
[6] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:04:05
[7] https://etherpad.openstack.org/p/keystone-unified-limit-migration-notepad

### No-nitpicking Culture

Following the community discussion on fostering a healthier culture by avoiding 
needlessly nitpicking changes[8], the keystone team had a thoughtful discussion 
on what constitutes nitpicking and how we should be voting on changes[9]. 
Context is always important, and considering who the author is, how significant 
the imperfection is, and how much effort it will take the author to correct it 
should to be considered when deciding whether to ask them to change something 
about their patch versus proposing yor own fix in a folllowup. I've always been 
proud of keystone's no-nitpicking culture and it's encouraging to see 
continuous introspection.

[8] https://governance.openstack.org/tc/reference/principles.html
[9] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-19.log.html#t2018-06-19T21:18:01

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 16 changes this week, including client support for limits and a major 
bugfix for implied roles.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 57 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots, so their authors are waiting for 
any feedback.

## Bugs

This week we opened 5 new bugs and closed 4.

Bugs opened (5) 
Bug #1777671 (keystone:Medium) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1777671 
Bug #1777892 (keystone:Medium) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1777892 
Bug #1777893 (keystone:Medium) opened by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1777893 
Bug #1778023 (keystone:Undecided) opened by kirandevraaj 
https://bugs.launchpad.net/keystone/+bug/1778023 
Bug #1778109 (keystone:Undecided) opened by Jeremy Freudberg 
https://bugs.launchpad.net/keystone/+bug/1778109 

Bugs closed (2) 
Bug #1758460 (keystone:Low) https://bugs.launchpad.net/keystone/+bug/1758460 
Bug #1774654 (keystone:Undecided) 
https://bugs.launchpad.net/keystone/+bug/1774654 

Bugs fixed (2) 
Bug #1754184 (keystone:Medium) fixed by wangxiyuan 
https://bugs.launchpad.net/keystone/+bug/1754184 
Bug #1774229 (keystone:Medium) fixed by Lance Bragstad 
https://bugs.launchpad.net/keystone/+bug/1774229

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

This week is our feature proposal freeze deadline. All our major efforts seem 
to have at least one initial patch proposed for them.

The keystone feature freeze is only 3 weeks away. The final release for 
non-client libraries is the week after that[10], so we need to ensure that all 
the work needed especially for keystonemiddleware is completed by them.

[10] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131732.html

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 

[openstack-dev] [keystone] Keystone Team Update - Week of 11 June 2018

[Colleen Murphy]

# Keystone Team Update - Week of 11 June 2018

## News

### New Implied Roles in keystone-manage bootstrap

We landed one of the first building blocks for Default Roles across OpenStack, 
which is ensuring they are created during the bootstrap of keystone[1]. Since 
this is new feature of the bootstrap command, it has implications for people 
who run the command after their keystone is already bootstrapped. We talked[2] 
about what the intended purpose of the bootstrap command is versus what it is 
potentially being used for, for example as part of automation that expects it 
to be idempotent.

We agreed that the bootstrap change for default roles needed to highlight the 
changing behavior in the upgrade notes so that operators could prepare for it 
if needed. Separately, it would also be good to implement a way to check 
whether bootstrap had already been run so that automated tools can make 
decisions about whether they need to run it, perhaps sidestepping the question 
of whether the command itself should be considered idempotent.

[1] https://review.openstack.org/572243
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-06-13.log.html#t2018-06-13T12:44:00

### OPNFV Edge Computing

I attended the OPNFV Edge Computing Group's[3] meeting[4] to represent the 
keystone team and answer their questions about keystone's testing for federated 
scenarios. They were interested in donating hardware resources to fill out our 
use case coverage, but I had to inform them that we're still a ways away from 
having even basic keystone-to-keystone coverage and that the best way to help 
would to provide people resources to help work on it.

[3] https://wiki.opnfv.org/display/PROJ/Edge+cloud
[4] https://etherpad.opnfv.org/p/edge_cloud_meeting_minutes

### Flaskification

Morgan's work to replace our custom WSGI framework with Flask[5] is well 
underway. We'll be starting to move our API dispatching to Flask next week.

[5] https://review.openstack.org/#/q/topic:flaskification

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 19 changes this week, including the first steps for setting up 
default reader and member roles[6] and several changes for the Flask work[7].

[6] https://review.openstack.org/572243
[7] https://review.openstack.org/#/q/status:merged+topic:flaskification

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 53 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots, whose authors are waiting for any 
feedback. We've also started feature implementations, and initial feedback is 
welcome even if they are not passing tests yet[8][9][10][11].

[8] https://review.openstack.org/572776
[9] https://review.openstack.org/#/q/topic:bp/unified-limits+status:open
[10] 
https://review.openstack.org/#/q/topic:bp/strict-two-level-model+status:open
[11] https://review.openstack.org/#/q/topic:bug/1754184+status:open

## Bugs

These week we opened 8 new bugs and closed 2.

Bugs opened (8) 
Bug #1776506 (keystone:High) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1776506 
Bug #1776504 (keystone:Medium) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1776504 
Bug #1776532 (keystone:Medium) opened by John Dennis 
https://bugs.launchpad.net/keystone/+bug/1776532 
Bug #1776541 (keystone:Medium) opened by John Dennis 
https://bugs.launchpad.net/keystone/+bug/1776541 
Bug #1776221 (keystone:Undecided) opened by Yuxin Wang 
https://bugs.launchpad.net/keystone/+bug/1776221 
Bug #1777086 (keystone:Undecided) opened by 徐爱保 
https://bugs.launchpad.net/keystone/+bug/1777086 
Bug #1776501 (keystoneauth:Undecided) opened by Chris Dent 
https://bugs.launchpad.net/keystoneauth/+bug/1776501 
Bug #1777177 (keystonemiddleware:Medium) opened by Morgan Fainberg 
https://bugs.launchpad.net/keystonemiddleware/+bug/1777177 

Bugs fixed (2) 
Bug #1776506 (keystone:High) fixed by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1776506 
Bug #1776501 (keystoneauth:Undecided) fixed by Eric Fried 
https://bugs.launchpad.net/keystoneauth/+bug/1776501

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

Next week is our feature *proposal* freeze. If you're working on implementing 
specs, some initial patches should be proposed by the end of next week.

Many feature patchs have already been proposed. Initial feedback on these WIP 
proposals is encouraged.

## Shout-outs

Thanks to everyone getting started on implementing our major feature work for 
this cycle: adriant, hrybacki, jaosorior, jgrassler, wxy, thank you!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

[openstack-dev] [keystone] Keystone Team Update - Week of 28 May 2018

[Colleen Murphy]

# Keystone Team Update - Week of 28 May 2018

## News

### Summit Recap

We had a productive summit last week. Lance has posted a recap[1].

[1] https://www.lbragstad.com/blog/openstack-summit-vancouver-recap

### Quota Models

There was a productive discussion at the forum on hierarchical quotas (which I 
missed), but which resulted in some new thoughts about safely tracking quota 
which Adam captured[2]. We then discussed some performance implications for 
unlimited-depth project trees[3]. The spec for a strict two-level model still 
needs reviews[4].

[2] http://adam.younglogic.com/2018/05/tracking-quota/#more-5542
[3] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-05-29-16.02.log.html#l-9
[4] https://review.openstack.org/540803

## Open Specs

Search query: https://bit.ly/2G8Ai5q

Last week we merged the Default Roles spec[5] after discussing it at the 
Summit. We still need to review and merge the update the hierarchical unified 
limits spec[6] which has been updated following discussions at the summit.

[5] https://review.openstack.org/566377
[6] https://review.openstack.org/540803

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 5 changes this week. One of those was to partially remove the 
deprecated TokenAuth middleware[7], which has implications for upgrades.

[7] https://review.openstack.org/508412

## Changes that need Attention

Changes with no negative feedback:  https://bit.ly/2wv7QLK
Changes with only human negative feedback: https://bit.ly/2LeW1vC

There are 42 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots. This data is provided to 
highlight patches that are currently waiting for any feedback.

There are 81 total changes that are ready for review.

## Bugs

These week we opened 6 new bugs and closed 4.

One of the bugs opened and fixed was for our docs builds which had broken since 
the latest docs PTI updates[8]. I also opened a bug regarding the usage of 
groups with application credentials[9], which has implications for federated 
users using application credentials.

[8] https://bugs.launchpad.net/keystone/+bug/1774508
[9] https://bugs.launchpad.net/keystone/+bug/1773967

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

Next week is specification freeze (I think unified limits is the only remaining 
specification that needs attention). Our next deadline after that is feature 
proposal freeze on June 22nd.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] [keystone] Signing off

[Colleen Murphy]

On Wed, May 30, 2018, at 10:45 AM, Henry Nash wrote:
> Hi
>  
> It is with a somewhat heavy heart that I have decided that it is time to
> hang up my keystone core status. Having been involved since the closing
> stages of Folsom, I've had a good run! When I look at how far keystone
> has come since the v2 days, it is remarkable - and we should all feel a
> sense of pride in that. 
> Thanks to all the hard work, commitment, humour and support from all the
> keystone folks over the years - I am sure we will continue to interact
> and meet among the many other open source projects that many of us are
> becoming involved with. Ad astra! 
> Best regards,
>  
> Henry
> Twitter: @henrynash
> linkedIn: www.linkedin.com/in/henrypnash
> 

Thank you for all the incredible work you've done for this project! You were an 
invaluable asset at the PTGs, it was great to see you there even though 
keystone hasn't been your main focus lately. Wishing you the best of luck.

Colleen

__
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] [StarlingX] StarlingX code followup discussions

[Colleen Murphy]

On Wed, May 23, 2018, at 8:07 PM, Dean Troyer wrote:
> On Wed, May 23, 2018 at 11:49 AM, Colleen Murphy <coll...@gazlene.net> wrote:
> > It's also important to make the distinction between hosting something on 
> > openstack.org infrastructure and recognizing it in an official capacity. 
> > StarlingX is seeking both, but in my opinion the code hosting is not the 
> > problem here.
> 
> StarlingX is an OpenStack Foundation Edge focus area project and is
> seeking to use the CI infrastructure.  There may be a project or two
> contained within that may make sense as OpenStack projects in the
> not-called-big-tent-anymore sense but that is not on the table, there
> is a lot of work to digest before we could even consider that.  Is
> that the official capacity you are talking about?

I was talking about it being recognized by the OpenStack Foundation as part of 
one of its strategic focus areas. I understand StarlingX isn't seeking official 
recognition within the OpenStack project under the TC's governance.

Colleen

__
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] [StarlingX] StarlingX code followup discussions

[Colleen Murphy]

On Tue, May 22, 2018, at 10:57 PM, Jay Pipes wrote:
> 
> Are any of the distributions of OpenStack listed at 
> https://www.openstack.org/marketplace/distros/ hosted on openstack.org 
> infrastructure? No. And I think that is completely appropriate.

Hang on, that's not quite true. From that list I see Mirantis, Debian, Ubuntu, 
and RedHat, who all have (or had until recently) significant parts of their 
distros hosted on openstack.org infrastructure and are/were even official 
OpenStack projects governed by the TC.

It's also important to make the distinction between hosting something on 
openstack.org infrastructure and recognizing it in an official capacity. 
StarlingX is seeking both, but in my opinion the code hosting is not the 
problem here.

Colleen

__
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] [keystone] Keystone Team Update - Week of 14 May 2018

[Colleen Murphy]

# Keystone Team Update - Week of 14 May 2018

## News

### WSGI

Morgan has been working on converting keystone's core application to use 
Flask[1], which will help us to stop using paste.deploy and simplify our WSGI 
middleware and routing. While we're reworking our WSGI application framework, 
we also need to be thinking about how we can implement the mutable 
configuration community goal[2] which relies on having a SIGHUP handler in the 
service application that can talk to oslo.config, which is a feature that is 
part of oslo.service which we're not using.

[1] https://review.openstack.org/#/c/568377/
[2] 
https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html

### Sphinx issues

This week we started seeing mysterious issues with the API docs builder in the 
docs jobs for keystoneauth[3][4]. They seemed to start sometime after the 
upper-constraint for Sphinx was bumped to 1.7.4[5] and seemed to go away when 
the constraint was reverted[6], but we haven't fully confirmed that correlation 
yet. If you have some free time and like puzzles please feel free to dive in.

[3] 
http://logs.openstack.org/65/568365/5/check/build-openstack-sphinx-docs/368b8db/
[4] 
http://logs.openstack.org/40/568640/2/check/build-openstack-sphinx-docs/c66ea98/
[5] https://review.openstack.org/#/c/566451/
[6] https://review.openstack.org/#/c/568248/

### Summit/forum next week

The OpenStack Summit and Forum is next week in Vancouver, BC. A team dinner is 
going to be organized, so please respond to the survey[7] with your 
availability if you'd like to join.

[7] http://lists.openstack.org/pipermail/openstack-dev/2018-May/130649.html

Some sessions that might be of interest to the keystone team are:

Default Roles - 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21761/default-roles
Project Update - 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21584/keystone-project-update
Project Onboarding - 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21633/keystone-project-onboarding
Possible edge architectures for Keystone - 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21737/possible-edge-architectures-for-keystone
Feedback session -  
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21762/keystone-feedback-session
Unified limits - 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21760/unified-limits

The Open Research Cloud Alliance, which focuses on federated cloud topics, is 
also meeting on Thursday (requires a separate registration) - 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21845/cloud-federation-and-open-research-cloud-alliance-congress

## Open Specs

Search query: https://bit.ly/2G8Ai5q

In addition to the specs proposed for Rocky, we also have the Patrole in CI 
spec[8] proposed for Stein. It was originally being proposed in the 
openstack-specs repo but it's now reproposed to the keystone-specs repo.

[8] https://review.openstack.org/#/c/464678/

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 15 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 37 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

These week we opened 5 new bugs and closed 7.

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

The spec freeze is in about three weeks. We're starting to close in on our 
bigger specs so things are looking good.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone] Keystone Team Update - Week of 7 May 2018

[Colleen Murphy]

# Keystone Team Update - Week of 7 May 2018

## News

### Patrole in CI

With all the work that has been happening around fixing policy, it would be 
good to have better policy validation in CI[1]. However, there are some 
concerns that using Patrole in a voting gate job will lock us in to unwanted 
behavior. We agreed to start setting up the framework but to keep the jobs 
nonvoting until 968696[2] is fully fixed.

[1] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-05-08-16.00.log.html#l-51
[2] https://bugs.launchpad.net/keystone/+bug/968696

### Multi-Site Keystone

Keystone has never been able to provide straightforward guidance on 
implementing multi-region/multi-site clouds. We discussed an implementation 
proposal to "stretch" over existing clouds[3] with a combination of Galera 
syncing and orchestration around keystone-manage commands. A proof of concept 
already exists[4] and a spec will be forthcoming. We had also discussed[5] 
tying this into the default roles spec[6] by perhaps assigning static, non-UUID 
IDs to the new default roles in order to gain uniformity across distinct sites, 
but migrating existing clouds would be a challenge and we would need to come up 
with a solution for domain-specific roles.

[3] 
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-05-08-16.00.log.html#l-156
[4] https://github.com/zzzeek/stretch_cluster/tree/standard_tripleo_version
[5] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-05-07.log.html#t2018-05-07T17:23:29
[6] https://review.openstack.org/566377

## Open Specs

Search query: https://bit.ly/2G8Ai5q

As discussed last week, the default roles spec has been reproposed to 
keystone-specs[7]. We also need to prioritize reviews of the unified limits 
specs[8][9]. The remaining specs are likely to be deferred until next cycle.

[7] https://review.openstack.org/566377
[8] https://review.openstack.org/540803
[9] https://review.openstack.org/565412

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 19 changes this week. Among these were patches to enhance service 
discovery in keystoneauth using service-types-authority.

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 43 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

Launchpad report generator: https://github.com/lbragstad/launchpad-toolkit

These week we opened 5 new bugs and closed 4.

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

We have about four weeks to get our current spec proposals in shape to be 
merged, and six weeks to start seeing implementation proposals for those specs.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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] [keystone] Keystone Team Update - Week of 23 April 2018

[Colleen Murphy]

# Keystone Team Update - Week of 23 April 2018

## News

### scope_types in nova

We've had some good discussions incorporating scope_types into nova [0]. Thanks 
to mriedem and jaypipes for helping out. The discussion flushed out some work 
needed in keystonemiddleware [1] and oslo.context [2], making the interaction 
between those components more clear and easier for other services to use 
system-scoped tokens. Jay's comments/questions are probably going to be asked 
by other people working on incorporating these changes into their service. If 
that pertains to you, please see those reviews.

[0] https://review.openstack.org/#/c/553613/
[1] https://review.openstack.org/#/c/564072/
[2] https://review.openstack.org/#/c/530509/

### Milestone 1 retrospective

We had our first team retrospective of the cycle after the meeting on Tuesday. 
We captured our thoughts on a Trello board[3].

[3] https://trello.com/b/PiJecAs4/keystone-rocky-m1-retrospective

### Forum schedule

All of the topics we submitted for the Vancouver forum were accepted[4][5][6].

[4] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21761/default-roles
[5] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21762/keystone-feedback-session
[6] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21760/unified-limits

## Open Specs

Search query: https://goo.gl/eyTktx

We still have four open keystone specs as well as our cross-project spec on 
default roles[7]. At our milestone retrospective we talked about possibly 
dropping some of the lower priority specs from the roadmap for this cycle.

[7] https://review.openstack.org/#/c/523973/

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 14 changes this week.

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 62 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

Report: https://gist.github.com/lbragstad/80862a9111ff821af07e43e217c52190

This week we opened 6 new bugs and closed 2.

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

We're about six weeks away from spec freeze. Feature proposal freeze is just 
two weeks after that.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] Summit Forum Schedule

[Colleen Murphy]

Hi Jimmy,

On Wed, Apr 25, 2018, at 11:07 PM, Jimmy McArthur wrote:
> Hi everyone -
> 
> Please have a look at the Vancouver Forum schedule: 
> https://docs.google.com/spreadsheets/d/15hkU0FLJ7yqougCiCQgprwTy867CGnmUvAvKaBjlDAo/edit?usp=sharing
>  
> (also attached as a CSV) The proposed schedule was put together by two 
> members from UC, TC and Foundation.
> 
> We do our best to avoid moving scheduled items around as it tends to 
> create a domino affect, but we do realize we might have missed 
> something.  The schedule should generally be set, but if you see a major 
> conflict in either content or speaker availability, please email 
> speakersupp...@openstack.org.

I have a conflict on Thursday afternoon. Could I propose swapping these two 
sessions:

Monday 11:35-12:15 Manila Ops feedback: running at scale, barriers to deployment
Thursday 1:50-2:30 Default Roles

I've gotten affirmation from Tom and Lance on the swap, though if this causes 
problems for anyone else I'm happy to retract this request.

Colleen

__
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] [keystone] Keystone Team Update - Week of 16 April 2018

[Colleen Murphy]

# Keystone Team Update - Week of 16 April 2018

## News

### Retrospective scheduled

We're planning on having our milestonely team retrospective next week 
immediately after the weekly meeting[1]. We usually do this as a video 
conference. Come with your feedback!

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129444.html

### Milestone releases

We released our main libraries and keystone for Milestone 1 of the Rocky 
cycle[2][3][4][5].

[2] https://review.openstack.org/562735
[3] https://review.openstack.org/562730
[4] https://review.openstack.org/562723
[5] https://review.openstack.org/562732

### Forum topics submitted

We submitted topic proposals for the Vancouver Forum[6]. We're proposing to 
discuss the next stage of Unified Limits[7], the default roles cross-project 
initiative[8], and have a standard feedback session[9]. We opted not to submit 
anything on application credentials since we think there is not much 
controversy over the projected direction (mainly adding fine-grained access 
control).

[6] https://etherpad.openstack.org/p/YVR-keystone-forum-sessions
[7] http://forumtopics.openstack.org/cfp/details/130
[8] http://forumtopics.openstack.org/cfp/details/131
[9] http://forumtopics.openstack.org/cfp/details/132

### JWT still under discussion

There are still a number of open questions[10] on the design of the proposed 
JWT token provider[11]. We're not sure if the token ought to be encrypted 
(fernet tokens are) and we're not sure whether we want symmetric or asymmetric 
signing (and encryption). Part of the issue is that we don't have a specific 
ask from stakeholders, so this is mostly all in "it would be nice" territory. 
The latest revision of the spec has been updated to include potential use 
cases. If you have a vested interest in this work, please engage with us on the 
spec.

[10] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-04-17.log.html#t2018-04-17T17:37:43
[11] https://review.openstack.org/541903

### Default roles cross-project spec

The keystone team is satisfied with the current state of the cross-project spec 
to agree upon a set of default roles across projects[12] but we need more 
feedback and eventual approval from cross-project liasons[13]. If you have 
input or questions, please reach out to us.

[12] https://review.openstack.org/523973
[13] https://review.openstack.org/#/admin/groups/1372,members

## Open Specs

Search query: https://goo.gl/eyTktx

No new specs have been proposed for Rocky this week, and today is the deadline 
so we'll only expect to continue refinement of the current proposals.

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 14 changes this week.

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 55 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

These week we opened 7 new bugs and fixed 4 bugs across keystone, keystoneauth, 
keystonemiddleware, python-keystoneclient, and oslo.policy.

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

The time for submitting spec ideas is over. We'll continue to refine the 
current proposals until the Rocky-2 deadline in about six weeks.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone] Keystone Team Update - Week of 2 April 2018

[Colleen Murphy]

# Keystone Team Update - Week of 2 April 2018

## News

Relatively quiet week. Most of our activity was focused on polishing up specs.

## Open Specs

Search query: https://goo.gl/eyTktx

No new specs have been proposed since last week. We're getting some good 
feedback on the cross-project spec to implement default roles[1], which will 
need more discussion and clarification. One hot debate was (is?) over what the 
role names should be (as a team we're really good at naming things).

The JWT spec[2] also needs some attentive eyes on it, and the unified limits 
spec[3] may need to have its scope narrowed down. The application credentials 
spec[4] is probably one or two revisions away from being ready to merge.

[1] https://review.openstack.org/523973
[2] https://review.openstack.org/541903
[3] https://review.openstack.org/540803
[4] https://review.openstack.org/396331

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 8 changes this week.

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 38 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

The keystone spec proposal freeze is in two weeks.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone] Keystone Team Update - Week of 26 March 2018

[Colleen Murphy]

# Keystone Team Update - Week of 26 March 2018

## News

### JSON Web Tokens

Lance found an interesting article denouncing JWT[1][2] which, in an ironic 
twist, also advocated fernet as an alternative. We're still plowing forward on 
the JWT spec[3], but we need to be very precise in our design and mindful not 
just of the RFCs but of our chosen library's implementation details. The spec 
is being expanded to more precisely define the payload (and some advantages the 
new payload format will give us[4]), and how and whether to encrypt or just 
sign is still an open question[5].

[1] 
https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-28.log.html#t2018-03-28T17:53:06
[3] https://review.openstack.org//541903
[4] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-28.log.html#t2018-03-28T15:04:01
[5] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-29.log.html#t2018-03-29T16:16:06

### PostgreSQL support

We have an open bug for a problem in one of the SQL migrations on PostgreSQL[6] 
which brought to mind a TC resolution about the current status of PostgreSQL in 
OpenStack[7]. We do test migrations on PostgreSQL, but not at scale and not in 
a rolling upgrade scenario. No one has proposed to drop support for PostgreSQL 
since it more or less works most of the time, but we do need to document within 
keystone that it is not a first class citizen and resolving some of these 
weirder bugs is only best effort[8].

[6] https://bugs.launchpad.net/keystone/+bug/1755906
[7] https://governance.openstack.org/tc/reference/help-most-needed.html
[8] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-27.log.html#t2018-03-27T18:12:15

### Help wanted lists

Like other projects, keystone gets a lot of drive-by patches for typo fixes, 
URL updates, and lately PTI updates. In the last meeting, I suggested that 
perhaps we could steer these types of contributions toward something that would 
be more beneficial to keystone specifically. Low-investment tasks like 
resolving deprecation warnings, for example, would provide a bigger value to us 
than typo fixes. I started a list of the types of things we could direct these 
contributors toward[9], please feel free to add to it. I'll add it to our 
contributor guide.

In discussing this "help wanted list", we also circled back to the possibiliy 
of requesting to add keystone to the TC's "help most needed" list[10]. This 
would not be about focusing drive-by patches constructively, but on gaining 
long-term maintainers who can help us with some of keystone's fundamental 
issues and feature backlog. We haven't yet been moved to action on this.

[9] https://etherpad.openstack.org/p/keystone-help-wanted-list
[10] https://governance.openstack.org/tc/reference/help-most-needed.html

## Open Specs

Search query:  https://goo.gl/hdD9Kw

We merged our first spec for Rocky, which was for MFA improvements[11]. We also 
converged on some terminology decisions for the application credential 
improvement spec[12] and expect to merge it soon.

[11] https://review.openstack.org/553670
[12] https://review.openstack.org/396331

## Recently Merged Changes

Search query: https://goo.gl/FLwpEf

We merged 18 changes in the last week, including some significant bug fixes.

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 38 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

Among these are a couple of changes to python-keystoneclient[13][14] to add the 
ability to return a request ID to the caller, which have been making steady 
progress for a while and are now in good shape.

[13] https://review.openstack.org/329913
[14] https://review.openstack.org/267456

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

We're about three weeks out from spec proposal freeze. If you have a feature 
you would like to work on in keystone, please propose it now.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone] Keystone Team Update - Week of 19 March 2018

[Colleen Murphy]

# Keystone Team Update - Week of 19 March 2018

## News

### Spec review meeting

During our Tuesday office hours we had a call to discuss some of our open 
specs. We were able to reduce some of the scope creep that had arisen in the 
application credentials enhancement spec[1], iron out some details in the MFA 
enhancement spec[2], and reaffirm our mission to keep the default roles spec[3] 
as simple as possible for this round of RBAC improvements.

[1] https://review.openstack.org/396331
[2] https://review.openstack.org/553670
[3] https://review.openstack.org/523973

### oslo.limit library created

The oslo.limit repository has been created[4] and an Oslo spec was merged[5] to 
outline the purpose of the new library.

[4] https://review.openstack.org/#/c/550496/
[5] https://review.openstack.org/#/c/552907/

## Open Specs

Search query: https://goo.gl/eyTktx

Since last week, a new spec has been proposed to add a new static catalog 
backend[6]. This is work that was started last cycle but that we still need to 
flesh out properly.

[6] https://review.openstack.org/554320

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged a whopping 6 changes this week. In fairness a lot of our energy has 
been spent reviewing our awesome spec proposals.

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 36 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots. Among these are a few changes to 
add a lower-constraints job to our repos as part of a plan to eventually stop 
syncing global requirements[7], which we might want to have a quick chat about 
before merging.

[7] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128352.html

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

The next deadline is the Rocky-1 milestone spec proposal freeze.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone] Keystone Team Update - Week of 12 March 2018

[Colleen Murphy]

# Keystone Team Update - Week of 12 March 2018

## News

### Keystone Admin-ness: the Future

At the Denver PTG, while grappling with the concept of admin-ness, we had a 
moment of clarity when we realized that there were some classes of admin 
actions that could be described as "global" across keystone projects, like 
listing all servers in all projects, and other admin actions that were better 
classified as "system" actions that operated on no project at all, like 
creating endpoints. From this came the new system scope[1] for operating on 
system-level APIs. But we have yet to properly deal with the 
global-across-projects case. There are conflicting views within the keystone 
team on how best to support this going forward[2], and whether we should enable 
system-scoped tokens to work on project-level operations or if we can lean on 
Hierarchical Multitenancy to enable this. Somewhat intermixed in this issue is 
how, or whether, to deal with cleaning up resources in other services that are 
tied to keystone projects when the service has no insight into keystone 
internals. If you have thoughts on these issues, please discuss on Adam's 
thread[3].

[1] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-13.log.html#t2018-03-13T22:42:44
[3] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128302.html

### Edge Computing

We've previously gotten requests to support syncing data across different 
keystone deployments at the application level rather than at the data storage 
level[4]. As Edge Computing gains stronger footing in our community[5], we need 
to start thinking about use cases like this and how to support them. We 
discussed this a bit[6] but we are a ways off from having a concrete plan. If 
you have thoughts on this, please reach out to us!

[4] https://review.openstack.org/#/c/323499/
[5] http://markvoelker.github.io/blog/dublin-ptg-edge-sessions/
[6] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-13.log.html#t2018-03-13T13:50:03

### JWT

We have a spec proposed[7] to implement JSON Web Tokens as a new token format 
similar to fernet. We discussed some of the particulars[8] with regard to 
whether the token needs to be encrypted and token size considerations. 
Implementing this might make a good Outreachy project since it is interesting 
and reasonably self-contained, but we will want to nail down these details 
before dumping it on an intern.

[7] https://review.openstack.org/#/c/541903/
[8] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-13.log.html#t2018-03-13T20:03:56

### Milestone Planning Meeting

We had a conference call meeting to organize our Rocky roadmap[9] and do some 
sprint-like planning for the first milestone. If you're working on something in 
the roadmap, please feel free to make updates to the Trello board as needed.

[9] https://trello.com/b/wmyzbFq5/keystone-rocky-roadmap

### Outreachy projects

OpenStack didn't get into GSOC this year, but we still have a chance to submit 
applications for Outreachy[10]. We have some internship ideas[11] that we 
should add to and/or finalize ASAP. We need to have mentors assigned up-front 
who should submit the project idea themselves, but even if there is only one 
name attached to a project, we found last round that co-mentoring can be pretty 
successful for both the intern and the mentors.

[10] https://www.outreachy.org/communities/cfp/openstack/
[11] https://etherpad.openstack.org/p/keystone-internship-ideas

## Open Specs

Search query: https://goo.gl/eyTktx

Since last week, a new spec has been proposed to provide proper usable 
multi-factor auth[12]. In total we have five specs proposed for Rocky that are 
awaiting feedback.

We've also had a revival of a spec currently proposed to the backlog to improve 
OpenIDC support[13].

[12] https://review.openstack.org/#/c/553670
[13] https://review.openstack.org/#/c/373983

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 13 changes this week. One of these was a significant bugfix to the 
template catalog backend[14]. We had postponed merging this with the idea that 
we might create a whole new, better, file-based catalog backend[15] but work on 
that had stalled (and is being picked up again).

[14] https://review.openstack.org/#/c/482364/
[15] https://review.openstack.org/#/c/483514/

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 36 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

We added our milestone goals to the release schedule[16]. The next deadline is 
the spec proposal freeze the week of April 16.

[16] https://review.openstack.org/#/c/553502/

## 

[openstack-dev] [keystone] Keystone Team Update - Week of 5 March 2018

[Colleen Murphy]

# Keystone Team Update - Week of 5 March 2018

## News

### PTG Summaries

Last week many of us attended the PTG in Dublin and made significant progress 
on a lot of keystone topics. Here are some recaps:

- https://www.lbragstad.com/blog/keystone-rocky-ptg-summary
- http://www.gazlene.net/dublin-ptg.html

### URL whitelisting for application credentials

One of the major topics at the PTG was the next steps for application 
credentials. To make them truly useful we need to enable finer-grained access 
control than what we can currently provide with our traditional "scope RBAC" 
system. It turns out we already had a spec proposed[1] that predated 
application credentials but that largely fills the gaps here. A lot of the 
elements in this proposal were very similar to the RBAC in middleware 
proposal[2] and Adam had major concerns that the approach taken here would 
conflict with the path to eventually properly fixing RBAC in keystone. We were 
able to get on a call together and come to a compromise, which is that 
operators must be able to pre-approve allowed API paths that a user can add to 
their application credential whitelists, but allowing wildcards in the 
pre-approved list is acceptable. This can enable a safety net for users to 
avoid them accidentally enabling something they didn't intend, and it will put 
us on a path toward fully managed policy mappings in keystone eventually.

### Unified Limits next steps

Lance proposed creating a new Oslo library[3] to continue the next stage of 
work of unifying quota implementations in keystone. We will also need to 
propose an Oslo spec[4] to coordinate this work with the Oslo team. We're also 
trying to work out some of the oddities in the current API implementation and 
hoping to come out with a consistent and useful interface[5].

### Changing meeting time

We proposed changing the meeting time[6] to make it easier for one of our newer 
contributors to join. The meeting change was merged[7] so next week's meeting 
will be at 1600 UTC in #openstack-meeting-alt.

### Domain and Project scope

Adrian brought us a fun puzzle[8][9][10] involving ambiguity between how role 
assignments are handled between domains and projects. Some bugs were opened to 
correct some logic errors but the open question is what kind of future we see 
for domains and projects.

[1] https://review.openstack.org/#/c/396331/
[2] https://review.openstack.org/#/c/391624/
[3] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128006.html
[4] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128032.html
[5] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128027.html
[6] http://lists.openstack.org/pipermail/openstack-dev/2018-March/127970.html
[7] https://review.openstack.org/#/c/550260/
[8] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-08.log.html#t2018-03-08T23:43:31
[9] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-03-09.log.html#t2018-03-09T02:49:24
[10] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128093.html

## Open Specs

Search query: https://goo.gl/eyTktx

We have four specs proposed for the Rocky cycle so far.

### Repropose JWT specification for Rocky[11]

We already wrote a "this would be nice" spec about implementing JSON Web Tokens 
as a new token format, and this cycle we have some of the token provider 
refactoring far enough along that we're ready to commit to implementing it.

### Add whitelist-extension-for-app-creds[12]

As discussed above, this was a major topic at the PTG and the next logical step 
in making application credentials useful.

### Add specification for a capabilities API[13]

Another topic we discussed at the PTG was expanding on our JSON-home document 
to provide a way for users to query what they have permissions to do within 
keystone.

### Hierarchical Unified Limits[14]

With our initial limtis API supporting a flat project structure, the next step 
is supporting hierarchical project models.

[11] https://review.openstack.org/541903
[12] https://review.openstack.org/396331
[13] https://review.openstack.org/547162
[14] https://review.openstack.org/540803

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 4 changes this week.

Might be a bit unfair to count this week since many of us are still recovering 
from travel and digesting the events of the PTG.

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 41 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Milestone Outlook

https://releases.openstack.org/rocky/schedule.html

Welcome to the new cycle! We haven't proposed deadlines yet, but at the PTG we 
discussed moving our feature freeze deadline up to avoid the rush, as well as 
aiming for finishing client work earlier in order to avoid pressuring the OSC 
team at the end of the cycle.

[openstack-dev] [keystone] Keystone Team Update - Week of 12 February 2018

[Colleen Murphy]

# Keystone Team Update - Week of 12 February 2018

## News

Relatively quiet week, the big news is that we're on track for a solid
RC2 next week :)

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 37 changes this week. The most significant of these were
Queens backports fixing issues with system-scope, needed before RC2.
We also merged documentation for application credentials and a bugfix
for a long-standing bug in the identity backend[1].

[1] https://bugs.launchpad.net/keystone/+bug/1718747

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 23 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots.

While my filter ignores the proposal bot since it's not a human
waiting for feedback, as per Sean's countdown notice[2] please be on
the lookout for translations proposals so they can be merged ASAP.

[2] http://lists.openstack.org/pipermail/openstack-dev/2018-February/127465.html

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

We are in the last week of the cycle. We'll release our RC2 next week.

We currently seem to be on track for all RC2-targeted bugs[3] but
please be on the lookout for any critical bugs that arise in the next
week.

There's also a bug that we had targeted at Queens-3 but didn't
retarget at an RC because we haven't been able to reproduce it yet. If
you have spare cycles, please take a look[4].

[3] https://launchpad.net/keystone/+milestone/queens-rc2
[4] https://bugs.launchpad.net/keystone/+bug/1735250

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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][Kingbird][Heat][Glance]Multi-Region Orchestrator

[Colleen Murphy]

On Mon, Feb 12, 2018 at 7:44 AM, Goutham Pratapa
 wrote:

>
> OUR USE-CASES QUOTA-MANAGEMENT:
>
> 1. Admin must have a global view of all quotas to all tenants across all the
> regions
> 2. Admin can periodically balance the quotas (we have a formula using which
> we do this balancing ) across regions
> 3. Admin can update, Delete quotas for tenants
> 4. Admin can sync quotas for all tenants so that the quotas will be updated
> in all regions.

Global quota management is something we're seeking to solve in
keystone[1][2][3][4], which would enable admins to do 1, 3, and 4 via
keystone (though admittedly this is a few cycles out). We expect to
dive into this at the PTG if you'd like to help shape this work.

[1] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.html
[2] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[3] https://review.openstack.org/#/c/441203/
[4] https://review.openstack.org/#/c/540803/

Colleen

__
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] [keystone] Keystone Team Update - Weeks of 29 January and 5 February 2018

[Colleen Murphy]

# Keystone Team Update - Weeks of 29 January and 5 February 2018

It's been a busy couple of weeks and I missed the last update, here's
an update for the last two weeks.

## News

### RC1

RC1 was cut today[1]. We expect to release an RC2 after branching
since we have a translations patch and a couple of bugfixes that we
hope to get in.

### PTG Planning

We're finalizing topics to cover during the cross-project days of the PTG[2].

[1] https://review.openstack.org/#/c/542385/
[2] https://etherpad.openstack.org/p/baremetal-vm-rocky-ptg

## Open Specs

Search query: https://goo.gl/pc8cCf

We don't have any new specs proposed currently but Adrian has hinted
that an interesting one is on its way[3].

[3] 
http://lists.openstack.org/pipermail/openstack-operators/2018-February/014852.html

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 33 changes this last week, 76 since the last update
newsletter. These included the last of our api-ref reorganization
changes, cleanup of v2 cruft and documentation, and some major
bugfixes.

## Changes that need Attention

Search query: https://goo.gl/tW5PiH

There are 25 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots. Please focus reviews
on release-critical bugs.

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

We've released our RC1 and we are in hard string freeze. We have two
more weeks to make another RC release.

## Shout-outs

Thanks to our Outreachy intern Suramya for completing our api-ref
reorganization! This was a big step in making our API reference more
useable. Of course we have many more things for you to help us with ;)

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

[Colleen Murphy]

On Wed, Jan 31, 2018 at 6:46 PM, Graham Hayes <g...@ham.ie> wrote:
> On 31/01/18 17:22, Dmitry Tantsur wrote:
>> On 01/31/2018 06:15 PM, Matt Riedemann wrote:
>>> On 1/30/2018 9:33 AM, Colleen Murphy wrote:
[snip]
>>>
>>> These all seem like good topics for big cross-project issues.
>>>
>>> I've never liked the "BM/VM" platform naming thing, it seems to imply
>>> that the only things one needs to care about for these discussions is
>>> if they work on or use nova and ironic, and that's generally not the
>>> case.
>>
>> ++ can we please rename it? I think people (myself included) will expect
>> specifically something related to bare metal instances co-existing with
>> virtual ones (e.g. scheduling or networking concerns). Which is also a
>> great topic, but it does not seem to be present on the list.
>>
>
> Yeah - both of these topic apply to all projects. If we could do
> scheduled time for both of these, and then separate time for Ironic /
> Nova issues it would be good.
>
>>>
>>> So if you do have a session about this really cross-project
>>> platform-specific stuff, can we at least not call it "BM/VM"? Plus,
>>> "BM" always makes me think of something I'd rather not see in a room
>>> with other people.
>>>

++

Sorry, I didn't mean to be exclusive. These topics do apply to most
projects, and it did feel awkward writing that email with keystone
goals in mind when keystone is in neither category.

Colleen

__
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] [keystone][nova][ironic][heat] Do we want a BM/VM room at the PTG?

[Colleen Murphy]

At the last PTG we had some time on Monday and Tuesday for
cross-project discussions related to baremetal and VM management. We
don't currently have that on the schedule for this PTG. There is still
some free time available that we can ask for[1]. Should we try to
schedule some time for this?

From a keystone perspective, some things we'd like to talk about with
the BM/VM teams are:

- Unified limits[2]: we now have a basic REST API for registering
limits in keystone. Next steps are building out libraries that can
consume this API and calculate quota usage and limit allocation, and
developing models for quotas in project hierarchies. Input from other
projects is essential here.
- RBAC: we've introduced "system scope"[3] to fix the admin-ness
problem, and we'd like to guide other projects through the migration.
- Application credentials[4]: this main part of this work is largely
done, next steps are implementing better access control for it, which
is largely just a keystone team problem but we could also use this
time for feedback on the implementation so far

There's likely some non-keystone-related things that might be at home
in a dedicated BM/VM room too. Do we want to have a dedicated day or
two for these projects? Or perhaps not dedicated days, but
planned-in-advance meeting time? Or should we wait and schedule it
ad-hoc if we feel like we need it?

Colleen

[1] 
https://docs.google.com/spreadsheets/d/e/2PACX-1vRmqAAQZA1rIzlNJpVp-X60-z6jMn_95BKWtf0csGT9LkDharY-mppI25KjiuRasmK413MxXcoSU7ki/pubhtml?gid=1374855307=true
[2] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[3] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
[4] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/application-credentials.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

Re: [openstack-dev] [keystone] FFE for application credentials

[Colleen Murphy]

> On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad  wrote:
>> Hey all,
>>
>> The work for application credentials [0] has been up for a while,
>> reviewers are happy with it, and it is slowly making it's way through
>> the gate. I propose we consider a feature freeze exception given the
>> state of the gate and the frequency of rechecks/failures.
>>
>> Thoughts, comments, or concerns?
>>
>> [0]
>> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/application-credentials

These changes were approved on Wednesday (Jan 24). They are still not
merged as of now (Monday, Jan 29, about 16:00 UTC) because of

* tempest failures related to issues with cinder
* the log server falling over
* tempest timing out
* merge conflicts with the system-scope patches that managed to land
* hosting provider maintenance that caused zuul to fall over and jobs
needing to be reenqueued and start over
* unit test jobs timing out (https://bugs.launchpad.net/keystone/+bug/1746016)
* zuul running out of memory and jobs needing to be reenqueued and start over

As of now, the base patch in this change series is about 21st in the
integrated gate queue. With any luck, there is a chance it might be
merged some time tomorrow.

I'd like to request that we keep the feature freeze exception open for
these changes.

Colleen

__
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] [keystone] Keystone Team Update - Week of 22 January 2018

[Colleen Murphy]

# Keystone Team Update - Week of 22 January 2018

## News

### Feature freeze

This week was feature freeze and client freeze. While we approved
everything we cared about for this release on time, some CI issues
(some unexpected and some predictable) delayed these features being
merged. The release team has extended the freeze deadline to Monday,
which should (hopefully) give us enough time for the last few changes
to land before we release RC1.

### RC bugs

We've started compiling a list of potential release-critical bugs[1].
Please continue to report bugs as you find them in the RC, and also
please focus your attention on fixing these bugs and reviewing
bugfixes.

[1] https://etherpad.openstack.org/p/keystone-queens-bug-list

### API Discovery

We had some interesting discussions this week about experimental APIs
and API discovery[2][3]. This was partly in the context of our new
"unified limits" API, which is step 1 in providing a cross-project
service where quotas for projects could be set and retrieved by other
OpenStack services. We're marking this API as "experimental" for the
time being while we shake out some of the cross-project usage patterns
we'll need to support, but this poses a discoverabiltiy problem. We
already expose a "home document" which lists all of our API routes and
their statuses, e.g. whether they're tagged as "experimental". While
this seems like a really useful feature for API consumers as well as a
great way to expose experimental features without committing to
stability, it seems like the JSON-home standard never quite made it
off the ground, so it's not a standard we can rely on API consumers
supporting. However, we could certainly build off of what we already
have to enhance our API discoverability

[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-01-24.log.html#t2018-01-24T22:27:50
[3] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-01-25.log.html#t2018-01-25T14:43:46
[4] https://mnot.github.io/I-D/json-home/

### GSoC Projects

OpenStack is applying to participate in the Google Summer of Code
project[5]. We've started compiling a list of potential projects that
a GSoC intern could work on[6]. Please help us add to the list! And if
you're interested in being a mentor, please step up! We'll likely
discuss this more at the next keystone meeting.

[5] 
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-01-25.log.html#t2018-01-25T14:38:28
[6] https://etherpad.openstack.org/p/keystone-internship-ideas

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 49 changes this week, though we approved quite a few that
are still making their way through the gate, including changes that
are part of our main feature objectives.

## Changes that need Attention

Search query: https://goo.gl/h9knRA

There are 36 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots. Expect to see a lot
more as we bugstomp over the next two weeks.

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

This week marked feature freeze and client freeze, but due to a number
of CI problems the release team has extended the feature freeze till
Monday and the client freeze until Tuesday[7]. This just means the
approved changes that we still have moving through CI should hopefully
have time to finish and be merged.

[7] http://lists.openstack.org/pipermail/openstack-dev/2018-January/126621.html

## Shout-outs

Thanks to the whole team for working so hard this week!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone] FFE for application credentials

[Colleen Murphy]

+1

On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad  wrote:
> Hey all,
>
> The work for system assignments and system scope [0] has been up for a
> while, reviewers are happy with it, and it is slowly making it's way
> through the gate. I propose we consider a feature freeze exception given
> the state of the gate and the frequency of rechecks/failures.
>
> Thoughts, comments, or concerns?
>
> [0]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/system-scope
>
>
>
> __
> 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] [keystone] FFE for application credentials

[Colleen Murphy]

+1

On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad  wrote:
> Hey all,
>
> The work for application credentials [0] has been up for a while,
> reviewers are happy with it, and it is slowly making it's way through
> the gate. I propose we consider a feature freeze exception given the
> state of the gate and the frequency of rechecks/failures.
>
> Thoughts, comments, or concerns?
>
> [0]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/application-credentials
>
>
>
> __
> 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] [keystone] FFE for unified limits

[Colleen Murphy]

+1

On Thu, Jan 25, 2018 at 10:14 PM, Lance Bragstad  wrote:
> Hey all,
>
> The work for unified limits [0] has been up for a while, reviewers are
> happy with it being experimental, and it is slowly making it's way
> through the gate. I propose we consider a feature freeze exception given
> the state of the gate and the frequency of rechecks/failures.
>
> Thoughts, comments, or concerns?
>
> [0]
> https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/unified-limits
>
>
>
> __
> 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] [keystone] Keystone Team Update - Week of 15 January 2018

[Colleen Murphy]

# Keystone Team Update - Week of 15 January 2018

## News

### Core team changes

We added a new core reviewer! Thanks Gage Hugo for all your hard work
and for stepping up to take on more responsibility!

We also lost some core members: Boris Bobrov, Steve Martinelli, Brant
Knudson and Brad Topol have stepped down from core membership after
having made enormous contributions over the years. We're grateful to
them for everything they've done to make keystone better and welcome
them back any time.

### Proposed community goals for Rocky

There are five community goals[1][2][3][4][5] proposed for Rocky that
are under discussion. In the meeting this week we had some confusion
and conerns over whether the proposed goal about pagination links[3]
would apply to us. We don't paginate anything in keystone, so the goal
wouldn't apply to us. The one that would potentially apply to keystone
is about mutable configuration[5]. If you have thoughts on any of
these potential community goals, including whether the team has the
capacity to take on this work, make your voice heard on the reviews.

### PTG Planning

We still need to put some thought into our agenda for the PTG. Add
your ideas to the etherpad[6] and also add your name if you're going
to be attending so that we can organize a team dinner.

I noticed that no one requested a BM/VM room for the cross-project
days of the PTG[7]. If we want to organize discussions with those
teams we might want to start thinking about that now, but we will be
able to book rooms spontaneously if we want to.

[1] https://review.openstack.org/513875
[2] https://review.openstack.org/532361
[3] https://review.openstack.org/532627
[4] https://review.openstack.org/533544
[5] https://review.openstack.org/534605
[6] https://etherpad.openstack.org/p/keystone-rocky-ptg
[7] http://lists.openstack.org/pipermail/openstack-dev/2018-January/126335.html

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 38 changes this week. Lots of these were major stepping
stones for our new features.

## Changes that need Attention

Search query: https://goo.gl/h9knRA

There are 55 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots. Please prioritize
reviews for python-keystoneclient and our major feature initiatives
(see below).

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

The non-client freeze was yesterday. Keystonemiddleware[8] and
oslo.policy[9] were released in time. Unfortunately we dropped the
ball on keystoneauth and there are some important changes we want to
get in for this release. The release team has graciously granted us an
exception but we'll have to make sure these changes are merged by
Monday.

Client and feature freeze is next week on THURSDAY[10]. Please
prioritize reviews for python-keystoneclient[11] and our major feature
initiatives[12][13][14].

[8] https://review.openstack.org/#/c/531423/
[9] https://review.openstack.org/#/c/531734/
[10] http://lists.openstack.org/pipermail/openstack-dev/2018-January/126351.html
[11] 
https://review.openstack.org/#/q/project:openstack/python-keystoneclient+is:open
[12] https://review.openstack.org/#/q/is:open+topic:bp/system-scope
[13] https://review.openstack.org/#/q/is:open+topic:bp/unified-limits
[14] https://review.openstack.org/#/q/is:open+topic:bp/application-credentials

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] Clarifying testing recommendation for interop programs

[Colleen Murphy]

On Fri, Jan 19, 2018 at 1:52 AM, Ken'ichi Ohmichi  wrote:
> 2018-01-18 12:36 GMT-08:00 Doug Hellmann :
>>
>> I feel pretty sure that was discussed in a TC meeting, but I can't
>> find that. I do find Matt and Ken'ichi voting +1 on the resolution
>> itself.  https://review.openstack.org/#/c/312718/. If I remember
>> correctly, Ken'ichi was the PTL at the time.
>
> Yeah, I have still agreed with the resolution.
> When I voted +1 on that, core projects were defined as 6 projects like
> Nova, Cinder, Glance, Keystone, Neutron and Swift.
> And the project navigator also showed these 6 projects as core projects.
> Now I cannot find such definition on the project navigator[1], the
> definition has been changed?
> I just want to clarify "is it true that designate and heat become core
> projects?"
> If there is a concrete decision, I don't have any objections against
> that we have these projects tests in Tempest as the resolution.

I think the fuzziness between what we're colloquially calling "core"
(or sometimes "integrated"), what has tests in tempest, and what is
part of the original trademark program, is part of the problem.

As I understand it, designate and heat are not trying to become
"core". What they are applying for is to be part of a new subgroup
within the trademark program. The question at hand is, given that they
are not "core" (whatever that really means), but they are going to be
part of the trademark program, is there a technical reason they
shouldn't have some of their tests in tempest? And if not, is there a
social reason for it?

Colleen

>
> Thanks
> Ken Ohmichi
>
> ---
> [1]: https://www.openstack.org/software/project-navigator
>

__
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] [keystone] Keystone Team Update - Week of 8 January 2018

[Colleen Murphy]

# Keystone Team Update - Week of 8 January 2018

## News

### PTG

We're still brainstorming for the PTG. If you have any topic
proposals, please add them to the etherpad[1]. We'll need to
coordinate with other teams to schedule discussion time on our major
cross-project topics, especially unified limits and policy changes.

### Scope types ambiguity

In the keystone and policy meetings Lance highlighted a number of APIs
that could have different behaviors depending on whether the requester
uses the new system scope or a project scope, for example in the
projects API[2]. Keystone currently doesn't treat these scopes
differently, but we'll be marking and tracking APIs and policies that
need to have this addressed. It's likely that we'll have to help other
projects deal with such ambiguous APIs in the future as well.

[1] https://etherpad.openstack.org/p/keystone-rocky-ptg
[2] 
https://review.openstack.org/#/c/526159/3/keystone/common/policies/project.py@32

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 16 changes this week. Many of these were organizational
changes to our api-ref from our Outreachy intern, Suramya, who has
been helping us make our api-ref more consistent. We've also merged
some more of Lance's system-scope changes, though those are still
making their way through the gate.

## Changes that need Attention

Search query: https://goo.gl/h9knRA

There are 79 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots. Among these are a
number of fixes for the api-ref and several changes to add the
scope_types option to our policies.

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

Our feature freeze is in two weeks. Please help review changes for
system-scope, application credentials, and unified limits so we can
meet this deadline.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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][tc] Clarifying testing recommendation for interop programs

[Colleen Murphy]

Hi everyone,

We have governance review under debate[1] that we need the community's help on.
The debate is over what recommendation the TC should make to the Interop team
on where the tests it uses for the OpenStack trademark program should be
located, specifically those for the new add-on program being introduced. Let me
badly summarize:

A couple of years ago we issued a resolution[2] officially recommending that
the Interop team use solely tempest as its source of tests for capability
verification. The Interop team has always had the view that the developers,
being the people closest to the project they're creating, are the best people
to write tests verifying correct functionality, and so the Interop team doesn't
maintain its own test suite, instead selecting tests from those written in
coordination between the QA team and the other project teams. These tests are
used to validate clouds applying for the OpenStack Powered tag, and since all
of the projects included in the OpenStack Powered program already had tests in
tempest, this was a natural fit. When we consider adding new trademark programs
comprising of other projects, the test source is less obvious. Two examples are
designate, which has never had tests in the tempest repo, and heat, which
recently had its tests removed from the tempest repo.

So far the patch proposes three options:

1) All trademark-related tests should go in the tempest repo, in accordance
   with the original resolution. This would mean that even projects that have
   never had tests in tempest would now have to add at least some of their
   black-box tests to tempest.

The value of this option is that centralizes tests used for the Interop program
in a location where interop-minded folks from the QA team can control them. The
downside is that projects that so far have avoided having a dependency on
tempest will now lose some control over the black-box tests that they use for
functional and integration that would now also be used for trademark
certification.
There's also concern for the review bandwidth of the QA team - we can't expect
the QA team to be continually responsible for an ever-growing list of projects
and their trademark tests.

2) All trademark-related tests for *add-on projects* should be sourced from
   plugins external to tempest.

The value of this option is it allows project teams to retain control over
these tests. The potential problem with it is that individual project teams are
not necessarily reviewing test changes with an eye for interop concerns and so
could inadvertently change the behavior of the trademark-verification tools.

3) All trademark-related tests should go in a single separate tempest plugin.

This has the value of giving the QA and Interop teams control over
interop-related tests while also making clear the distinction between tests
used for trademark verification and tests used for CI. Matt's argument against
this is that there actually is very little distinction between those two cases,
and that a given test could have many different applications.

Other ideas that have been thrown around are:

* Maintaining a branch in the tempest repo that Interop tests are pulled from.

* Tagging Interop-related tests with decorators to make it clear that they need
  to be handled carefully.

At the heart of the issue is the perception that projects that keep their
integration tests within the tempest tree are somehow blessed, maybe by the QA
team or by the TC. It would be nice to try to clarify what technical
and political
reasons we have for why different projects have tests in different places -
review bandwidth of the QA team, ownership/control by the project teams,
technical interdependency between certain projects, or otherwise.

Ultimately, as Jeremy said in the comments on the resolution patch, the
recommendation should be one that works best for the QA and Interop teams. So
far we've heard from Matt and Mark expressing moderate support for option 2.
We'd like to hear more from those teams about how they see this working,
especially with regard to concerns about the quality and stability standards
that out-of-tree tests may be held to. We additionally need input from the
whole community on how maintaining trademark-related tests in tempest will
affect you if you don't already have your tests there. We'd especially like to
address any perceptions of favoritism or exclusionism that stem from these
issues.

And to quickly clear up one detail before it makes it onto this thread, the
Queens Community Goal about splitting tempest plugins out of the main project's
tree[3] is entirely about addressing technical problems related to packaging for
existing tempest plugins, it's not a decree about what should live
within the tempest
repository nor does it have anything to do with the Interop program.

As I'm not deeply steeped in the history of either the Interop or QA teams I am
sure I've misrepresented some details here, I'm sorry about that. But 

[openstack-dev] Keystone Team Update - Weeks of 25 December 2017 and 1 January 2018

[Colleen Murphy]

# Keystone Team Update - Weeks of 25 December 2017 and 1 January 2018

## News

Happy new year! Things have been slow during the holiday season so not
much to report.

The policy meeting was short but we talked about starting up our
investigations into other RBAC systems again. Lance kicked off a
thread to gauge interest[1].

We're also ready to start planning for the PTG. Please add your ideas
to the etherpad[2]

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-January/125998.html
[2] https://etherpad.openstack.org/p/keystone-rocky-ptg

## Open Specs

Search query: https://goo.gl/pc8cCf

None at this time

## Recently Merged Changes

Search query: https://goo.gl/gu9yQa

We merged 28 changes in the last two weeks. A lot of those were to
convert the old dependency-injection mechanism for internal APIs to
use a centralized provider manager.


## Changes that need Attention

Search query: https://goo.gl/CkMmbK

There are 74 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots.

In particular, there are a set of changes that reorganize our api-ref
into a consistent format that are ready to go:
https://review.openstack.org/#/q/status:open+topic:api-ref-reorganization

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

The extras-ATC deadline is next week, so if there are any non-code
keystone contributors that we need to get on the list we should figure
that out ASAP.

The following week is the final non-client library release date, so
things like keystonemiddleware, keystoneauth, oslo.policy, etc will
need a final release.

Feature freeze is the following week - Jan 22 -2 26 - so all of our
in-flight major features will have to be merged by the end of that
week.

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] Keystone Team Update - Week of 18 December 2017

[Colleen Murphy]

# Keystone Team Update - Week of 18 December 2017

## News

### Unified Limits

We accepted the Limits API spec[1] last week, for which we had made a
spec freeze exception.

### Allowing control over project ID generation

At our weekly meeting, we had a productive conversation[2] about a
recurring feature request[3] by telecom operators to allow operators
direct control over the ID of a project and thereby enable users to
use a token to authenticate and scope to the "same" project in
distinct, non-replicated clouds. The team is very concerned with
exposing an API like this and also unwilling to make it an optional
feature as this causes interoperability issues. We agreed that a
reasonable way forward is for the telecom folks to write their own
out-of-tree resource driver which could synchronize project IDs across
clouds, which would give them the control they need over their
keystone projects but not require a change in an upstream keystone API
nor require buy-in from the keystone team or be constrained by our
release schedule.

Something that came up during this discussion was that the telecom
operators had tried using Keystone to Keystone federation to allow
resource sharing between clouds, but reported it was not performant.
Unfortunately this was a long time ago and they did not have details
on what was slow. We'd like to investigate how we can improve Keystone
to Keystone performance since this is intended to solve the
inter-cloud use case described, but it's unfortunately hard to tell
who is using it or has tried to use it[4].

### Next week

Next week will be a short week and probably a slow one so I won't
bother to post an update.

[1] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[2] 
http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-12-19-18.00.log.html#l-69
[3] https://review.openstack.org/#/c/323499/
[4] http://lists.openstack.org/pipermail/openstack-dev/2017-December/125744.html

## Open Specs

Search query: https://goo.gl/pc8cCf

We've merged all of our proposed Queens specs.

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 24 changes this week (two are in the gate as I write this),
including the client support for project tags and some of Lance's
system-scope changes.

## Changes that need Attention

Search query:  https://goo.gl/h9knRA (query updated to not include
already approved not-yet-merged changes)

There are 47 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots.

The major changes that need feedback are the system-scope changes[5].
There is also this client change for capturing request IDs[6] that has
been in progress for a while and is in pretty good shape now.

[5] https://review.openstack.org/#/q/topic:bp/system-scope+is:open
[6] https://review.openstack.org/#/c/329913/

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

Today is feature proposal freeze, which no accepted specs are in
danger of missing. The next deadline is the feature freeze at R-5, the
week of 22 January.

## Shout-outs

Thanks to Qinglin Cheng and Andreas Jaeger for helping us fix our docs
jobs (after they were so rudely broken ;))!

Also, welcome to our Outreachy intern Suramya Shah who is going to be
helping us out with our docs!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] Keystone Team Update - Week of 4 December 2017

[Colleen Murphy]

On Fri, Dec 8, 2017 at 6:58 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2017-12-08 18:48:56 +0100 (+0100), Colleen Murphy wrote:
> [...]
>> The major hindrance to keystone using Storyboard is its lack of
>> support for private bugs, which is a requirement given that
>> keystone is a VMT-managed project. If anyone is tired of keystone
>> work and wants to help the Storyboard team with that feature I'm
>> sure they would appreciate it!
> [...]
>
> I also followed up on this topic in the SB meeting yesterday[*] and
> realized support is much further along than I previously recalled.
> In summary, SB admins can define "teams" (e.g., OpenStack VMT) and
> anyone creating a private story can choose to share it with any
> teams or individual accounts they like. What we're mostly missing at
> this point is a streamlined reporting mechanism to reduce the steps
> (and chances to make mistakes) when reporting a suspected
> vulnerability. A leading candidate solution would be support for
> custom reporting URLs which can feed arbitrary values into the
> creation form.
>
> [*] 
> http://eavesdrop.openstack.org/meetings/storyboard/2017/storyboard.2017-12-06-19.05.log.html#l-36
>
> --
> Jeremy Stanley
>
Thanks for pointing this out! Good to know this is moving along.

Colleen

__
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] Keystone Team Update - Week of 4 December 2017

[Colleen Murphy]

# Keystone Team Update - Week of 4 December 2017

## News

### Keystone Queens-2 Retrospective

We used our meeting time for our milestone-ly team retrospective,
which took place on Google Hangouts. We were unfortunately not able to
record the session but the Trello board reflects the discussion
topics[1].

One of the key topics that came up was the potential of moving our
roadmap management from Trello to Storyboard. Earlier advice from the
Storyboard folks advised that there would be a mass migration for all
interlinked projects, but the current evolution of the plan promotes a
more iterative approach. See the discussion on the Community Goal
governance review[2]. The major hindrance to keystone using Storyboard
is its lack of support for private bugs, which is a requirement given
that keystone is a VMT-managed project. If anyone is tired of keystone
work and wants to help the Storyboard team with that feature I'm sure
they would appreciate it! In any case, we don't want to switch our
roadmap tooling in the middle of a cycle, so we would continue to use
Trello for roadmap tracking until a cycle change.

[1] https://trello.com/b/jrpmDKtf/keystone-retrospective
[2] 
https://review.openstack.org/#/c/513875/4/goals/rocky/storyboard_migration.rst@82

### Policy Meetings

The last policy meeting was pretty quiet[3]. We decided to cancel
policy meetings until after the holidays.

[3] 
http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-12-06-16.00.log.txt

### Longer project names

We rejected Adrian's patch to extend the maximum length of project
names from 64 to 255 characters[4]. While it might initially seem like
a harmless expansion, it is actually an API breakage because it
changes a response from a 400 to a 200. Keystone does not currently
implement microversions, but we think that microversions would still
not be helpful here, for reasons I described on that patch. We'd like
to look for an alternative way to support Adrian's use case[5].

[4] https://review.openstack.org/#/c/440941/
[5] http://lists.openstack.org/pipermail/openstack-dev/2016-October/106288.html

## Open Specs

Search query: https://goo.gl/pc8cCf

We are closing in on the Limits API spec[6]. We had a good discussion
about it today[7] where we walked through some of the API
compatibility implications of whether or not to start defining and
implementing hierarchical quota models at this stage and reached a
satisfactory conclusion. We'll likely make a spec freeze exception for
this spec so that we can flesh this out fully and get feedback from
other teams.

We also have renewed interest in a feature allowing control over the
generation of project IDs[8], a request that has been independently
made by multiple groups over the years but has historically been
resisted by the keystone team.

[6] https://review.openstack.org/#/c/455709/
[7] 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2017-12-08.log.html#t2017-12-08T15:00:28
[8] https://review.openstack.org/#/c/323499/

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 17 changes this week.

Among those are a couple of patches that push us further down our
policy roadmap:

Enforce policy on oslo-context: https://review.openstack.org/#/c/523650/
Add scope_types to RuleDefault objects:
https://review.openstack.org/#/c/510222/

We also finally moved keystonemiddleware to using oslo.cache instead
of using the python-memcached library directly:

Use oslo_cache in auth_token middleware:
https://review.openstack.org/#/c/268664/

## Changes that need Attention

Search query:https://goo.gl/YiLt6o

There are 49 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots, so their authors are
waiting for feedback from reviewers. Please have a look at them.

In particular, Adam has been working on finishing the is_admin_project
work: https://goo.gl/dDojbk

Lance is closing in on the system-scope implementation: https://goo.gl/2nLbVx

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

Queens-2 is today. Lance has been preparing releases for this
milestone: https://goo.gl/GQBeAi

Spec freeze is today but we'll likely make an exception for the Limits API spec.

Our next deadline is for the Feature Proposal Freeze at Rocky-10.

## Shout-outs

Thanks Harry Rybacki for leading our retrospective!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] [keystone] multiple federated keystones with single Identity Provider

[Colleen Murphy]

On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy
 wrote:
> Hi all,
>
> We have a following use case - several independent keystones (say KeyA and
> KeyB), using fernet tokens and synchronized fernet keys, and single external
> IdP for federated auth.
>
> Is it generally possible to configure both KeyA and KeyB such that scoped
> token issued by KeyA for a federated user is valid on KeyB?
>
> Currently we have the next problem - although domains/projects where
> keystone's mapping engine assigns federated users are equal by name between
> KeyA and KeyB, the UUIDs of projects/domains in KeyA and KeyB  are
> different, which seems to invalidate the scoped token issued by KeyA when
> trying to use it for KeyB. And it is not possible to create projects/domains
> with specific UUIDs via keystone API (which would probably solve this
> problem for non-autoprovisioned projects).
>
> Is such usage scenario supported? Or one should always use the unscoped
> token first to list projects/domains available on a specific keystone
> instance and then get a scoped token for usage o this instance only?

No, it is not currently possible to use the same token on projects in
different keystones, for the reasons you gave. You might be interested
in following https://review.openstack.org/#/c/323499/ if you're not
already aware of it, which has the goal of solving that problem.

It's also been brought up before:

https://review.openstack.org/#/c/403866/
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html

And we talked about it a lot at the last Forum (sorry my brief summary
does not really do the discussion justice):

http://www.gazlene.net/sydney-summit.html#keystone-operator-and-user-feedback

Lance mentioned today that we'd likely try to discuss it at our next
weekly meeting: http://eavesdrop.openstack.org/#Keystone_Team_Meeting

Colleen

__
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] [keystone] Keystone weekly update - Week of 27 November 2017

[Colleen Murphy]

In the "Making OpenStack More Palatable to Part-Time Contributors"
Forum session in Sydney, one barrier to contribution that came up was
keeping up with everything happening in OpenStack. The dev mailing
list is a firehose and IRC can be just as daunting, especially for
contributors in non-Americas timezones. The current time of the weekly
team meeting basically excludes a third of the world from
participating. I don't propose we stop having them, but it would be
good to try to be a little more inclusive. Following the lead of some
of the other folks in our community, I propose we consolidate the
mailing list discussions, IRC meetings, and general discussions in a
weekly update, just to share what we've been up to and what's
important to know.

I don't guarantee I'll get to this every week but I'll make an effort.
Please feel free to provide feedback on what you think would be useful
to see in a newsletter like this. If you want to help out, I created
an etherpad - feel free to help fill in the sections or edit the
template itself.

https://etherpad.openstack.org/p/keystone-team-newsletter

Without further ado, here's what's been going on this week from my perspective:

# Keystone Team Update - Week of 27 November 2017

## News

Next week we'll use the meeting time to have a video conference to do
a milestone retrospective for Queens-2:

http://lists.openstack.org/pipermail/openstack-dev/2017-November/124997.html

We abandoned some very old patches in gerrit. If we abandoned one that
we shouldn't have, come talk to us:

http://lists.openstack.org/pipermail/openstack-dev/2017-November/124910.html

We used the last weekly keystone meeting to talk about open specs. In
particular we talked about the Unified Limits spec and what the
implications are for requiring a region ID in order to create a
registered limit:

http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-11-28-18.00.log.txt

In the weekly policy meeting we talked about using the next round of
community goals to get projects using the new system scope, but
decided that we'd like to have a couple of early adopters before
proposing it community-wide and so we'll likely hold off on proposing
it until the following cycle. We did decide that we could start a
community-wide discussion on defining a set of default-roles by
proposing a cross-project spec.

http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-11-29-16.00.log.txt

## Open Specs

Search query: https://goo.gl/pc8cCf

We only have one spec proposed for Queens still under review:

Limits API: https://review.openstack.org/455709

## Recently Merged Changes

Search query: https://goo.gl/hdD9Kw

We merged 24 changes this week. Notably, we merged a few Queens specs
and some policy roadmaps:

Repropose application credentials to queens: https://review.openstack.org/512505
Specification for system roles: https://review.openstack.org/460344
Outline policy goals: https://review.openstack.org/460344
Add policy roadmap for security: https://review.openstack.org/#/c/462733/

## Changes that need Attention

Search query:https://goo.gl/YiLt6o

There are 51 changes that are passing CI and have no negative reviews,
so these authors are waiting for feedback from reviewers. Please give
them a look.

That doesn't mean you should ignore changes that are failing CI or
have negative reviews, it's just that the changes highlighted here are
more likely to be in the reviewers' court rather than a requiring a
new revision from the author. Sometimes negative votes are misplaced
or CI needs to be fixed project-wide so this doesn't necessarily mean
that this list is the only one to mind.

## Milestone Outlook

https://releases.openstack.org/queens/schedule.html

Queens-2 is next week. That means the specification freeze is on
December 8 and all Queens specifications must be merged by then or
will be pushed to the next release. The only open spec affected by
this is the Limits API spec.

## Shout-outs

wangxiyuan has been doing a ton of awesome work squashing our bugs and
taking on the Unified Limits feature. Thanks wangxiyuan!

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter

__
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] Dublin PTG format

[Colleen Murphy]

On Mon, Nov 27, 2017 at 11:58 AM, Thierry Carrez  wrote:
> Hi everyone,
>
> We are in the final step in the process of signing the contract with the
> PTG venue. We should be able to announce the location this week !
>
> So it's time to start preparing. We'll have 5 days, like in Denver. One
> thing we'd like to change for this round is to give a bit more
> flexibility in the topics being discussed, especially in the first two days.
>
> In Denver, we selected a number of general "themes" and gave them all a
> room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
> project team meeting could get a room for 2 or 3 days on
> Wednesday-Friday. That resulted in a bit of flux during the first two
> days, with a lot of empty rooms as most of the themes did not really
> need 2 days, and a lot of conflicts were present.
>
> For Dublin, the idea would be to still predetermine topics (themes and
> teams) and assign them rooms in advance. But we would be able to assign
> smaller amounts of time (per half-day) based on the expressed needs.
> Beyond those pre-assigned themes/teams we'd add flexibility for other
> groups to book the remaining available rooms in 90-min slots on-demand.
> A bit like how we did reservable rooms in the past, but more integrated
> with the rest of the event. It would all be driven by the PTGbot, which
> would show which topic is being discussed in which room, in addition to
> the current discussion subject within each topic.
>
> We have two options in how we do the split for predetermined topics. We
> used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
> general idea there was to allow some people only interested in a team
> meeting to only attend the second part of the week. However most people
> attend all 5 days, and during event feedback some people suggested that
> "themes" should be in the mornings and "teams" in the afternoons (and
> all Friday).
>
> What would be your preference ? The Mon-Tue/Wed-Fri split means less
> room changes, which make it easier on the events team. So all else being
> equal we'd rather keep it the way it is, but I'm open to changing it if
> attendees think it's a good idea.
>
> If you have any other suggestion (that we could implement in the 3
> months we have between now and the event) please let me know :)
>
> --
> Thierry Carrez (ttx)

I felt like the 2/3 day split worked well for the discussions I
participated in. We were able to come up with ideas and common
understanding in cross-project discussions on the first two days, and
then solidify a plan to implement those ideas within the team during
the last three days. The colocation of the project teams in the last
three days allowed us to pull other people in if we needed to revisit
something from the first two days. I'm not sure that changing the
split is solving a problem that we have.

Colleen

__
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] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Colleen Murphy]

On Tue, Oct 24, 2017 at 1:47 PM, Thierry Carrez <thie...@openstack.org>
wrote:

> Colleen Murphy wrote:
> > On Sat, Oct 21, 2017 at 9:00 AM, Diana Clarke
> > <diana.joan.cla...@gmail.com <mailto:diana.joan.cla...@gmail.com>>
> wrote:
> >
> > Congrats on being elected to the TC, Colleen!
> >
> > You mentioned earlier in this thread that, "a major problem in the
> > tech world is not just attracting underrepresented contributors, but
> > retaining them".
> >
> > I'm curious if the TC has considered polling the people that have
> left
> > OpenStack for their experiences on this front.
> >
> > Something along the lines of:
> >
> > "I see you contributed 20 patches in the last cycle, but haven't
> > contributed recently, why did you stop contributing?".
> >
> > Given the recent layoffs, I suspect many of the responses will be
> > predicable, but you might find some worthwhile nuggets there
> > nonetheless.
> >
> > I'm not aware of such an initiative so far but I do think it would be
> > useful, and perhaps something we can partner with the foundation on.
>
> Kind of parallel to the polling idea:
>
> John Dickinson has some interesting scripts that he runs to detect
> deviation from a past contribution pattern (like someone who used to
> contribute a few patches per cycle but did not contribute anything over
> the past cycle, or someone who used to contribute a handful of patches
> per month who did not send a single patch over the past month). Once
> oddities in the contribution pattern are detected, he would contact the
> person to ask if anything happened or changed that made them stop
> contributing.
>
> John would probably describe it better than I did. I like that it's not
> just quantitative but more around deviation from an established
> contribution pattern, which lets him spot issues earlier.
>
It's great to hear that something like this already exists.

>
> Note that this sort of analysis works well when combined with personal
> outreach, which works better at project team level... If done at
> OpenStack level you would likely have more difficulty making it feel
> personal (if I end up reaching out to a Tacker dev that stopped
> contributing, it won't be as effective as if the Tacker PTL did the
> outreach).

That's a really good point, but I would counter that in certain
circumstances this might not result in the most honest answers, if for
example the reason for leaving was due to personal problems with the PTL or
someone in the team leadership.

Even with a personalized outreach approach, I think it's important that the
data be recorded centrally so it can be analyzed across the various teams
for trends.

> One thing we could do would be to productize those tools and
> make them available to a wider number of people.
>
++

>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Colleen Murphy]

On Sat, Oct 21, 2017 at 9:00 AM, Diana Clarke <diana.joan.cla...@gmail.com>
wrote:

> Congrats on being elected to the TC, Colleen!
>
> You mentioned earlier in this thread that, "a major problem in the
> tech world is not just attracting underrepresented contributors, but
> retaining them".
>
> I'm curious if the TC has considered polling the people that have left
> OpenStack for their experiences on this front.
>
> Something along the lines of:
>
> "I see you contributed 20 patches in the last cycle, but haven't
> contributed recently, why did you stop contributing?".
>
> Given the recent layoffs, I suspect many of the responses will be
> predicable, but you might find some worthwhile nuggets there
> nonetheless.
>
I'm not aware of such an initiative so far but I do think it would be
useful, and perhaps something we can partner with the foundation on.

Colleen

>
> Congrats again,
>
> --diana
>
> On Sun, Oct 15, 2017 at 3:38 AM, Colleen Murphy <coll...@gazlene.net>
> wrote:
> > A major problem in the tech world is not just attracting underrepresented
> > contributors, but retaining them. They leave their communities or careers
> > because of bias problems. To my knowledge, that doesn't happen in
> OpenStack,
> > but just because I can't see it doesn't mean it's not there. A long-term
> > study of participation by underrepresented demographics will help us
> answer
> > this and fix it if necessary.
>
> __
> 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] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Colleen Murphy]

On Fri, Oct 13, 2017 at 2:45 PM, Flavio Percoco  wrote:

> Greetings,
>
> Some of you, TC candidates, expressed concerns about diversity and
> inclusiveness
> (or inclusivity, depending on your taste) in your candidacy. I believe
> this is a
> broad, and some times ill-used, topic so, I'd like to know, from y'all,
> how you
> think we could make our community more inclusive. What areas would you
> improve
> first?
>
> Thank you,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> First, we need more data. We need a better gender study that doesn't rely
on first-name analysis and takes into account non-binary contributors. We
need data on who is participating from which country (I'm reasonably sure
this exists but I haven't found it published), what language they speak,
whether they are participating in IRC meetings and why or why not (time
zone problems? language barriers?). We need data on contribution by
ethnicity.

A major problem in the tech world is not just attracting underrepresented
contributors, but retaining them. They leave their communities or careers
because of bias problems. To my knowledge, that doesn't happen in
OpenStack, but just because I can't see it doesn't mean it's not there. A
long-term study of participation by underrepresented demographics will help
us answer this and fix it if necessary.

We do already know that we need to attract a more diverse contributor base.
To do that, we need to expand and support outreach programs, especially
things like Outreachy. It might not be a bad idea to start an
OpenStack-specific Outreachy-type thing. We need to offer more mentors to
the program so that we can support more interns.

We need to be friendlier to new people. You might have no idea how much a
negative interaction on your first patch or your first question in IRC can
frame your opinion of a community. A new person can't help but wonder if
they are being treated that way because they have a feminine IRC nick or
because their English wasn't good. I certainly think no one here tries to
be unfriendly but I'm sure we could all do better to keep it in mind. I
think Feilong's point about being publicly shamed for making a language and
culture mistake is especially unfriendly and an example of something we can
do better at.

Thanks for the great question.

Colleen
__
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] TC Candidates: what does an OpenStack user look like?

[Colleen Murphy]

On Fri, Oct 13, 2017 at 9:21 PM, Zane Bitter  wrote:

> Replying to myself here, to avoid singling anyone in particular out. I
> want to rephrase the question, because people are overwhelmingly either
> failing to understand or refusing to answer it in the way I intended it.
>
> Most of the candidates are essentially saying that the answer is
> 'everyone'.
>
> I'm glad that we have such a bunch of next-level geniuses running for the
> TC that they are able to analyse the needs of all 7 billion people and
> evaluate every decision they make against all of them in real time. Me, I'm
> just an ordinary guy who can only hold a few things in his head at once, so
> I just try to focus on those and collaborate with people who have different
> perspectives to make sure that a range of needs are covered. This is kind
> of the founding principle of the Open Source (note: not Free Software)
> movement, actually. None of us is as smart as all of us (present company
> excepted, apparently). So it's good, but somewhat surprising that y'all are
> still here, given that you would be guaranteed insta-billionaires if you
> went out and started a proprietary software company.
>
> All sarcasm aside though, 'everyone' is a BS non-answer. It's the
> politician's answer.
>
> Not only because engineering trade-offs are a real thing, and some use
> cases will *definitely* be excluded in order to better serve others, but
> because the average user doesn't exist. If you design for the 'average'
> user then you are designing for nobody, because nobody is the average user.
> We shouldn't be designing for 'everybody' (aka nobody in particular), but
> for a large variety of somebodies.
>
> As an example, look at the Keystone discussion that I linked below.
> - If you were designing Keystone for an individual user, you'd might just
> have one account per tenant.
> - If you were designing Keystone for a team deploying semi-autonomous
> apps, you might design a way for multiple agents to authenticate to each
> tenant.
> - If you were designing Keystone for 'everyone', you might have a matrix
> of users, tenants and roles - the most generic solution, right? - and spend
> half a decade polishing it without ever realising that individual users
> don't need it and teams can't use it.
>
> One of these solutions works for both individuals and teams. The other two
> only work for individuals. As an added bonus, one of those is also
> expensive to develop and hard to operate. That's why we should design for
> someones, not for 'everyone'. This is not a problem limited to Keystone -
> throughout OpenStack we often fail to develop solutions that can actually
> be used by the people whom we say we're building them for, IMHO.
>
> I'm not asking y'all to say that some group of end-users is unimportant
> even though the question is trying to keep the bar extremely low by asking
> about only one group. Nor am I asking y'all to say that operators are
> unimportant, even though the question is *explicitly* *NOT* about operators.
>
> I'm asking if you can describe, to a modest level of detail, even one
> *end* user persona for OpenStack that you're familiar enough with to be
> comfortable advocating for on the TC.
>
> So far the answer I'm hearing mostly translates as 'no'. (Props to the
> folks who did actually answer though!) Does anybody want to try again?
>
> cheers,
> Zane.
>
>
> On 12/10/17 12:51, Zane Bitter wrote:
>
>> In my head, I have a mental picture of who I'm building OpenStack for.
>> When I'm making design decisions I try to think about how it will affect
>> these hypothetical near-future users. By 'users' here I mean end-users, the
>> actual consumers of OpenStack APIs. What will it enable them to do? What
>> will they have to work around? I think we probably all do this, at least
>> subconsciously. (Free tip: try doing it consciously.)
>>
>> So my question to the TC candidates (and incumbent TC members, or anyone
>> else, if they want to answer) is: what does the hypothetical OpenStack user
>> that is top-of-mind in your head look like? Who are _you_ building
>> OpenStack for?
>>
>> There's a description of mine in this email, as an example:
>> http://lists.openstack.org/pipermail/openstack-dev/2017-Octo
>> ber/123312.html
>>
>> To be clear, for me at least there's only one wrong answer ("person who
>> needs somewhere to run their IRC bouncer"). What's important in my opinion
>> is that we have a bunch of people with *different* answers on the TC,
>> because I think that will lead to better discussion and hopefully better
>> decisions.
>>
>> Discuss.
>>
>> cheers,
>> Zane.
>>
>
> What an interesting thread this has been. Thanks to Doug for speaking up -
it's unfair to pose a very general question, say "there are no wrong
answers", and then call everyone out for getting the answer wrong.

It's still a good question, though, since it was designed to expose the
fact that most of us are building clouds for operators, not 

Re: [openstack-dev] [keystone][nova] Persistent application credentials

[Colleen Murphy]

On Mon, Oct 9, 2017 at 6:39 PM, Zane Bitter <zbit...@redhat.com> wrote:

> On 12/09/17 18:58, Colleen Murphy wrote:
>
>> While it's fresh in our minds, I wanted to write up a short recap of
>> where we landed in the Application Credentials discussion in the BM/VM room
>> today. For convenience the (as of yet unrevised) spec is here:
>>
>
> Thanks so much for staying on this Colleen, it's tremendously helpful to
> have someone from the core team keeping an eye on it :)

No problem :)

>
>
> http://specs.openstack.org/openstack/keystone-specs/specs/ke
>> ystone/backlog/application-credentials.html
>>
>> Attached are images of the whiteboarded notes.
>>
>> On the contentious question of the lifecycle of an application
>> credential, we re-landed in the same place we found ourselves in when the
>> spec originally landed, which is that the credential becomes invalid when
>> its creating user is disabled or deleted. The risk involved in allowing a
>> credential to continue to be valid after its creating user has been
>> disabled is not really surmountable, and we are basically giving up on this
>> feature. The benefits we still get from not having to embed user passwords
>> in config files, especially for LDAP or federated users, is still a vast
>> improvement over the situation today, as is the ability to rotate
>> credentials.
>>
>
> OK, there were lots of smart people in the room so I trust that y'all made
> the right decision.
>
> I'd just like to step back for a moment though and ask: how exactly do we
> expect users to make use of Keystone?
>
> When I think about a typical OpenStack user of the near future, they looks
> something like this: there's a team with a handful of developers, with
> maybe one or two devops engineers. This team is responsible for a bunch of
> applications, at various stages in their lifecycles. They work in a
> department with several such teams, in an organisation with several such
> departments. People regularly join or leave the team - whether because they
> join or leave the organisation or just transfer between different teams.
> The applications are deployed with Heat and are at least partly
> self-managing (e.g. they use auto-scaling, or auto-healing, or have
> automated backups, or all of the above), but also require occasional manual
> intervention (beyond just a Heat stack-update). The applications may be
> deployed to a private OpenStack cloud, a public OpenStack cloud, or both,
> with minimal differences in how they work when moving back and forth.
>
> (Obviously the beauty of Open Source is that we don't think about only one
> set of users. But I think if we can serve this set of users as a baseline
> then we have built something pretty generically useful.)
>
> So my question is: how do we recommend these users use Keystone? We
> definitely _can_ support them. But the most workable way I can think of
> would be to create a long-lived application user account for each project
> in LDAP/ActiveDirectory/whatever and have that account manage the
> application. Then things will work basically the same way in the public
> cloud, where you also get a user per project. Hopefully some auditability
> is maintained by having Jenkins/Zuul/Solum/whatever do the pushing of
> changes to Heat, although realistically many users will not be that
> sophisticated. Once we have application credentials, the folks doing manual
> intervention would be able to do so in the same way on public clouds as on
> private clouds, without being given the account credentials.
>
> Some observations about this scenario:
> * The whole user/role infrastructure is completely unused - 'Users' are
> 1:1 with projects. We might as well not have built it.
> * Having Keystone backed by LDAP/ActiveDirectory is arguably worse than
> useless - it just means there are two different places to set things up
> when creating a project and an extra layer of indirection. (I won't say we
> might as well not have built it, because many organisations have compliance
> rules that, ahem, well let's just say they were developed in a different
> context :)
> * We're missing an essential feature of cloud (or even of VPSs): you
> shouldn't need to raise a ticket with IT to be able to deploy a new
> application. Any involvement from them should be asynchronous (e.g. setting
> quotas - although even that is an OpenStack-specific thing: in public
> clouds excessive use is discouraged by _billing_ and in non-OpenStack
> clouds users set their _own_ quotas); we don't want humans in the loop.
> * AFAIK it's not documented anywhere that this is the way we expect you to
> use OpenStack. Anybody would think it's all about the Users

[openstack-dev] [tc][election] TC candidacy

[Colleen Murphy]

I'd like to submit my candidacy for a position on the OpenStack TC.

I work at SUSE as a Cloud Developer. I have been involved with OpenStack for
three years, first as a contributor to the Puppet-OpenStack team, then with
the
Infra team, and now as a core reviewer for keystone.

>From the beginning I have had a keen interest in onboarding new
contributors and
guiding them to be productive community members. Growing our community
following our recent drop in contributors is one of our biggest challenges.
I also see diversifying our community as intertwined with attracting and
onboarding new members. I have always been impressed with OpenStack's
welcoming
community and inclusivity, but the numbers show that we could be doing
better
on gender diversity[1] and I believe we must continue to build up momentum
in
improving cultural inclusivity.

My work in OpenStack has given me with an understanding of the needs of
operators and deployment tool teams and a desire to support those needs.
Admitting deployment tools into the Big Tent was a great step in closing the
communication gap between core projects and deployers and ultimately lead
to an
improvement in the user experience for operators. Continuing this pattern of
inter-group collaboration is fundamental to making OpenStack better.

I care a lot about OpenStack and I'd like to contribute to its overall
health
and success in any way that I can, and I see serving on the TC as an
excellent
way to do that. Thank you for your consideration.

Colleen Murphy (cmurphy)
https://www.openstack.org/community/members/profile/11727/colleen-murphy
http://stackalytics.com/?release=all_id=krinkle

[1] http://superuser.openstack.org/articles/bitergia-intel-report/
__
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] [policy] AWS IAM session

[Colleen Murphy]

On Tue, Oct 3, 2017 at 10:08 PM, Lance Bragstad  wrote:

> Hey all,
>
> It was mentioned in today's keystone meeting [0] that it would be useful
> to go through AWS IAM (or even GKE) as a group. With all the recent
> policy discussions and work, it seems useful to get our eyes on another
> system. The idea would be to spend time using a video conference/screen
> share to go through and play with policy together. The end result should
> keep us focused on the implementations we're working on today, but also
> provide clarity for the long-term vision of OpenStack's RBAC system.
>
> Are you interested in attending? If so, please respond to the thread.
> Once we have some interest, we can gauge when to hold the meeting, which
> tools we can use, and setting up a test IAM account.
>
> Thanks,
>
> Lance
>
> [0]
> http://eavesdrop.openstack.org/meetings/keystone/2017/
> keystone.2017-10-03-18.00.log.html#l-119
>
> Please count me in.

Colleen
__
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] [keystone][nova] Persistent application credentials

[Colleen Murphy]

On Tue, Jul 18, 2017 at 1:39 AM, Zane Bitter  wrote:

> So the application credentials spec has merged - huge thanks to Monty and
> the Keystone team for getting this done:
>
> https://review.openstack.org/#/c/450415/
> http://specs.openstack.org/openstack/keystone-specs/specs/
> keystone/pike/application-credentials.html
>
> However, it appears that there was a disconnect in how two groups of folks
> were reading the spec that only became apparent towards the end of the
> process. Specifically, at this exact moment:
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone
> /%23openstack-keystone.2017-06-09.log.html#t2017-06-09T17:43:59
>
> To summarise, Keystone folks are uncomfortable with the idea of
> application credentials that share the lifecycle of the project (rather
> than the user that created them), because a consumer could surreptitiously
> create an application credential and continue to use that to access the
> OpenStack APIs even after their User account is deleted. The agreed
> solution was to delete the application credentials when the User that
> created them is deleted, thus tying the lifecycle to that of the User.
>
> This means that teams using this feature will need to audit all of their
> applications for credential usage and rotate any credentials created by a
> soon-to-be-former team member *before* removing said team member's User
> account, or risk breakage. Basically we're relying on users to do the Right
> Thing (bad), but when they don't we're defaulting to breaking [some of]
> their apps over leaving them insecure (all things being equal, good).
>
> Unfortunately, if we do regard this as a serious problem, I don't think
> this solution is sufficient. Assuming that application credentials are
> stored on VMs in the project for use by the applications running on them,
> then anyone with access to those servers can obtain the credentials and
> continue to use them even if their own account is deleted. The solution to
> this is to rotate *all* application keys when a user is deleted. So really
> we're relying on users to do the Right Thing (bad), but when they don't
> we're defaulting to breaking [some of] their apps *and* [potentially]
> leaving them insecure (worst possible combination).
>
> (We're also being inconsistent, because according to the spec if you
> revoke a role from a User then any application credentials they've created
> that rely on that role continue to work. It's only if you delete the User
> that they're revoked.)
>
>
> As far as I can see, there are only two solutions to the fundamental
> problem:
>
> 1) Fine-grained user-defined access control. We can minimise the set of
> things that the application credentials are authorised to do. That's out of
> scope for this spec, but something we're already planning as a future
> enhancement.
> 2) Automated regular rotation of credentials. We can make sure that
> whatever a departing team member does manage to hang onto quickly becomes
> useless.
>
> By way of comparison, AWS does both. There's fine-grained defined access
> control in the form of IAM Roles, and these Roles can be associated with
> EC2 servers. The servers have an account with rotating keys provided
> through the metadata server. I can't find the exact period of rotation
> documented, but it's on the order of magnitude of 1 hour.
>
> There's plenty not to like about this design. Specifically, it's 2017 not
> 2007 and the idea that there's no point offering to segment permissions at
> a finer grained level than that of a VM no longer holds water IMHO, thanks
> to SELinux and containers. It'd be nice to be able to provide multiple sets
> of credentials to different services running on a VM, and it's probably
> essential to our survival that we find a way to provide individual
> credentials to containers. Nevertheless, what they have does solve the
> problem.
>
> Note that there's pretty much no sane way for the user to automate
> credential rotation themselves, because it's turtles all the way down. e.g.
> it's easy in principle to set up a Heat template with a Mistral workflow
> that will rotate the credentials for you, but they'll do so using trusts
> that are, in turn, tied back to the consumer who created the stack. (It
> suddenly occurs to me that this is a problem that all services using trusts
> are going to need to solve.) Somewhere it all has to be tied back to
> something that survives the entire lifecycle of the project.
>
> Would Keystone folks be happy to allow persistent credentials once we have
> a way to hand out only the minimum required privileges?
>

I agree that in the haste of getting this approved before the spec freeze
deadline we took this in the wrong direction. I think that this spec was
fine before the addition of "Will be deleted when the associated User is
deleted" constraint.

As I understand it, the worry coming from the team is that a user who
sneakily copies the secret keys to an offsite 

Re: [openstack-dev] [keystone] deprecating and removing tools/sample_data.sh

[Colleen Murphy]

On Wed, Jul 5, 2017 at 9:36 PM, Lance Bragstad  wrote:

> Hi all,
>
> Keystone has a script to perform some bootstrapping operations [0]. It's
> not really tested and its purpose has been superseded by using the
> `keystone-manage bootstrap` command. Based on codesearch, only
> openstack/rpm-packaging references the script [1].
>
It's not exactly superceded by `keystone-manage bootstrap` - in fact it
uses bootstrap as part of its data generation:

https://github.com/openstack/keystone/blob/82f60fe22c405829f8e5f6576f25cf3663b10f73/tools/sample_data.sh#L97



> Is anyone opposed to the removal of this script in favor of more
> supported and tested bootstrapping methods?
>
I haven't used this script in a while but I have found value in it in the
past. It would be great if it or something like it was gate tested.

Colleen

>
> Thanks,
>
>
> [0]
> https://github.com/openstack/keystone/blob/82f60fe22c405829f8e5f6576f25cf
> 3663b10f73/tools/sample_data.sh
> [1] http://codesearch.openstack.org/?q=sample_data.sh=nope==
>
>
>
> __
> 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] [keystone] removing domain configuration upload via keystone-manage

[Colleen Murphy]

>
> On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad 
> wrote:
>
>> Hi all,
>>
>> Keystone has deprecated the domain configuration upload capability
>> provided through `keystone-manage`. We discussed it's removal in today's
>> meeting [0] and wanted to send a quick note to the operator list. The
>> ability to upload a domain config into keystone was done as a stop-gap
>> until the API was marked as stable [1]. It seems as though file-based
>> domain configuration was only a band-aid until full support was done.
>>
>> Of the operators using the domain config API in keystone, how many are
>> backing their configurations with actual configuration files versus the API?
>>
>>
>> [0] http://eavesdrop.openstack.org/meetings/keystone/2017/keysto
>> ne.2017-06-27-18.00.log.html#l-167 [1] https://github.com/openstack/k
>> eystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
>>
>  I am not clear on why we need to deprecate and remove file-backed domain
configuration. The way I see it:

* It's reflectve with the primary configuration, so I can copy over the
chunks I need from keystone.conf into
/etc/keystone/domains/keystone.domain.conf without thinking too hard about
it
* It's convenient for deployment tools to just lay down config files
* It's not that much extra effort for the keystone team to maintain (is it?)

The use case for file-backed domain configs is for smaller clouds with just
one or two LDAP-backed domains. There's not a real need for users to change
domain configs so the file-backed config is plenty fine. I don't see a lot
of gain from removing that functionality.

I don't particularly care about the keystone-manage tool, if that goes away
it would still be relatively easy to write a python script to parse and
upload configs if a user does eventually decide to transition.

As a side note, SUSE happens to be using file-backed domain configs in our
product. It would not be a big deal to rewrite that bit to use the API, but
I think it's just as easy to let us keep using it.

Colleen
__
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][keystone][product] api keys/application specific passwords

[Colleen Murphy]

On Wed, May 17, 2017 at 12:21 AM, Monty Taylor  wrote:

> On 05/16/2017 02:44 PM, Sean Dague wrote:
>
>> On 05/16/2017 03:40 PM, Monty Taylor wrote:
>>
>>> On 05/16/2017 10:20 AM, Doug Hellmann wrote:
>>>
 Excerpts from Chris Dent's message of 2017-05-16 15:16:08 +0100:

> On Tue, 16 May 2017, Monty Taylor wrote:
>
> FWIW - I'm un-crazy about the term API Key - but I'm gonna just roll
>> with
>> that until someone has a better idea. I'm uncrazy about it for two
>> reasons:
>>
>> a) the word "key" implies things to people that may or may not be
>> true here.
>> If we do stick with it - we need some REALLY crisp language about
>> what it is
>> and what it isn't.
>>
>> b) Rackspace Public Cloud (and back in the day HP Public Cloud) have
>> a thing
>> called by this name. While what's written in the spec is quite
>> similar in
>> usage to that construct, I'm wary of re-using the name without the
>> semantics
>> actually being fully the same for risk of user confusion. "This uses
>> api-key... which one?" Sean's email uses "APPKey" instead of
>> "APIKey" - which
>> may be a better term. Maybe just "ApplicationAuthorization"?
>>
>
> "api key" is a fairly common and generic term for "this magical
> thingie I can create to delegate my authority to some automation".
> It's also sometimes called "token", perhaps that's better (that's
> what GitHub uses, for example)? In either case the "api" bit is
> pretty important because it is the thing used to talk to the API.
>
> I really hope we can avoid creating yet more special language for
> OpenStack. We've got an API. We want to send keys or tokens. Let's
> just call them that.
>
>
 +1

>>>
>>> Fair. That's an excellent argument for "api key" - because I certainly
>>> don't think we want to overload 'token'.
>>>
>>
>> As someone who accidentally named "API Microversions", I fully cede
>> naming territory to others here.
>>
>
> I named "jeepyb" on _purpose_.
>
> For those playing at home, that's a phoneticization of "GPB" which is an
> otherwise never-used acronym for "Gerrit Project Builder".
>
> /me hides
>
> It seems like there is general agreement on the review that "api key" is a
bad name. Thoughts on renaming it "application key" / "app key" (what Ron
proposed in an earlier version of this spec)?

Colleen
__
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][keystone][product] api keys/application specific passwords

[Colleen Murphy]

On Sun, May 14, 2017 at 6:59 PM, Monty Taylor  wrote:

> On 05/11/2017 02:32 PM, Lance Bragstad wrote:
>
>> Hey all,
>>
>> One of the Baremetal/VM sessions at the summit focused on what we need
>> to do to make OpenStack more consumable for application developers [0].
>> As a group we recognized the need for application specific passwords or
>> API keys and nearly everyone (above 85% is my best guess) in the session
>> thought it was an important thing to pursue. The API
>> key/application-specific password specification is up for review [1].
>>
>> The problem is that with all the recent churn in the keystone project,
>> we don't really have the capacity to commit to this for the cycle. As a
>> project, we're still working through what we've committed to for Pike
>> before the OSIC fallout. It was suggested that we reach out to the PWG
>> to see if this is something we can get some help on from a keystone
>> development perspective. Let's use this thread to see if there is anyway
>> we can better enable the community through API keys/application-specific
>> passwords by seeing if anyone can contribute resources to this effort.
>>
>
> In the session, I signed up to help get the spec across the finish line.
> I'm also going to do my best to write up something resembling a user story
> so that we're all on the same page about what this is, what it isn't and
> what comes next.
>
> I probably will not have the time to actually implement the code - but if
> the PWG can help us get resources allocated to this I'll be happy to help
> them.
>
If anyone's counting, here are the current open specs (that I've found)
that attempt to address, in slightly different ways, the slightly different
use cases for API keys (not including the open specs to overhaul policy):

 - https://review.openstack.org/#/c/186979 - Subset tokens
 - https://review.openstack.org/#/c/389870 - Adding user credentials and
delegating role assignments to credential types
 - https://review.openstack.org/#/c/396634 - Standalone trusts
 - https://review.openstack.org/#/c/440593 - API keys
 - https://review.openstack.org/#/c/450415 - Application keys

Additionally, I think OAuth - either extending the existing OAuth1.0 plugin
or implementing OAuth2.0 - should probably be on the table.

Colleen
__
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][keystone][product] api keys/application specific passwords

[Colleen Murphy]

On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak 
wrote:

>
>
> Tangentially related to this (because my reasons are different), on our
> cloud I'm actually working on something like this, but under the hood all
> I'm doing is creating a user with a generated password and enforcing a
> username convention. I ask them for a name and what roles they want for the
> user and I spit out:
> username: "service_user_for_web_app_1@"
> password: ""
>
>
On Tue, May 16, 2017 at 4:10 AM, Adrian Turjak 
 wrote:
>
>
> On 16/05/17 14:00, Adrian Turjak wrote:
>


> I'm just concerned that this feels like a feature we don't really need
> when really it's just a slight variant of a user with a new auth model
> (that is really just another flavour of username/password). The sole reason
> most of the other cloud services have API keys is because a user can't talk
> to the API directly. OpenStack does not have that problem, users are API
> keys. So I think what we really need to consider is what exact benefit does
> API keys actually give us that won't be solved with users and better policy?
>
> From my look at the specs the only feature difference compared to users is
> optional expiry of the API keys. Why make something entirely different for
> just that one feature when, as David says in his spec, there is debate if
> that feature is even a good idea.
>
> As an application developer, I don't see why I can't just create a user
> and limit the roles. I feel as if this is better addressed with
> documentation because it almost sounds like people are asking for something
> that already exists, but just doesn't have as nice an API as they would
> like. Another option, make a better API in Keystone for user
> creation/management alongside the old one? That's pretty much what we did,
> except we wrote a service to act as a proxy/wrapper around Keystone for
> some customer actions.
>
> If expiry is the killer feature, why no just add it to users? Temporary
> user accounts could solve that, and probably be useful beyond the scope of
> just API keys.
>

It's not just expiry. I think your proposal is missing one of the major use
cases: empowerment of non-admin users. A non-admin can't create new users
themselves, they have to (as you've pointed out) ask an admin to do it for
them. As an application developer, I want to be able to delegate a subset
of my own roles to a programmatic entity without being dependent on some
other human. One of the (numerous) specs proposed seeks to address that use
case: https://review.openstack.org/#/c/396634

Colleen
__
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] [puppet] Puppet OpenStack PTL non-candidacy

[Colleen Murphy]

Emilien,

Thank you so much for your incredible work on this project. The deployment
tools and OpenStack itself is in a better state because of your work. I'm
glad to work with you and call you a friend.

Colleen

On Fri, Sep 9, 2016 at 9:05 AM, Emilien Macchi  wrote:

> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
> --
> Emilien Macchi
>
> __
> 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] [puppet] Stepping down from puppet-openstack-core

[Colleen Murphy]

On Mon, Apr 18, 2016 at 8:37 AM, Sebastien Badia  wrote:

> Hello here,
>
> I would like to ask to be removed from the core reviewers team on the
> Puppet for OpenStack project.
>
> I lack dedicated time to contribute on my spare time to the project. And I
> don't work anymore on OpenStack deployments.
>
> In the past months, I stopped reviewing and submitting changes on our
> project,
> that's why I slopes down gradually into the abyss stats of the group :-)
> Community coc¹ suggests I step down considerately.
>
> I've never been very talkative, but retrospectively it was a great
> adventure, I
> learned a lot at your side. I'm very proud to see where the project is now.
>
> So Long, and Thanks for All the Fish
> I whish you the best ♥
>
> Seb
>
> ¹http://www.openstack.org/legal/community-code-of-conduct/
> ²http://stackalytics.com/report/contribution/puppetopenstack-group/90
> --
> Sebastien Badia
>
> Thank you Sebastien! We appreciate all the work you've put into this
project.

Colleen
__
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] [puppet] how to run rspec tests? r10k issue

[Colleen Murphy]

On Thu, Feb 18, 2016 at 2:26 PM, Matt Fischer  wrote:

> Is anyone able to share the secret of running spec tests since the r10k
> transition? bundle install && bundle exec rake spec have issues because
> r10k is not being installed. Since I'm not the only one hopefully this
> question will help others.
>
> +
> PUPPETFILE=/etc/puppet/modules/keystone/openstack/puppet-openstack-integration/Puppetfile
> + /var/lib/gems/1.9.1/bin/r10k puppetfile install -v
> /etc/puppet/modules/keystone/openstack/puppet-openstack-integration/functions:
> line 51: /var/lib/gems/1.9.1/bin/r10k: No such file or directory
> rake aborted!
>
> The script is written with the assumption that gem binaries are installed
in $GEM_HOME/bin, because in our CI we install them to a local directory
and that's where bundler will put them[1]. If you're used to just
installing gems with 'bundle install' with either system ruby or a ruby
version manager such as RVM or rbenv, it's possible that your binaries
don't end up in $GEM_HOME/bin. This was true for me using rbenv.

Our CI used to use sudo to install gems at the system level, which meant
binaries were just available in the normal PATH. It might be a good idea to
reconsider going back to that, since that would allow any ruby manager to
work normally with this script.

Colleen

[1]
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/puppet-module-jobs.yaml#n15
__
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] [puppet] Stepping down from Puppet Core

[Colleen Murphy]

On Wed, Jan 27, 2016 at 12:35 PM, Emilien Macchi  wrote:

>
>
> On 01/27/2016 03:13 PM, Mathieu Gagné wrote:
> > Hi,
> >
> > I would like to ask to be removed from the core reviewers team on the
> > Puppet for OpenStack project.
> >
> > My day to day tasks and focus no longer revolve solely around Puppet and
> > I lack dedicated time to contribute to the project.
> >
> > In the past months, I stopped actively reviewing changes compared to
> > what I used to at the beginning when the project was moved to
> > StackForge. Community code of conduct suggests I step down
> > considerately. [1]
> >
> > I'm very proud of what the project managed to achieve in the past
> > months. It would be a disservice to the community to pretend I'm still
> > able or have time to review changes. A lot changed since and I can no
> > longer keep up or pretend I can review changes pedantically or
> > efficiently as I used to.
>
> > Today is time to formalize and face the past months reality by
> > announcing my wish to be removed from the core reviewers team.
> >
> > I will be available to answer questions or move ownership of anything I
> > still have under my name.
> >
> > Wishing you the best.
>
> Mathieu, I would like to personally thank your for your mentoring in my
> early Puppet times ;-)
>
I would echo this as well :)

>
> You took any work conscientiously, you helped to setup lot of
> conventions, you were painstaking in your reviews and code.
> That's something very previous in a team and I'm very happy you were
> on-board all those years.
>
> I wish you all the best in your day2day work, and feel free to kick our
> asses in Gerrit if you see something wrong ;-)
>
> Merci,
> --
> Emilien Macchi
>
> Thank you for all your work on this project. I know that a large part of
why this project has been so successful is because of your guidance.

Colleen
__
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] [puppet] [oslo] Proposal of adding puppet-oslo to OpenStack

[Colleen Murphy]

On Tue, Jan 19, 2016 at 9:57 AM, Xingchao Yu  wrote:

> Hi, Emilien:
>
>  Thanks for your efforts on this topic, I didn't attend V release
> summit and missed related discussion about puppet-oslo.
>
>  As the reason for not using a unified way to manage oslo_* parameters
> is there maybe exist different oslo_* version between openstack projects.
>
>  I have an idea to solve this potential problem,we can maintain
> several versions of puppet-oslo, each module can map to different version
> of puppet-oslo.
>
> It would be something like follows: (the map info is not true, just
> for example)
>
> In Mitaka release
> puppet-nova maps to puppet-oslo with 8.0.0
> puppet-designate maps to puppet-oslo with 7.0.0
> puppet-murano maps to puppet-oslo with 6.0.0
>
> In Newton release
> puppet-nova maps to puppet-oslo with 9.0.0
> puppet-designate maps to puppet-oslo with 9.0.0
> puppet-murano maps to puppet-oslo with 7.0.0
>
For the simplest case of puppet infrastructure configuration, which is a
single puppetmaster with one environment, you cannot have multiple versions
of a single puppet module installed. This means you absolutely cannot have
an openstack infrastructure depend on having different versions of a single
module installed. In your example, a user would not  be able to use both
puppet-nova and puppet-designate since they are using different versions of
the puppet-oslo module.

When we put out puppet modules, we guarantee that version X.x.x of a given
module works with the same version of every other module, and this proposal
would totally break that guarantee.

>
> And by the way, most of projects' requirements.txt
> and test-requirements.txt are maintained automatically by requirements
> project(https://github.com/openstack/requirements), they have the same
> version of oslo.* projects.
> So there maybe minor projects would need extra efforts.
>
> If projects seem to be converging together, maybe this isn't such an issue
anymore? I have no insight here.

Colleen
__
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] [OpenStack-Infra] Mitaka Infra Sprint

[Colleen Murphy]

On Wed, Dec 9, 2015 at 9:17 PM, Joshua Hesketh 
wrote:

> Hi all,
> As discussed during the infra-meeting on Tuesday[0], the infra team will
> be holding a mid-cycle sprint to focus on infra-cloud[1].
> The sprint is an opportunity to get in a room and really work through as
> much code and reviews as we can related to infra-cloud while having each
> other near by to discuss blockers, technical challenges and enjoy company.
> Information + RSVP:
> https://wiki.openstack.org/wiki/Sprints/InfraMitakaSprint
> Dates:Mon. February 22nd at 9:00am to Thursday. February 25th
> Location:HPE Fort Collins Colorado Office
> Who:Anybody is welcome. Please put your name on the wiki page if you are
> interested in attending.
> If you have any questions please don't hesitate to ask.
> Cheers,Josh + Infra team
> [0]
> http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-08-19.00.html[1]
> https://specs.openstack.org/openstack-infra/infra-specs/specs/infra-cloud.html
>
> Since I didn't see one, I started an etherpad for the sprint, and added it
to the wiki page:

https://etherpad.openstack.org/p/mitaka-infra-midcycle

Colleen
__
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] [infra] Nodepool and wiki.openstack.org downtime on 5 January 2016

[Colleen Murphy]

On Mon, Jan 4, 2016 at 10:46 AM, Colleen Murphy <coll...@gazlene.net> wrote:

> The site wiki.openstack.org as well as the nodepool service will be
> offline for 30 minutes starting at 2100 UTC on 5 January 2016 while we
> update infrastructure management of these services. The nodepool downtime
> will cause a disruption in the testing infrastructure that will cause jobs
> to be delayed.
>
> If you have questions, please reply to this thread or contact us in
> #openstack-infra.
>
> Colleen
>
Our infrastructure update was completed successfully. Thank you for your
patience.

Colleen
__
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] [infra] Nodepool and wiki.openstack.org downtime on 5 January 2016

[Colleen Murphy]

The site wiki.openstack.org as well as the nodepool service will be offline
for 30 minutes starting at 2100 UTC on 5 January 2016 while we update
infrastructure management of these services. The nodepool downtime will
cause a disruption in the testing infrastructure that will cause jobs to be
delayed.

If you have questions, please reply to this thread or contact us in
#openstack-infra.

Colleen
__
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] [puppet] [neutron] Serious bug in puppet neutron cli json output parsing.

[Colleen Murphy]

On Wed, Dec 30, 2015 at 8:37 AM, Sofer Athlan-Guyot 
wrote:

> Hi,
>
> I have added neutron people as they may help to find a solution.
>
> After banging my head against the wall for a whole afternoon I
> discovered a serious bug in puppet neutron module.
>
> I not going to repeat here the detail of the bug report[1].  Basically:
>  - neutron_port
>  - neutron_subnet
>  - neutron_router
>  - neutron_network
>
> may break idempotency randomly and won't work at all when clifftablib is
> removed from the package dependency of python-openstackclient
> (Mitaka[2])
>
> So the problem is that neutron cli json output on liberty (at least, and
> maybe before) is not consistent and may come from cliff or clifftablib.
> I didn't test it but the same may apply to openstack cli. As we don't
> use the openstack cli json output it's not a issue (for puppet modules)
>
> The available solution I can see are:
>  1. go back to parsing csv, shell output (revert [3])
>  2. find a way to leverage openstacklib parsing for neutron as well
>  3. keep json and parse the right output (cliff) and find a way to make
> sure that it is always used by stevedore
>  4. ?
>
> Last I checked, which was quite a while ago, openstackclient didn't
support everything we were using from the neutron client. I would like to
reevaluate that and go with option 2 if we can. Otherwise option 1 seems
reasonable.


> From my point of view 3) is not a option, but other may disagree.
>
> The problem is tricky and the fact that the CI cannot detect this is
> trickier[4].
>
> So before Mitaka, the json parsing should go.  I would love to see an
> interface that all puppet modules would use (solution 2).  The current
> openstacklib parses openstack client well enough.  The neutron command
> is not that different and I think there is space for code reuse.  This
> would be a long term solution.  It would bring the advantage of having
> only one interface to change if it was decided to use the API directly
> for instance[5]
>
> In the meantime, a quick solution to this bug must be found.
>
> Looking forward to your comments.
>
> Regards,
>
> [1] https://bugs.launchpad.net/puppet-neutron/+bug/1530163
> [2] https://bugs.launchpad.net/python-neutronclient/+bug/1529914
> [3] https://review.openstack.org/#/c/238156/
> [4] https://review.openstack.org/#/c/262223/
> [5]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076439.html
> --
> Sofer Athlan-Guyot
>
> Colleen
__
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] [puppet] proposing Cody Herriges part of Puppet OpenStack core

[Colleen Murphy]

On Tue, Dec 8, 2015 at 8:49 AM, Emilien Macchi  wrote:

> Hi,
>
> Back in "old days", Cody was already core on the modules, when they were
> hosted by Puppetlabs namespace.
> His contributions [1] are very valuable to the group:
> * strong knowledge on Puppet and all dependencies in general.
> * very helpful to debug issues related to Puppet core or dependencies
> (beaker, etc).
> * regular attendance to our weekly meeting
> * pertinent reviews
> * very understanding of our coding style
>
> I would like to propose having him back part of our core team.
> As usual, we need to vote.
>
> Thanks,
>
> [1]
>
> http://stackalytics.openstack.org/?metric=commits=all_type=all_id=ody-cat
> --
> Emilien Macchi
>

Big +1, Cody has been doing a lot of great work in the last few months.

Colleen
__
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] [puppet][Fuel] Using Native Ruby Client for Openstack Providers

[Colleen Murphy]

On Tue, Oct 13, 2015 at 6:13 AM, Vladimir Kuklin 
wrote:

> Puppetmaster and Fuelers,
>
> Last week I mentioned that I would like to bring the theme of using native
> ruby OpenStack client and use it within the providers.
>
> Emilien told me that I had already been late and the decision was made
> that puppet-openstack decided to not work with Aviator based on [0]. I went
> through this thread and did not find any unresolvable issues with using
> Aviator in comparison with potential benefits it could have brought up.
>
> What I saw actually was like that:
>
> * Pros
>
> 1) It is a native ruby client
> 2) We can import it in puppet and use all the power of Ruby
> 3) We will not need to have a lot of forks/execs for puppet
> 4) You are relying on negotiated and structured output provided by API
> (JSON) instead of introducing workarounds for client output like [1]
>
> * Cons
>
> 1) Aviator is not actively supported
> 2) Aviator does not track all the upstream OpenStack features while native
> OpenStack client does support them
> 3) Ruby community is not really interested in OpenStack (this one is
> arguable, I think)
>
> * Proposed solution
>
> While I completely understand all the cons against using Aviator right
> now, I see that Pros above are essential enough to change our mind and
> invest our own resources into creating really good OpenStack binding in
> Ruby.
> Some are saying that there is not so big involvement of Ruby into
> OpenStack. But we are actually working with Puppet/Ruby and are invloved
> into community. So why should not we own this by ourselves and lead by
> example here?
>
> I understand that many of you do already have a lot of things on their
> plate and cannot or would not want to support things like additional
> library when native OpenStack client is working reasonably well for you.
> But if I propose the following scheme to get support of native Ruby client
> for OpenStack:
>
> 1) we (community) have these resources (speaking of the company I am
> working for, we at Mirantis have a set of guys who could be very interested
> in working on Ruby client for OpenStack)
> 2) we gradually improve Aviator code base up to the level that it
> eliminates issues that are mentioned in  'Cons' section
> 3) we introduce additional set of providers and allow users and operators
> to pick whichever they want
> 4) we leave OpenStackClient default one
>
> Would you support it and allow such code to be merged into upstream
> puppet-openstack modules?
>
>
> [0]
> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J
> [1]
> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>

The scale-tipping reason we went with python-openstackclient over the
Aviator library was that at the same time we were trying to switch, we were
also developing keystone v3 features and we could only get those features
from python-openstackclient.

For the first two pros you listed, I'm not convinced they're really pros.
Puppet types and providers are actually extremely well-suited to shelling
out to command-line clients. There are existing, documented puppet APIs to
do it and we get automatic debug output with it. Nearly every existing type
and provider does this. It is not well-suited to call out to other
non-standard ruby libraries because they need to be added as a dependency
somehow, and doing this is not well-established in puppet. There are
basically two options to do this:

 1) Add a gem as a package resource and make sure the package resource is
called before any of the openstack resources. I could see this working as
an opt-in thing, but not as a default, for the same reason we don't require
our users to install pip libraries - there is less security guarantees from
pypi and rubygems than from distro packages, plus corporate infrastructure
may not allow pulling packages from these types of sources. (I don't see
this policy documented anywhere, this was just something that's been
instilled in me since I started working on this team. If we want to revisit
it, formalize it, or drop it, we can start a separate thread for that.)

2) Vendor the gem as a module. This was how we tried it before, and you can
see aimonb/aviator  for this. The
problems I see with this are that we have to keep the module in sync with
the gem, and there is no way to keep proper attribution in the module for
work that was really done in the gem.

I am not convinced that the fork/execs are really causing that much
performance issues, though I've heard from some people 

Re: [openstack-dev] [puppet] weekly meeting #54

[Colleen Murphy]

On Mon, Oct 5, 2015 at 5:48 AM, Emilien Macchi  wrote:

> Hello!
>
> Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
> in #openstack-meeting-4:
>
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151006
>
> Feel free to add any additional items you'd like to discuss.
> If our schedule allows it, we'll make bug triage during the meeting.
>
> Note: I'll be at the airport for my trip to Portland (Puppetconf 2015).
> Colleen will lead the meeting if my flight is on-time and I'll be
> probably afk.
>
> Regards,
> --
> Emilien Macchi
>
Our meeting notes from this morning are here:

http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-10-06-15.00.html

Thanks!

Colleen
__
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] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

[Colleen Murphy]

On Wed, Sep 2, 2015 at 11:09 AM, Emilien Macchi  wrote:

> TL;DR, I propose to move our developer documentation from wiki to
> something like http://docs.openstack.org/developer/puppet-openstack
>
> (Look at http://docs.openstack.org/developer/tempest/ for example).
>
> For now, most of our documentation is on
> https://wiki.openstack.org/wiki/Puppet but I think it would be great to
> use RST format and Gerrit so anyone could submit documentation
> contribute like we do for code.
>
> I propose a basic table of contents now:
> Puppet modules introductions
> Coding Guide
> Reviewing code
>
> I'm taking the opportunity of the puppet sprint to run this discussion
> and maybe start some work of people agrees to move on.
>
> Thanks,
> --
> Emilien Macchi
>
Please consider the Puppet Approved criteria[1] when making decisions about
documentation. In particular, we should be making sure the README contained
within the module is complete. Publishing .rst docs to docs.o.o is not a
substitute.

The READMEs and examples/ in our modules are generally inaccurate or out of
date. We should focus on enhancing the content of our docs before worrying
about the logistics of publishing them.

Colleen

[1] https://forge.puppetlabs.com/approved/criteria
__
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] [infra][puppet] Keeping common set of file synchronized across puppet modules

[Colleen Murphy]

On Wed, Jul 29, 2015 at 5:40 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-07-29 10:53:38 +0200 (+0200), Yanis Guenane wrote:
  On 07/28/2015 07:13 PM, Andreas Jaeger wrote:
 [...]
   * If there is a proposed change already for a project, reuse that one
   instead of creating a new one?
 
  I don't have the answer for that I'd have to look. But this should never
  happen as the goal here is to enforce a process where a change to a
  shared file can only be done via the modulesync repository.

 The question comes from experience preforming similar
 synchronization proposals for requirements lists, translations, data
 file normalization, et cetera. Specifically, if you update the msync
 repo and that triggers change proposals for all your module repos,
 but then core reviewers don't get around to approving at least some
 of those before the next change merges to the msync repo (especially
 possible if you approve two msync changes at roughly the same time),
 will it properly update the existing but not-yet-merged changes it
 previously proposed rather than creating new changes?

No, it would create a new set of changes that for the entire the current
state of the modulesync-configs repository (not just the latest change), so
any unmerged changes from the last sync would have to be manually
abandoned, or the new changes would have to be manually rebased on the old
changes.


   * Will msync check out the git repositories itself?
 
  Yes, msync checks out the repositories listed in managed_modules.yml,
  loop on them, clone them, apply the templates and submit the review.

 Also, does msync know to take advantage of the on-disk cache of git
 repositories on our job workers, or does it clone them all over the
 network every time it runs? The latter can lead to additional
 fragility.

It can take any URI as a remote, so it can clone from the local filesystem
if we tell it to.

 --
 Jeremy Stanley


Modulesync is a beta tool that is in danger of being massively rewritten[1]
and has the potential to allow you to shoot yourself in the foot[2].
Multiple people have suggested that it over-reaches its primary function by
trying to do too many things. Its main value-add is the ability to template
files that are /slightly/ different between repositories. I suspect that
this is something we don't need, so if there is already synchronization
tooling in place in the OpenStack world it makes sense to use that.

Colleen

[1] https://github.com/puppet-community/modulesync/pull/52
[2]
http://lists.openstack.org/pipermail/openstack-infra/2015-July/002965.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

Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

[Colleen Murphy]

On Mon, Jul 27, 2015 at 12:06 PM, Emilien Macchi emil...@redhat.com wrote:

 Puppet group,

 Yanis has been working in our group for a while now.
 He has been involved in a lot of tasks, let me highlight some of them:

 * Many times, involved in improving consistency across our modules.
 * Strong focus on data binding, backward compatibility and flexibility.
 * Leadership on cookiebutter project [1].
 * Active participation to meetings, always with actions, and thoughts.
 * Beyond the stats, he has a good understanding of our modules, and
 quite good number of reviews, regularly.

 Yanis is for our group a strong asset and I would like him part of our
 core team.
 I really think his involvement, regularity and strong knowledge in
 Puppet OpenStack will really help to make our project better and stronger.

 I would like to open the vote to promote Yanis part of Puppet OpenStack
 core reviewers.

 Best regards,

 [1] https://github.com/openstack/puppet-openstack-cookiecutter
 --
 Emilien Macchi


 +1, Yanis has been a strong contributor for a long time.

Colleen
__
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] [puppet] [infra] issues with beaker/centos7 job

[Colleen Murphy]

On Thu, Jul 2, 2015 at 11:40 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-07-02 16:02:32 +0200 (+0200), Alan Pevec wrote:
  After having a closer look, I see that image has requests 2.7
  installed from pypi which overwrites python-requests RPM installation
  and wreaks havoc when trying to upgrade RPM.
  I'm not sure why and where is pypi used during the image build but it
  should not be installed system-wide on RPM system. If really needed,
  install it in venv.

 After some deep digging, I think https://review.openstack.org/198082
 will solve this (I'll fire up manual image updates once it merges).
 --
 Jeremy Stanley

It looks like things are starting to work again. Thanks Ian and Jeremy for
your tremendous help.

Colleen
__
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] [puppet] Installing dependent modules in functional testing

[Colleen Murphy]

On Thu, Jun 18, 2015 at 2:24 PM, Colleen Murphy coll...@gazlene.net wrote:

 Now that we have the basic beaker-rspec framework set up in the modules
 and working in infra's CI, we need to start making our testing aware of
 Zuul dependencies. The infra team is facing similar challenges so it would
 be nice to work together on this. Discussions with jeblair and nibalizer
 have resulted in an etherpad[1] with some possible solutions, where Idea 1
 seems to be the most mutually beneficial. The idea is to have JJB prepare
 the node prior to testing, and to share an install script for when
 developers are running tests locally. This would install all of our modules
 and all their dependencies, not just the specific ones needed by one
 particular module, because this makes it easier to share a common thing
 between modules and frees us from worrying about implicit dependencies
 (modules needed to set up infrastructure that aren't listed explicitly in
 metadata.json) and transitive dependencies (dependencies of co-gated
 modules).

 I've written a possible implementation using r10k with a Puppetfile[2][3].
 R10k is generally promoted as the preferred way to manage puppet
 environments so it makes sense to use it in our tests. It also gives us the
 benefit of having a commonly defined Puppetfile that lays out versions of
 modules that are guaranteed to work together. This POC script is also using
 zuul-cloner to clone dependencies from Zuul if running in a CI environment.
 This part could be extracted out into the node prep stage later, which
 would be more in line with Idea 1 in the etherpad, but it's hard to test
 that functionality at this early stage.

 I'd like to create a new repo to hold this install script and Puppetfile.
 This repo could also eventually become a home for integration testing
 material, like a kind of devstack. I suggest we call it
 openstack/puppet-openstack-testing or
 openstack/puppet-openstack-integration. I would like to avoid calling it
 anything that could imply that it should be used as a composition module.

 Opening this up for thoughts on this implementation proposal and the repo
 name.

 Colleen

 [1] https://etherpad.openstack.org/p/puppet-git-dependencies
 [2] https://review.openstack.org/#/c/190839
 [3] https://github.com/cmurphy/puppet-openstack-dependencies


I proposed a patch to create a new repo for this, see
https://review.openstack.org/194287

Colleen
__
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] [puppet] Installing dependent modules in functional testing

[Colleen Murphy]

Now that we have the basic beaker-rspec framework set up in the modules and
working in infra's CI, we need to start making our testing aware of Zuul
dependencies. The infra team is facing similar challenges so it would be
nice to work together on this. Discussions with jeblair and nibalizer have
resulted in an etherpad[1] with some possible solutions, where Idea 1 seems
to be the most mutually beneficial. The idea is to have JJB prepare the
node prior to testing, and to share an install script for when developers
are running tests locally. This would install all of our modules and all
their dependencies, not just the specific ones needed by one particular
module, because this makes it easier to share a common thing between
modules and frees us from worrying about implicit dependencies (modules
needed to set up infrastructure that aren't listed explicitly in
metadata.json) and transitive dependencies (dependencies of co-gated
modules).

I've written a possible implementation using r10k with a Puppetfile[2][3].
R10k is generally promoted as the preferred way to manage puppet
environments so it makes sense to use it in our tests. It also gives us the
benefit of having a commonly defined Puppetfile that lays out versions of
modules that are guaranteed to work together. This POC script is also using
zuul-cloner to clone dependencies from Zuul if running in a CI environment.
This part could be extracted out into the node prep stage later, which
would be more in line with Idea 1 in the etherpad, but it's hard to test
that functionality at this early stage.

I'd like to create a new repo to hold this install script and Puppetfile.
This repo could also eventually become a home for integration testing
material, like a kind of devstack. I suggest we call it
openstack/puppet-openstack-testing or
openstack/puppet-openstack-integration. I would like to avoid calling it
anything that could imply that it should be used as a composition module.

Opening this up for thoughts on this implementation proposal and the repo
name.

Colleen

[1] https://etherpad.openstack.org/p/puppet-git-dependencies
[2] https://review.openstack.org/#/c/190839
[3] https://github.com/cmurphy/puppet-openstack-dependencies
__
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] [puppet] Change abandonment policy

[Colleen Murphy]

On Tue, Jun 2, 2015 at 11:39 AM, Colleen Murphy coll...@gazlene.net wrote:

 In today's meeting we discussed implementing a policy for whether and when
 core reviewers should abandon old patches whose author's were inactive.
 (This doesn't apply to authors that want to abandon their own changes, only
 for core reviewers to abandon other people's changes.) There are a few
 things we could do here, with potential policy drafts for the wiki:

 1) Never abandon

 ```
 Our policy is to never abandon changes except for our own.
 ```

 The sentiment here is that an old change in the queue isn't really hurting
 anything by just sitting there, and it is more visible if someone else
 wants to pick up the change.

 2) Manually abandon after N months/weeks changes that have a -2 or were
 fixed in a different patch

 ```
 If a change is submitted and given a -1, and subsequently the author
 becomes unresponsive for a few weeks, reviewers should leave reminder
 comments on the review or attempt to contact the original author via IRC or
 email. If the change is easy to fix, anyone should feel welcome to check
 out the change and resubmit it using the same change ID to preserve
 original authorship. Core reviewers will not abandon such a change.

 If a change is submitted and given a -2, or it otherwise becomes clear
 that the change can not make it in (for example, if an alternate change was
 chosen to solve the problem), and the author has been unresponsive for at
 least 3 months, a core reviewer should abandon the change.
 ```

 Core reviewers can click the abandon button only on old patches that are
 definitely never going to make it in. This approach has the advantage that
 it is easier for contributors to find changes and fix them up, even if the
 change is very old.

 3) Manually abandon after N months/weeks changes that have a -1 that was
 never responded to

 ```
 If a change is submitted and given a -1, and subsequently the author
 becomes unresponsive for a few weeks, reviewers should leave reminder
 comments on the review or attempt to contact the original author via IRC or
 email. If the change is easy to fix, anyone should feel welcome to check
 out the change and resubmit it using the same change ID to preserve
 original authorship. If the author is unresponsive for at least 3 months
 and no one else takes over the patch, core reviewers can abandon the patch,
 leaving a detailed note about how the change can be restored.

 If a change is submitted and given a -2, or it otherwise becomes clear
 that the change can not make it in (for example, if an alternate change was
 chosen to solve the problem), and the author has been unresponsive for at
 least 3 months, a core reviewer should abandon the change.
 ```

 Core reviewers can click the abandon button on changes that no one has
 shown an interest in in N months/weeks, leaving a message about how to
 restore the change if the author wants to come back to it. Puppet Labs does
 this for its module pull requests, setting N at 1 month.

 4) Auto-abandon after N months/weeks if patch has a -1 or -2

 ```
 If a change is given a -2 and the author has been unresponsive for at
 least 3 months, a script will automatically abandon the change, leaving a
 message about how the author can restore the change and attempt to resolve
 the -2 with the reviewer who left it.
 ```

 We would use a tool like this one[1] to automatically abandon changes
 meeting a certain criteria. We would have to decide whether we want to only
 auto-abandon changes with -2's or go as far as to auto-abandon those with
 -1's. The policy proposal above assumes -2. The tool would leave a canned
 message about how to restore the change.


 Option 1 has the problem of leaving clutter around, which the discussion
 today seeks to solve.

 Option 3 leaves the possibility that a change that is mostly good becomes
 abandoned, making it harder for someone to find and restore it.

  I don't think option 4 is necessary because there are not an overwhelming
 number of old changes (I count 9 that are currently over six months old).
 In working through old changes a few months ago I found that many of them
 are easy to fix up to remove a -1, and auto-abandoning removes the ability
 for a human to make that call. Moreover, if a patch has a procedural -2
 that ought to be lifted after some point, auto-abandonment has the
 potential to accidentally throw out a change that was intended to be kept
 (though presumably the core reviewer who left the -2 would notice the
 abandonment and restore it if that was the case).

 I am in favor of option 2. I think setting N to be 3 months or 6 months is
 appropriate. I don't have very strong feelings about options 1 or 3. I'm
 against option 4.

 Colleen

 [1]
 https://github.com/openstack/nova/blob/master/tools/abandon_old_reviews.sh

Though we didn't seem to reach a clear consensus in this thread, based on
feedback from today's IRC meeting I have added a section based

Re: [openstack-dev] [puppet] openstacklib::db::sync proposal

[Colleen Murphy]

On Sun, Jun 7, 2015 at 11:48 PM, Yanis Guenane yguen...@redhat.com wrote:



 On 06/03/2015 02:32 PM, Martin Mágr wrote:
 
  On 06/02/2015 07:05 PM, Mathieu Gagné wrote:
  On 2015-06-02 12:41 PM, Yanis Guenane wrote:
  The openstacklib::db::sync[2] is currently only a wrapper around an
  exec
  that does the actual db sync, this allow to make any modification to
  the
  exec into a single place. The main advantage IMO is that a contributor
  is provided with the same experience as it is not the case today across
  all modules.
 
  The amount of possible change to an exec resource is very limited. [1] I
  don't see a value in this change which outweighs the code churn and
  review load needed to put it in place. Unless we have real use cases or
  outrageously genius feature to add to it, I'm not in favor of this
  change.
 
  Furthermore, any change to the public interface of
  openstacklib::db::sync would require changes across all our modules
  anyway to benefit from this latest hypothetical feature. I think we are
  starting to nitpick over as little generic code we could possibly find
  to put in openstacklib.
 
  [1] https://docs.puppetlabs.com/references/latest/type.html#exec
 
 
  Wearing my consistency hat I must say I like this change. On the other
  hand I agree with Mathieu that delegating single resource from several
  modules to single module is necessary in this case.
 
  Regards,
  Martin

 Mathieu, Martin, thank you for replying.

 For the wrapper around exec usefulness I understand your concerns.
 On a note I was trying to follow the current use of openstacklib.

 If we look at openstacklib::db::postgresql[1] or
 openstackib::db::mysql[2] they are simple wrapper around
 puppet resources with no extra logic, but a common resource across all
 modules.

The openstacklib::db::mysql resource is a wrapper around a couple of
resources and contains logic around choosing an allowed hosts lists.

The openstacklib::db::postgresql is largely useless but makes the database
interface consistent with mysql.

Colleen


 Also, to move forward on this topic I will submit to a vote one of the
 three propositions during our next meeting

  1. Abandon this change
  2. Move everything to X::db::sync, but just run the exec there, no
 openstacklib::db::sync
  3. Move forward with current implementation

 Thanks again for the feedbacks,

 [1]

 https://github.com/stackforge/puppet-openstacklib/blob/master/manifests/db/postgresql.pp
 [2]

 https://github.com/stackforge/puppet-openstacklib/blob/master/manifests/db/mysql.pp

 --
 Yanis Guenane

 __
 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] [puppet] Change abandonment policy

[Colleen Murphy]

In today's meeting we discussed implementing a policy for whether and when
core reviewers should abandon old patches whose author's were inactive.
(This doesn't apply to authors that want to abandon their own changes, only
for core reviewers to abandon other people's changes.) There are a few
things we could do here, with potential policy drafts for the wiki:

1) Never abandon

```
Our policy is to never abandon changes except for our own.
```

The sentiment here is that an old change in the queue isn't really hurting
anything by just sitting there, and it is more visible if someone else
wants to pick up the change.

2) Manually abandon after N months/weeks changes that have a -2 or were
fixed in a different patch

```
If a change is submitted and given a -1, and subsequently the author
becomes unresponsive for a few weeks, reviewers should leave reminder
comments on the review or attempt to contact the original author via IRC or
email. If the change is easy to fix, anyone should feel welcome to check
out the change and resubmit it using the same change ID to preserve
original authorship. Core reviewers will not abandon such a change.

If a change is submitted and given a -2, or it otherwise becomes clear that
the change can not make it in (for example, if an alternate change was
chosen to solve the problem), and the author has been unresponsive for at
least 3 months, a core reviewer should abandon the change.
```

Core reviewers can click the abandon button only on old patches that are
definitely never going to make it in. This approach has the advantage that
it is easier for contributors to find changes and fix them up, even if the
change is very old.

3) Manually abandon after N months/weeks changes that have a -1 that was
never responded to

```
If a change is submitted and given a -1, and subsequently the author
becomes unresponsive for a few weeks, reviewers should leave reminder
comments on the review or attempt to contact the original author via IRC or
email. If the change is easy to fix, anyone should feel welcome to check
out the change and resubmit it using the same change ID to preserve
original authorship. If the author is unresponsive for at least 3 months
and no one else takes over the patch, core reviewers can abandon the patch,
leaving a detailed note about how the change can be restored.

If a change is submitted and given a -2, or it otherwise becomes clear that
the change can not make it in (for example, if an alternate change was
chosen to solve the problem), and the author has been unresponsive for at
least 3 months, a core reviewer should abandon the change.
```

Core reviewers can click the abandon button on changes that no one has
shown an interest in in N months/weeks, leaving a message about how to
restore the change if the author wants to come back to it. Puppet Labs does
this for its module pull requests, setting N at 1 month.

4) Auto-abandon after N months/weeks if patch has a -1 or -2

```
If a change is given a -2 and the author has been unresponsive for at least
3 months, a script will automatically abandon the change, leaving a message
about how the author can restore the change and attempt to resolve the -2
with the reviewer who left it.
```

We would use a tool like this one[1] to automatically abandon changes
meeting a certain criteria. We would have to decide whether we want to only
auto-abandon changes with -2's or go as far as to auto-abandon those with
-1's. The policy proposal above assumes -2. The tool would leave a canned
message about how to restore the change.


Option 1 has the problem of leaving clutter around, which the discussion
today seeks to solve.

Option 3 leaves the possibility that a change that is mostly good becomes
abandoned, making it harder for someone to find and restore it.

 I don't think option 4 is necessary because there are not an overwhelming
number of old changes (I count 9 that are currently over six months old).
In working through old changes a few months ago I found that many of them
are easy to fix up to remove a -1, and auto-abandoning removes the ability
for a human to make that call. Moreover, if a patch has a procedural -2
that ought to be lifted after some point, auto-abandonment has the
potential to accidentally throw out a change that was intended to be kept
(though presumably the core reviewer who left the -2 would notice the
abandonment and restore it if that was the case).

I am in favor of option 2. I think setting N to be 3 months or 6 months is
appropriate. I don't have very strong feelings about options 1 or 3. I'm
against option 4.

Colleen

[1]
https://github.com/openstack/nova/blob/master/tools/abandon_old_reviews.sh
__
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] [puppet] Weekly meeting #36

[Colleen Murphy]

On Mon, Jun 1, 2015 at 12:16 PM, Colleen Murphy coll...@gazlene.net wrote:

 Hi everyone,

 Here's an initial agenda for our weekly meeting tomorrow at 1500 UTC in
 #openstack-meeting-4:

 https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150602

 Please add additional items you'd like to discuss.

 Colleen

Our meeting minutes this week:

http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-06-02-15.00.html

Thanks everyone,

Colleen
__
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] [puppet] Weekly meeting #36

[Colleen Murphy]

Hi everyone,

Here's an initial agenda for our weekly meeting tomorrow at 1500 UTC in
#openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150602

Please add additional items you'd like to discuss.

Colleen
__
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] [puppet] Weekly meeting #36

[Colleen Murphy]

Hi everyone,

Here's an initial agenda for our weekly meeting tomorrow at 1500 UTC in
#openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150526

Please add additional items you'd like to discuss.

Colleen
__
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