Hi Abel,
For Keystone we already have a way to prune out expired records:
keystone-manage token_flush
This can be run via cron (recommended). The reason for the side band tool is
that keystone does not have an internal scheduler for periodic tasks (not a
common use keystone needs to do across
e LDAP Assignment
backend which only contains Projects/Tenants and Roles/Grants.
Cheers,
Morgan Fainberg
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
As a note, since I've seen some responses about users and/or groups on this
survey, I will be sending a survey about identity out today. This survey is
strictly about projects/tenants and roles/role assignments in LDAP.
Sent via mobile
> On Jan 6, 2015, at 11:22, Morgan Fainber
The Keystone development team is looking for deployment feedback regarding the
use of the LDAP Identity backend. The Identity backend only covers Users and
Groups.
We are looking to get an idea of types (read-only, read-write, etc) and reasons
for use of the LDAP backend. The answers to this su
ading through the whole email! Please feel free to chat with the
development team on IRC or via the Mailing List to discuss any other issues /
concerns related to this change.
Cheers,
Morgan Fainberg
Keystone PTL
___
OpenStack-operators mailing list
Open
From an operator perspective I wanted to get input on the SQL Schema Downgrades.
Today most projects (all?) provide a way to downgrade the SQL Schemas after
you’ve upgraded. Example would be moving from Juno to Kilo and then back to
Juno. There are some odd concepts when handling a SQL migration
I think the simple answer is "yes". We (keystone) should emit notifications.
And yes other projects should listen.
The only thing really in discussion should be:
1: soft delete or hard delete? Does the service mark it as orphaned, or just
delete (leave this to nova, cinder, etc to discuss)
2:
On February 2, 2015 at 1:31:14 PM, Joe Gordon (joe.gord...@gmail.com) wrote:
On Mon, Feb 2, 2015 at 10:28 AM, Morgan Fainberg
wrote:
I think the simple answer is "yes". We (keystone) should emit notifications.
And yes other projects should listen.
The only thing really in discuss
As a follow up on this topic, the specification for this change has been
proposed to the openstack-specs (cross-project) specifications repository:
https://review.openstack.org/#/c/152337/
Feedback from the operators would be greatly appreciated.
—Morgan
--
Morgan Fainberg
On January 30
The Keystone development team is planning to deprecate deployment of Keystone
under Eventlet during the Kilo cycle. Support for deploying under eventlet will
be dropped as of the “M”-release of OpenStack.
The reasoning behind this move is multifaceted but the core of the reasons are
as follows:
This sounds like something we can bake into the session object to make it
easier / more consistent.
--Morgan
Sent via mobile
> On Mar 25, 2015, at 14:03, John Dewey wrote:
>
> I faced this very issue in the past. We solved the problem by adding the CA
> to the system bundle (as you stated)
it, and explaining what you just said here:
>>
>> https://blueprints.launchpad.net/keystone
>
> Adding a blueprint for discussion would be a good idea if you think you want
> a change to the project.
>
>
>>
>> I’d also try to contact Keystone PTL (I’m not
gt; 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
>
> On Fri, May 1, 2015 at 12:22 PM, Morgan Fainberg <
> morgan.fainb...@gmail.com> wr
13 matches
Mail list logo
