subject:"\[openstack\-dev\] Keystone"

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

2018-11-09 Thread 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

[openstack-dev] [keystone] No meeting 13 Nov 2018

2018-11-06 Thread Lance Bragstad

Just a reminder that we won't be holding a weekly meeting for keystone next
week due to the OpenStack Summit in Berlin.

Meetings will resume on the 20th of November.

Thanks,

Lance
__
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] Berlin Forum Sessions & Talks

2018-11-06 Thread Lance Bragstad

Hey all,

Here is what's on my radar for keystone-specific sessions and talks next
week:

*Tuesday*
- Change ownership of resources [0]
- Keystone Project Update [1]
- OpenStack Policy 101 [2]
- Keystone Project Onboarding [3]
- Gaps between OpenStack and business logic with Adjutant [4]

*Wednesday*
- Deletion of project and project resources [5]
- Enforcing Quota Consistently with Unified Limits [6]

*Thursday*
- Keystone as an Identity Provider Proxy [7]
- Keystone Operator Feedback [8]

If you know about a keystone-related session that I've missed, please feel
free to follow up. Links to the forum session etherpads are available from
the main wiki [9].


[0]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22785/change-of-ownership-of-resources
[1]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22728/keystone-project-updates
[2]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21977/openstack-policy-101
[3]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22727/keystone-project-onboarding
[4]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22184/bridging-the-gaps-between-openstack-and-business-logic-with-adjutant
[5]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22784/deletion-of-project-and-project-resources
[6]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22557/enforcing-quota-consistently-with-unified-limits
[7]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22791/keystone-as-an-identity-provider-proxy
[8]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22792/keystone-operator-feedback
[9] https://wiki.openstack.org/wiki/Forum/Berlin2018#Thursday.2C_November_15
__
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 29 October 2018

2018-11-02 Thread 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

2018-10-28 Thread 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

[openstack-dev] [keystone][tc] Seeking feedback on the OpenStack cloud vision

2018-10-24 Thread Zane Bitter


Greetings, Keystone team!
As you may be aware, I've been working with other folks in the community 
on documenting a vision for OpenStack clouds (formerly known as the 
'Technical Vision') - essentially to interpret the mission statement in 
long-form, in a way that we can use to actually help guide decisions. 
You can read the latest draft here: https://review.openstack.org/592205


We're trying to get feedback from as many people as possible - in many 
ways the value is in the process of coming together to figure out what 
we're trying to achieve as a community with OpenStack and how we can 
work together to build it. The document is there to help us remember 
what we decided so we don't have to do it all again over and over.


The vision is structured with two sections that apply broadly to every 
project in OpenStack - describing the principles that we believe are 
essential to every cloud, and the ones that make OpenStack different 
from some other clouds. The third section is a list of design goals that 
we want OpenStack as a whole to be able to meet - ideally each project 
would be contributing toward one or more of these design goals.


Identity management is specifically called out as a key aspect of the 
'Basic Physical Data Center Management' design goal, so obviously 
Keystone fits in there. However, there are other parts of the document 
that can also help provide guidance. One is the last paragraph of the 
'Customisable Integration' goal, which talks about which combinations of 
interactions need to be possible (needs that are currently met by a 
combination of application credentials and trusts), and the importance 
of least-privilege access and credential rotation. Another is the 
section on 'Application Control'. All of this is stuff we have talked 
about in the past so there should be no surprises, but hopefully this 
helps situate it all in the context of the bigger picture.


If you would like me or another TC member to join one of your team IRC 
meetings to discuss further what the vision means for your team, please 
reply to this thread to set it up. You are also welcome to bring up any 
questions in the TC IRC channel, #openstack-tc - there's more of us 
around during Office Hours 
(https://governance.openstack.org/tc/#office-hours), but you can talk to 
us at any time.


Feedback can also happen either in this thread or on the review 
https://review.openstack.org/592205


If the team is generally happy with the vision as it is and doesn't have 
any specific feedback, that's cool but I'd like to request that at least 
the PTL leave a vote on the review. It's important to know whether we 
are actually developing a consensus in the community or just talking to 
ourselves :)


many thanks,
Zane.

__
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 1 October 2018

2018-10-05 Thread Morgan Fainberg

On Fri, Oct 5, 2018, 07:04 Colleen Murphy  wrote:

> # 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



As an update to JSON Home bits, I have worked around the possible needed
changes. The document should remain the same as before.

--Morgan

>
>
__
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

2018-10-05 Thread 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

2018-09-28 Thread 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

2018-09-27 Thread Lance Bragstad

Using the domain name + group name pairing also allows for things like:


JSON:{"group_name": "C",
"domain_name": "X"}
JSON:{"group_name": "C",
"domain_name": "Y"}


To showcase how we solve the ambiguity in group names by namespacing them
with domains.

On Thu, Sep 27, 2018 at 3:11 AM Colleen Murphy  wrote:

>
>
> 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 encod

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

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

2018-09-26 Thread vishakha agarwal

> 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):
>  > > >
>  > > > Given a list of openstack_groups like ["A", "B", "C"], it would work 
> like this:
>  > > >
>  > > > [
>  > > >{
>  > > >  "local":
>  > > >  [
>  > > >{
>  > > >  "group":
>  > > >  {
>  > > >

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

2018-09-25 Thread 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"
> >}
> >  ]
> >}
> > ]
> > (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":
> >  {
> >

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

2018-09-24 Thread John Dennis

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"
}
]
}
]
(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,

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

2018-09-24 Thread 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 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.
> >
> 
> Oh - yeah that makes sense. In your opinion, does that prevent us from
> adopting another way of solving the problem if we find a better data type?

Not 100% sure. The format of the SAML assertion is part of our API so we do 
have to be really careful about changing it, that's why I nacked the current 
patch. But how much leeway we have might depend on what the alternate solution 
is: maybe if the end result changes the NameFormat or the xsi:type of the 
Attribute, and we still support the xsi:type="xs:string" solution (the one 
we're discussing now), that might be okay?

> 
> 
> >
> > [1]
> >

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

2018-09-24 Thread Lance Bragstad

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 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.
>

Oh - yeah that makes sense. In your opinion, does that prevent us from
adopting another way of solving the problem if we find a better data type?


>
> [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 like ["A", "B",

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

2018-09-24 Thread 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 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

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

2018-09-24 Thread Lance Bragstad

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?


> 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}"
>

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

2018-09-24 Thread 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:

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/ )

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

2018-09-21 Thread 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] [keystone] noop role in openstack

2018-09-20 Thread Lance Bragstad

On Thu, Sep 20, 2018 at 12:22 AM Adrian Turjak 
wrote:

> For Adam's benefit continuing this a bit in email:
>
> regarding the noop role:
>
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-20.log.html#t2018-09-20T04:13:43
>
> The first benefit of such a role (in the given policy scenario) is that
> you can now give a user explicit scope on a project (but they can't do
> anything) and then use that role for Swift ACLs with full knowledge they
> can't do anything other than auth, scope to the project, and then
> whatever the ACLs let them do. An example use case being: "a user that
> can ONLY talk to a specific container and NOTHING else in OpenStack or
> Swift" which is really useful if you want to use a single project for a
> lot of websites, or backups, or etc.
>
> Or in my MFA case, a role I can use when wanting a user to still be able
> to auth and setup their MFA, but not actually touch any resources until
> they have MFA setup at which point you give them back their real member
> role.
>
> It all relies on leaving no policy rules 'empty' unless those rules (and
> their API) really are safe for a noop role. And by empty I don't mean
> empty, really I mean "any role on a project". Because that's painful to
> then work with.
>
> With the default policies in Nova (and most other projects), you can't
> actually make proper use of Swift ACLs, because having any role on a
> project gives you access to all the resources. Like say:
> https://github.com/openstack/nova/blob/master/nova/policies/base.py#L31
>
> ^ that rule implies, if you are scoped to the project, don't care about
> the role, you can do anything to the resources. That doesn't work for
> anything role specific. Such rules would need to be:
> "is_admin:True or (role:member and project_id:%(project_id)s)"
>
> If we stop with this assumption that "any role" on a project works,
> suddenly policy becomes more powerful and the roles are actually useful
> beyond admin vs not admin. System scope will help, but then we'll still
> only have system scope, admin on a project, and not admin on a project,
> which still makes the role mostly pointless.
>

Kind of. System-scope is only half the equation for fixing RBAC because it
gives developers an RBAC target that isn't project-scoped that they can use
to protect APIs with. When you combine that with default roles (admin,
member, and reader) [0] then you can start building a matrix, per se.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html


>
> We as a community need to stop with this assumption (that "any role" on
> a project works), because it hurts us in regards to actually useful
> RBAC. Yes deployers can edit the policy to avoid the any role on a
> project issue (we have), but it's a huge amount of work to figure out
> that we could all work together and fix upstream.
>

As I'm sure you know, even rolling custom policy files might not be enough.
Despite an override, there are APIs that still check for 'admin' roles.


>
> Part of that work is actually happening. With the default roles that
> Keystone is defining, and system scope. We can then start updating all
> the project default policies to actually require those roles explicitly,
> but that effort, needs us to get everyone on board...
>

That's the idea. We're trying to build that out in keystone now so that
other projects have a template to follow.


>
>
> __
> 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] noop role in openstack

2018-09-19 Thread Adrian Turjak

For Adam's benefit continuing this a bit in email:

regarding the noop role:

http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-09-20.log.html#t2018-09-20T04:13:43

The first benefit of such a role (in the given policy scenario) is that
you can now give a user explicit scope on a project (but they can't do
anything) and then use that role for Swift ACLs with full knowledge they
can't do anything other than auth, scope to the project, and then
whatever the ACLs let them do. An example use case being: "a user that
can ONLY talk to a specific container and NOTHING else in OpenStack or
Swift" which is really useful if you want to use a single project for a
lot of websites, or backups, or etc.

Or in my MFA case, a role I can use when wanting a user to still be able
to auth and setup their MFA, but not actually touch any resources until
they have MFA setup at which point you give them back their real member
role.

It all relies on leaving no policy rules 'empty' unless those rules (and
their API) really are safe for a noop role. And by empty I don't mean
empty, really I mean "any role on a project". Because that's painful to
then work with.

With the default policies in Nova (and most other projects), you can't
actually make proper use of Swift ACLs, because having any role on a
project gives you access to all the resources. Like say:
https://github.com/openstack/nova/blob/master/nova/policies/base.py#L31

^ that rule implies, if you are scoped to the project, don't care about
the role, you can do anything to the resources. That doesn't work for
anything role specific. Such rules would need to be:
"is_admin:True or (role:member and project_id:%(project_id)s)"

If we stop with this assumption that "any role" on a project works,
suddenly policy becomes more powerful and the roles are actually useful
beyond admin vs not admin. System scope will help, but then we'll still
only have system scope, admin on a project, and not admin on a project,
which still makes the role mostly pointless.

