-Original Message-
From: Brant Knudson
Reply: OpenStack Development Mailing List (not for usage questions)
>
Date: September 12, 2014 at 14:32:20
To: OpenStack Development Mailing List (not for usage questions)
>
Subject: Re: [openstack-dev] masking X-Auth-Token in debug output - propo
/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
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
Responses in-line.
-Original Message-
From: Robert Collins
Reply: OpenStack Development Mailing List (not for usage questions)
>
Date: September 7, 2014 at 20:16:32
To: OpenStack Development Mailing List >
Subject: [openstack-dev] doubling our core review bandwidth
> I hope the subjec
Comments in line (added my thoughts on a couple of the targets Sean
outlined).
On Thursday, September 4, 2014, Sean Dague wrote:
>
>
> Here is my top 5 list:
>
> 1. Functional Testing in Integrated projects
>
> The justification for this is here -
> http://lists.openstack.org/pipermail/openstack-
On Sunday, August 24, 2014, Anne Gentle 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 sample config is
ren
-Original Message-
From: Doug Hellmann
Reply: OpenStack Development Mailing List (not for usage questions)
>
Date: August 15, 2014 at 13:29:15
To: Ben Nemec >, OpenStack Development Mailing List
(not for usage questions) >
Subject: Re: [openstack-dev] [oslo][db] Nominating Mike Bayer f
-Original Message-
From: Thierry Carrez
Reply: OpenStack Development Mailing List (not for usage questions)
>
Date: July 30, 2014 at 05:20:28
To: openstack-dev@lists.openstack.org >
Subject: Re: [openstack-dev] [Keystone] Survey on Token Provider Usage
> Morgan Fainberg wrote
On Thursday, July 31, 2014, Russell Bryant 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 call from re
and check to see how 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
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 used
On Wednesday, July 23, 2014, Russell Bryant 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 Keysto
but specifics are still up in the air as this is under active
development.
These are just some of benefits of V3, there are a lot of improvements over V2
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
--
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 openstack-dev@lists.openstack
: 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:
>
>
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
On Wednesday, July 16, 2014, Joe Gordon wrote:
On Tue, Jul 15, 2014 at 7:20 AM, Morgan Fainberg
wrote:
On Tuesday, July 15, 2014, Steven Hardy 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,
> >
>
> > 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
> 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 ch
On Tuesday, July 15, 2014, Steven Hardy 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, an
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 wit
Here is the list of patches pending to resolve this issue (Keystone Master,
Keystone Stable/Icehouse, and Tempest)
https://review.openstack.org/#/q/status:open+topic:bug/1334368,n,z
—
Morgan Fainberg
--
From: Nathan Kinder nkin
default 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
.
Cheers,
Morgan
—
Morgan Fainberg
From: Tom Fifield t...@openstack.org
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: June 24, 2014 at 20:23:42
To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
Subject: Re
The Keystone team would like to announce the official split of
python-keystoneclient and the Keystone middleware code.
Over time the middleware (auth_token, s3_token, ec2_token) has developed into a
fairly expansive code base and
includes dependencies that are not necessarily appropriate for the
o Niu 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 > 写道：
> >
> > Great. Thi
to work with newer
> 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:
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 (n
+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
This sounds totally reasonable. +1 to keeping style-specific changes consistent
across a release.
—
Morgan Fainberg
From: Clint Byrum cl...@fewbar.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: June 16, 2014 at 10:51:31
To
is
awful (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
On Thu, Jun 12, 2014 at 1:59 PM, Sean Dague wrote:
The only thing it makes harder is you have to generate your own token to
run the curl command. The rest is there.
Well I would have imagine that the curl command debug are here so people can
easily copy and paste them and/or tweak them, but su
}%(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
, 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
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
> 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
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
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
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
To
+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
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
a
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 wrote:
> On 05/21/2014 11:09 AM, Chuck Thier wrot
)
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
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
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
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 l
On March 4, 2014 at 10:45:02, Vishvananda Ishaya (vishvana...@gmail.com) wrote:
On Mar 3, 2014, at 11:32 AM, Jay Pipes wrote:
> On Mon, 2014-03-03 at 11:09 -0800, Vishvananda Ishaya wrote:
>> On Mar 3, 2014, at 6:48 AM, Jay Pipes wrote:
>>
>>> On Sun, 2014-03-0
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
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
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 benchmark
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
On Thursday, February 27, 2014, Dolph Mathews
wrote:
>
> On Thu, Feb 27, 2014 at 11:52 AM, Jay Pipes
>
> > wrote:
>
>> On Thu, 2014-02-27 at 16:13 +, Henry Nash wrote:
>> > So a couple of things about this:
>> >
>> >
>> > 1) Today (and also true for Grizzly and Havana), the user can chose
>
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
, 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
t 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
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
Yes! There is a reason Keystone has a very small footprint of
caching/invalidation done so far. It really needs to be correct when it
comes to proper invalidation logic. I am happy to offer some help in
determining logic for caching/invalidation with Dogpile.cache in mind as we
get it into oslo a
Keystone uses dogpile.cache and I am making an effort to add it into the
oslo incubator cache library that was recently merged.
Cheers,
--Morgan
On Thu, Jan 23, 2014 at 1:35 PM, Renat Akhmerov wrote:
>
> On 23 Jan 2014, at 08:41, Joshua Harlow wrote:
>
> > So to me memoizing is typically a pre
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
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 (doug.hellm...@dreamhost.co
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
recommen
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 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 programs as a home.
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 p
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 wrote:
++ and
Feel free to try though.
Jamie
>
>
> --
> Adrian
>
>
> Original message
> From: Morgan Fainberg
> Date:12/04/2013 6:17 PM (GMT-08:00)
> To: Jamie Lennox ,"OpenStack Development Mailing List (not for usage
> questions)"
> Subject: Re: [op
On December 4, 2013 at 18:05:07, Jamie Lennox (jamielen...@redhat.com) wrote:
On Wed, 2013-12-04 at 20:48 -0500, David Stanek wrote:
> 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
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.
(Sent
> 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
e one real major hurdle
to get converted over, 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 p
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 wrote:
> Hi,
>
> So maybe if it gets to the point where
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. Htt
taclasses have their
places, but it really makes it hard to clearly view what is going on
in a straight forward manner. I would prefer to keep metaclass use
limited (wherever possible) with the exception of abstract base
classes (which are straightforward enough to understand). I think
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, ke
ontext
of Congress groups or Groups that Keystone sees. While I am not
opposed to a grouping mechanism within the policy engine, I want to
make sure everyone has a clear understanding of the concepts being
described (there was a recent issue with two concepts in keystone
a little short to convey that.
--Morgan Fainberg
On Sunday, November 10, 2013, Robert Collins wrote:
> On 9 November 2013 01:51, Morgan Fainberg >
> wrote:
>
> > I agree this would be interesting but if it isn't configurable (e.g. A
> > mechanism to support current
idea. and we could try it out for a
> few weeks to see what happen.
>
>
I agree this would be interesting but if it isn't configurable (e.g. A
mechanism to support current behavior) I think this would very much disrupt
the workflow I use. If configurable, I'd be open to it, i
patchset.
"Hard to test" is too similar to F.
Just my general feelings 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
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 is
+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
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:
> https://review.opensta
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
On Tue, Oct 15, 2013 at 5:05 PM, Doug Hellmann
wrote:
>
>
> 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
> would also welcome
ay just not be feasible/worth the effort in the grand scheme 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
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
a vocal advocate for increased usability and ease of
deployment for all of OpenStack. I would be honored to also serve as a
member of the TC, collaborating, and helping to guide the technical
direction of the project as a whole.
Cheers,
Morgan Fainberg
___
O
On Fri, Sep 20, 2013 at 3:20 PM, Monty Taylor wrote:
>
> What if we rethought the organization just a little bit. Instead of
> having oslo-incubator from which we copy code, and then oslo.* that we
> consume as libraries, what if:
>
> - we split all oslo modules into their own repos from the star
there. Also is there a minimum version that you require? I think getting
the packagers involved (and know if there is a minimum version requirement)
is the best way to know if it should be accepted.
Cheers,
Morgan Fainberg
IRC: morganfainberg
On Thu, Sep 19, 2013 at 2:08 PM, Mark Washenb
packaging ?if it requires packaging). With that being said, I agree that
it make sense for other (non-openstack) libraries to be added carefully
late in the cycle. Perhaps the best would be to limit additions to prior
to the release Feature-Freeze.
Cheers,
Morgan Fainberg
On Sunday, September 15
place because other things changed? At a certain point restore from
backup is really the only sane option. That threshold isn't exactly a long
period of time.
Cheers,
Morgan Fainberg
IRC: morganfainberg
On Wed, Sep 11, 2013 at 10:30 PM, Robert Collins
wrote:
> I think having backup tab
NICE!!
On Wed, Sep 4, 2013 at 11:05 AM, Dan Smith wrote:
> > Because we landed a patch to tox upstream to use setup.py develop
> > instead of sdist+install like our run_tests.sh scripts do - this means
> > that with the new tox config changes, tox runs should be just as quick
> > as run_tests.s
import is likely going to take a significant amount of
refactoring. My guess is that it's going to be a bit late in the cycle,
but we will see what comes up.
--Morgan Fainberg
IRC: morganfainberg
On Wed, Sep 4, 2013 at 8:21 AM, Dolph Mathews wrote:
>
> On Wed, Sep 4, 2013 at 9:5
you are looking for. It would still require lookups
to the backend for a number of reasons (not listed, as I don't think it is
relevant for this conversation).
--
Morgan Fainberg
IRC: morganfainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists
tone,
but I think it would make understanding what should be implemented when
subclassing for driver development (and similar pluggable systems) a bit
more clear.
Cheers!
--
Morgan Fainberg
Sr. Software Architect | Metacloud, Inc
Email: m...@metacloud.com
IRC: morganfainberg
_
penstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
I really like this concept. This would be a very nice level of
transparency (not that the TC hides anything) and makes it much easier to
see what is/has been going on and how we got there.
n it comes to review, I am going to agree with Sean here, it is a boon
on large changes. I am against lessening/removing H302; but I understand
why people desire it eased up.
Cheers,
Morgan Fainberg
IRC: morganfainberg
On Tue, Aug 6, 2013 at 1:18 PM, Christopher Armstrong <
chris.armstr...@
=keystone.token.providers.uuid.Provider
In older versions I believe the option (still in the [token] section) is:
token_format=UUID
I hope this info helps you out some.
Cheers,
Morgan Fainberg
Sent from my iPhone (please excuse the brevity)
31/07/2013, Paul Michali :
> Yeah I was playing with t
ommit of Icehouse (barring
any major issue) the point in which we move to Alembric. We can be
selective in taking extension modifications that add migration repos if it
is a major concern that moving to Alembric is going to be really painful.
Cheers,
Morgan Fainberg
On Thu, Jul 25, 2013 at 7:35 PM,
penstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>
> __**_
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.**org
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
+1 to what Jay said. I was actually getting ready to write a very similar
email.
Cheers,
Morgan Fainberg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
around migrate issues
with SQLite and the limited Alter support.
In one of the discussions in IRC I had offered to help with the effort
of moving away from SQLite migration testing; if the nova-way is the
way we want to go, I'll be happy to help contribute to that.
Cheers,
Morgan Fainberg
__
the token_id to the driver, instead of
in-line within the driver. The original fix should have been correct
in hashing the PKI token to the short-form "ID". Your fix to simply
hash the tokens is the correct one and more closely mirrors how the
original fix was implemented.
If y
401 - 500 of 502 matches
Mail list logo
