Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On Tue, Apr 19, 2016 at 7:57 AM, Dean Troyer wrote: > On Tue, Apr 19, 2016 at 9:06 AM, Adam Young wrote: > >> I wonder how much of that is Token caching. In a typical CLI use patter, >> a new token is created each time a client is called, with no passing

Re: [openstack-dev] [Keystone] State of Fernet Token deployment

On Mon, Apr 18, 2016 at 5:43 PM, Matt Fischer <m...@mattfischer.com> wrote: > On Mon, Apr 18, 2016 at 12:52 PM, Morgan Fainberg < > morgan.fainb...@gmail.com> wrote: > >> >> >> On Mon, Apr 18, 2016 at 7:29 AM, Brant Knudson <b...@acm.org> wrote: &

Re: [openstack-dev] [Keystone] State of Fernet Token deployment

On Mon, Apr 18, 2016 at 7:29 AM, Brant Knudson wrote: > > > On Fri, Apr 15, 2016 at 9:04 PM, Adam Young wrote: > >> We all want Fernet to be a reality. We ain't there yet (Except for mfish >> who has no patience) but we are getting closer. The goal is to get

Re: [openstack-dev] [all] removal of "Using keystoneauth correctly in projects" from cross project schedule

On Mon, Apr 18, 2016 at 6:50 AM, Sean Dague wrote: > After chatting with Monty and Thierry this morning, and trying to figure > out the right way to ensure that enough voices are in the requirements > x-p session, we've decided to do the following: > > * remove "Using

[openstack-dev] [keystone] Newton midycle planning

It is that time again, the time to plan the Keystone midcycle! Looking at the schedule [1] for Newton, the weeks that make the most sense look to be (not in preferential order): R-14 June 27-01 R-12 July 11-15 R-11 July 18-22 As usual this will be a 3 day event (probably Wed, Thurs, Fri), and

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

On Tue, Apr 12, 2016 at 8:06 PM, Adrian Otto wrote: > Please don't miss the point here. We are seeking a solution that allows a > location to place a client side encrypted blob of data (A TLS cert) that > multiple magnum-conductor processes on different hosts can reach

Re: [openstack-dev] [keystone][performance][profiling] Profiling Mitaka Keystone: some results and asking for a help

12, 2016 at 8:16 AM, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > Fixes have been proposed for both of these bugs. > > Cheers, > --Morgan > > On Tue, Apr 12, 2016 at 12:38 AM, Dina Belova <dbel...@mirantis.com> > wrote: > >> Matt, >> >> T

Re: [openstack-dev] [keystone][performance][profiling] Profiling Mitaka Keystone: some results and asking for a help