We as a community need to stop with this assumption (that "any role" on
a project works), because it hurts us in regards to actually useful
RBAC. Yes deployers can edit the policy to avoid the any role on a
project issue (we have), but it's a huge amount of work to figure out
that we could all work together and fix upstream.

Part of that work is actually happening. With the default roles that
Keystone is defining, and system scope. We can then start updating all
the project default policies to actually require those roles explicitly,
but that effort, needs us to get everyone on board...

[openstack-dev] [keystone] Rocky Retrospective

2018-09-17 Thread Lance Bragstad

This is typically something we do in-person during the PTG, but due to
weather and travel approval we didn't have great representation last week.

That said, let's try to do an asynchronous retrospective to gather feedback
regarding the last cycle. Afterwords we can try and meet to go through
specific things, if needed. I've created a doodle to see if we can get a
time lined up [0]. The retrospective board [1] is available and waiting for
your feedback! The board should be public, but if you need access to add
cards, just ping me.

I'll collect results from the doodle on Friday and see what times work.

Thanks,

Lance

[0] https://doodle.com/poll/5vkztz9sumkbzp4h
[1] https://trello.com/b/af8vmDPs/keystone-rocky-retrospective
__
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][adjutant] Sync with adjutant team

2018-09-10 Thread Adrian Turjak

As I'm not attending the PTG, I thought I might help put some words
against these questions for when you're having the meeting. Plus even if
I did want to be online, it would be something like 4am my time.

Stein will likely see a lot of Adjutant refactor work as I get myself
back onto the project full swing, and onboard a new dev who will be
helping me. As that work happens I'll be in a better place to reevaluate
exactly where Adjutant sits around Keystone, so I'll be updating you all
as much as I can, but for now have some answers that may help.



## They are building on top of keystone, is there anything we can do to
make those interactions easier?

Most of the admin level APIs we interact with do the work well enough
and the 'primitives' in Keystone work as a base layer for us to build
account management logic on top of. I think there was something with
querying roles up and down a tree that was awkward, but I think I found
ways of doing that which didn't amount to silly numbers of API calls.

I think the only real thing I can think of which was awkward is that
Keystone doesn't have a concept for quota in regards to how many
projects a subtree can have (and how deep that tree can be). In my WIP
HMT management code I'm faking it by sticking a key=value in the root
project extras blob and doing the checking in my code, and I guess I can
potentially switch to using the limits API once that's considered
stable, although I don't know how far Keystone itself wants to go down
the route of actually implementing quota checking on its own resources.
My WIP code has quota checking implemented in Adjutant and because of
how it works it likely will stay there as right now that code does quota
as: "allowed to create x number of projects across the whole tree within
a period of y days, to a depth of z" where x, y, and z have default
values in Adjutant or key=values present in the root project extras blob
if a project tree needs custom quotas. As for checking quotas, that's
done against total project creations across a whole tree based on the
number of previous subproject creation tasks in Adjutant in the same tree.


## Is there anything we should incorporate into keystone? maybe after
all the scope work lands in Stein?

There are indeed places where with some work the Keystone APIs (with
proper policy and roles) could provide a replacement for some of the
work in Adjutant, and some cases where it just doesn't make sense
because the parts of that workflow aren't things Keystone is meant to do
(anything with emails or that may need to talk to external systems). The
annoying part here though is that while there are definitely things
Adjutant can do, or will do that make sense to have in Keystone, other
parts of that which a deployer may want to link with external systems or
add more workflow logic on top of don't make sense in Keystone. I'm torn
because there are a lot of small features I could propose we add to
Keystone, but then I doubt I'd be able to use them because I'd need to
still keep elements of them pluggable in Adjutant itself, or would still
write logic around, at which stage working with the primitives is
somewhat easier.

What I might do is make a list and see what 'could' work in Keystone,
and if I could find a way to still use it in Adjutant. If I can still
use it, great, if not, we can evaluated it anyway and consider it as a
minor quality of life improvement to Keystone without an Adjutant. That
way Keystone potentially gains features that makes sense for it, but if
Adjutant is around they can be disabled (or blocked with policy) and
Adjutant's more flexible/complex variants can be configured by the
deployer. The worry though is that you end up with two cloud variants
with slightly similar features, but that's always going to be the case
(Keystone + Adjutant vs just Keystone), the question is if adding
similar overlapping features may prove too confusing.


## Is there anything we need to be aware of with the scope work in Stein
that needs to be communicated to them?

Not that I'm entirely aware of? Maybe some of the internals of Adjutant
will need to change as to how Adjutant's admin user interacts with
Keystone (as it likely will use system scope to have access to
everything), but all the assignments that Adjutant manages for users are
in project scope. Need to really play with and figure this out, not sure
how much is really changing that will cause us pain.

__
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 3 September 2018

2018-09-07 Thread Lance Bragstad

# Keystone Team Update - Week of 3 September 2018

## News

This week was mainly focused on the python3 community goal and ultimately
cleaning up a bunch of issues with stable branches that were uncovered in
those reviews. Next week is the PTG, which the group is preparing for in
addition to brainstorming Stein forum topics [0][1].

[0]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134362.html
[1] https://etherpad.openstack.org/p/BER-keystone-forum-sessions

## User Feedback

The foundation provided us with the latest feedback from our users [0]. A
sanitized version of that data has been shared publicly [1] for you to
checkout prior to the PTG. We have time set aside on Wednesday to review
the feedback and discuss any adjustments we want to make to the survey
questions.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134434.html
[1]
https://docs.google.com/spreadsheets/d/1wz-GOoFODGWrFuGqVWDunEWsuhC_lvRJLrfUybTj69Q/edit?usp=sharing

## PTG Planning

As I'm sure you're aware, the PTG is next week. The schedule is relatively
firm at this point [0], but please raise any conflicts with other sessions
if you see any.

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

## Open Specs

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

A new specification was proposed this week to enable limit support for
domains [0]. This is going to be a main focus next week as we discuss
unified limits. Please have a look if you're interested in that particular
discussion.

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

## Recently Merged Changes

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

We merged 26 changes this week, most of which were for the python3
community goal [0].

We did notice a high number of stable branch failures for keystoneauth,
keystonemiddleware, and python-keystoneclient. This was discussed on the
ML[1][2].

[0] https://governance.openstack.org/tc/goals/stein/python3-first.html
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134391.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134454.html

## Changes that need Attention

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

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

[0]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1776504

## Bugs

This week we opened 9 new bugs, closed 1, and fixed 3.

Bugs opened (9)

   - Bug #1790148 (keystone:Low) opened by FreudianSlip
   https://bugs.launchpad.net/keystone/+bug/1790148


   - Bug #1790428 (keystone:Undecided) opened by Eric Miller
   https://bugs.launchpad.net/keystone/+bug/1790428


   - Bug #179 (keystone:Undecided) opened by Paul Peereboom
   https://bugs.launchpad.net/keystone/+bug/179


   - Bug #1780164 (keystoneauth:Undecided) opened by mchlumsky
   https://bugs.launchpad.net/keystoneauth/+bug/1780164


   - Bug #1790423 (python-keystoneclient:Undecided) opened by ChenWu
   https://bugs.launchpad.net/python-keystoneclient/+bug/1790423


   - Bug #1790931 (oslo.limit:Medium) opened by Lance Bragstad
   https://bugs.launchpad.net/oslo.limit/+bug/1790931


   - Bug #1790954 (oslo.limit:Medium) opened by Lance Bragstad
   https://bugs.launchpad.net/oslo.limit/+bug/1790954


   - Bug #1790894 (oslo.limit:Low) opened by Lance Bragstad
   https://bugs.launchpad.net/oslo.limit/+bug/1790894


   - Bug #1790935 (oslo.limit:Low) opened by Lance Bragstad
   https://bugs.launchpad.net/oslo.limit/+bug/1790935


Bugs closed (1)

   - Bug #1790423 (python-keystoneclient:Undecided)
   https://bugs.launchpad.net/python-keystoneclient/+bug/1790423


Bugs fixed (3)

   - Bug #1777671 (keystone:Medium) fixed by Vishakha Agarwal
   https://bugs.launchpad.net/keystone/+bug/1777671


   - Bug #1790148 (keystone:Low) fixed by Chason Chan
   https://bugs.launchpad.net/keystone/+bug/1790148


   - Bug #1789351 (keystonemiddleware:Undecided) fixed by wangxiyuan
   https://bugs.launchpad.net/keystonemiddleware/+bug/1789351


## Milestone Outlook

We have a lot of work to do to shape the release between now and milestone
1, which will be October 26th. Focusing on specifications and early feature
development is appreciated.

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

## Shout-outs

Thanks to Ben, Doug, and Tony for helping us make sense of the
tox_install.sh and pip stable branch mess! We should be past the last layer
of the onion with respect to the python3 stable patches.

## 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] [keystone] 2018 User Survey Results

2018-09-07 Thread Lance Bragstad

The foundation just gave me a copy of the latest feedback from our users. I
wanted to share this with the group so people have time to digest it prior
to the PTG next week [0].

Here is the total count based on each response:

Federated identity enhancements had *184* responses

Performance improvements had *144* responses

Scaling out to multiple regions had *136* responses

Enhancing policy had *92* responses

Per domain configuration had *79* responses


Next Wednesday I have a time slot set aside to go through the results as a
group. Otherwise we can use the time to refine the questions we present in
the survey, since they haven't changed in years (I think Steve put the ones
we have today in place).


The script I used to count each occurrence is available [1] in case you
recently received survey results and want to parse them in a similar
fashion.


[0]
https://docs.google.com/spreadsheets/d/1wz-GOoFODGWrFuGqVWDunEWsuhC_lvRJLrfUybTj69Q/edit?usp=sharing

[1] https://gist.github.com/lbragstad/a812df72494ffbbbc8c742f4d90333d5
__
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] No meeting or office hours September 11th

2018-09-06 Thread Lance Bragstad

I wanted to send out a reminder that we won't be having formal office hours
or a team meeting next week due to the PTG. Both will resume on the 18th of
September.

Thanks,

Lance
__
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] Stein Forum Brainstorming

2018-09-06 Thread Lance Bragstad

I can't believe it's already time to start thinking about forum topics, but
it's upon us [0]!

I've created an etherpad for us to brainstorm ideas that we want to bring
to the forum in Germany [1]. I also linked it to the wiki [2].

Please feel free to throw out ideas. We can go through them as a group
before the submission phase starts if people wish.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134336.html
[1] https://etherpad.openstack.org/p/BER-keystone-forum-sessions
[2]
https://wiki.openstack.org/wiki/Forum/Berlin2018#Etherpads_from_Teams_and_Working_Groups
__
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 27 August 2018

2018-08-31 Thread Lance Bragstad

# Keystone Team Update - Week of 27 August 2018

## News

Welcome to Stein development!

## Release Status

Well, Rocky went out the door. A friendly reminder to keep an eye out for
bugs and things we should backport.

## PTG Planning

The topics in the PTG etherpad have been worked into a schedule [0].

