Re: [openstack-dev] [Ceilometer] Question on decorators in Ceilometer pecan framework

It looks like maybe WSME or Pecan is inspecting the method signature. Have you tried to change the order of the decorators? On Aug 8, 2014, at 9:16, Pendergrass, Eric eric.pendergr...@hp.com wrote: Wrong link again, this is embarrassing L https://review.openstack.org/#/c/112137/3 From:

Re: [openstack-dev] [Nova] [All] API standards working group

On Wed, Sep 24, 2014 at 11:42 AM, Dean Troyer dtro...@gmail.com wrote: On Tue, Sep 23, 2014 at 5:18 PM, Jay Pipes jaypi...@gmail.com wrote: Yes, I'd be willing to head up the working group... or at least participate in it. I'll bring an API consumer's perspective. I would love to

Re: [openstack-dev] Hierarchicical Multitenancy Discussion

That's why I love this site: http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140130T2100 On Thu, Jan 30, 2014 at 1:46 PM, Vishvananda Ishaya vishvana...@gmail.comwrote: Thanks Soren, you are correct! Yay Timezones Vish On Jan 30, 2014, at 10:39 AM, Soren Hansen so...@linux2go.dk

Re: [openstack-dev] [qa][keystone] Adding client library related tests to tempest

On Fri, Oct 18, 2013 at 1:48 PM, Sean Dague s...@dague.net wrote: On 10/18/2013 12:04 PM, Brant Knudson wrote: 2) git cloneing the keystoneclient doesn't work well with parallel testing (we have a similar problem in our tests with our pristine database backup) Can you go into the

Re: [openstack-dev] RFC - Icehouse logging harmonization

On Wed, Oct 23, 2013 at 3:26 PM, Robert Collins robe...@robertcollins.netwrote: On 24 October 2013 08:14, Dolph Mathews dolph.math...@gmail.com wrote: On Wed, Oct 23, 2013 at 1:20 PM, Sean Dague s...@dague.net wrote: Deprecation warnings! Based on the approach we're taking in the

Re: [openstack-dev] Remove vim modelines?

On Thu, Oct 24, 2013 at 2:48 PM, Robert Collins robe...@robertcollins.netwrote: *) They help casual contributors *more* than long time core contributors : and those are the folk that are most likely to give up and walk away. Keeping barriers to entry low is an important part of making

Re: [openstack-dev] Bad review patterns

On Wed, Nov 6, 2013 at 7:21 PM, Day, Phil philip@hp.com wrote: Leaving a mark. === You review a change and see that it is mostly fine, but you feel that since you did so much work reviewing it, you should at least find *something* wrong. So you find some nitpick and

Re: [openstack-dev] [style] () vs \ continuations

On Mon, Nov 18, 2013 at 8:23 PM, Vishvananda Ishaya vishvana...@gmail.comwrote: +1 to sticking something in hacking. FWIW I would probably do the following to avoid the debate altogether: result = self._path_file_exists(ds_browser, folder_path, file_name) folder_exists, file_exists,

Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last released version of keystoneclient does not work with python33

On Wed, Dec 4, 2013 at 6:44 PM, Adrian Otto adrian.o...@rackspace.comwrote: Jamie, Thanks for the guidance here. I am checking to see if any of our developers might take an interest in helping with the upstream work. At the very least, it might be nice to have some understanding of how much

Re: [openstack-dev] [qa][keystone] Keystoneclient tests to tempest

On Sun, Dec 8, 2013 at 3:37 PM, Matt Riedemann mrie...@linux.vnet.ibm.comwrote: On Sunday, December 08, 2013 11:26:07 AM, Brant Knudson wrote: We'd like to get the keystoneclient tests out of keystone. They're serving a useful purpose of catching problems with non-backwards compatible

Re: [openstack-dev] [oslo] Proposal: add local hacking for oslo-incubator

On Mon, May 5, 2014 at 5:28 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: The assert ones do seem to fit the best practices as I understand them, but I suspect there's going to be quite a bit of work to get projects compliant. I've seen some work being done on that already, but I

Re: [openstack-dev] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

On Thu, May 22, 2014 at 10:48 AM, Jarret Raim jarret.r...@rackspace.comwrote: This should make travel a bit easier for everyone as people won't need Hey Jarret, I'm going to be at the Keystone meetup for sure, but I'm also thinking about going to the Barbican meetup too. -- David blog:

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

On Thu, Oct 16, 2014 at 2:54 PM, Dave Walker em...@daviey.com wrote: Hi Steve, Thanks for your response. I am talking generally about the external auth support. One use case is Kerberos, but for the sake of argument this could quite easily be Apache Basic auth. The point is, we have

Re: [openstack-dev] [Keystone] Alternative federation mapping

