Hi,
> It sounds like we all agree -- the client we ship should default to a fixed,
> older version. Anyone who wants newer functionality can pass a newer version
> to their client.
>
> Here's the current state of things:
>
> server:
> - stable/kilo: 1.6
> - current: 1.11
>
> client:
> - stable/kil
Hi Marek
Thanks for the clear exposition.
To answer your question Why are you interested in such a feature? is
that it seemed to be the logical thing to do. A user is identified by a
set of identity attributes (by the IdP) and these are mapped into
permission by mapping ru
Hi Everyone
I have a student building a GUI for federated login with Horizon. The
interface supports both a drop down list of configured IDPs, and also
Type Ahead for massive federations with hundreds of IdPs. Screenshots
are visible in InVision here
https://invis.io/HQ3QN2123
All comments on th
> I know that with Keystone we needed to run with standard threads, not
> eventlet greenthreads in order to get step by step debugging.
> I've been mostly working with RPD, and that has worked well for me. I
> used PyCHarm for a bout a year, but did not renew it, as it doesn't
> really buy me t
I suggest to use pacemaker multistate clone resource to rotate and rsync fernet
tokens from local directories across cluster nodes. The resource prototype is
described here https://etherpad.openstack.org/p/fernet_tokens_pacemaker
Pros: Pacemaker will care about CAP/split-brain stuff for us, we ju
Meta: Bogdan, please do try to get your email client to reply with references
to the thread, so it doesn't create a new thread.
Excerpts from bdobrelia's message of 2015-08-01 09:27:17 -0700:
> I suggest to use pacemaker multistate clone resource to rotate and rsync
> fernet tokens from local dir
Thanks gord. I will enable "store_events" and see if neutron related
meters/state events are appearing under "ceilometer events-list"
Thanks
Srikanth
-Original Message-
From: gord chung [mailto:[email protected]]
Sent: Thursday, July 30, 2015 2:05 PM
To: [email protected]
Sub
On Saturday 01 August 2015 16:27:17 [email protected] wrote:
> I suggest to use pacemaker multistate clone resource to rotate and
rsync
> fernet tokens from local directories across cluster nodes. The resource
> prototype is described here
> https://etherpad.openstack.org/p/fernet_tokens_pace
Excerpts from Boris Bobrov's message of 2015-08-01 14:18:21 -0700:
> On Saturday 01 August 2015 16:27:17 [email protected] wrote:
> > I suggest to use pacemaker multistate clone resource to rotate and
> rsync
> > fernet tokens from local directories across cluster nodes. The resource
> > prot
Agree that you guys are way over thinking this. You don't need to rotate
keys at exactly the same time, we do it in within a one or two hours
typically based on how our regions are setup. We do it with puppet, puppet
runs on one keystone node at a time and drops the keys into place. The
actual rota
On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum wrote:
> This too is overly complex and will cause failures. If you replace key 0,
> you will stop validating tokens that were encrypted with the old key 0.
No. Key 0 is replaced after rotation.
Also, come on, does http://paste.openstack.org/show/40667
Hi Jordan,
Thanks for pointing this up:-)
Your point is right for current nova situation.
Nova API continues changing with small steps. The kwargs changes of tempest
will help us to avoid a lot of changes in long-term.
I also am happy if getting opinions from the others.
Thanks for your help and
On 09/07/15 20:37 +0200, Flavio Percoco wrote:
Greetings,
I'd like to propose Stuart Mclaren for the glance-drivers team. Stuart
has a huge amount of knowledge about Glance's history, he knows the
Glance codebase well and he also has experience in deploying and
maintaning Glance production envir
>From Operators point of view i'd love to see less technology proliferation
in OpenStack, if you wear the developer hat please don't be selfish, take
into account the others :)
ZK is a robust technology but hey is a beast like Rabbit, there is a lot to
massage and over 2 data centers ZK is not ver
Daniel Comnea wrote:
From Operators point of view i'd love to see less technology
proliferation in OpenStack, if you wear the developer hat please don't
be selfish, take into account the others :)
ZK is a robust technology but hey is a beast like Rabbit, there is a lot
to massage and over 2 dat
15 matches
Mail list logo