The TL;DR is that Monday is going to be a mainly focused on large,
cross-project initiatives (just like what we did in Dublin). Tuesday we are
going to be discussing ways we can improve multi-region support
(edge-related discussions) and federation. Wednesday is relatively free of
topics, but we have a lot of hackathon ideas. This is a good time to
iterate quickly on things we need to get done, clean things up, or share
how something works with respect to keystone (e.g. Flask). Have an idea you
want to propose for Wednesday's hackathon? Just add it to the schedule [0].
Thursday is going to be for keystone-specific topics. Friday we plan to
cover any remaining topics and try and formalize everything into the
roadmap or specifications repo *before* we leave Denver.

If you have comments, questions, or concerns regarding the schedule, please
let someone know and we'll get it addressed.

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

## Stein Roadmap Planning

Harry and I are working through the Rocky roadmap [0] and preparing a new
board for Stein. Most of this prep work should be done prior to the PTG so
that we can finalize and make adjustments in person. If you want to be
involved in this process just ask. Additionally, the Stein series has been
created in launchpad, along with the usual blueprints [1][2]. Feel free to
use accordingly for other blueprints and bugs.

[0] https://trello.com/b/wmyzbFq5/keystone-rocky-roadmap
[1] https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-stein
[2] https://blueprints.launchpad.net/keystone/+spec/removed-as-of-stein

## Open Specs

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

We landed a couple cleanup patches that re-propose the MFA receipts [0] and
capability lists [1] specifications to Stein. Just a note to make sure we
treat those as living documents by updating them regularly if details
change as we work through the implementations.

The JWT specification [2] also received a facelift and is much more
specific than it was in the past. Please have a gander if you're
interested, or just curious. If the details are still unclear, just let us
know and we can get them proposed prior to PTG discussions in a couple
weeks.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/mfa-auth-receipt.html
[1]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/capabilities-app-creds.html
[2] https://review.openstack.org/#/c/541903/

## Recently Merged Changes

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

We merged 27 changes this week. We also got a good start on the python 3
community goal [0].

Note that there were some patches proposed for the community goal last
week, but the author wasn't listed as a champion for the goal and the
patches contained errors. We weren't able to reach the author and neither
were the goal champions. That said, those patches have been abandoned and
Doug reran the tooling to migrate our jobs. Just something to keep in mind
if you're reviewing those patches.

[0] https://governance.openstack.org/tc/goals/stein/python3-first.html

## Changes that need Attention

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

There are 61 changes that are passing CI, not in merge conflict, have no
negative reviews and aren't proposed by bots. We're making good progress on
the Flask reviews [0], but more reviews are always welcome.

[0]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1776504

## Bugs

This week we opened 4 new bugs and closed 1.

Bugs opened (4)

- Bug #1789450 (keystone:Undecided) opened by Steven Relf
https://bugs.launchpad.net/keystone/+bug/1789450

- Bug #1789849 (keystone:Undecided) opened by Jean-
https://bugs.launchpad.net/keystone/+bug/1789849

- Bug #1790148 (keystone:Undecided) opened by FreudianSlip
https://bugs.launchpad.net/keystone/+bug/1790148

- Bug #1789351 (keystonemiddleware:Undecided) opened by yatin
https://bugs.launchpad.net/keystonemiddleware/+bug/1789351

Bugs fixed (1)

- Bug #1787874 (keystone:Medium) fixed by wangxiyuan
https://bugs.launchpad.net/keystone/+bug/1787874

## Milestone Outlook

We have a lot of work to do to shape the release between now and milestone
1, which will be October 26th. Otherwise we'll be meeting in Denver in a
couple weeks.

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

## Help with this newsletter

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

2018-08-30 Thread Adrian Turjak

Actually now that I think about it, another problem is that (at least in
our case) Keystone is really a cluster wide service present across
regions, so if it was to use Barbican (or Vault for that matter) then
the secret store service would too need to be cluster wide and across
all regions.

Our current plan for our deployment of Barbican is per region. Is that
the norm? Because if so, then it kind of means using it for Keystone
becomes less useful.

On 31/08/18 12:02 PM, Adrian Turjak wrote:
>
> Oh I was literally just thinking about the 'credential' type key value
> items we store in the Keystone DB. Rather than storing them in the
> Keystone db and worrying about encryption (and encryption keys) in
> Keystone around what is otherwise a plaintext secret, just offload
> that to a service specific for handling those (which Keystone isn't).
>
> My only really worry then is if tying MFA credential values to an
> external service is a great idea as now Keystone and Barbican have to
> be alive for auth to occur (plus auth could be marginally slower).
> Although by using an external service security could potentially be
> enhanced and deployers don't need to worry about credential encryption
> key rotation (and re-encryption of credentials) in Keystone.
>
> As for fernet keys in Barbican... that that does sound like a fairly
> terrifying chicken and egg problem. Although Castellan with a Vault
> plugin sounds doable (not tied back to Keystone's own auth), and could
> actually be useful for multi-host keystone deployments since Vault now
> handles your Key replication/distribution provided Keystone rotates
> keys into it.
>
> On 31/08/18 1:50 AM, Lance Bragstad wrote:
>> This topic has surfaced intermittently ever since keystone
>> implemented fernet tokens in Kilo. An initial idea was written down
>> shortly afterwords [0], then we targeted it to Ocata [1], and removed
>> from the backlog around the Pike timeframe [2]. The commit message of
>> [2] includes meeting links. The discussion usually tripped attempting
>> to abstract enough of the details about rotation and setup of keys to
>> work in all cases.
>>
>> [0] https://review.openstack.org/#/c/311268/
>> [1] https://review.openstack.org/#/c/363065/
>> [2] https://review.openstack.org/#/c/439194/
>>
>> On Thu, Aug 30, 2018 at 5:02 AM Juan Antonio Osorio Robles
>> mailto:jaosor...@redhat.com>> wrote:
>>
>> FWIW, instead of barbican, castellan could be used as a key manager.
>>
>>
>> On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>>>
>>>
>>> On 30/08/18 6:29 AM, Lance Bragstad wrote:

 Is that what is being described here ? 
 
 https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html


 This is a separate mechanism for storing secrets, not
 necessarily passwords (although I agree the term credentials
 automatically makes people assume passwords). This is used if
 consuming keystone's native MFA implementation. For example,
 storing a shared secret between the user and keystone that is
 provided as a additional authentication method along with a
 username and password combination.
  
>>>
>>> Is there any interest or plans to potentially allow Keystone's
>>> credential store to use Barbican as a storage provider?
>>> Encryption already is better than nothing, but if you already
>>> have (or will be deploying) a proper secret store with a
>>> hardware backend (or at least hardware stored encryption keys)
>>> then it might make sense to throw that in Barbican.
>>>
>>> Or is this also too much of a chicken/egg problem? How safe is
>>> it to rely on Barbican availability for MFA secrets and auth?
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

2018-08-30 Thread Adrian Turjak

Oh I was literally just thinking about the 'credential' type key value
items we store in the Keystone DB. Rather than storing them in the
Keystone db and worrying about encryption (and encryption keys) in
Keystone around what is otherwise a plaintext secret, just offload that
to a service specific for handling those (which Keystone isn't).

My only really worry then is if tying MFA credential values to an
external service is a great idea as now Keystone and Barbican have to be
alive for auth to occur (plus auth could be marginally slower). Although
by using an external service security could potentially be enhanced and
deployers don't need to worry about credential encryption key rotation
(and re-encryption of credentials) in Keystone.

As for fernet keys in Barbican... that that does sound like a fairly
terrifying chicken and egg problem. Although Castellan with a Vault
plugin sounds doable (not tied back to Keystone's own auth), and could
actually be useful for multi-host keystone deployments since Vault now
handles your Key replication/distribution provided Keystone rotates keys
into it.

On 31/08/18 1:50 AM, Lance Bragstad wrote:
> This topic has surfaced intermittently ever since keystone implemented
> fernet tokens in Kilo. An initial idea was written down shortly
> afterwords [0], then we targeted it to Ocata [1], and removed from the
> backlog around the Pike timeframe [2]. The commit message of [2]
> includes meeting links. The discussion usually tripped attempting to
> abstract enough of the details about rotation and setup of keys to
> work in all cases.
>
> [0] https://review.openstack.org/#/c/311268/
> [1] https://review.openstack.org/#/c/363065/
> [2] https://review.openstack.org/#/c/439194/
>
> On Thu, Aug 30, 2018 at 5:02 AM Juan Antonio Osorio Robles
> mailto:jaosor...@redhat.com>> wrote:
>
> FWIW, instead of barbican, castellan could be used as a key manager.
>
>
> On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>>
>>
>> On 30/08/18 6:29 AM, Lance Bragstad wrote:
>>>
>>> Is that what is being described here ? 
>>> 
>>> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>>>
>>>
>>> This is a separate mechanism for storing secrets, not
>>> necessarily passwords (although I agree the term credentials
>>> automatically makes people assume passwords). This is used if
>>> consuming keystone's native MFA implementation. For example,
>>> storing a shared secret between the user and keystone that is
>>> provided as a additional authentication method along with a
>>> username and password combination.
>>>  
>>
>> Is there any interest or plans to potentially allow Keystone's
>> credential store to use Barbican as a storage provider?
>> Encryption already is better than nothing, but if you already
>> have (or will be deploying) a proper secret store with a hardware
>> backend (or at least hardware stored encryption keys) then it
>> might make sense to throw that in Barbican.
>>
>> Or is this also too much of a chicken/egg problem? How safe is it
>> to rely on Barbican availability for MFA secrets and auth?
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

2018-08-30 Thread Lance Bragstad

This topic has surfaced intermittently ever since keystone implemented
fernet tokens in Kilo. An initial idea was written down shortly afterwords
[0], then we targeted it to Ocata [1], and removed from the backlog around
the Pike timeframe [2]. The commit message of [2] includes meeting links.
The discussion usually tripped attempting to abstract enough of the details
about rotation and setup of keys to work in all cases.

[0] https://review.openstack.org/#/c/311268/
[1] https://review.openstack.org/#/c/363065/
[2] https://review.openstack.org/#/c/439194/

On Thu, Aug 30, 2018 at 5:02 AM Juan Antonio Osorio Robles <
jaosor...@redhat.com> wrote:

> FWIW, instead of barbican, castellan could be used as a key manager.
>
> On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>
>
> On 30/08/18 6:29 AM, Lance Bragstad wrote:
>
> Is that what is being described here ?
>> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>>
>
> This is a separate mechanism for storing secrets, not necessarily
> passwords (although I agree the term credentials automatically makes people
> assume passwords). This is used if consuming keystone's native MFA
> implementation. For example, storing a shared secret between the user and
> keystone that is provided as a additional authentication method along with
> a username and password combination.
>
>
> Is there any interest or plans to potentially allow Keystone's credential
> store to use Barbican as a storage provider? Encryption already is better
> than nothing, but if you already have (or will be deploying) a proper
> secret store with a hardware backend (or at least hardware stored
> encryption keys) then it might make sense to throw that in Barbican.
>
> Or is this also too much of a chicken/egg problem? How safe is it to rely
> on Barbican availability for MFA secrets and auth?
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

2018-08-30 Thread Juan Antonio Osorio Robles

FWIW, instead of barbican, castellan could be used as a key manager.


On 08/30/2018 12:23 PM, Adrian Turjak wrote:
>
>
> On 30/08/18 6:29 AM, Lance Bragstad wrote:
>>
>> Is that what is being described here ? 
>> 
>> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>>
>>
>> This is a separate mechanism for storing secrets, not necessarily
>> passwords (although I agree the term credentials automatically makes
>> people assume passwords). This is used if consuming keystone's native
>> MFA implementation. For example, storing a shared secret between the
>> user and keystone that is provided as a additional authentication
>> method along with a username and password combination.
>>  
>
> Is there any interest or plans to potentially allow Keystone's
> credential store to use Barbican as a storage provider? Encryption
> already is better than nothing, but if you already have (or will be
> deploying) a proper secret store with a hardware backend (or at least
> hardware stored encryption keys) then it might make sense to throw
> that in Barbican.
>
> Or is this also too much of a chicken/egg problem? How safe is it to
> rely on Barbican availability for MFA secrets and auth?
>
>
>
> __
> 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] [barbican] Keystone's use of Barbican ?

2018-08-30 Thread Adrian Turjak

On 30/08/18 6:29 AM, Lance Bragstad wrote:
>
> Is that what is being described here ? 
> 
> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>
>
> This is a separate mechanism for storing secrets, not necessarily
> passwords (although I agree the term credentials automatically makes
> people assume passwords). This is used if consuming keystone's native
> MFA implementation. For example, storing a shared secret between the
> user and keystone that is provided as a additional authentication
> method along with a username and password combination.
>  

Is there any interest or plans to potentially allow Keystone's
credential store to use Barbican as a storage provider? Encryption
already is better than nothing, but if you already have (or will be
deploying) a proper secret store with a hardware backend (or at least
hardware stored encryption keys) then it might make sense to throw that
in Barbican.

Or is this also too much of a chicken/egg problem? How safe is it to
rely on Barbican availability for MFA secrets and auth?

__
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] [barbican] Keystone's use of Barbican ?

2018-08-29 Thread Lance Bragstad

On Wed, Aug 29, 2018 at 1:16 PM Waines, Greg 
wrote:

> Makes sense.
>
>
>
> So what is the recommended upstream approach for securely storing user
> passwords in keystone ?
>

Keystone will hash passwords before persisting them in their own table.
Encrypted passwords are never stored.


>
>
> Is that what is being described here ?
> https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html
>

This is a separate mechanism for storing secrets, not necessarily passwords
(although I agree the term credentials automatically makes people assume
passwords). This is used if consuming keystone's native MFA implementation.
For example, storing a shared secret between the user and keystone that is
provided as a additional authentication method along with a username and
password combination.


>
>
>
>
> Greg.
>
>
>
>
>
> *From: *Juan Antonio Osorio Robles 
> *Reply-To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Date: *Wednesday, August 29, 2018 at 2:00 PM
> *To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [keystone] [barbican] Keystone's use of
> Barbican ?
>
>
>
> This is not the case. Barbican requires users and systems that use it to
> use keystone for authentication. So keystone can't use Barbican for this.
> Chicken and egg problem.
>
>
>
> On 08/29/2018 08:08 PM, Waines, Greg wrote:
>
> My understanding is that Keystone can be configured to use Barbican to
> securely store user passwords.
>
> Is this true ?
>
>
>
> If yes, is this the standard / recommended / upstream way to securely
> store Keystone user passwords ?
>
>
>
> If yes, I can’t find any descriptions of this is configured ?
>
> Can someone provide some pointers ?
>
>
>
> Greg.
>
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?

2018-08-29 Thread Waines, Greg

Makes sense.

So what is the recommended upstream approach for securely storing user 
passwords in keystone ?

Is that what is being described here ?  
https://docs.openstack.org/keystone/pike/admin/identity-credential-encryption.html


Greg.


From: Juan Antonio Osorio Robles 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Wednesday, August 29, 2018 at 2:00 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [keystone] [barbican] Keystone's use of Barbican ?


This is not the case. Barbican requires users and systems that use it to use 
keystone for authentication. So keystone can't use Barbican for this. Chicken 
and egg problem.

On 08/29/2018 08:08 PM, Waines, Greg wrote:
My understanding is that Keystone can be configured to use Barbican to securely 
store user passwords.
Is this true ?

If yes, is this the standard / recommended / upstream way to securely store 
Keystone user passwords ?

If yes, I can’t find any descriptions of this is configured ?
Can someone provide some pointers ?

Greg.




__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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] [barbican] Keystone's use of Barbican ?

2018-08-29 Thread Juan Antonio Osorio Robles

This is not the case. Barbican requires users and systems that use it to
use keystone for authentication. So keystone can't use Barbican for
this. Chicken and egg problem.


On 08/29/2018 08:08 PM, Waines, Greg wrote:
>
> My understanding is that Keystone can be configured to use Barbican to
> securely store user passwords.
>
> Is this true ?
>
>  
>
> If yes, is this the standard / recommended / upstream way to securely
> store Keystone user passwords ?
>
>  
>
> If yes, I can’t find any descriptions of this is configured ?
>
> Can someone provide some pointers ?
>
>  
>
> Greg.
>
>
>
> __
> 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] [barbican] Keystone's use of Barbican ?