On Tue, Nov 4, 2014 at 10:30 AM, John Dennis jden...@redhat.com wrote: O.K. group assignment is the final goal in Keystone. I suppose the relevant question then is the functionality in the current Keystone mapper sufficiently rich such that you can present to it an arbitrary set of values and

Re: [openstack-dev] [Review] Use of exception for non-exceptional cases

On Thu, Jul 11, 2013 at 5:20 AM, Mark McLoughlin mar...@redhat.com wrote: But I think what you're saying is missing is the stack trace from the underlying exception. As I understood it, Python doesn't have a way of chaining exceptions like this but e.g. Java does. A little bit more poking

Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core

+1 On Sun, Jan 18, 2015 at 2:11 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote: Hello all, I would like to nominate Brad Topol for Keystone Spec core (core reviewer for Keystone specifications and API-Specification only: https://git.openstack.org/cgit/openstack/keystone-specs ). Brad

Re: [openstack-dev] [Keystone] Proposing Marek Denis for the Keystone Core Team

+1 On Tue, Feb 10, 2015 at 12:51 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote: Hi everyone! I wanted to propose Marek Denis (marekd on IRC) as a new member of the Keystone Core team. Marek has been instrumental in the implementation of Federated Identity. His work on Keystone and

Re: [openstack-dev] [Glance] IRC logging

It's also important to remember that IRC channels are typically not private and are likely already logged by dozens of people anyway. On Tue, Jan 6, 2015 at 1:22 PM, Christopher Aedo ca...@mirantis.com wrote: On Tue, Jan 6, 2015 at 2:49 AM, Flavio Percoco fla...@redhat.com wrote: Fully

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On Sun, Mar 8, 2015 at 10:28 PM, Chen, Wei D wei.d.c...@intel.com wrote: +1, I am fan of checking the constraints in the controller level instead of relying on FK constraints itself, thanks. The Keystone controllers shouldn't do any business logic. This should be in the managers. The

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer mba...@redhat.com wrote: can you elaborate on your reasoning that FK constraints should be used less overall? or do you just mean that the client side should be mirroring the same rules that would be enforced by the FKs? I don't think he means

Re: [openstack-dev] [keystone] Output on stderr

On Wed, Mar 4, 2015 at 6:50 AM, Abhishek Talwar/HYD/TCS abhishek.tal...@tcs.com wrote: While working on a bug for keystoneclient I have replaced sys.exit with return. However, the code reviewers want that the output should be on stderr(as sys.exit does). So how can we get the output on

Re: [openstack-dev] [keystone][fernet] Fernet tokens sync

On Fri, Mar 27, 2015 at 10:14 AM, Boris Bobrov bbob...@mirantis.com wrote: As you know, keystone introduced non-persistent tokens in kilo -- Fernet tokens. These tokens use Fernet keys, that are rotated from time to time. A great description of key rotation and replication can be found on [0]

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

On Sat, Apr 18, 2015 at 9:30 PM, Boris Pavlovic bo...@pavlovic.me wrote: Code coverage is one of the very important metric of overall code quality especially in case of Python. It's quite important to ensure that code is covered fully with well written unit tests. One of the nice thing is

Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

On Mon, Apr 6, 2015 at 2:41 PM, Mike Bayer mba...@redhat.com wrote: On 4/6/15 12:49 PM, David Stanek wrote: Exactly. This is the direction I have been going. Functional tests are written using the public APIs using the client. I would also add that I don't like that the Keystone unit

Re: [openstack-dev] [Keystone] SQLite support (migrations, work-arounds, and more), is it worth it?

Exactly. This is the direction I have been going. Functional tests are written using the public APIs using the client. I would also add that I don't like that the Keystone unit tests are so database heavy. I would not want MySQL or ant RDBMS to be a requirement for running the tests. On Mon, Apr

Re: [openstack-dev] [nova][security] Enable user password complexity verification

On Wed, Jun 3, 2015 at 6:04 AM liusheng liusheng1...@126.com wrote: Thanks for this topic, also, I think it is similar situation when talking about keystone users, not only the instances's password. In the past we've talked about having more advanced password management features in Keystone

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

On Thu, Jun 4, 2015 at 10:10 AM Rodrigo Duarte rodrigodso...@gmail.com wrote: Also, if we are going to use a delimiter, we need to update the way projects names are returned in the GET v3/projects API to include the hierarchy so the user (or client) knows how to request a token using the

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov bbob...@mirantis.com wrote: On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum cl...@fewbar.com 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.

Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys

On Mon, Aug 3, 2015 at 7:14 AM, Davanum Srinivas dava...@gmail.com wrote: agree. Native HA solution was already ruled out in several email threads by keystone cores already (if i remember right). This is a devops issue and should be handled as such was the feedback. I'm sure you are right.

Re: [openstack-dev] [all] service catalog: TNG

On Fri, Oct 9, 2015 at 1:28 PM, Jonathan D. Proulx wrote: > On Fri, Oct 09, 2015 at 01:01:20PM -0400, Shamail wrote: > :> On Oct 9, 2015, at 12:28 PM, Monty Taylor wrote: > :> > :>> On 10/09/2015 11:21 AM, Shamail wrote: > :>> > :>> > :>>> On Oct 9,

Re: [openstack-dev] FFE Request for completion of data driven assignment testing in Keystone

On Thu, Sep 3, 2015 at 3:44 PM Henry Nash wrote: > > I would like to request an FFE for the remaining two patches that are > already in review (https://review.openstack.org/#/c/153897/ and > https://review.openstack.org/#/c/154485/). These contain only test code > and

Re: [openstack-dev] [keystone] PTL non-candidacy

On Thu, Sep 10, 2015 at 5:40 PM, Morgan Fainberg wrote: > While I will be changing my focus to spend more time on the general needs > of OpenStack and working on the Public Cloud story, I am confident in those > who can, and will, step up to the challenges of leading

[openstack-dev] [keystone] PTL Candidacy

review pace. We need to work together to find ways to give more people the ability to contribute upstream. I do believe it's possible to make our thriving community even better. Thank you for voting for me as your PTL for the Mitaka release cycle. -- David Stanek

Re: [openstack-dev] [keystone] creating new users with invalid mail addresses possible

On Fri, Sep 11, 2015 at 8:26 AM, Christian Berendt wrote: > At the moment it is possible to create new users with invalid mail > addresses. I pasted the output of my test at > http://paste.openstack.org/show/456642/. (the listing of invalid mail > addresses is available at

Re: [openstack-dev] [releases][requirements][keystone]something incompatible with our requirements

On Fri, Sep 18, 2015 at 3:32 PM, Robert Collins wrote: > I know this is terrible timing with the release and all, but > constraints updates are failing. This is the first evidence - and it > doesn't look like a race to me: > >

Re: [openstack-dev] Apache2 vs uWSGI vs ...

I thoughts below mention Keystone, but in reality I would apply the same logic to any OpenStack service. On Fri, Sep 18, 2015 at 10:32 AM, Boris Bobrov wrote: > There are 2 dimensions this discussion should happen in: web server and > application server. Now we use

Re: [openstack-dev] Apache2 vs uWSGI vs ...

On Fri, Sep 25, 2015 at 8:25 AM Adam Heczko wrote: > Are we discussing mod_wsgi and Keystone or OpenStack as a general? > If Keystone specific use case, then probably Apache provides broadest > choice of tested external authenticators. > I'm not against uwsgi at all, but to

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

On Thu, Jan 7, 2016 at 3:01 PM, Jim Rollenhagen wrote: > We'd be using this for functional tests, not unit, where we can't really > inject mocks. The idea is that we could run a full functional suite > against either mimic or a full ironic environment, just by changing a

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

On Mon, Nov 23, 2015 at 6:06 PM David Chadwick wrote: [snip] > > > > This is just a vote for distrusting the community. If you think there's > > "power" in being able to merge things, and that organizations will abuse > > this power, then you vote for distrust. > > No,

Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model

On Mon, Nov 23, 2015 at 11:52 AM Dmitry Tantsur wrote: > On 11/23/2015 05:42 PM, Morgan Fainberg wrote: > > Hi everyone, > > > [snip,snip] > > > > This type of policy is an actively distrustful policy. > I don't see it quite like that. I don't think the policy is there

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On Tue, Jan 12, 2016 at 8:51 AM, Amrith Kumar wrote: > I've tagged this message with the projects impacted by a series of change > sets: > > [trove] https://review.openstack.org/#/c/266220/ > [neutron] https://review.openstack.org/#/c/266156/1 >

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

On Tue, Jan 12, 2016 at 9:13 AM, Amrith Kumar wrote: > Chris, Ihar, > > I assumed that this was stylistic based on the fact that in the places > where I was seeing it, it seemed to be the case that the LHS was > intuitively positive (a length, for example). I did not

Re: [openstack-dev] [keystone] orchestration and db_sync

On Fri, May 27, 2016 at 12:08 PM, Ryan Hallisey wrote: Theses changes do not all happen at the same times for an OpenStack installation. > - Create the service's users and add a password into the databse Should only happen once during installation. > - Sync the

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

On Tue, Jun 21, 2016 at 08:00:50AM -0400, Sean Dague wrote: > > Keystone - custom WSGI with Routes / Paste > Keystone is moving toward Flask. I have an experimental patch that moves us in that direction. I'm in the process to rebasing and fixing it up since it's wildly out of date. -- David

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

On Wed, Feb 17, 2016 at 6:58 PM Sean Dague wrote: > > Question. Are we only tripping this up in unit tests because the tests > are doing things we'd never really do in real life? > I think that some of the issues have been real. Keystone had issues with 0.18.0 because it dropped

Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project

On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic wrote: > > 2) This will reduce scope of Keystone, which means 2 things > 2.1) Smaller code base that has less issues and is simpler for testing > 2.2) Keystone team would be able to concentrate more on fixing >

Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

