On Wed, Dec 4, 2013 at 6:44 PM, Adrian Otto wrote:
> 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 work
> there is to be
On Sun, Dec 8, 2013 at 3:37 PM, Matt Riedemann
wrote:
>
>
> 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 changes in keyston
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
wrote:
> Thanks Soren, you are correct! Yay Timezones
>
> Vish
>
> On Jan 30, 2014, at 10:39 AM, Soren Hansen wrote:
>
> 2100 UTC is 1 PM Pacif
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 wrote:
> On Tue, Jan 6, 2015 at 2:49 AM, Flavio Percoco wrote:
> > Fully agree... I don't see how enable logging
+1
On Sun, Jan 18, 2015 at 2:11 PM, Morgan Fainberg
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 has been
> a consisten
On Mon, May 5, 2014 at 5:28 PM, Doug Hellmann
wrote:
>
>
> > 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 don't know how
> st
On Thu, May 22, 2014 at 10:48 AM, Jarret Raim wrote:
>
> 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: http://www.traceback.org
tw
On Thu, May 29, 2014 at 12:59 PM, Morgan Fainberg wrote:
>
>
> David and Kristy, the slides and summit session are a great starting place
> for this work. Now we need to get the proposal drafted up in the new
> Keystone-Specs repository (
> https://git.openstack.org/cgit/openstack/keystone-specs )
On Wed, Sep 24, 2014 at 11:42 AM, Dean Troyer wrote:
> On Tue, Sep 23, 2014 at 5:18 PM, Jay Pipes 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 participate too. I have an in
On Thu, Oct 16, 2014 at 2:54 PM, Dave Walker 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
> current support
On Tue, Nov 4, 2014 at 10:30 AM, John Dennis 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 yield a group
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 wrote:
> Wrong link again, this is embarrassing L
> https://review.openstack.org/#/c/112137/3
>
> From: Pendergrass, Eric
>
On Fri, Oct 18, 2013 at 1:48 PM, Sean Dague wrote:
> On 10/18/2013 12:04 PM, Brant Knudson wrote:
>
>>
>> 2) "git clone"ing 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 spec
On Wed, Oct 23, 2013 at 3:26 PM, Robert Collins
wrote:
> On 24 October 2013 08:14, Dolph Mathews wrote:
> >
> > On Wed, Oct 23, 2013 at 1:20 PM, Sean Dague wrote:
>
> >
> > Deprecation warnings!
> >
> > Based on the approach we're taking in the patch below, we'll be able to
> > notate how immine
On Thu, Oct 24, 2013 at 2: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 give up
> and walk away. Keeping barriers to entry low is an important part of
> making OpenStack development acce
On Wed, Nov 6, 2013 at 7:21 PM, Day, Phil 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 -1
On Mon, Nov 18, 2013 at 8:23 PM, Vishvananda Ishaya
wrote:
>
>
> +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, file_size_in_kb, disk_
On Thu, Jul 11, 2013 at 5:20 AM, Mark McLoughlin 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 right now sho
On Wed, Sep 4, 2013 at 10:23 AM, Dolph Mathews wrote:
>
> On Wed, Sep 4, 2013 at 9:14 AM, Salvatore Orlando wrote:
>
>> whenever I run devstack keystone falies to start because dogpile.cache is
>> not installed; this is easily solved by installing it, but I wonder if it
>> should be in requirement
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 because
I'm not trusted t
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, rather for the abuse of pow
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 service with the databas
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
___
application to have 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 bro
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/cl
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:
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
> perf/scalability issues of authorization
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
attributes where they don't belo
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 integrated into a wider calendari
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
> test setting.
>
I'm as
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
> [cinder] https://review.ope
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 exhaustively verify
> this bu
On Mon, Aug 3, 2015 at 7:14 AM, Davanum Srinivas 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. I'm not sure
On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov wrote:
> 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 aft
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 no functional changes, and
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
> http://codefool.tumbl
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 development of
> Keystone and
ready to be core to speed up our 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
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 apache2 as web server and mod
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:
>
> http://logs.openstack.org/57/221157/10/check/gate-tempest-dsvm-full/18
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 be honest expectation
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, 2015, at 10:39 AM, Sean Dague wrote:
> :>>>
>
I would like to start running a recurring bug squashing day. The general
idea is to get more focus on bugs and stability. You can find the details
here: https://etherpad.openstack.org/p/keystone-office-hours
--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://
On Sat, May 30, 2015, 12:32 Adam Young wrote:
I've started a Trello Board to manage the details.
https://trello.com/b/SXrl6UQ5/midcycle-planning. It is world readable,
but you need to be a member to be able to edit it. Let me know if you
feel the need to be able to edit it, or to receive not
On Wed, Jun 3, 2015 at 6:04 AM liusheng 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 (complexity check
On Thu, Jun 4, 2015 at 10:10 AM Rodrigo Duarte
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
> project name.
>
This
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 methods from sub
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 b
+1
On Tue, Feb 10, 2015 at 12:51 PM, Morgan Fainberg 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 first hand knowledge of
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 st
On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer 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 that we will use
On Sun, Mar 8, 2015 at 10:28 PM, Chen, Wei D 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 controllers should
On Fri, Mar 27, 2015 at 10:14 AM, Boris Bobrov 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] and
> [1]
> (thank
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
On Mon, Apr 6, 2015 at 2:41 PM, Mike Bayer 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 t
On Sat, Apr 18, 2015 at 9:30 PM, Boris Pavlovic 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 coverage job.
>
to also implement 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:/
this
introducing 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?su
On 12-Apr 15:25, Rodrigo Duarte wrote:
> On Wed, Apr 12, 2017 at 2:47 PM, David Stanek 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 between the federat
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
database could expose thos
red. Operators can still 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://dst
day. We didn't carry baggage for 6 months to a year. My
fear with keystone 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 e
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
ink having 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
b
os
> 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
f the slowness is
the crypto (which it was in 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
w
ther 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 e
67 matches
Mail list logo