Fixes have been proposed for both of these bugs. Cheers, --Morgan On Tue, Apr 12, 2016 at 12:38 AM, Dina Belova wrote: > Matt, > > Thanks for sharing the information about your benchmark. Indeed we need to > follow up on this topic (I'll attend the summit). Let's try to

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

On Sun, Apr 10, 2016 at 4:37 PM, Clint Byrum wrote: > Excerpts from Matt Riedemann's message of 2016-04-09 06:42:54 -0700: > > There is also disincentive in +1ing a change that you don't understand > > and is wrong and then a core comes along and -1s it (you get dinged for > >

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

On Apr 9, 2016 12:05, "Ken'ichi Ohmichi" wrote: > > > 2016/04/08 10:55、Anita Kuno : > > >> On 04/08/2016 01:42 PM, Dmitry Tantsur wrote: > >> 2016-04-08 19:26 GMT+02:00 Davanum Srinivas : > >> > >>> Team, > >>> > >>> Steve pointed

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

On Fri, Apr 8, 2016 at 4:54 PM, Dolph Mathews wrote: > > > On Friday, April 8, 2016, John Dickinson wrote: > >> >> >> On 8 Apr 2016, at 13:35, Jeremy Stanley wrote: >> >> > On 2016-04-08 19:42:18 +0200 (+0200), Dmitry Tantsur wrote: >> >> There are many

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

On Fri, Apr 8, 2016 at 1:42 PM, Dmitry Tantsur wrote: > > 2016-04-08 19:26 GMT+02:00 Davanum Srinivas : > >> Team, >> >> Steve pointed out to a problem in Stackalytics: >> https://twitter.com/stevebot/status/718185667709267969 > > > There are many ways

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

On Wed, Apr 6, 2016 at 6:29 PM, David Stanek wrote: > > 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

Re: [openstack-dev] [designate][osc] new sub commands - how should they be named?

On Wed, Apr 6, 2016 at 7:44 AM, Sheel Rana Insaan wrote: > Hey Graham, > > I just added service for block storage, we have named these > openstack volume service list/enable/disable. > > Same protocol is used for nova as well previosly. > > Hope this will help. > >

Re: [openstack-dev] Acknowledging Jim Blair's work on the TC

On Fri, Apr 1, 2016 at 12:06 PM, Anita Kuno wrote: > Jim is an incumbent on the TC this election and he didn't run. I'm > posting this to express my thanks to Jim for his work and dedication on > the TC. > > Jim, I think your commitment to open source, spanning many years

[openstack-dev] [election][tc] TC Candidacy

consumers of “cloud” technologies. Finally, I look forward to continuing to be part of this amazing Open Source community for many more development cycles. Thanks for your time, consideration, and contributions to this community. Cheers, Morgan Fainberg IRC: "morgan" (or "not

Re: [openstack-dev] [all][infra] revert new gerrit

On Fri, Mar 18, 2016 at 8:35 AM, Monty Taylor wrote: > On 03/18/2016 08:31 AM, Andrey Kurilin wrote: > >> Hi all! >> >> I want to start this thread because I'm tired. I spent a lot of time, >> but I can't review as easy as it was with old interface. New Gerrit is >> awful.

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

On Thu, Mar 10, 2016 at 1:54 PM, Xav Paice <xavpa...@gmail.com> wrote: > > > On 11 March 2016 at 10:45, Morgan Fainberg <morgan.fainb...@gmail.com> > wrote: > >> >> >> On Thu, Mar 10, 2016 at 1:29 PM, Xav Paice <xavpa...@gmail.com> wro

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

On Thu, Mar 10, 2016 at 1:29 PM, Xav Paice wrote: > Remember that we're talking here about all the projects, not just > keystone. I can't see that we'll move everything to subpaths at any time > soon, and until that point we still need to at least make an informal >

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

On Thu, Mar 10, 2016 at 4:43 AM, Sean Dague wrote: > On 03/10/2016 07:11 AM, Tim Bell wrote: > > > > > > From: Sylvain Bauza > > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > >

Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

This type of configuration is not supported as Matt highlighted. What problem are you trying to solve with having the multiple token formats? Before we discuss if it would be a good idea, we need to know what problem you are solving. On Tue, Mar 8, 2016 at 8:06 AM, Matt Fischer

Re: [openstack-dev] When to revert a patch?

On Mar 4, 2016 10:16, "Monty Taylor" wrote: > > On 03/04/2016 08:37 AM, Ruby Loo wrote: >> >> Hijacked from ' [openstack-dev] [ironic] Remember to follow RFE process' >> thread: >> >> > Should we revert the patch [1] for now? (Disclaimer. I haven't looked at the >>

Re: [openstack-dev] [Keystone] State of Fernet tokens

On Wed, Feb 24, 2016 at 9:27 PM, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > On Wed, Feb 24, 2016 at 8:50 PM, Adam Young <ayo...@redhat.com> wrote: > >> A lot of people seem to be counting on Fernet tokens, so I figured I'd >> give a quick up

Re: [openstack-dev] [Keystone] State of Fernet tokens

On Wed, Feb 24, 2016 at 8:50 PM, Adam Young wrote: > A lot of people seem to be counting on Fernet tokens, so I figured I'd > give a quick update. > > Back in December, I made a quick check to see what would happen if we > swapped Fernet in as the default token provider. A

Re: [openstack-dev] Versions api always returns the listen address

On Tue, Feb 23, 2016 at 3:49 AM, Gyorgy Szombathelyi < gyorgy.szombathe...@doclerholding.com> wrote: > Hi! > > Just noticed by a failing > tempest.api.compute.test_versions.TestVersions.test_get_version_details > test: > The versions answer of the components always return the listen address of >

Re: [openstack-dev] [all] A proposal to separate the design summit

+1 hits all the points. Solid proposal. On Feb 22, 2016 7:14 AM, "Thierry Carrez" wrote: > Hi everyone, > > TL;DR: Let's split the events, starting after Barcelona. > > Long long version: > > In a global and virtual community, high-bandwidth face-to-face time is >

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

On Sat, Feb 20, 2016 at 8:27 PM, Michał Jastrzębski wrote: > I don't think kolla will need limit of cores per company, we are > diverse and our diversity grows if anything. Mirantis did make a lot > of commitment this release, and that's great, but that won't change > our

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Fri, Feb 19, 2016 at 8:24 AM, Sean Dague wrote: > On 02/19/2016 11:15 AM, Ben Swartzlander wrote: > > On 02/19/2016 10:57 AM, Sean Dague wrote: > >> On 02/18/2016 10:38 AM, D'Angelo, Scott wrote: > >>> Cinder team is proposing to add support for API microversions [1]. It > >>>

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Adam, CORS shouldn't need catalog integration ever. CORS is a layer above anything in the service catalog and doesn't provide extra security except signalling to the javascript vm it can access resources outside of it's current domain; something that can be worked around in many ways including

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 9:58 AM, Sean Dague wrote: > On 02/18/2016 12:17 PM, Michael Krotscheck wrote: > > Clarifying: > > > > On Thu, Feb 18, 2016 at 2:32 AM Sean Dague > > wrote: > > > > Ok, to make sure we all ended up on the same

Re: [openstack-dev] [all] [cinder] [glance] tenant vs. project

Not all clients are fully v3 compatible, this is the effort to move to session, from keystone client.session to keystone auth.session, and os-client-config. Since this work has been slow, we are not 100% there yet, but as Henrique said, OpenStack client does support both consistently. If devstack

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Wed, Feb 17, 2016 at 2:24 PM, Doug Hellmann wrote: > Excerpts from Morgan Fainberg's message of 2016-02-17 10:44:50 -0800: > > I am very much against adding extra data to paste-ini especially config > > data that is consumed by the applications. I generally understand

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

I am very much against adding extra data to paste-ini especially config data that is consumed by the applications. I generally understand why it was implemented in the way it has. The oslo_config change that Doug linked will make this need mostly go away however. I would like to move us towards

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

On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague wrote: > On 02/17/2016 08:42 AM, Doug Hellmann wrote: > > Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100: > >> Le 17/02/2016 13:43, Henry Gessau a écrit : > >>> And it looks like eventlet 0.18.3 breaks neutron: >

Re: [openstack-dev] [grenade][keystone] Keystone multinode grenade

On Mon, Feb 8, 2016 at 5:20 AM, Grasza, Grzegorz wrote: > > > From: Sean Dague [mailto:s...@dague.net] > > > > On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote: > > > > > >> From: Sean Dague [mailto:s...@dague.net] > > >> > > >> On 02/04/2016 10:25 AM, Grasza, Grzegorz

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

On Sun, Feb 7, 2016 at 12:07 PM, Jay Pipes wrote: > Hello all, > > tl;dr > = > > I have long thought that the OpenStack Summits have become too commercial > and provide little value to the software engineers contributing to > OpenStack. > > I propose the following: > > 1)

Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported

igration). > > Tim > > All on the table for discussion - right now the S3Token code relies on the EC2 API code in Keystone, so they cannot be separated without more work. We'll work on this in either case and figure the best way going forward. Cheers, --Morgan > From: Morga

Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported

On Feb 5, 2016 20:42, "Andrey Pavlov" wrote: > > Tim, > > swift3 calls keystone for authentication (in similar way as ec2api) > > Andrey. > > On Fri, Feb 5, 2016 at 11:51 PM, Tim Bell wrote: > > Does Swift3 (for S3 on SWIFT) need Keystone or is it

[openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

Looking over the state [and relatively untested nature] of the Keystone EC2 API and S3Token APIs, I want to propose deprecating these mechanisms of auth within Keystone at this time. These systems have been historically poorly tested and supported and have remained broken / incompatible for long

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

On Feb 5, 2016 09:43, "Tim Bell" wrote: > > > Is it certain that there is no need for the functions with the new EC2-API functions ? > > The S3 functions are somewhat separated from the EC2 API. How does SWIFT implement the S3 compatibility layer ? > > Getting a ‘to be

Re: [openstack-dev] [grenade][keystone] Keystone multinode grenade

On Fri, Feb 5, 2016 at 6:06 AM, Sean Dague wrote: > On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote: > > > > > >> -Original Message- > >> From: Sean Dague [mailto:s...@dague.net] > >> > >> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote: > >>> > >>> Keystone is just one

Re: [openstack-dev] [all] the trouble with names

On Thu, Feb 4, 2016 at 4:51 AM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2016-02-04 06:38:26 -0500: > > A few issues have crept up recently with the service catalog, API > > headers, API end points, and even similarly named resources in different > >

Re: [openstack-dev] [keystone] Domain Specific Roles vs Local Groups

On Feb 2, 2016 19:38, "Yee, Guang" wrote: > > I presume there’s a spec coming for this “seductive approach”? Not sure if I get all of it. From what’s been described here, conceptually, isn’t “local groups”, DSRs, or role groups the same thing? > Subtle differences. Local

Re: [openstack-dev] [oslo] Sachi King for oslo core

Yay Sachi! On Jan 27, 2016 05:01, "Sachi King" wrote: > Thanks for the vote of confidence all, I look forward to expanding > what I'm working on. > > Cheers, > Sachi > > __ > OpenStack Development Mailing

Re: [openstack-dev] [keystone][neutron][requirements] - keystonemiddleware-4.1.0 performance regression

So this was due to a change in keystonemiddleware. We stopped doing in-memory caching of tokens per process, per worker by default [1]. There are a couple of reasons: 1) in-memory caching produced unreliable validation because some processed may have a cache, some may not 2) in-memory caching was

Re: [openstack-dev] [keystone][neutron][requirements] - keystonemiddleware-4.1.0 performance regression

As promised here are the fixes: https://review.openstack.org/#/q/Ifc17c27744dac5ad55e84752ca6f68169c2f5a86,n,z Proposed to both master and liberty. On Wed, Jan 20, 2016 at 12:15 PM, Sean Dague <s...@dague.net> wrote: > On 01/20/2016 02:59 PM, Morgan Fainberg wrote: > >

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

A standard method of rate limiting for OpenStack services would be a good thing to figure out. On Jan 13, 2016 02:56, "Jordan Pittier" wrote: > Hi, > Can't you just do some rate limiting at your webserver level ? > > On Tue, Jan 12, 2016 at 3:55 PM, McPeak, Travis

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

This needs to be proposed as a spec, not just a blueprint. For what it is worth, this has been discussed many times and it was determined that keystone as a project was not interested in really managing the life cycle of passwords on this front. Since we support the use of real Identity Stores

Re: [openstack-dev] [nova] path forward on making project_id optional in API URLs

As a note, there is potential that this will require older deployments that have historical names migrated to update project IDs to hex-strings. These are a minority of deployments at best, but this should be considered in the proposal so if this goes forward we can clearly communicate this change

Re: [openstack-dev] Nova scheduler startup when database is not available

On Wed, Dec 23, 2015 at 10:32 AM, Jay Pipes wrote: > On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote: > >> I've been looking into the startup constraints involved when launching >> Nova services with systemd using Type=notify (which causes systemd to >> wait for an

Re: [openstack-dev] [keystone] Addressing issue of keysone token expiry during long running operations

Right now the solution is to increase the token expiration time in keystone config. I personally am working on a longer term solution but it is a ways out (regarding changing how services pass authorization around internally). Unfortunately the current architecture makes changing how token

Re: [openstack-dev] [oslo][keystone] Move oslo.policy from oslo to keystone

For what is is worth, we originally proposed oslo.policy to graduate to Keystone when we were converting to the library. I still think it belongs in keystone (as long as the oslo team doesn't mind that long-term keystone team owns something in the oslo. namespace). The short term adding

[openstack-dev] Changes to Gerrit and handling double encoded slashes

Today (Dec 12) there was an update performed to gerrit web server changing how apache proxies requests to the java application. This change is in preperation for the update of gerrit planned for December 16th. We have moved from utilizing mod_rewrite to directly using mod_proxy. In performing this

Re: [openstack-dev] openstackdocstheme to be considered (very) harmful for your generated sphinx docs

On Mon, Dec 7, 2015 at 7:54 AM, Thomas Goirand wrote: > On 12/04/2015 03:23 PM, Anne Gentle wrote: > > > > > > On Fri, Dec 4, 2015 at 8:09 AM, Thomas Goirand > > wrote: > > > > Hi, > > > > I've investigated a bit the

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On Dec 7, 2015 17:51, "Brant Knudson" wrote: > > > > On Tue, Dec 1, 2015 at 12:57 AM, Steve Martinelli wrote: >> >> Trying to summarize here... >> >> - There isn't much interest in keeping eventlet around. >> - Folks are OK with running keystone in a WSGI

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

Chunked Encoding is a bad idea with mod_wsgi in general. While enabling it like that is fine, you are not guaranteed to get 100% consistent results simply because the wsgi spec did not/does not support it. Not all versions of mod_wsgi can enable it. So, in short, officially keystone does not

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On Tue, Dec 1, 2015 at 1:57 AM, Steve Martinelli wrote: > Trying to summarize here... > > - There isn't much interest in keeping eventlet around. > - Folks are OK with running keystone in a WSGI server, but feel they are > constrained by Apache. > - uWSGI could help to

Re: [openstack-dev] [openstack-announce] [release][stable][keystone][ironic] keystonemiddleware release 1.5.3 (kilo)

Here is the first pass at a fixture to handle the case that ceilometer is doing with the hacked-up memcache interface. This will be something supported by keystonemiddleware so it should not break randomly in the future: https://review.openstack.org/#/c/249794/ On Thu, Nov 26, 2015 at 7:27 AM,

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

happened to not >> > be cores, but it's a related organizational behavior taken to an >> extreme.) >> > >> > I can actually think of a few more specific examples, but they are >> > already described by one of the above. >> > >> >

Re: [openstack-dev] [release][stable][keystone] keystonemiddleware release 1.5.3 (kilo)

Would it be possible to get a bit more detail in (especially if other projects are mocking like this) what is being done so that I [or anothe rKeystone dev] can work towards a real mock/test module in keystonemiddleware so this doesn't occur again due to internal-interface mocking? On Tue, Nov

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

On Mon, Nov 23, 2015 at 8:51 AM, Dmitry Tantsur <dtant...@redhat.com> wrote: > On 11/23/2015 05:42 PM, Morgan Fainberg wrote: > >> Hi everyone, >> >> This email is being written in the context of Keystone more than any >> other project but I strongly belie

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

Hi everyone, This email is being written in the context of Keystone more than any other project but I strongly believe that other projects could benefit from a similar evaluation of the policy. Most projects have a policy that prevents the following scenario (it is a social policy not enforced

Re: [openstack-dev] [ironic][security] what is OK to put in DEBUG logs?

On Nov 18, 2015 13:52, "Devananda van der Veen" wrote: > > > On Wed, Nov 18, 2015 at 9:48 AM, Ruby Loo wrote: >> >> Hi, >> >> I think we all agree that it isn't OK to log credentials (like passwords) in DEBUG logs. However, what about other

Re: [openstack-dev] Help with getting keystone to migrate to Debian testing: fixing repoze.what and friends

On Nov 11, 2015 10:57, "Clint Byrum" wrote: > > Excerpts from Morgan Fainberg's message of 2015-11-10 20:17:12 -0800: > > On Nov 10, 2015 16:48, "Clint Byrum" wrote: > > > > > > Excerpts from Morgan Fainberg's message of 2015-11-10 15:31:16 -0800: > > > > On

Re: [openstack-dev] Help with getting keystone to migrate to Debian testing: fixing repoze.what and friends

On Tue, Nov 10, 2015 at 3:20 PM, Thomas Goirand wrote: > Hi there! > > All of Liberty would be migrating from Sid to Testing (which is the > pre-condition for an upload to offical Debian backports) if I didn't > have a really annoying situation with the repoze.{what,who}

Re: [openstack-dev] Help with getting keystone to migrate to Debian testing: fixing repoze.what and friends

On Nov 10, 2015 16:48, "Clint Byrum" wrote: > > Excerpts from Morgan Fainberg's message of 2015-11-10 15:31:16 -0800: > > On Tue, Nov 10, 2015 at 3:20 PM, Thomas Goirand wrote: > > > > > Hi there! > > > > > > All of Liberty would be migrating from Sid to

Re: [openstack-dev] [requirements] [infra] speeding up gate runs?

On Nov 4, 2015 09:14, "Sean Dague" wrote: > > On 11/04/2015 12:10 PM, Jeremy Stanley wrote: > > On 2015-11-04 08:43:27 -0600 (-0600), Matthew Thode wrote: > >> On 11/04/2015 06:47 AM, Sean Dague wrote: > > [...] > >>> Is there a nodepool cache strategy where we could pre build

Re: [openstack-dev] [all][api][tc][perfromance] API for getting only status of resources

On Nov 3, 2015 4:29 PM, "Clint Byrum" wrote: > > Excerpts from Boris Pavlovic's message of 2015-11-03 14:20:10 -0800: > > Hi stackers, > > > > Usually such projects like Heat, Tempest, Rally, Scalar, and other tool > > that works with OpenStack are working with resources (e.g.

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

As a core (and former PTL) I just ignored commit message -1s unless there is something majorly wrong (no bug id where one is needed, etc). I appreciate well formatted commits, but can we let this one go? This discussion is so far into the meta-bike-shedding (bike shedding about bike shedding

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

There is no reason why the wsgi app container matters. This is simply a "we should document use if uwsgi and/or gunicorn as an alternative to mod_wsgi". If one solution is better for the gate it will be used there and each deployment will make the determination of what they want to use. Adam's

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

I'm not seeing the source of this at a quick glance (in keystoneclient where I am assuming the plugin is being loaded from?). I'll look a bit more closely after I finish my food. --Morgan Sent via mobile > On Sep 18, 2015, at 12:32, Robert Collins wrote: > > I

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

The conversations around alternative wsgi containers (uwsgi, gunicorn, etc) still would be tied to apache or nginx. While it is possible to deploy without the webservers in some cases, jt would not be recommended nor do I see that being tested in gate. We want to leverage the auth support of

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

There is and has been desire to support uWSGI and other alternatives to mod_wsgi. There are a variety of operational reasons to consider uWSGI and/or gunicorn behind apache most notably to facilitate easier management of the processes independently of the webserver itself. With mod_wsgi the

Re: [openstack-dev] [all][elections] PTL nomination period is now over

Time.is is showing utc in "PM" not a 24 hour clock. It is past 1500 UTC at the moment. Sent via mobile > On Sep 17, 2015, at 08:05, Douglas Mendizábal > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > I think someone jumped the gun on this

Re: [openstack-dev] [all][elections] PTL nomination period is now over

On Thu, Sep 17, 2015 at 12:00 PM, Kevin Benton wrote: > It guarantees that if you hit the date deadline local time, that you won't > miss the deadline. It doesn't matter if there are extra hours afterwards. > The idea is that it gets rid of the need to do time zone

Re: [openstack-dev] Pycharm License for OpenStack developers

On Wed, Sep 16, 2015 at 11:12 AM, Joshua Harlow wrote: > Anyone know about the impact of: > > - > https://mmilinkov.wordpress.com/2015/09/04/jetbrains-lockin-we-told-you-so/ > > - http://blog.jetbrains.com/blog/2015/09/03/introducing-jetbrains-toolbox/ > > I'm pretty sure a

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

On Mon, Sep 14, 2015 at 2:46 PM, Sofer Athlan-Guyot <sathl...@redhat.com> wrote: > Morgan Fainberg <morgan.fainb...@gmail.com> writes: > > > On Mon, Sep 14, 2015 at 1:53 PM, Rich Megginson <rmegg...@redhat.com> > > wrote: > > > > > >

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

On Mon, Sep 14, 2015 at 1:53 PM, Rich Megginson wrote: > On 09/14/2015 02:30 PM, Sofer Athlan-Guyot wrote: > >> Hi, >> >> Gilles Dubreuil writes: >> >> A. The 'composite namevar' approach: >>> >>> keystone_tenant {'projectX::domainY': ... } >>> B.

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

On Fri, Sep 11, 2015 at 4:25 AM, Gilles Dubreuil wrote: > > > On 11/09/15 20:17, David Chadwick wrote: > > Whichever approach is adopted you need to consider the future and the > > longer term objective of moving to fully hierarchical names. I believe > > the current Keystone

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

We don't utilize email address for anything. It is not meant to be a top-level column. We've had a lot of discussions on this. The main result is we decided that Keystone should be getting out of the PII game as much as possible. I am against making email a top level attribute. Instead we

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

As I outlined (briefly) in my recent announcement of changes ( https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/ ) I will not be running for PTL of Keystone this next cycle (Mitaka). The role of PTL is a difficult but extremely rewarding job. It has been amazing to see

Re: [openstack-dev] [magnum]keystone version

> On Sep 5, 2015, at 22:14, Steve Martinelli wrote: > > +1, we're trying to deprecate the v2 API as soon as is sanely possible. Plus, > there's no reason to not use v3 since you can achieve everything you could in > v2, plus more goodness. > > Thanks, > > Steve

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

> On Sep 4, 2015, at 07:04, Monty Taylor wrote: > > mordred@camelot:~$ neutron net-create test-net-mt > Policy doesn't allow create_network to be performed. > > Thank you neutron. Excellent job. > > Here's what that looks like at the REST layer: > > DEBUG:

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

t, thanks. > > Henry > > On 4 Sep 2015, at 09:17, Thierry Carrez <thie...@openstack.org> wrote: > > > > Morgan Fainberg wrote: > >> > >>>I would like to request an FFE for the remaining two patches that > >>>are already

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

On Fri, Sep 4, 2015 at 10:35 AM, Mathieu Gagné <mga...@internap.com> wrote: > On 2015-09-04 12:50 PM, Monty Taylor wrote: > > On 09/04/2015 10:55 AM, Morgan Fainberg wrote: > >> > >> Obviously the translation of errors > >> would be more diffic

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

> On Sep 3, 2015, at 19:48, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > > >> On Sep 3, 2015, at 19:28, David Stanek <dsta...@dstanek.com> wrote: >> >> >>> On Thu, Sep 3, 2015 at 3:44 PM Henry Nash <hen...@linux.vne

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

> On Sep 3, 2015, at 19:28, David Stanek wrote: > > >> 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

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

It seems like Flask has a reasonable amount of support and there is a good ecosystem around it but that aside (as Jay said)... I definitely support exposing the schema to the end user; making it easier for the end user to validate input / model outputs for their integration with OpenStack services

Re: [openstack-dev] [api][keystone][openstackclient] Standards for object name attributes and filtering

On Thu, Aug 27, 2015 at 11:47 AM, Everett Toews everett.to...@rackspace.com wrote: On Aug 26, 2015, at 4:45 AM, Henry Nash hen...@linux.vnet.ibm.com wrote: Hi With keystone, we recently came across an issue in terms of the assumptions that the openstack client is making about the

Re: [openstack-dev] [puppet][keystone] Keystone resource naming with domain support - no '::domain' if 'Default'

This seems quite reasonable. +1 Sent via mobile On Aug 25, 2015, at 13:30, Rich Megginson rmegg...@redhat.com wrote: This concerns the support of the names of domain scoped Keystone resources (users, projects, etc.) in puppet. At the puppet-openstack meeting today [1] we decided that

Re: [openstack-dev] [oslo] incubator move to private modules

into their own package/module structure (and change the contracts however they see fit). -- Dims On Tue, Aug 25, 2015 at 1:48 AM, Morgan Fainberg morgan.fainb...@gmail.com wrote: Over time oslo incubator has become less important as most things are simply becoming libraries from

Re: [openstack-dev] [api] [docs] Generating API samples

Keystone doesn't use anything similar to sample requests at this time. Though I am sure there wouldn't be much opposition to it provided there was someone stepping up to do the work. Sent via mobile On Aug 24, 2015, at 08:51, Anne Gentle annegen...@justwriteclick.com wrote: Hi all,

Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources

While I don't think it is a bad idea to allow the arbitrary k/v on resources just be aware that the content gets a little wonky as you allow users to place anything they want on resources. I will also voice support for the tag model. The other option is a way to allow the extra values to have

[openstack-dev] [oslo] incubator move to private modules

Over time oslo incubator has become less important as most things are simply becoming libraries from the get-go. However, there is still code in incubator and particularly Keystone client has seen an issue where the incubator code is considered a public api by consuming projects. I would like

Re: [openstack-dev] Cross-project meeting times

I am ok with this moving as long as it doesn't camp on the Keystone meeting time ;). In all seriousness I'm not opposed to moving the meeting if it will include more people / make lives better for those who are there. Sent via mobile On Aug 19, 2015, at 08:20, Sean Dague s...@dague.net

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

On Aug 16, 2015, at 08:02, Michael Krotscheck krotsch...@gmail.com wrote: On Sat, Aug 15, 2015 at 11:02 AM Morgan Fainberg morgan.fainb...@gmail.com wrote: Please do not construe a major api change as backwards incompatible. This pagination was never supported in v3 properly/at all

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

On Aug 15, 2015, at 10:15, Michael Krotscheck krotsch...@gmail.com wrote: On Fri, Aug 14, 2015 at 2:26 PM Adam Young ayo...@redhat.com wrote: On 08/14/2015 12:43 PM, Michael Krotscheck wrote: 1- Do users want to page through search results? Does not matter: in Federation, the User

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

On Aug 15, 2015, at 10:58, Morgan Fainberg morgan.fainb...@gmail.com wrote: On Aug 15, 2015, at 10:15, Michael Krotscheck krotsch...@gmail.com wrote: On Fri, Aug 14, 2015 at 2:26 PM Adam Young ayo...@redhat.com wrote: On 08/14/2015 12:43 PM, Michael Krotscheck wrote: 1- Do users

Re: [openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities

towards and wouldn't block efforts to implement if it is not already available (if not available this is likely a mitaka goal). --Morgan Sent via mobile On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com wrote: On 08/14/2015 09:14 AM, Morgan Fainberg wrote: As a quick note the api

Re: [openstack-dev] [Keystone] [Horizon] Pagination support for Identity dashboard entities

steps, so please regard this paragraph as my personal opinion - I don't think Horizon could be lighting fast on its own (i.e. without additional services) with a lot of data without pagination. On Fri, Aug 14, 2015 at 6:03 PM Morgan Fainberg morgan.fainb...@gmail.com wrote: For the identity

<    1   2   3   4   5   >