On Wed, Apr 13, 2016 at 3:26 AM koshiya maho wrote: > > My request to all keystone cores to give their suggestions about the same. > > I'll test this a little and see if I can see how it breaks. Overall I'm not really a fan of this design. It's just a hack to add

Re: [openstack-dev] [magnum] High Availability

On Fri, Mar 18, 2016 at 4:03 PM Douglas Mendizábal < douglas.mendiza...@rackspace.com> wrote: > [snip] > > > > Regarding the Keystone solution, I'd like to hear the Keystone team's > feadback on that. It definitely sounds to me like you're trying to put a > square peg in a round hole. > > > > I

Re: [openstack-dev] summit tools

On Wed, Apr 20, 2016 at 12:14 PM Neil Jerram wrote: > A couple of questions about our Austin-related planning tools... > > - Can one's calendar at > > https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-25 > be exported as .ics, or otherwise

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak wrote: > We need an MFA solution, and this doesn't seem like too terrible an option. One thing to note here is that the credentials for TOTP stored in the keystone credentials backend are not encrypted. So a breach of your

Re: [openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS client

n via getCurrentUserSession().token > Hey Kevin, It's hard to tell without a lot of the context. From what I can tell the token is pulled down as part of the data of an API request. As long as that's not cached I think you are OK. -- David Stanek web: http://dstanek.

Re: [openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS client

access to the token as being a terrible thing. We just need to make sure we do it as safely as we can in order to prevent the token from lingering around after the web session has completed. For example, putting the token in redirect URLs may cause it to end up in browser history, puttin

Re: [openstack-dev] Syntribos Error : AttributeError: 'tuple' object has no attribute 'headers'

ect. The tuple contains two items: a response object and a signal handler object. This is the first I've heard of this project, so I was very disappointed to not find any docs for it. 1. https://github.com/openstack/syntribos/blob/master/syntribos/clients/http/base_http_cli

Re: [openstack-dev] [keystone]PKI token VS Fernet token

the past) then you can tune it a little bit. Another option might be to keep the same token flow and find a faster method for hashing a token. 1. http://git.openstack.org/cgit/openstack/keystone/tree/etc/keystone.conf.sample#n67 -- david stanek web: https://dstanek.com twitter: https://twitter.c

Re: [openstack-dev] [keystone] webob 1.7

t; as well or already have hit. > I've confirmed that this is an issue. I'll work on a fix. We can take further discussion to the bug tracker. -- david stanek web: https://www.dstanek.com twitter: https://twitter.com/dstanek ___

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

is that we'd slow development even more by adding more cruft and cruft on top of cuft. > > SO ... > > Just do what Nova and Neutron are doing - and if it's not good enough, > fix it. Having some projects use triggers and other projects not use > trig

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

till go the old route and db_sync while others help test out the cutting edge features. The triggers are not there during the entire lifecycle of the application. The expand phase adds them and the contract removes them. -- David Stanek web: http://dstanek.com blog: http:

Re: [openstack-dev] [keystone] new core reviewer (rderose)

On Thu, Sep 01 at 10:44 -0400, Steve Martinelli wrote: > > Thanks for all your hard work Ron, we sincerely appreciate it. > Contrats! Well deserved for sure! -- David Stanek web: http://dstanek.com blog: http://trac

Re: [openstack-dev] [keystone] Custom ProjectID upon creation

aving different behavior for tokens based on scope will not only lead to bad user experiences, but will lead to baking in those rules into the client. Someone will propose this as soon as they get confused by the token 401ing unexpectedly. -- david stanek web: http://www.dstanek.com blog:

[openstack-dev] [keystone] Adding foreign keys between subsystems

it for the other highly coupled subsystems. They would also have to provide any FK enforcement that their own datastore does not provide. Thoughts? -- david stanek web: https://dstanek.com twitter: https://twitter.com/dstanek

Re: [openstack-dev] [keystone] Adding foreign keys between subsystems

On 12-Apr 15:25, Rodrigo Duarte wrote: > On Wed, Apr 12, 2017 at 2:47 PM, David Stanek <dsta...@dstanek.com> wrote: > > > On 12-Apr 14:30, Rodrigo Duarte wrote: > > > Just to illustrate the discussion, we have a bug fix that currently tries > > > to drop a FK

Re: [openstack-dev] [keystone] Adding foreign keys between subsystems

ducing a new bug? -- 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:unsu

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

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