2018-08-29 Thread Waines, Greg

My understanding is that Keystone can be configured to use Barbican to securely 
store user passwords.
Is this true ?

If yes, is this the standard / recommended / upstream way to securely store 
Keystone user passwords ?

If yes, I can’t find any descriptions of this is configured ?
Can someone provide some pointers ?

Greg.
__
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] Stein PTG Schedule

2018-08-27 Thread Lance Bragstad

I've worked through the list of topics and organized them into a rough
schedule [0]. As it stands right now, Monday is going to be the main
cross-project day (similar to the identity-integration track in Dublin).
We don't have a room on Tuesday and Wednesday, but we will likely have
continued cross-project discussions around federation. Thursday and
Friday are currently staged for keystone-specific topics.

If you see any conflicts or issues with what is proposed, please let me
know.

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



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 6 August 2018

2018-08-24 Thread Lance Bragstad



On 08/22/2018 07:49 AM, Lance Bragstad wrote:
>
> On 08/22/2018 03:23 AM, Adrian Turjak wrote:
>> Bah! I saw this while on holiday and didn't get a chance to respond,
>> sorry for being late to the conversation.
>>
>> On 11/08/18 3:46 AM, Colleen Murphy wrote:
>>> ### 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
>> As you can probably expect, I'd love to be a part of any of these
>> discussions. Anything I can nicely move to being logic directly
>> supported in Keystone, the less I need to do in Adjutant. The majority
>> of things though I think I can do reasonably well with the primitives
>> Keystone gives me, and what I can't I tend to try and work with upstream
>> to fill the gaps.
>>
>> System vs project scope helps a lot though, and I look forward to really
>> playing with that.
> Since it made sense to queue incorporating system scope after the flask
> work, I just started working with that on the credentials API*. There is
> a WIP series up for review that attempts to do a couple things [0].
> First it tries to incorporate system and project scope checking into the
> API. Second it tries to be more explicit about protection test cases,
> which I think is going to be important since we're adding another scope
> type. We also support three different roles now and it would be nice to
> clearly see who can do what in each case with tests.
>
> I'd be curious to get your feedback here if you have any.
>
> * Because the credentials API was already moved to flask and has room
> for self-service improvements [1]
>
> [0] https://review.openstack.org/#/c/594547/

This should be passing tests at least now, but there are still some
tests left to write. Most of what's in the patch is testing the new
authorization scope (e.g. system).

I'm currently taking advice on ways to extensively test six different
personas without duplication running rampant across test cases (project
admin, project member, project reader, system admin, system member,
system reader).

In summary, it does make the credential API much more self-service
oriented, which is something we should try and do everywhere (I picked
credentials first because it was already moved to flask).

> [1]
> https://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/credential.py#n21
>
>> I sadly won't be at the PTG, but will be at the Berlin summit. Plus I
>> have a lot of Adjutant work planned for Stein, a large chunk of which is
>> refactors and reshuffling blueprints and writing up a roadmap, plus some
>> better entry point tasks for new contributors.
>>
>>> ### 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] 
>>>

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 20 August 2018

2018-08-24 Thread Lance Bragstad



On 08/24/2018 10:15 AM, Colleen Murphy wrote:
> # 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!

++

I can't say thanks enough to everyone who contributes to this in some
way, shape, or form. I'm looking forward to Stein :)

>
> ## 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




signature.asc
Description: OpenPGP digital 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 20 August 2018

2018-08-24 Thread 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 14.0.0.0rc2 (rocky)

2018-08-24 Thread no-reply


Hello everyone,

A new release candidate for keystone for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/keystone/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

https://git.openstack.org/cgit/openstack/keystone/log/?h=stable/rocky

Release notes for keystone can be found at:

https://docs.openstack.org/releasenotes/keystone/




__
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

2018-08-22 Thread Lance Bragstad



On 08/22/2018 03:23 AM, Adrian Turjak wrote:
> Bah! I saw this while on holiday and didn't get a chance to respond,
> sorry for being late to the conversation.
>
> On 11/08/18 3:46 AM, Colleen Murphy wrote:
>> ### 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
> As you can probably expect, I'd love to be a part of any of these
> discussions. Anything I can nicely move to being logic directly
> supported in Keystone, the less I need to do in Adjutant. The majority
> of things though I think I can do reasonably well with the primitives
> Keystone gives me, and what I can't I tend to try and work with upstream
> to fill the gaps.
>
> System vs project scope helps a lot though, and I look forward to really
> playing with that.

Since it made sense to queue incorporating system scope after the flask
work, I just started working with that on the credentials API*. There is
a WIP series up for review that attempts to do a couple things [0].
First it tries to incorporate system and project scope checking into the
API. Second it tries to be more explicit about protection test cases,
which I think is going to be important since we're adding another scope
type. We also support three different roles now and it would be nice to
clearly see who can do what in each case with tests.

I'd be curious to get your feedback here if you have any.

* Because the credentials API was already moved to flask and has room
for self-service improvements [1]

[0] https://review.openstack.org/#/c/594547/
[1]
https://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/credential.py#n21

>
> I sadly won't be at the PTG, but will be at the Berlin summit. Plus I
> have a lot of Adjutant work planned for Stein, a large chunk of which is
> refactors and reshuffling blueprints and writing up a roadmap, plus some
> better entry point tasks for new contributors.
>
>> ### 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
> This one is interesting because another department at Catalyst is
> actually looking to use Keystone outside of the scope of OpenStack. They
> are building a SaaS platform, and they need authn, authz (with some
> basic RBAC), a service catalog (think API endpoint per software
> offering), and most of those things are useful outside of OpenStack.
> They can then use projects to signify a customer, and a project
> (customer) could have one or more users accessing the management GUIs,
> with roles giving them some RBAC. A large part of this is because they
> can then also piggy back on a lot of work our team has done with
> OpenStack and Keystone and even reuse some of our

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 6 August 2018

