# 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://governan
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 f
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]
*Wednesda
# 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] a
# 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-fir
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 gui
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 i
# 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
# 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/%23open
n 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
>
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
>
> 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:
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: Key
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 u
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/b
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.or
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.
>
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/l
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 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 de
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
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
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
speci
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
# 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 brains
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 improve
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 u
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 g
# 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
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 c
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
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
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-encryp
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 cred
;
>
>
>
>
> *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"
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 us
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
> secu
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 pr
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
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
>>>
>>
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
# 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 cre
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 forma
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-servi
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, po
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/ke
# 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 cha
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
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 info
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 R
# 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-key
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
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 forma
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.l
# 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 land
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 s
# 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
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
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.open
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
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,
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 mov
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
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 ha
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 w
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
# 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
### Rel
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 testin
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
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 uni
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
# 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
# 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
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
# 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 boots
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 d
# 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 appl
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 every
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] htt
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 wo
# 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 (
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]
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 t
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 keyst
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 ha
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, Henr
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 sinc
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
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://urbansus
# 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
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 ti
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 digita
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
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 r
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] s
# 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
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 w
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 o
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
1 - 100 of 2948 matches
Mail list logo