names to appear in the 'groups'
mapping rule (although I don't think this feature is documented in our
mapping rules documentation). The receiver (our mapping engine) has
hard-coded logic to look for a list of names.
[2] We might want to prepend a format specifier to string containing
complex data, e.g. "JSON:{json object}". Our parser could then look for
a leading format tag and if if finds one strip it off and pass the rest
of the string into the proper parser.
--
John Dennis
__
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
ed an understanding of the code.
Please respond with +1 or any concerns you may have. Thanks.
+1
--
John Dennis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
addition to the
oslo.config review team.
Please indicate your approval or concerns with +1/-1.
+1
--
John Dennis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
s more important to keep the code base clean
and consistent for those that follow than it is to coddle in the near term.
--
John Dennis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
On 04/04/2018 02:52 AM, 何健乐 wrote:
Hi all,
Could keystone to keystone federation be deployed on Centos. I have
notice all the document was deployment on Ubuntu. If could, is there
some documents that is about deploying k2k on centos.
Yes k2k should work on centos, there is nothing OS specifi
On 10/02/2017 10:13 PM, Jamie Lennox wrote:
Hi All,
I'm really sad to announce that I'll be leaving the OpenStack community
(at least for a while), I've accepted a new position unrelated to
OpenStack that'll begin in a few weeks, and am going to be mostly on
holiday until then.
It's a shame
The existing documentation on setting up mod_auth_mellon
(https://docs.openstack.org/keystone/latest/advanced-topics/federation/mellon.html)
is sparse.
Our experience with using mod_auth_mellon either in the context of
OpenStack federation or simply as a SAML SP working in conjunction with
an
On 08/07/2016 11:16 PM, Adam Young wrote:
On 08/06/2016 08:44 AM, John Dennis wrote:
On 08/05/2016 06:06 PM, Adam Young wrote:
Ah...just noticed the redirect is to :5000, not port :13000 which is
the HA Proxy port.
OK, this is due to the SAML request:
https://identity.ayoung-dell-t1700
On 08/05/2016 06:06 PM, Adam Young wrote:
Ah...just noticed the redirect is to :5000, not port :13000 which is
the HA Proxy port.
OK, this is due to the SAML request:
https://identity.ayoung-dell-t1700.test/auth/realms/openstack/protocol/saml";
Consent="urn:oasis:names:tc
On 06/21/2016 10:55 AM, Ian Cordasco wrote:
-Original Message-
From: Adam Young
Reply: OpenStack Development Mailing List (not for usage questions)
Date: June 21, 2016 at 09:40:39
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Tripleo] X509 Management
When deployin
On 04/18/2016 12:34 PM, Martin Millnert wrote:
(** ECP is a new feature, not supported by all IdP's, that at (second)
best requires reconfiguration of core authentication services at each
customer, and at worst requires customers to change IdP software
completely. This is a varying degree of show
On 10/14/2015 11:58 AM, Marek Denis wrote:
pretty much - yes! Luckily for you the reference libraries (shibboleth)
are written in Java so it should be easier to integrate with your
application.
Only the Shibboleth IdP is written in Java. Shibboleth the SP is written
in C++. If you're trying to
On 10/14/2015 07:10 AM, wyw wrote:
hello, keystoners. please help me
Here is my use case:
1. use keystone as IDP , supported with SAML
2. keystone integrates with LDAP
3. we use a java application as Service Provider, and to integrate it
with keystone IDP.
4. we use a keystone as Service Provid
On 09/01/2015 10:57 AM, Clark, Robert Graham wrote:
The reason that is compelling is that you can have Barbican generate,
sign, and store a keypair without transmitting the private key over the
network to the client that originates the signing request. It can be
directly stored, and made availa
On 09/01/2015 02:49 AM, Tim Bell wrote:
Will it also be possible to use a different CA ? In some
environments, there is already a corporate certificate authority
server. This would ensure compliance with site security standards.
A configurable CA was one of the original design goals when the Ba
On 08/21/2015 05:10 AM, Stanislaw Bogatkin wrote:
Hi folks.
Today I want to discuss the way we save SSL keys for Fuel environments.
As you maybe know we have 2 ways to get a key:
a. Generate it by Fuel (self-signed certificate will be created in this
case). In this case we will generate private
On 06/11/2015 01:46 PM, Mike Bayer wrote:
I am firmly in the "let's use items()" camp. A 100 ms difference for
a totally not-real-world case of a dictionary 1M items in size is no
kind of rationale for the Openstack project - if someone has a
dictionary that's 1M objects in size, or even 100K,
On 05/12/2015 08:47 AM, Clint Byrum wrote:
> I agree with all the things above, and I want to add that I think SVG
> is probably the most appropriate candidate as a W3C approved drawing
> format. We can even enforce style rules and use a reformatter so that
> diffs make sense.
+1 for SVG
As alrea
Can't this be solved with a couple of environment variables? The two
keys pieces of information needed are:
1) who authenticated the subject?
2) what authentication method was used?
There is already precedence for AUTH_TYPE, it's used in AJP to
initialize the authType property in a Java Servelet
On 11/04/2014 04:19 PM, David Stanek wrote:
> There are probably a few other assumptions, but the main one is that the
> mapper expects the incoming data to be a dictionary where the value is a
> string. If there are multiple values we expect them to be delimited with
> a semicolon in the string.
On 11/04/2014 02:46 AM, David Chadwick wrote:
> Hi John
Good morning David. I hope you're enjoying Paris and the summit is both
productive and enjoyable. Wish I was there :-)
> Its seems like your objective is somewhat different to what was intended
> with the current mapping rules. You seem to w
On 11/03/2014 08:50 AM, John Dennis wrote:
> I had a bunch of notes but I can't find them at the moment
> so I'm going from memory here (always a bit risky).
I found my notes, attached is an reStructured text document that
summarizes the issues I found with the current Keystone ma
s a critical component of federation, and it should
> be fit for purpose
>
> regards
>
> David
>
>
> On 03/11/2014 09:08, Morgan Fainberg wrote:
>>
>> On Nov 2, 2014, at 22:21, Dolph Mathews > <mailto:dolph.math...@gmail.com>> wrote:
>
On 11/02/2014 03:55 PM, Marek Denis wrote:
> Hi John,
>
> It indeed looks interesting and enhancing the mapping engine is on
> ours to-do list for a long time. I'd be happy to talk this through
> during the summit. Do you think you will be able to come for a
> Keystone websso/federation Design Se
While working on federated authentication for a different project
(OpenDaylight) we discovered we needed to map from the assertion
provided by an external federated IdP to local values. This is
essentially the same requirement which exists in Keystone's federated
support. It was hoped we could simp
On 10/08/2014 04:58 PM, Adam Young wrote:
> When gyee posted his X509 server-side auth plugin patch, the feedback
> we gave was that it should be using the mapping code from Federation to
> transform the environment variables set by the web server to the
> Keystone userid, username, domain name
On 07/21/2014 04:45 AM, Christian Berendt wrote:
> Hello.
>
> There are some files using the Python source code encodings as the first
> line. That's normally not necessary and I want propose to introduce a
> hacking check to check for the absence of the source code encodings.
>
I assume you mean
On 07/10/2014 12:55 PM, Douglas Mendizabal wrote:
> Hi Everyone,
>
> I would like to nominate Ade Lee for the barbican-core team.
>
>
I'm not a member of the barbican core team but I'd like to endorse Ade
anyway with a +1.
I've worked with Ade for years and consider him an exceptional engineer
wh
On 06/27/2014 12:21 AM, Carlos Garza wrote:
> I don't know where we can check in experimental code so I have a
> demonstration
> of how to extract CNs subjAltNames or what ever we want from x509
> certificates. Later on
> I plan to use the OpenSSL libraries to verify certs coming from barbi
Using standard formats such as PEM and PKCS12 (most people don't use
PKCS8 directly) is a good approach. Be mindful that some cryptographic
services do not provide *any* direct access to private keys (makes
sense, right?). Private keys are shielded in some hardened container and
the only way to ref
On 05/21/2014 01:11 PM, Igor Kalnitsky wrote:
>> So, write:
>>
>> LOG.debug(u'Could not do whatever you asked: %s', exc)
>>
>> or just:
>>
>> LOG.debug(exc)
>
> Actually, that's a bad idea to pass an exception instance to
> some log function: LOG.debug(exc). Let me show you why.
>
> Here
On 05/15/2014 11:41 AM, Victor Stinner wrote:
> Hi,
>
> The functions safe_decode() and safe_encode() have been ported to Python 3,
> and changed more than once. IMO we can still improve these functions to make
> them more reliable and easier to use.
>
>
> (1) My first concern is that these fu
On 05/16/2014 09:11 AM, Johannes Erdfelt wrote:
> six.text_type(exc) is the recommended solution.
+1
--
John
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 04/29/2014 09:48 AM, Mark McLoughlin wrote:
> What appeared to be unusual was that the timestamp had both sub-second
> time resolution and timezone information. It was felt that this wasn't a
> valid timestamp format and then some debate about how to 'fix' it:
> My conclusions from all that:
>
On 04/07/2014 12:06 PM, Nathan Kinder wrote:
> Hi,
>
> We don't currently collect high-level security related information about
> the projects for OpenStack releases. Things like the crypto algorithms
> that are used or how we handle sensitive data aren't documented anywhere
> that I could see.
You may want to take a peek at this recent thread, there may be
information in it you'll find useful.
http://lists.openstack.org/pipermail/openstack-dev/2014-March/029408.html
--
John
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
ht
On 04/01/2014 02:08 PM, John Dennis wrote:
>>> My concern is this. The singled biggest change in Py2 -> Py3 is
>>> string handling, especially with regards to str vs. unicode. We
>>> have a significant number of bugs in the current code base with
>>> reg
On 04/01/2014 12:28 PM, Victor Stinner wrote:
> Le mardi 1 avril 2014, 09:44:11 John Dennis a écrit :
>>> The goal of the sprint is to port OpenStack components and
>>> OpenStack dependencies to Python 3,
>>
>> This is a great goal, thank you! But I'm concer
On 04/01/2014 12:15 PM, Victor Stinner wrote:
> Hi,
>
> Le mardi 1 avril 2014, 09:11:52 John Dennis a écrit :
>> What are the plans for python-ldap? Only a small part of python-ldap is
>> pure python, are you also planning on tackling the CPython code?
>
> Oh, python-
On 04/01/2014 09:44 AM, John Dennis wrote:
> FWIW projects that deal with web services, wire protocols, external
> datastores, etc. who have already started porting to Py3 have
> encountered significant pain points with Py3, some of which is just
> being resolved and which have cau
On 04/01/2014 04:40 AM, victor stinner wrote:
> Hi,
>
> I will organize a sprint to Port OpenStack to Python 3 during 4 days
> at Montreal (Canada) during Pycon Montreal 2014, between April, 14
> (Monday) and April, 17 (Thursday).
>
> The goal of the sprint is to port OpenStack components and Ope
On 04/01/2014 04:40 AM, victor stinner wrote:
> Hi,
>
> I will organize a sprint to Port OpenStack to Python 3 during 4 days
> at Montreal (Canada) during Pycon Montreal 2014, between April, 14
> (Monday) and April, 17 (Thursday).
>
> The goal of the sprint is to port OpenStack components and Ope
When a change is complex good practice is to break the change into a
series of smaller individual patches that show the individual
incremental steps needed to get to the final goal. When partitioned into
small steps each change is easier to review and hopefully illustrates
the progression.
In most
On 03/13/2014 12:31 AM, Thomas Goirand wrote:
> Hi,
>
> Since Havana, I've been ignoring the 5 unit test failures that I always
> get. Though I think it'd be nice to have them fixed. The log file is
> available over here:
>
> https://icehouse.dev-debian.pkgs.enovance.com/job/keystone/59/console
>
On 03/12/2014 01:22 PM, Zane Bitter wrote:
> On 10/03/14 20:29, Robert Collins wrote:
>> Which bits look raw? It should only show text/* attachments, non-text
>> should be named but not dumped.
>
> I was thinking of the:
>
> pythonlogging:'': {{{
>
> part.
Yes, this is the primary culprit, it's
On 03/10/2014 02:31 PM, Zane Bitter wrote:
> Fewer logs is hardly ever what you want when debugging a unit test.
>
> I think what John is looking for is a report at the end of each test run
> that just lists the tests that failed instead of all the details (like
> `testr failing --list`), or per
On 03/07/2014 04:30 PM, Clark Boylan wrote:
> Now onto indirectly answering some of the questions you have. If a
> single unittest is producing thousands of lines of log output that is
> probably a bug. The test scope is too large or the logging is too
> verbose or both. To work around this we pro
On 03/07/2014 04:33 PM, Steve Kowalik wrote:
> On 07/03/14 12:56, John Dennis wrote:
>> Question: How do you list just the failing tests? I don't want to see
>> the contents of the logging data stored under the pythonlogging: key.
>> Ideally I'd like to see the nam
I've read the following documents as well as the doc for subunit and
testtools but I'm still missing some big picture usage.
https://wiki.openstack.org/wiki/Testr
https://testrepository.readthedocs.org/en/latest/index.html
The biggest problem seems to be whenever tests are listed I get
thousands
On 03/03/2014 10:00 AM, Matthew Booth wrote:
> PEP 8, under 'Programming Recommendations' recommends against implicit
> comparison to None. This isn't just stylistic, either: we were actually
> bitten by it in the VMware driver
> (https://bugs.launchpad.net/nova/+bug/1262288). The bug was hard to
>
I'd like to enable debug logging while running some specific unit tests
and I've not been able to find the right combination of levers to pull
to get logging output on the console.
In keystone/etc/keystone.conf.sample (which is config file loaded for
the unit tests) I've set debug to True, I've ve
On 02/19/2014 08:58 PM, Adam Young wrote:
>> Can you give more detail here? I can see arguments for both ways of
>> doing this but continuing to use ids for ownership is an easier
>> choice. Here is my thinking:
>>
>> 1. all of the projects use ids for ownership currently so it is a
>> smaller chan
On 01/26/2014 05:36 PM, rajesh_moh...@dell.com wrote:
> I am working on SSL VPN BP.
>
> CA certificate is one of the resources. We decided to use PEM formatted
> certificates. It is multi-line string
>
> 1 -BEGIN CERTIFICATE-
> 2 MIID3TCCA0agAwIBAgIJAKRWnul3NJnrMA0GCSqGSIb3DQEBBQUAM
>> Keeping them separate is awesome for *us* but really, really, really
>> sucks for users trying to use the system.
>
> I agree. Keeping them separate trades user usability for developer
> usability, I think user usability is a better thing to strive for.
I don't understand how multiple indepen
On 01/15/2014 08:24 PM, Rich Megginson wrote:
> Hello. My name is Rich Megginson. I am a Red Hat employee interested
> in working on Designate (DNSaaS), primarily in the areas of integration
> with IPA DNS, DNSSEC, and authentication (Keystone).
>
> I've signed up for the openstack/launchpad/g
On 11/14/2013 07:54 PM, Caitlin Bestler wrote:
> I would suggest that each *established* project (core or incubator) have
> its own mailing list, and that "openstack-dev" be reserved for
> topics of potential interest across multiple projects (which new
> projects would qualify as).
+1
This see
On 10/31/2013 10:36 PM, Jeremy Stanley wrote:
> As has been said many times already, OpenStack does not lack
> developers... it lacks reviewers.
In regards to reviews in general and in particular for welcoming new
committers I think we need to be careful about reviewers NAK'ing a
submission for wh
On 10/25/2013 03:43 PM, Robert Collins wrote:
> On 26 October 2013 08:40, Dolph Mathews wrote:
>>
>> On Thu, Oct 24, 2013 at 1:48 PM, Robert Collins
>> wrote:
>>>
>>>
>>> *) They help casual contributors *more* than long time core
>>> contributors : and those are the folk that are most likely to
On 10/18/2013 12:57 PM, Doug Hellmann wrote:
>
>
>
> On Thu, Oct 17, 2013 at 2:24 PM, John Dennis <mailto:jden...@redhat.com>> wrote:
>
> On 10/17/2013 12:22 PM, Luis A. Garcia wrote:
> > On 10/16/2013 1:11 PM, Doug Hellmann wrote:
> >>
&
On 10/17/2013 12:22 PM, Luis A. Garcia wrote:
> On 10/16/2013 1:11 PM, Doug Hellmann wrote:
>>
>> [snip]
>> Option 3 is closer to the new plan for Icehouse, which is to have _()
>> return a Message, allow Message to work in a few contexts like a string
>> (so that, for example, log calls and excep
On 08/06/2013 11:19 AM, Dean Troyer wrote:
> And that is the crux of the problem. When both can be installed
> side-by-side and sys.path is in control of the order, things work.
> This is such a fundamental problem in the distro that I am beginning
> to thing that we need to address it ourselves.
On 07/16/2013 12:56 AM, Zhongyue Luo wrote:
> Gareth,
>
> https://wiki.openstack.org/wiki/Oslo#Principles
>
> I believe this link will answer most of your answers.
This is very topical, we've just been having a closely related discussion.
There is another class of common code and we're not sure
On 07/01/2013 05:52 PM, Clint Byrum wrote:
> Last week I went to use oslo.config in a utility I am writing called
> os-collect-config[1]...
>
> While running unit tests on the main() method that is used for the CLI,
> I was surprised to find that my unit tests were picking up values from
> a confi
On 06/18/2013 04:59 AM, Thierry Carrez wrote:
> The issue here is not really the burden of maintaining an alternate
> testing method in the tree... it's that by default newcomers use the
> alternate method rather than the one used by our CI infrastructure,
> which should be their default choice.
>
64 matches
Mail list logo