2018-08-22 Thread Adrian Turjak

Bah! I saw this while on holiday and didn't get a chance to respond,
sorry for being late to the conversation.

On 11/08/18 3:46 AM, Colleen Murphy wrote:
> ### 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

As you can probably expect, I'd love to be a part of any of these
discussions. Anything I can nicely move to being logic directly
supported in Keystone, the less I need to do in Adjutant. The majority
of things though I think I can do reasonably well with the primitives
Keystone gives me, and what I can't I tend to try and work with upstream
to fill the gaps.

System vs project scope helps a lot though, and I look forward to really
playing with that.

I sadly won't be at the PTG, but will be at the Berlin summit. Plus I
have a lot of Adjutant work planned for Stein, a large chunk of which is
refactors and reshuffling blueprints and writing up a roadmap, plus some
better entry point tasks for new contributors.

> ### 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

This one is interesting because another department at Catalyst is
actually looking to use Keystone outside of the scope of OpenStack. They
are building a SaaS platform, and they need authn, authz (with some
basic RBAC), a service catalog (think API endpoint per software
offering), and most of those things are useful outside of OpenStack.
They can then use projects to signify a customer, and a project
(customer) could have one or more users accessing the management GUIs,
with roles giving them some RBAC. A large part of this is because they
can then also piggy back on a lot of work our team has done with
OpenStack and Keystone and even reuse some of our projects and tools for
billing and other things (Adjutant maybe?). They could use KeystoneAuth
for CLI and client tools, they can build their APIs using
Keystonemiddleware.

Then another reason why this actually interests the Catalyst Cloud team
is because we actually use Keystone with an SQL backend for our public
cloud, with the db in a multi-region galera cluster. Keystone is our
Idp, we don't federate it, and we now have a reasonably passable 2FA
option on it, with a better MFA option coming in Stein when I'm done
with Auth Receipts. We actually kind of like Keystone for our authn, and
because we didn't have any existing users when we first built our cloud
so using vanilla Keystone seemed like a sensible solution. We had plans
to migrate users and federate, or move to LDAP, but they never
materialized because maintaining more systems didn't make sense and did
add many useful benefits. Making Keystone a fully fledged Idp with SAML
and OpenID support would be fantastic because we could

[openstack-dev] [keystone] Keystone Team Update - Week of 13 August 2018

2018-08-17 Thread 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

2018-08-17 Thread 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

2018-08-17 Thread 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] Cross-project discussions about Keystone for Edge at the PTG

2018-08-12 Thread Ildiko Vancsa

Hi,

The Keystone, Edge Computing Group and StarlingX teams are planning to have 
follow up discussions about using Keystone in edge scenarios including 
discussing requirements, architecture options and currently ongoing activities.

If you are interested in participating you can find further information here: 
http://lists.openstack.org/pipermail/edge-computing/2018-August/000394.html

Please let me know if you have any questions.

Thanks and Best Regards,
Ildikó



__
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

2018-08-11 Thread Lance Bragstad

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
>
> ### 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:

[openstack-dev] [keystone] Keystone Team Update - Week of 6 August 2018

2018-08-10 Thread 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] [keystone][nova] Struggling with non-admin user on Queens install

2018-08-09 Thread Neil Jerram

It appears this is to do with Keystone v3-created users not having any role
assignment by default.  Big thanks to lbragstad for helping me to
understand this on IRC; he also provided this link as historical context
for this situation: https://bugs.launchpad.net/keystone/+bug/1662911.

In detail, I was creating a non-admin project and user like this:

tenant = self.keystone3.projects.create(username,
"default",

description=description,
enabled=True)
user = self.keystone3.users.create(username,
   domain="default",
   project=tenant.id,
   password=password)

With just that, that user won't be able to do anything; you need to give it
a role assignment as well, for example:

admin_role = None
for role in self.keystone3.roles.list():
_log.info("role: %r", role)
if role.name == 'admin':
admin_role = role
break
assert admin_role is not None, "Couldn't find 'admin' role"
self.keystone3.roles.grant(admin_role, user=user,
project=tenant)

I still don't have a good understanding of what 'admin' within that project
really means, or why it means that that user can then do, e.g.
nova.images.list(); but at least I have a working system again.

Regards,
 Neil


On Thu, Aug 9, 2018 at 4:42 PM Neil Jerram  wrote:

> I'd like to create a non-admin project and user that are able to do
> nova.images.list(), in a Queens install.  IIUC, all users should be able to
> do that.  I'm afraid I'm pretty lost and would appreciate any help.
>
> Define a function to test whether a particular set of credentials can do
> nova.images.list():
>
> from keystoneauth1 import identity
> from keystoneauth1 import session
> from novaclient.client import Client as NovaClient
>
> def attemp(auth):
> sess = session.Session(auth=auth)
> nova = NovaClient(2, session=sess)
> for i in nova.images.list():
> print i
>
> With an admin user, things work:
>
> >>> auth_url = "http://controller:5000/v3;
> >>> auth = identity.Password(auth_url=auth_url,
> >>>   username="admin",
> >>>   password="abcdef",
> >>>   project_name="admin",
> >>>   project_domain_id="default",
> >>>   user_domain_id="default")
> >>> attemp(auth)
> 
> 
>
> With a non-admin user with project_id specified, 401:
>
> >>> tauth = identity.Password(auth_url=auth_url,
> ...   username="tenant2",
> ...   password="password",
> ...   project_id="tenant2",
> ...   user_domain_id="default")
> >>> attemp(tauth)
> ...
> keystoneauth1.exceptions.http.Unauthorized: The request you have made
> requires authentication. (HTTP 401) (Request-ID:
> req-ed0630a4-7df0-4ba8-a4c4-de3ecb7b4d7d)
>
> With the same but without project_id, I get an empty service catalog
> instead:
>
> >>> tauth = identity.Password(auth_url=auth_url,
> ...   username="tenant2",
> ...   password="password",
> ...   #project_name="tenant2",
> ...   #project_domain_id="default",
> ...   user_domain_id="default")
> >>>
> >>> attemp(tauth)
> ...
> keystoneauth1.exceptions.catalog.EmptyCatalog: The service catalog is
> empty.
>
> Can anyone help?
>
> Regards,
>  Neil
>
>
__
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 14.0.0.0rc1 (rocky)

2018-08-09 Thread no-reply


Hello everyone,

A new release candidate for keystone for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/keystone/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/keystone/log/?h=stable/rocky

Release notes for keystone can be found at:

http://docs.openstack.org/releasenotes/keystone/




__
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] Struggling with non-admin user on Queens install

2018-08-09 Thread Neil Jerram

I'd like to create a non-admin project and user that are able to do
nova.images.list(), in a Queens install.  IIUC, all users should be able to
do that.  I'm afraid I'm pretty lost and would appreciate any help.

Define a function to test whether a particular set of credentials can do
nova.images.list():

from keystoneauth1 import identity
from keystoneauth1 import session
from novaclient.client import Client as NovaClient

def attemp(auth):
sess = session.Session(auth=auth)
nova = NovaClient(2, session=sess)
for i in nova.images.list():
print i

With an admin user, things work:

>>> auth_url = "http://controller:5000/v3;
>>> auth = identity.Password(auth_url=auth_url,
>>>   username="admin",
>>>   password="abcdef",
>>>   project_name="admin",
>>>   project_domain_id="default",
>>>   user_domain_id="default")
>>> attemp(auth)



With a non-admin user with project_id specified, 401:

>>> tauth = identity.Password(auth_url=auth_url,
...   username="tenant2",
...   password="password",
...   project_id="tenant2",
...   user_domain_id="default")
>>> attemp(tauth)
...
keystoneauth1.exceptions.http.Unauthorized: The request you have made
requires authentication. (HTTP 401) (Request-ID:
req-ed0630a4-7df0-4ba8-a4c4-de3ecb7b4d7d)

With the same but without project_id, I get an empty service catalog
instead:

>>> tauth = identity.Password(auth_url=auth_url,
...   username="tenant2",
...   password="password",
...   #project_name="tenant2",
...   #project_domain_id="default",
...   user_domain_id="default")
>>>
>>> attemp(tauth)
...
keystoneauth1.exceptions.catalog.EmptyCatalog: The service catalog is empty.

Can anyone help?

Regards,
 Neil
__
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 30 July 2018

2018-08-03 Thread Lance Bragstad

# Keystone Team Update - Week of 30 July 2018

## News

This week was relatively quiet, but we're working towards RC1 as our
next deadline.

## Recently Merged Changes

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

We merged 20 changes this week.

Mainly changes to continue moving APIs to flask and we landed a huge
token provider API refactor.

## 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.

Reminder that we're in soft string freeze and past the 3rd milestone so
prioritizing bug fixes is beneficial.

## Bugs

This week we opened 4 new bugs, closed 1, and fixed 3.

The main concern with
fixing https://bugs.launchpad.net/keystone/+bug/1778945 was that it will
impact downstream providers, hence the release note. Otherwise it's
cleaned up a ton of technical debt (I appreciate the reviews here).

## Milestone Outlook

This upcoming week is going to be RC1, which we will plan to cut by
Friday unless critical bugs emerge. We do have a list of bugs to target
to RC, but none of them are blockers. If it comes down to it, they can
likely be pushed to Stein. If you notice anything that comes up as a
release blocker, please let me know.

https://bit.ly/2MeXN0L
https://releases.openstack.org/rocky/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


signature.asc
Description: OpenPGP digital 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] Prospective RC1 Bugs

2018-08-02 Thread Lance Bragstad

Hey all,

I went through all bugs opened during the Rocky release and came up with
a list of ones that might be good to fix before next week [0]. The good
news is that more than half are in progress and none of them are release
blockers, just ones that would be good to get in.

Let me know if you see anything reported this week that needs to get fixed.

[0] https://bit.ly/2MeXN0L



signature.asc
Description: OpenPGP digital 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 23 July 2018

2018-07-27 Thread Lance Bragstad

# Keystone Team Update - Week of 23 July 2018

## News

This week wrapped up rocky-3, but the majority of the things working
through review are refactors that aren't necessarily susceptible to the
deadline.

## Recently Merged Changes

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

We merged 32 changes this week, including the remaining patches for
implementing strict two-level hierarchical limits (server and client
support), Flask work, and a security fix.

## Changes that need Attention

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

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

There are still a lot of patches that need attention, specifically the
work to start converting keystone APIs to consume Flask. These changes
should be transparent to end users, but if you have questions about the
approach or specific reviews, please come ask in #openstack-keystone.
Kristi also has a patch up to implement the mutable config goal for
keystone [0]. This work was dependent on Flask bits that merged earlier
this week, but based on a discussion with the TC we've already missed
the deadline [1]. Reviews here would still be appreciated because it
should help us merge the implementation early in Stein.

