-Original Message-
From: Doug Hellmann d...@doughellmann.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: August 15, 2014 at 13:29:15
To: Ben Nemec openst...@nemebean.com, OpenStack Development Mailing List
(not for usage
On Sunday, August 24, 2014, Anne Gentle a...@openstack.org wrote:
I'm following this as well since I have the exact same problem in a
docstring patch for heat.
Keystone saw an oddity with the new sample config generator (changing how
options are sorted and therefore changing the way the
Comments in line (added my thoughts on a couple of the targets Sean
outlined).
On Thursday, September 4, 2014, Sean Dague s...@dague.net wrote:
Here is my top 5 list:
1. Functional Testing in Integrated projects
The justification for this is here -
Responses in-line.
-Original Message-
From: Robert Collins robe...@robertcollins.net
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 7, 2014 at 20:16:32
To: OpenStack Development Mailing List
Glanceclient to using session as I know he’s been working
on the client front in this regard. I hope that sometime within the K
development cycle timeline we will be converting the logging over to audit_ids
where possible (but that has not been 100% decided on).
Cheers,
Morgan
—
Morgan Fainberg
/openstack/python-keystoneclient/tree/test-requirements.txt?id=0.10.1
[2]
http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/requirements.txt?id=1.1.1
[3]
http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/test-requirements.txt?id=1.1.1
—
Morgan Fainberg
-Original
-Original Message-
From: Brant Knudson b...@acm.org
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 12, 2014 at 14:32:20
To: OpenStack Development Mailing List (not for usage questions)
-Original Message-
From: Ian Cordasco ian.corda...@rackspace.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 17, 2014 at 16:28:57
To: OpenStack Development Mailing List (not for usage questions)
Clark Boylan cboy...@sapwetik.org Wrotr :
On Wed, Sep 17, 2014, at 06:48 PM, Clark Boylan wrote:
On Wed, Sep 17, 2014, at 06:37 PM, Matt Riedemann wrote:
On 9/17/2014 7:59 PM, Ian Wienand wrote:
On 09/18/2014 09:49 AM, Clark Boylan wrote:
Recent sampling of test run times
need to collect a
bit more data but this doesn't look good for keystone eventlet.
On Wed, Sep 17, 2014 at 11:02 PM, Morgan Fainberg
morgan.fainb...@gmail.com wrote:
I've kicked off a test[1] as well to check into some tunable options
(eventlet workers) for improving keystone eventlet
we are today. I am
extremely pleased with how far we’ve come and look forward to seeing the
continued success as we move into the Kilo release cycle and beyond not just
for Keystone but all of OpenStack.
Cheers,
Morgan Fainberg
—
Morgan Fainberg
-Original Message-
From: Dolph Mathews dolph.math...@gmail.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 22, 2014 at 07:50:42
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Subject:
Keystone team has released 0.11.1 of python-keystoneclient. Due to some delays
getting things through the gate this took a few extra days.
https://pypi.python.org/pypi/python-keystoneclient/0.11.1
—Morgan
—
Morgan Fainberg
-Original Message-
From: John Dickinson m...@not.mn
Reply
The Keystone team has released python-keystoneclient 0.11.1 [1]. This version
is meant to be the release coinciding with the Juno release of OpenStack.
The release includes two fixes [2] on top of the 0.11.0 [3] version.
Cheers,
Morgan Fainberg
[1] https://pypi.python.org/pypi/python
-Original Message-
From: John Griffith john.griffi...@gmail.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 23, 2014 at 08:02:23
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
-Original Message-
From: Dolph Mathews dolph.math...@gmail.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 23, 2014 at 16:41:27
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Subject: Re:
Hi Chmouel,
I think the correct way to sync is to run the update.py script and submit a
review (I don’t think it’s changed recently).
Cheers,
Morgan
On December 9, 2013 at 23:58:42, Chmouel Boudjnah (chmo...@enovance.com) wrote:
On Fri, Dec 6, 2013 at 4:30 PM, Dolph Mathews
the protection
occurs likely warrants a deeper discussion (perhaps in Atlanta?).
Cheers,
Morgan Fainberg
On December 12, 2013 at 10:32:40, Dolph Mathews (dolph.math...@gmail.com) wrote:
The policy file is protecting v3 API calls at the controller layer, but you're
calling the v2 API. The policy
On December 12, 2013 at 14:32:36, Dolph Mathews (dolph.math...@gmail.com) wrote:
On Thu, Dec 12, 2013 at 2:58 PM, Adam Young ayo...@redhat.com wrote:
On 12/04/2013 08:58 AM, Jarret Raim wrote:
While I am all for adding a new program, I think we should only add one
if we
rule out all existing
Brant,
That is fine for some cases but we provide non-ldap backends, and a
read/write backend. If we continue to provide a keystone specific idp
(likely we need to), these features are a must-have in the long run. Just
my view (and requests from real customers). It's all well and good to
I agree with Doug’s question, but also would extend the train of thought to ask
why not help to make Chef or Puppet better and cover the more OpenStack
use-cases rather than add yet another competing system?
Cheers,
Morgan
On January 9, 2014 at 10:24:06, Doug Hellmann
Yes, this feature is used in real deployments just as Yuriy described. I
really want to avoid a new API version since we're just now getting solidly
into V3 being used more extensively. Is it unreasonable to have wsme allow
extra values in some manner? (I think that is the crux, is it something
team will still
be in #openstack-dev so that we can catch Keystone and Identity related
questions (just as before).
Cheers,
Morgan Fainberg
—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m...@metacloud.com___
OpenStack-dev
and the community.
TL;DR, “don’t break the contract”. If we are seriously making incompatible
changes (and we will be regardless of the direction) the only reasonable option
is a new major version.
—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m...@metacloud.com
On February
, consumer, and developer) this means
we should keep V2, and work on benefiting from the lessons learned in
developing V3 while moving to correct the issues we have in a maintainable /
friendly way (to developers, deployers, and consumers).
—
Morgan Fainberg
Principal Software Engineer
Core Developer
with this change to USER_ID format, please
respond so that the issues/concerns can be addressed. Again, the plan is not
to change current USER_IDs but that new ones could be up to 255 characters in
length.
Cheers,
Morgan Fainberg
—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m
On Thursday, February 27, 2014, Dolph Mathews dolph.math...@gmail.com
wrote:
On Thu, Feb 27, 2014 at 11:52 AM, Jay Pipes
jaypi...@gmail.comjavascript:_e(%7B%7D,'cvml','jaypi...@gmail.com');
wrote:
On Thu, 2014-02-27 at 16:13 +, Henry Nash wrote:
So a couple of things about this:
Hi Thomas,
I’ll take a look at that tonight and see if it’s an easy solve. Hopefully I can
have something posted by Monday for you.
—Morgan
—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m...@metacloud.com
On March 1, 2014 at 20:06:54, Thomas Goirand (z...@debian.org
Having done some work with MySQL (specifically around similar data sets)
and discussing the changes with some former coworkers (MySQL experts) I am
inclined to believe the move from varchar to binary absolutely would
increase performance like this.
However, I would like to get some real
Hi Joe,
I think that in a V2 only world a 2 cycle deprecation model would be sufficient
for any extension. I don’t foresee any complaints on that front, especially if
there is work to supersede or obsolete the need for the extension.
Cheers,
Morgan
—
Morgan Fainberg
Principal Software
propose changing the topic of this thread slightly: In a V2 only world,
how do we know if something is used? How do we understand how it is used and
when? Lets answer that instead.
—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m...@metacloud.com
On March 4, 2014 at 02:09:51
at 12:05 -0800, Morgan Fainberg wrote:
Having done some work with MySQL (specifically around similar data
sets) and discussing the changes with some former coworkers (MySQL
experts) I am inclined to believe the move from varchar to binary
absolutely would increase performance like
On March 4, 2014 at 16:13:45, Dan Smith (d...@danplanet.com) wrote:
What I'd like to do next is work through a new proposal that includes
keeping both v2 and v3, but with a new added focus of minimizing the
cost. This should include a path away from the dual code bases and to
something like
I’ve been working on (albeit slowly) getting the keystone implementation of
dogpile.cache into oslo.cache. It’s been slow due to other demands, but I’m
hoping to get back to it in the near future here so we can make moves like this
more easily.
—
Morgan Fainberg
Principal Software Engineer
Core
I think this could be a significant win for all projects (I'd like to see
it adopted beyond nova). This should help ferret out the upgrade impacts
that sometimes sneak up on us (and cause issues later on).
+1 from me.
Cheers,
Morgan Fainberg
IRC: morganfainberg
On Mon, Oct 14, 2013 at 4:51
of things.
Cheers,
Morgan Fainberg
IRC: morganfainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Tue, Oct 15, 2013 at 5:05 PM, Doug Hellmann
doug.hellm...@dreamhost.comwrote:
Making updates easier would be nice, and the abstract base class work
should help with that. On the other hand, as a deployer who has had to
rewrite our custom integration a few times in the past 6 months or so,
I agree that likely extensions and internal API discussions can become one
session. I think the API side of that won't need to fill a whole session.
On Wednesday, October 16, 2013, Adam Young wrote:
On 10/16/2013 12:23 PM, Dolph Mathews wrote:
I'll be finalizing the design summit schedule [1]
It seems like adopting 0.1.8 is the right approach. If it doesn't work with
other projects, we should work to help those projects get updated to work
with it.
--Morgan
On Thursday, October 24, 2013, Zhi Yan Liu wrote:
Hi all,
Adopt 0.1.8 as iso8601 minimum version:
+1 and likely this should be added to hacking so they don't sneak back in
by accident / reviewers missing the line since we've had them for do long.
On Thursday, October 24, 2013, Flavio Percoco wrote:
On 24/10/13 13:38 +0100, Joe Gordon wrote:
Since the beginning of OpenStack we have had vim
In light of what Dolph said with regards to Keystone, we are using
dogpile.cache to implement memoization in front of our driver calls.
It it has the ability to cache directly as well, but it has been
effective (so far) for our use-case.
That being said, I am unsure if caching in front of MySQL
on the topic.
Cheers,
Morgan Fainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to support current behavior) I think this would very much disrupt
the workflow I use. If configurable, I'd be open to it, if not
configurable I have to say -1 to this idea.
Cheers,
Morgan Fainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
was a little short to convey that.
--Morgan Fainberg
On Sunday, November 10, 2013, Robert Collins wrote:
On 9 November 2013 01:51, Morgan Fainberg m...@metacloud.com javascript:;
wrote:
I agree this would be interesting but if it isn't configurable (e.g. A
mechanism to support current behavior
to unwind
that).
There might be some value to seeing some work being done to provide
more information to Keystone, but I think this will become more
apparent as Congress develops.
Thoughts?
Tim
Cheers,
Morgan Fainberg
___
OpenStack-dev mailing list
A couple of quick points.
1) I think that splitting the list is the wrong approach.
2) Perhaps we need to look at adding a mechanism that enforces the use
of tags in the subject line (send a nice sorry, but you need to
indicate the topic(s) you are mailing about error back if it doesn't
exist,
to understand). I think the
plus of avoiding decorating things isn't really a huge win, and
actually i think takes clarity away.
--Morgan Fainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
Chuck,
The reason to use httpretty is that it handles everything at the
socket layer, this means if we change out urllib for requests or some
other transport to make HTTP requests to we don't need to refactor
every one of the mock/mox subouts to match the exact set of parameters
to be passed.
I'd be more willing to toss in and help to maintain/fix appropriately
on StackForge if that is needed. Though I am very much hoping
upstream can be used.
Cheers,
Morgan Fainberg
On Wed, Nov 20, 2013 at 7:21 PM, Chuck Short chuck.sh...@canonical.com wrote:
Hi,
So maybe if it gets to the point
, and deprecation of keystone v2 API).
Cheers,
--Morgan Fainberg
On Saturday, November 23, 2013, Caitlin Bestler wrote:
I have seen several people request that their users be members of two
projects and that they be allow to publish objects that are Shared by
multiple projects.
For some
I hear a concerted effort to get this bootstrapped in Keystone. We can do
this if it is the voice of the majority.
If we do:
Keep KDS configuration separate from the Keystone configuration: the fact
that they both point to the same host and port is temporary. In fact, we
should probably
Hi Thomas,
How pressing is this issue? I know there is work being done to unify
token/auth implementation across the clients. I want to have an idea of
the heat here so we can look at addressing this directly in novaclient if
it can't wait until the unification work to come down the line.
, tokens
are only marginally less exposure than a password in a log file.
I firmly believe that we should avoid putting information that conveys
authorization (e.g. username/password or bearer token id) in the logs.
—
Morgan Fainberg
From: Sean Dague s...@dague.net
Reply: OpenStack Development Mailing
}%(token)s’ instead of specifying a
specific obscuring algorithm. This means that if we ever update the way we
obscure the data in the future, we’re not lying about what was done in the log.
The proposed approach can be found here: https://review.openstack.org/#/c/99432
Cheers,
Morgan
—
Morgan
(rather than just silly) about the naming? I just don’t see how if we
don’t namespace collide on the executable side, how there can be any real
confusion (python-bash8, sure pypi is a little different) over what is being
installed.
Cheers,
Morgan
—
Morgan Fainberg
From: Thomas Goirand z
+1 across the board for this change.
H803 is ignored by a large number of projects after a rather extensive
conversation on the ML last year (as I recall). The other two changes seem
quite reasonable.
Cheers,
Morgan
—
Morgan Fainberg
From: Sean Dague s...@dague.net
Reply: OpenStack
The issue with the login page simply refreshing was due to a change in
Keystone that updated the type of Token issued by default from PKI to PKIZ
(compressed PKI/ASN1). The update to the django auth module was intended to
correct that specific issue with Keystone and Horizon (Juno).
The bug fix
django_openstack_auth versions, I currently have a patch up to restore the
strange import in openstack_auth https://review.openstack.org/#/c/101715/
once that merges I will release django_openstack_auth 1.1.7 and all gates
should work again.
David
From: Morgan Fainberg morgan.fainb...@gmail.com
...@gmail.com wrote:
I'm afraid we have to revert the PKIZ change since devstack is not support
django_openstack_auth now and all patches blocked including David's fix.
发自我的 iPhone
在 Jun 22, 2014，5:39，Morgan Fainberg morgan.fainb...@gmail.com
javascript:; 写道：
Great. This looks like your fix
deploy via devstack under Apache (and gate upon it). Please let me know
if anyone has significant issues with this change / concerns as I would like to
finish up this road to mod_wsgi based Keystone as early in the Juno cycle as
possible.
Cheers,
Morgan Fainberg
—
Morgan Fainberg
The Keystone team is happy to announce that as of yesterday (July 10th 2014),
with the merge of https://review.openstack.org/#/c/100747/ Keystone is now
gating on Apache + mod_wsgi based deployment. This also has moved the default
for devstack to deploy Keystone under apache. This is in-line
On Tuesday, July 15, 2014, Steven Hardy sha...@redhat.com wrote:
On Mon, Jul 14, 2014 at 02:43:19PM -0400, Adam Young wrote:
On 07/14/2014 11:47 AM, Steven Hardy wrote:
Hi all,
I'm probably missing something, but can anyone please tell me when
devstack
will be moving to keystone v3,
Thanks for the info - any chance you can provide links to the relevant
reviews here? If so I'll be happy to pull them and locally test to ensure
our issues will be addressed :)
Sure!
https://review.openstack.org/#/c/106819/ is the change for the
keystonemiddleware package (where the
Thanks for the info - any chance you can provide links to the relevant
reviews here? If so I'll be happy to pull them and locally test to ensure
our issues will be addressed :)
Sure!
https://review.openstack.org/#/c/106819/ is the change for the
keystonemiddleware
package
On Wednesday, July 16, 2014, Joe Gordon joe.gord...@gmail.com wrote:
On Tue, Jul 15, 2014 at 7:20 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:
On Tuesday, July 15, 2014, Steven Hardy sha...@redhat.com wrote:
On Mon, Jul 14, 2014 at 02:43:19PM -0400, Adam Young wrote:
On 07/14/2014
I apologize for the very mixed up/missed quoting in that response, looks like
my client ate a bunch of the quotes when writing up the email.
—
Morgan Fainberg
--
From: Morgan Fainberg morgan.fainb...@gmail.com
Reply: Morgan Fainberg
: July 16, 2014 at 02:27:42
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [devstack][keystone] Devstack, auth_token and
keystone v3
On Tue, Jul 15, 2014 at 7:20 AM, Morgan Fainberg
wrote:
On Tuesday, July
--
From: Rich Megginson rmegg...@redhat.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: July 16, 2014 at 08:08:00
To: openstack-dev@lists.openstack.org
that are not on this list (or are truly transparent to the end-user and
deployer).
Cheers,
Morgan Fainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Wednesday, July 23, 2014, Russell Bryant rbry...@redhat.com wrote:
On 07/22/2014 11:00 PM, Nathan Kinder wrote:
On 07/22/2014 06:55 PM, Steven Hardy wrote:
On Tue, Jul 22, 2014 at 05:20:44PM -0700, Nathan Kinder wrote:
Hi,
I've had a few discussions recently related to Keystone
Hi!
The Keystone team is looking for feedback from the community on what type of
Keystone Token is being used in your OpenStack deployments. This is to help us
understand the use of the different providers and get information on the
reasoning (if possible) that that token provider is being
many rows were affected.
Feel free to hit me up if I can help in any way on this.
Cheers,
Morgan
—
Morgan Fainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Thursday, July 31, 2014, Russell Bryant rbry...@redhat.com wrote:
On 07/30/2014 10:57 AM, Dolph Mathews wrote:
We recently merged an implementation for GET /v3/catalog which finally
enables POST /v3/auth/tokens?nocatalog to be a reasonable default
behavior, at the cost of an extra HTTP
: [openstack-dev] [Keystone] Survey on Token Provider Usage
Morgan Fainberg wrote:
The Keystone team is looking for feedback from the community on what type
of Keystone
Token is being used in your OpenStack deployments. This is to help us
understand the use
of the different providers and get
Hi everyone!
I would like to announce my candidacy for the Technical Committee election.
About Me
I’m Morgan Fainberg. I am a software engineer working for a startup focused on
deploying OpenStack in a private cloud configuration for a number of
organizations. I’ve been an active
)
backends, limiting enhancements and new development done on the templated
catalog backend.
Please feel free to respond via the survey below or via email to the mailing
list.
Keystone Catalog Backend Usage Survey: https://www.surveymonkey.com/s/3DL7FTY
Cheers,
Morgan
—
Morgan Fainberg
Principal
The keystone team is also looking at ways to reduce the data contained in
the token. Coupled with the compression, this should get the tokens back
down to a reasonable size.
Cheers,
Morgan
Sent via mobile
On Wednesday, May 21, 2014, Adam Young ayo...@redhat.com wrote:
On 05/21/2014 11:09 AM,
This is part of what I was referencing in regards to lightening the data
stored in the token. Ideally, we would like to see an ID only token that
only contains the basic information to act. Some initial tests show these
tokens should be able to clock in under 1k in size. However all the details
+1 Providing service crashing information is very valuable. In general we need
to provide as much information about why the service exited
(critically/traceback/unexpectedly) for our operators.
—Morgan
—
Morgan Fainberg
From: Jay Pipes jaypi...@gmail.com
Reply: OpenStack Development Mailing
will help us address any concerns with the proposal/redesign as we
move into implementation.
Cheers,
Morgan
—
Morgan Fainberg
From: Adam Young ayo...@redhat.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: May 28, 2014 at 09:24:26
the required fields, etc):
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/fixture/v3.py#L48
for example.
—
Morgan Fainberg
From: Doug Hellmann doug.hellm...@dreamhost.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev
that won’t ever be
submitted to the main repositories).
I, for one am very pleased that Drafts are now disabled. I never liked the
feature (it felt like it was missing a chunk of functionality to be really
useful).
Cheers,
Morgan
—
Morgan Fainberg
From: Clark Boylan clark.boy...@gmail.com
Reply
2. Since a patch is very much WIP, there is concern about consuming CI
resources with needless testing.
3. The code is “example”, “toy”, or “exploratory” (not planning to
submit to the project, but not private/proprietary)
The general advice I give to people is to post the patches
On 06/11/2014 02:01 PM, Sean Dague wrote:
Honestly, I kind of don't care. :)
+1 :-)
+1 yep. that about covers it.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Thursday, September 25, 2014, Thierry Carrez thie...@openstack.org
wrote:
Thierry Carrez wrote:
Kilo Design Summit: Nov 4-7
Kilo-1 milestone: Dec 11
Kilo-2 milestone: Jan 29
Kilo-3 milestone, feature freeze: March 12
2015.1 (Kilo) release: Apr 23
L Design Summit: May 18-22
Keystone team has released Keystonemiddleware 1.2.0
https://pypi.python.org/pypi/keystonemiddleware/1.2.0
This should be the version coinciding with the Juno OpenStack release.
—
Morgan Fainberg
-Original Message-
From: Sergey Lukjanov slukja...@mirantis.com
Reply: OpenStack
].
Cheers,
Morgan Fainberg
[1] https://pypi.python.org/pypi/keystonemiddleware/1.2.0
[2] https://launchpad.net/keystonemiddleware/+milestone/1.2.0
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
-Original Message-
From: John Griffith john.griffi...@gmail.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 25, 2014 at 12:27:52
To: OpenStack Development Mailing List (not for usage questions)
-Original Message-
From: James E. Blair cor...@inaugust.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 26, 2014 at 08:35:04
To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
Subject:
On Monday, September 29, 2014, Julien Danjou jul...@danjou.info wrote:
On Mon, Sep 29 2014, Jay Pipes wrote:
Any objection to me taking up the work? Was there any associated
blueprint for
it?
As said on IRC, go ahead. There's no blueprint associated AFAIK. :)
--
Julien Danjou
/* Free
The summit planning etherpad[1] is up and available for discussing Keystone
summit sessions. Other etherpad links (such as cross-project topics) can be
found on the Summit Planning wiki page[2].
Please do not hesitate to jump in and start talking about the Identity
sessions.
For those who
-Original Message-
From: Clint Byrum cl...@fewbar.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 29, 2014 at 16:17:39
To: openstack-dev openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev]
Comments in-line.
-Original Message-
From: Joshua Harlow harlo...@outlook.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 29, 2014 at 21:52:20
To: OpenStack Development Mailing List (not for usage questions)
On Wednesday, October 1, 2014, Sean Dague s...@dague.net wrote:
As stable branches got discussed recently, I'm kind of curious who is
actually stepping up to make icehouse able to pass tests in any real
way. Because right now I've been trying to fix devstack icehouse so that
icehouse
Keeping the enforcement local (same way policy works today) helps limit the
fragility, big +1 there.
I also agree with Vish, we need a uniform way to talk about quota
enforcement similar to how we have a uniform policy language / enforcement
model (yes I know it's not perfect, but it's far closer
will approve all
specs for Kilo as early as possible so that new code can land in the first part
of the Kilo development cycle. Any reviews of the current specifications by
cores or non-cores alike, of course, are appreciated and valued.
Cheers,
Morgan Fainberg
[1] http://git.openstack.org/cgit
be something
to be expected within the current development cycle (Kilo) or even the next,
but this is a conversation that needs to be started as it will help make
OpenStack better.
Thanks,
Morgan
—
Morgan Fainberg
___
OpenStack-dev mailing list
This sums up the large(er) part of or starting this conversation.
-NGK
Tim
On Oct 14, 2014, at 1:56 AM, David Chadwick d.w.chadw...@kent.ac.uk
javascript:; wrote:
On 14/10/2014 01:25, Nathan Kinder wrote:
On 10/13/2014 01:17 PM, Morgan Fainberg wrote:
Description
I agree we should use flake8 built-in if at all possible. I complexity checking
will definitely help us in the long run keeping code maintainable.
+1 from me.
—
Morgan Fainberg
On October 16, 2014 at 20:45:35, Joe Gordon (joe.gord...@gmail.com) wrote:
On Thu, Oct 16, 2014 at 8:11 PM, Angus
Chris,
Best of luck on the new adventure! Definitely don’t be a stranger!
Cheers,
Morgan
On Oct 22, 2014, at 10:37, Chris Behrens cbehr...@codestud.com wrote:
Hey all,
Just wanted to drop a quick note to say that I decided to leave Rackspace to
pursue another opportunity. My last day
1 - 100 of 481 matches
Mail list logo