[0] https://review.openstack.org/#/c/585417/
[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-07-27.log.html#t2018-07-27T15:03:49

## Bugs

This week we opened 6 new bugs and fixed 2.

The highlight here is a security bug that was fixed and backported to
all supported releases [0].

[0] https://bugs.launchpad.net/keystone/+bug/1779205

## Milestone Outlook

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

At this point we're past the third milestone, meaning requirements are
frozen and we're in a soft string freeze. Please be aware of those
things when reviewing patch sets. The next deadline for us is RC target
on August 10th.

## 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

signature.asc
Description: OpenPGP digital 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] PTL Candidacy for the Stein cycle

2018-07-26 Thread Lance Bragstad

Hey everyone,

I'm writing to submit my self-nomination as keystone's PTL for the Stein
release.

We've made significant progress tackling some of the major goals we set
for keystone in Pike. Now that we're getting close to wrapping up some
of those initiatives, I'd like to continue advocating for enhanced RBAC
and unified limits. I think we can do this specifically by using them in
keystone, where applicable, and finalize them in Stein.

While a lot of the work we tackled in Rocky was transparent to users, it
paved the way for us to make strides in other areas. We focused on
refactoring large chunks of code in order to reduce technical debt and
traded some hand-built solutions in favor of well-known frameworks. In
my opinion, these are major accomplishments that drastically simplified
keystone. Because of this, it'll be easier to implement new features we
originally slated for this release. We also took time to smooth out
usability issues with unified limits and implemented support across
clients and libraries. This is going to help services consume keystone's
unified limits implementation early next release.

Additionally, I'd like to take some time in Stein to focus on the next
set of challenges and where we'd like to take keystone in the future.
One area that we haven't really had the bandwidth to focus on is
federation. From Juno to Ocata there was a consistent development focus
on supporting federated deployments, resulting in a steady stream of
features or improvements. Conversely, I think having a break from
constant development will help us approach it with a fresh perspective.
In my opinion, federation improvements are a timely thing to work on
given the use-cases that have been cropping up in recent summits and
PTGs. Ideally, I think it would great to come up with an actionable plan
for making federation easier to use and a first-class tested citizen of
keystone.

Finally, I'll continue to place utmost importance on assisting other
services in how they consume and leverage the work we do.

Thanks for taking a moment to read what I have to say and I look forward
to catching up in Denver.

Lance



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 9 July 2018

2018-07-18 Thread Lance Bragstad



On 07/13/2018 01:33 PM, Colleen Murphy wrote:
> # 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.
I've starred some reviews that I think we should land before Thursday if
possible [0]. Eyes there would be appreciated. Morgan also reported a
bug that he is working on fixing in keystonemiddleware that we should
try an include as well [1]. I'll add the patch to the query as soon as a
review is proposed to gerrit.

[0]
https://review.openstack.org/#/q/starredby:lbragstad%2540gmail.com+status:open
[1] https://bugs.launchpad.net/keystonemiddleware/+bug/1782404
>
> [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
>
> __
>

Re: [openstack-dev] [keystone] Feature Status and Exceptions

2018-07-16 Thread 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

Re: [openstack-dev] [keystone] Feature Status and Exceptions

2018-07-13 Thread Johannes Grassler

Hello,

On Fri, Jul 13, 2018 at 03:50:33PM -0500, Lance Bragstad wrote:
> On 07/13/2018 03:37 PM, Johannes Grassler wrote:
> > On Fri, Jul 13, 2018 at 02:19:35PM -0500, Lance Bragstad wrote:
> >> *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].
> > I was was planning to email you about that, too...I didn't have much
> > time for it lately (rushing to get a few changes in Monasca in plus a
> > whole bunch of packaging stuff) and with the deadline this close I
> > didn't see much of a chance to get anything meaningful in.
> >
> > So +1 for Stein from my side. This time I can plan for and accomodate it
> > by having less Monasca stuff on my plate...
> 
> +1
> 
> Thanks for confirming. There still seems to be quite a bit of discussion
> around the data model and layout. We can use the PTG to focus on that as
> a group if needed (and if you'll be there).

For now I'll try to remain cautiously optimistic that this discussion
can mostly be resolved by starting from the controller end and making my
way to the data model from that side, as people suggested :-)

As for the PTG: until now I was planning on skipping it. Lots of travel
already this year and I need some quiet time without jetlag to work on
the code, too...

Cheers,

Johannes



-- 
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany 

__
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

2018-07-13 Thread Lance Bragstad



On 07/13/2018 02:37 PM, Harry Rybacki wrote:
> On Fri, Jul 13, 2018 at 3:20 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.
>>
> +1 to this approach.

I've proposed a couple updates to the specification, trying to clarify
exactly what was implemented in the release [0].

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

>
>> 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.
>>
>>
>> [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
> __
> 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




signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [keystone] Feature Status and Exceptions

2018-07-13 Thread Lance Bragstad



On 07/13/2018 03:37 PM, Johannes Grassler wrote:
> Hello,
>
> On Fri, Jul 13, 2018 at 02:19:35PM -0500, Lance Bragstad wrote:
>> *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].
> I was was planning to email you about that, too...I didn't have much
> time for it lately (rushing to get a few changes in Monasca in plus a
> whole bunch of packaging stuff) and with the deadline this close I
> didn't see much of a chance to get anything meaningful in.
>
> So +1 for Stein from my side. This time I can plan for and accomodate it
> by having less Monasca stuff on my plate...

+1

Thanks for confirming. There still seems to be quite a bit of discussion
around the data model and layout. We can use the PTG to focus on that as
a group if needed (and if you'll be there).

>
> Cheers,
>
> Johannes
>




signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [keystone] Feature Status and Exceptions

2018-07-13 Thread Johannes Grassler

Hello,

On Fri, Jul 13, 2018 at 02:19:35PM -0500, Lance Bragstad wrote:
> *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].

I was was planning to email you about that, too...I didn't have much
time for it lately (rushing to get a few changes in Monasca in plus a
whole bunch of packaging stuff) and with the deadline this close I
didn't see much of a chance to get anything meaningful in.

So +1 for Stein from my side. This time I can plan for and accomodate it
by having less Monasca stuff on my plate...

Cheers,

Johannes

-- 
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany 

__
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

2018-07-13 Thread Harry Rybacki

On Fri, Jul 13, 2018 at 3:20 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.
>
+1 to this approach.

> 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.
>
>
> [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

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

2018-07-13 Thread Lance Bragstad

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.

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

2018-07-13 Thread 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] Federation testing

2018-07-11 Thread Ildiko Vancsa

Hi,

Within the Edge Computing Group we have a few people interested in Keystone 
federation testing starting with general federation and moving to edge specific 
test cases onwards.

In case you are interested in this activity, we are organizing a call for next 
Thursday to talk about basic testing in OpenStack including identifying tasks 
and volunteers to complete them. We would like to use the time to clarify 
questions about Keystone federation capabilities if there’s any.

We are also collaborating with the OPNFV Edge Cloud project for advanced test 
scenarios which we will also discuss on the call.

The call details are here: 
https://wiki.openstack.org/wiki/Edge_Computing_Group#Federation_Testing_Call

Please check out the materials on this etherpad prior to the call if you plan 
to join: https://etherpad.openstack.org/p/ECG_Keystone_Testing

Please let me know if you have any questions.

Thanks and Best Regards,
Ildikó



__
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] Stein PTG Planning Etherpad

2018-07-11 Thread Lance Bragstad

It's getting to be that time of the release (and I'm seeing other
etherpads popping up on the mailing list). I've created one specifically
for keystone [0].

Same drill as the last two PTGs. We'll start by just getting topics
written down and I'll group similar topics into buckets prior to
building a somewhat official schedule.

Please feel free to add topics you'd like to discuss at the PTG.

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



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [keystone] Adding Wangxiyuan to keystone core

2018-07-11 Thread Harry Rybacki

On Tue, Jul 10, 2018 at 6:06 PM Lance Bragstad  wrote:
>
> Hi all,
>
> Today we added Wangxiyuan to the keystone core team [0]. He's been doing
> a bunch of great work over the last couple releases and has become a
> valuable reviewer [1][2]. He's also been instrumental in pushing forward
> the unified limits work not only in keystone, but across projects.
>
> Thanks Wangxiyuan for all your help and welcome to the team!
>
+1 well deserved!

> Lance
>
> [0]
> http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-07-10-16.00.log.html#l-100
> [1] http://stackalytics.com/?module=keystone-group
> [2] http://stackalytics.com/?module=keystone-group=queens
>
> __
> 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

Harry

__
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] Adding Wangxiyuan to keystone core

2018-07-10 Thread Lance Bragstad

Hi all,

Today we added Wangxiyuan to the keystone core team [0]. He's been doing
a bunch of great work over the last couple releases and has become a
valuable reviewer [1][2]. He's also been instrumental in pushing forward
the unified limits work not only in keystone, but across projects.

Thanks Wangxiyuan for all your help and welcome to the team!

Lance

[0]
http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-07-10-16.00.log.html#l-100
[1] http://stackalytics.com/?module=keystone-group
[2] http://stackalytics.com/?module=keystone-group=queens



signature.asc
Description: OpenPGP digital 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 2 July 2018

2018-07-07 Thread 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

2018-06-29 Thread 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

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 18 June 2018

2018-06-22 Thread Eric Fried

Also:

keystoneauth1 3.9.0 was released.  Its new feature is the ability to set
raise_exc on the Adapter object so you don't have to do it per request.
Here's a patch that makes use of the feature:
https://review.openstack.org/#/c/577437/

-efried

On 06/22/2018 06:53 AM, Colleen Murphy wrote:
> # 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

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

2018-06-22 Thread 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

2018-06-15 Thread 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

Re: [openstack-dev] [keystone] Signing off

2018-06-13 Thread David Stanek

On 30-May-2018 08:45, 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!
>  

Hey Henry!

It's good to hear from you! You were always fun to work with and I got a
lot out of our chats about crazy, enterprisey things. I guess the world
with have to wait for another episode of "Stanek & Nash".

-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek

__
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 4 June 2018

2018-06-11 Thread Lance Bragstad

# Keystone Team Update - Week of 4 June 2018

## News

Sorry this didn't make it out last week.

This week we were busy wrapping up specification discussion before spec
freeze. Most of which revolved around unified limits [0]. We're also
starting to see implementations for MFA receipts [1] and application
credentials capability lists [2].

[0] https://review.openstack.org/#/c/540803/
[1] 
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:spec/auth_receipts
[2] 
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/whitelist-extension-for-app-creds

## Open Specs

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

With the last few bits for hierarchical limits addressed and the
specification merged, we don't expect to accept any more specifications
for the Rocky release.

## Recently Merged Changes

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

We merged 28 changes last week. Most of which were to move keystone off
its homegrown WSGI implementation. Converting to Flask is a pretty big
move for keystone and the team, but it reduces technical dept and will
help with maintenance costs in the future since it's one less wheel we
have to look after.

## Changes that need Attention

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

There are 50 changes that are passing CI, not in merge conflict, have no
negative reviews and aren't proposed by bots. Please take it look if you
have time to do a review or two.

## Bugs

This week we opened 7 new bugs, closed 5, and fixed 5.

Bugs opened (7)
Bug #1775094 (keystone:Medium) opened by Lance Bragstad
https://bugs.launchpad.net/keystone/+bug/1775094
Bug #1774654 (keystone:Undecided) opened by Wyllys Ingersoll
https://bugs.launchpad.net/keystone/+bug/1774654
Bug #1774688 (keystone:Undecided) opened by Lance Bragstad
https://bugs.launchpad.net/keystone/+bug/1774688
  

Bug #1775140 (keystone:Undecided) opened by Andras Kovi
https://bugs.launchpad.net/keystone/+bug/1775140
 

Bug #1775207 (keystone:Undecided) opened by Pavlo Shchelokovskyy
https://bugs.launchpad.net/keystone/+bug/1775207


Bug #1775295 (keystone:Undecided) opened by johnpham
https://bugs.launchpad.net/keystone/+bug/1775295


Bug #1774722 (oslo.config:Low) opened by Kent Wu
https://bugs.launchpad.net/oslo.config/+bug/1774722 




 

Bugs closed
(5) 

 

Bug #1578466 (keystone:Medium)
https://bugs.launchpad.net/keystone/+bug/1578466

  

Bug #1578401 (keystone:Low)
https://bugs.launchpad.net/keystone/+bug/1578401

 

Bug #1775140 (keystone:Undecided)
https://bugs.launchpad.net/keystone/+bug/1775140

   

Bug #1775295 (keystone:Undecided)
https://bugs.launchpad.net/keystone/+bug/1775295

   

Bug #1774722 (oslo.config:Low)
https://bugs.launchpad.net/oslo.config/+bug/1774722 

  



 

Bugs fixed
(5) 

  

Bug #1728907 (keystone:Low) fixed by Gage Hugo
https://bugs.launchpad.net/keystone/+bug/1728907

  

Bug #1673859 (oslo.policy:Undecided)

Re: [openstack-dev] [keystone] Signing off

2018-06-05 Thread Rodrigo Duarte

Henry,

I'm really sad to see you go, you were a terrific mentor when I first
joined the community - I remember all the thorough reviews and nice
discussions ranging from topics on how to model the root domain for the
reseller usecase to how to improve the role assignments API. :)

Thanks for everything!

On Wed, May 30, 2018 at 11:22 AM, Gage Hugo  wrote:

> It was great working with you Henry.  Hope to see you around sometime and
> wishing you all the best!
>
> On Wed, May 30, 2018 at 3: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
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Rodrigo
http://rodrigods.com
__
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] test storyboard environment

2018-06-04 Thread Lance Bragstad

Hi all,

The StoryBoard team was nice enough to migrate existing content for all
keystone-related launchpad projects to a dev environment [0]. This gives
us the opportunity to use  StoryBoard with real content.

Log in and check it out. I'm curious to know what the rest of the team
thinks.

[0] https://storyboard-dev.openstack.org/#!/project_group/46



signature.asc
Description: OpenPGP digital 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] [tripleo] multi-region Keystone via stretched Galera cluster

2018-06-04 Thread Michael Bayer

Hey list -

as mentioned in the May 11 Keystone meeting, I am working on one of
the canonical approaches to producing a multi-region Keystone service,
which is by having overcloud-specific keystone services interact with
a Galera database that is running masters across multiple overclouds.
  The work here is to be integrated into tripleo and at [1] we discuss
the production of a multi-region Keystone service, deployable across
multiple tripleo overclouds.

As the spec is being discussed I continue to work on the proof of
concept [2] which in its master branch is being developed to deploy
the second galera DB as well as haproxy/vip/keystone completely from
tripleo heat templates; the changes being patched here are to be
proposed as changes to tripleo itself once this version of the POC is
working.

The "standard_tripleo_version" branch is the previous iteration, which
provides a fully working proof of concept that adds a second Galera
instance to a pair of already deployed overclouds.

Comments on the review welcome.

[1] https://review.openstack.org/#/c/566448/

[2] https://github.com/zzzeek/stretch_cluster

__
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 28 May 2018

2018-06-01 Thread 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

[openstack-dev] [keystone] failing documentation jobs

2018-05-31 Thread Lance Bragstad

Hi all,

If you've been trying to write documentation patches, you may have
noticed them tripping over unrelated errors when building the docs. We
have a bug opened detailing why this happened [0] and a fix working its
way through the gate [1]. The docs job should be back up and running soon.

[0] https://bugs.launchpad.net/keystone/+bug/1774508
[1] https://review.openstack.org/#/c/571369/



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [keystone] Signing off

2018-05-30 Thread Gage Hugo

It was great working with you Henry.  Hope to see you around sometime and
wishing you all the best!

On Wed, May 30, 2018 at 3: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
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> __
> 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] Signing off

2018-05-30 Thread Kristi Nikolla

Thank you for all your invaluable contributions Henry. It has been a pleasure 
working with you. Best of luck!

Kristi

‐‐‐ Original Message ‐‐‐
On May 30, 2018 4: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
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU__
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

2018-05-30 Thread Harry Rybacki

On Wed, May 30, 2018 at 5:05 AM, Colleen Murphy  wrote:
> 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.
>
Hear, hear. Keystone has largely been shaped by those continual
efforts, Henry. Your face may be missed but your voice will hang
around to guide us future. Hope to run into you somewhere, sometime!

/R

> 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

Harry

__
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

2018-05-30 Thread Lance Bragstad

I remember when I first started contributing upstream, I spent a
Saturday sending you internal emails asking about the intricacies of
database migrations :)

Since then you've give me (or I've stolen) a number of other tools and
techniques. Thanks for everything you've done for this community, Henry.
It's been a pleasure!

On 05/30/2018 03: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
>  
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
> __
> 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



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [keystone] Signing off

2018-05-30 Thread 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

[openstack-dev] [keystone] Signing off

2018-05-30 Thread Henry Nash

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
 Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



__
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 dinner

2018-05-20 Thread Lance Bragstad

Alright, based on the responses it looks like Tuesday is going to be the
best option for everyone.

There was one suggestion for sushi and it looks like there are more than
a few places around. Here are the ones I've found:

http://www.momogastown.ca/menus/
http://sushiyan.ca/#/menu
http://urbansushi.com/

There is also other stuff close by like:

http://steamworks.com/brew-pub
https://www.cactusclubcafe.com/?utm_source=google-maps_medium=organic_campaign=coal-harbour

Or if you've gone to a place you'd like to recommend, suggestions are
welcome!


On 05/18/2018 08:39 AM, Lance Bragstad wrote:
> Hey all,
>
> I put together a survey to see if we can plan a night to have supper
> together [0]. I'll start parsing responses tomorrow and see what we can
> get lined up.
>
> Thanks and safe travels to Vancouver,
>
> Lance
>
> [0] https://goo.gl/forms/ogNsf9dUno8BHvqu1
>




signature.asc
Description: OpenPGP digital 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 14 May 2018

2018-05-18 Thread 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] project onboarding

2018-05-18 Thread Lance Bragstad

Hey all,

We've started an etherpad in an attempt to capture information prior to
the on-boarding session on Monday [0]. If you're looking to get
something specific out of the session, please let us know in the
etherpad [1]. This will help us come to the session prepared and make
the most of the time we have.

See you there,

Lance

[0]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21633/keystone-project-onboarding
[1] https://etherpad.openstack.org/p/YVR-rocky-keystone-project-onboarding



signature.asc
Description: OpenPGP digital 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] team dinner

2018-05-18 Thread Lance Bragstad

Hey all,

I put together a survey to see if we can plan a night to have supper
together [0]. I'll start parsing responses tomorrow and see what we can
get lined up.

Thanks and safe travels to Vancouver,

Lance

[0] https://goo.gl/forms/ogNsf9dUno8BHvqu1



signature.asc
Description: OpenPGP digital 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

Re: [openstack-dev] [keystone] keystoneauth version auto discovery for internal endpoints in queens

2018-05-12 Thread Monty Taylor


On 05/11/2018 03:37 PM, Vlad Gusev wrote:

Hello.

We faced a bug in keystoneauth, which haven't existed before Queens.


Sorry about that.

In our OpenStack deployments we use urls like http://controller:5000/v3 
for internal and admin endpoints and urls like 
https://api.example.org/identity/v3 for public endpoints.


Thank you for using suburl deployment for your public interface and not 
the silly ports!!!


We set option 
public_endpoint in [default] section of the 
keystone.conf/nova.conf/cinder.conf/glance.conf/neutron.conf. For 
example, for keystone it is 
'public_endpoint=https://api.example.org/identity/'.


Since keystoneauth 3.2.0 or commit 
https://github.com/openstack/keystoneauth/commit/8b8ff830e89923ca6862362a5d16e496a0c0093c 
all internal client requests to the internal endpoints (for example, 
openstack server list from controller node) fail with 404 error, because 
it tries to do auto discovery at the http://controller:5000/v3. It gets 
{"href": "https://api.example.org/identity/v3/;, "rel": "self"} because 
of the public_endpoint option, and then in function 
_combine_relative_url() (keystoneauth1/discover.py:405) keystoneauth 
combines http://controller:5000/ with the path from public href. So 
after auto discovery attempt it goes to the wrong path 
http://controller:5000/identity/v3/


Ok. I'm going to argue that there are bugs on both the server side AND 
in keystoneauth. I believe I know how to fix the keystoneauth one- but 
let me describe why I think the server is broken as well, and then we 
can figure out how to fix that. I'm going to describe it in slightly 
excruciating detail, just to make sure we're all on the same page about 
mechanics that may be going on behind the scenes.


The user has said:

  I want the internal interface of v3 of the identity service

First, the identity service has to be found in the catalog. Looking in 
the catalog, we find this:


  {
"endpoints": [
  {
"id": "4deb4d0504a044a395d4480741ba628c",
"interface": "public",
"region": "RegionOne",
"url": "https://api.example.com/identity;
  },
  {
"id": "012322eeedcd459edabb4933021112bc",
"interface": "internal",
"region": "RegionOne",
"url": "http://controller:5000/v3;
  }
],
"name": "keystone",
"type": "identity"
  },

We've found the entry for 'identity' service, and looking at the 
endpoints we see that the internal endpoint is:


  http://controller:5000/v3

The next step is version discovery, because the user wants version 3 of 
the api. (I'm skipping possible optimizations that can be applied on 
purpose)


To do version discovery, one does a GET on the endpoint found in the 
catalog, so GET http://controller:5000/v3. That returns:


{
  "versions": {
"values": [
  {
"status": "stable",
"updated": "2016-04-04T00:00:00Z",
"media-types": [
  {
"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"
  }
],
"id": "v3.6",
"links": [
  {
"href": "https://api.example.com/identity/v3/;,
"rel": "self"
  }
]
  }
]
  }
}

Here is the server-side bug. A GET on the discovery document on the 
internal endpoint returned an endpoint for the public interface. That is 
incorrect information. GET http://controller:5000/v3 should return either:


{
  "versions": {
"values": [
  {
"status": "stable",
"updated": "2016-04-04T00:00:00Z",
"media-types": [
  {
"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"
  }
],
"id": "v3.6",
"links": [
  {
"href": "http://controller:5000/v3/;,
"rel": "self"
  }
]
  }
]
  }
}

or

{
  "versions": {
"values": [
  {
"status": "stable",
"updated": "2016-04-04T00:00:00Z",
"media-types": [
  {
"base": "application/json",
"type": "application/vnd.openstack.identity-v3+json"
  }
],
"id": "v3.6",
"links": [
  {
"href": "/v3/",
"rel": "self"
  }
]
  }
]
  }
}

That's because the discovery documents are maps to what the user wants. 
The user needs to be able to follow them automatically.


NOW - there is also a keystoneauth bug in play here that combined with 
this server-side bug have produced the issue you have.


That is in the way we do the catalog / discovery URL join.

First of all - we do the catalog / discovery URL join because of a 
frequently occuring deployment bug in the other direction. That is, it 
is an EXTREMELY common misconfiguration for the discovery url to return 
the internal url (this is what happens if

Re: [openstack-dev] [keystone] keystoneauth version auto discovery for internal endpoints in queens

2018-05-11 Thread Morgan Fainberg

Typically speaking if we broke a behavior via a change in KeystoneAuth
(not some behavior change in openstackclient or the way osc processes
requests), we are in the wrong and we will need to go back through and
fix the previous behavior.

I'll spend some time going through this to verify if this really is a
KSA change bug or something else. If it is in-fact a KSA
(keystoneauth) bug, we'll work to restore the previous behavior(s) as
reasonably quickly as possible.

Cheers,
--Morgan

On Fri, May 11, 2018 at 1:37 PM, Vlad Gusev  wrote:
> Hello.
>
> We faced a bug in keystoneauth, which haven't existed before Queens.
>
> In our OpenStack deployments we use urls like http://controller:5000/v3 for
> internal and admin endpoints and urls like
> https://api.example.org/identity/v3 for public endpoints. We set option
> public_endpoint in [default] section of the
> keystone.conf/nova.conf/cinder.conf/glance.conf/neutron.conf. For example,
> for keystone it is 'public_endpoint=https://api.example.org/identity/'.
>
> Since keystoneauth 3.2.0 or commit
> https://github.com/openstack/keystoneauth/commit/8b8ff830e89923ca6862362a5d16e496a0c0093c
> all internal client requests to the internal endpoints (for example,
> openstack server list from controller node) fail with 404 error, because it
> tries to do auto discovery at the http://controller:5000/v3. It gets
> {"href": "https://api.example.org/identity/v3/;, "rel": "self"} because of
> the public_endpoint option, and then in function _combine_relative_url()
> (keystoneauth1/discover.py:405) keystoneauth combines
> http://controller:5000/ with the path from public href. So after auto
> discovery attempt it goes to the wrong path
> http://controller:5000/identity/v3/
>
> Before this commit openstackclient made auth request to the
> https://api.example.org/identity/v3/auth/tokens (and it worked, because in
> our deployment internal services and console clients can access this public
> url). At best, we expect openstackclient always go to the
> http://controller:5000/v3/
>
> This problem partially could be solved by explicitly passing public
> --os-auth-url https://api.example.org/identity/identity/v3 to the console
> clients even if we want to use internal endpoints.
>
> I found similiar bug in launchpad, but it haven't received any attention:
> https://bugs.launchpad.net/keystoneauth/+bug/1733052
>
> What could be done with this behavior of keystoneauth auto discovery?
>
> - Vlad
>
> __
> 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] keystoneauth version auto discovery for internal endpoints in queens

2018-05-11 Thread Vlad Gusev

Hello.

We faced a bug in keystoneauth, which haven't existed before Queens.

In our OpenStack deployments we use urls like http://controller:5000/v3 for
internal and admin endpoints and urls like
https://api.example.org/identity/v3 for public endpoints. We set option
public_endpoint in [default] section of the
keystone.conf/nova.conf/cinder.conf/glance.conf/neutron.conf. For example,
for keystone it is 'public_endpoint=https://api.example.org/identity/'.

Since keystoneauth 3.2.0 or commit
https://github.com/openstack/keystoneauth/commit/8b8ff830e89923ca6862362a5d16e496a0c0093c
all internal client requests to the internal endpoints (for example,
openstack server list from controller node) fail with 404 error, because it
tries to do auto discovery at the http://controller:5000/v3. It gets
{"href": "https://api.example.org/identity/v3/;, "rel": "self"} because of
the public_endpoint option, and then in function _combine_relative_url()
(keystoneauth1/discover.py:405) keystoneauth combines
http://controller:5000/ with the path from public href. So after auto
discovery attempt it goes to the wrong path
http://controller:5000/identity/v3/

Before this commit openstackclient made auth request to the
https://api.example.org/identity/v3/auth/tokens (and it worked, because in
our deployment internal services and console clients can access this public
url). At best, we expect openstackclient always go to the
http://controller:5000/v3/

This problem partially could be solved by explicitly passing public
--os-auth-url https://api.example.org/identity/identity/v3 to the console
clients even if we want to use internal endpoints.

I found similiar bug in launchpad, but it haven't received any attention:
https://bugs.launchpad.net/keystoneauth/+bug/1733052

What could be done with this behavior of keystoneauth auto discovery?

- Vlad
__
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

2018-05-11 Thread 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

Re: [openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

2018-05-08 Thread Eric K

Thank you, Zane for the discussion.

Point taken about sending webhook notifications.

Primarily I want Congress to consume webhook notifications from the
openstack services which already send them (monasca, vitrage, etc.). Most
of them do not currently support sending appropriate keystone tokens with
the notifications, but some are open to doing it.

The aodh and zaqar references are exactly what I was hoping to find. I
couldn't find a reference to it in aodh docs or much on google, so many
thanks for the pointer!

Eric

On 5/8/18, 1:20 PM, "Zane Bitter"  wrote:
>If the caller is something that is basically trusted, then you should
>prefer regular keystone auth. If you need to make sure that the caller
>can only use that one API, signed URLs are still the only game in town
>for now (but we hope this is very temporary).
>
>> I know some people are working on adding the keystone auth option to
>> Monasca's webhook framework. If there is a project that already does it,
>> it could be a very helpful reference.
>
>There's a sort of convention that where you supply a webhook URL with a
>scheme trust+https:// then the service creates a keystone trust and uses
>that to get keystone tokens which are then used to authenticate the
>webhook request. Aodh and Zaqar at least follow this convention. The
>trust part is an important point that you're overlooking: (from your
>other message)

__
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][monasca][congress][senlin][telemetry] authenticated webhook notifications

2018-05-08 Thread Zane Bitter

On 03/05/18 15:49, Eric K wrote:

Question to the projects which send or consume webhook notifications
(telemetry, monasca, senlin, vitrage, etc.), what are your
supported/preferred authentication mechanisms? Bearer token (e.g.
Keystone)? Signing?

Signed URLs and regular Keystone auth are both options, and both used in
various places as Thomas said. Any time you can not implement your own
signed URL thing, it's better that you don't though. Security-sensitive
things like authentication should be implemented as few times as possible.

Eventually we should be able to mostly eliminate the need for signed
URLs with
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/capabilities-app-creds.html
but we're not there yet.

If the caller is something that is basically trusted, then you should
prefer regular keystone auth. If you need to make sure that the caller
can only use that one API, signed URLs are still the only game in town
for now (but we hope this is very temporary).

Any pointers to past discussions on the topic? My interest here is having
Congress consume and send webhook notifications.

Please don't.

Webhooks are a security nightmare. They can be used to enlist the
OpenStack infrastructure in mounting attacks on other random sites, or
to attack the OpenStack operator themselves if everything is not
properly secured.

Ideally there should be only one place in OpenStack that can send
webhooks, so that there's only one thing for operators to secure. (IMHO
since that thing will need to keep a queue of pending webhooks to send,
the logical place would be Zaqar notifications.) Obviously that's not
the case today - we already send webhooks from Aodh, Mistral, Zaqar and
others. But at least we can avoid adding more.

I know some people are working on adding the keystone auth option to
Monasca's webhook framework. If there is a project that already does it,
it could be a very helpful reference.

There's a sort of convention that where you supply a webhook URL with a
scheme trust+https:// then the service creates a keystone trust and uses
that to get keystone tokens which are then used to authenticate the
webhook request. Aodh and Zaqar at least follow this convention. The
trust part is an important point that you're overlooking: (from your
other message)

I'm thinking about the situation where the sending service can obtain
tokens directly from keystone.

If you haven't stored the user's password then you cannot, in fact,
obtain more tokens from keystone. You only have the one they gave you
with the initial request, and that will soon expire. So you have to
create a trust (which doesn't expire) and store the trust ID, which you
can then use in combination with the service token to get additional
user tokens from when required.

Don't do that though. Just create a Zaqar queue, store a pre-signed URL
that allows you to post to it, and set up a Zaqar notification for the
webhook URL you want to hit (which can be a trust+https:// URL). Avoid
being the next project to reinvent the wheel :)

cheers,
Zane.

Re: [openstack-dev] [keystone][monasca][congress][senlin][telemetry] authenticated webhook notifications

2018-05-08 Thread Eric K

To clarify, one of the reasons I'd like to accept webhook notifications
authenticated with keystone tokens is that I don't want the access to
expire, but of course it's poor practice to use a signed URL that never
expires.

Eric

On 5/8/18, 12:29 PM, "Eric K"  wrote:

>Thanks, Thomas!
>
>I see the point that it is impractical to configure a service with a fixed
>keystone token to use in webhook notifications because they expire fairly
>quickly.
>
>I'm thinking about the situation where the sending service can obtain
>tokens directly from keystone. In that case I'm guessing the main reason
>it hasn't been done that way is because it does not generalize to most
>other services that don't connect to keystone?
>
>On 5/6/18, 9:30 AM, "Thomas Herve"  wrote:
>
>>On Sat, May 5, 2018 at 1:53 AM, Eric K  wrote:
>>> Thanks a lot Witold and Thomas!
>>>
>>> So it doesn't seem that someone is currently using a keystone token to
>>> authenticate web hook? Is is simply because most of the use cases had
>>> involved services which do not use keystone?
>>>
>>> Or is it unsuitable for another reason?
>>
>>It's fairly impractical for webhooks because
>>
>>1) Tokens expire fairly quickly.
>>2) You can't store all the data in the URL, so you need to store the
>>token and the URL separately.
>>
>>-- 
>>Thomas
>>
>>_
>>_
>>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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 2755 matches

Mail list logo