The are still alive - http://specs.openstack.org/openstack/keystone-specs/
Regards,
Steve Martinelli
Software Developer - OpenStack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, ON L6G 1C7
Canada
From:
Adam Young
To
+1 to that, just `tox -e docs` and open
the generated file under doc/build/html
Regards,
Steve Martinelli
Software Developer - OpenStack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, ON L6G 1C7
Canada
Joe Gordon wrote on
08/16/2014 02
This is hardly a development related question.
Regards,
Steve Martinelli
Software Developer - OpenStack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, ON L6G 1C7
Canada
Aryeh Friedman wrote
on 08/25/2014 12:08:50 PM:
> From: Ar
> From: Doug Hellmann
> To: "OpenStack Development Mailing List
(not for usage questions)"
> ,
> Date: 08/26/2014 10:11 AM
> Subject: Re: [openstack-dev] [infra] [keystone]
pysaml2/xmlsec1 dep
> blocking keystone-to-keystone federation
>
>
> On Aug 26, 2014, at 7:44 AM, Sean Dague wrote:
>
FWIW, they Keystone team had discussed this topic a few
weeks ago. For the specs that didn't make FF, we pinged the author to see
if it would be re-submitted for Kilo. If we received a yes, then we moved
it to a separate Kilo folder [1][2][3]. Otherwise we were going to move
the spec into a new fol
++ to your suggestion David, I think making
the list of trusted IdPs publicly available makes sense.
- Steve
David Chadwick wrote
on 09/17/2014 09:37:21 AM:
> From: David Chadwick
> To: openstack-dev@lists.openstack.org, Kristy
Siu ,
> Date: 09/17/2014 09:42 AM
> Subject: Re: [openstack-dev]
Subject: Re: [openstack-dev] [Keystone][Horizon]
CORS and Federation
>
>
>
> On 17/09/2014 14:55, Marek Denis wrote:
> >
> >
> > On 17.09.2014 15:45, Steve Martinelli wrote:
> >> ++ to your suggestion David, I think making the list of trusted
IdPs
> &g
ended, so there won't be
any new API features landing in milestone 3. (Good time to keep an eye on
bugs :) )
That's all I can think of for now.
Thanks,
_________
Steve Martinelli
OpenStack Development - Keystone Core Member
Phone: (905) 41
Clicking on the magnifying glass icon (next to the project name) lists
all recent patches for that project (closed and open).
I have a bookmark that lists all open reviews of a project and
always try to keep it open in a tab, and open specific code reviews in
new tabs.
Steve
Chen CH Ji wrote on
Link to the docs for the debugger script:
http://docs.openstack.org/developer/oslotest/features.html#debugging-with-oslo-debug-helper
We have support for it in some of the Keystone related projects and folks
seem to find it useful. If may not fit your needs, but as Ben suggested,
give it a whir
Wondering if anyone can shed some light on this, it seems like a few of
the clients have been unable to build py33 environments lately:
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiTmFtZUVycm9yOiBuYW1lICdTdGFuZGFyZEVycm9yJyBpcyBub3QgZGVmaW5lZFwiIGJ1aWxkX3N0YXR1czonRkFJTFVSRSciLCJmaW
fix?
>
> Thanks
> Amit.
>
>
> > On Dec 17, 2014, at 3:38 PM, Jeremy Stanley wrote:
> >
> > On 2014-12-17 11:09:59 -0500 (-0500), Steve Martinelli wrote:
> > [...]
> >> The stack trace leads me to believe that docutils or sphinx is the
> >>
Howdy,
https://etherpad.openstack.org/p/kilo-keystone-midcycle is the etherpad
for the Keystone midcycle meetup. Similar to the Nova team, we should
start
collecting topics to cover, and sort them by priority later once we've
collected a few.
Steve___
Ajaya, also, I think you can go ahead and rebase your patches on master,
as
I don't see a need for them to depend on the patch you mention.
AFAICT you are adding new caching for identity and trusts, we already have
caching for a few other spots so this shouldn't conflict with dstanek's
work
of i
1. There's a process outlined here for debugging tests using testtools,
pdb should work:
http://docs.openstack.org/developer/neutron/devref/development.environment.html#debugging
FWIW, you can also look into using the olso debug helper script, but
looks like tempest doesn't support it ATM
+1
Steve
Morgan Fainberg wrote on 01/18/2015 02:11:02
PM:
> From: Morgan Fainberg
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: 01/18/2015 02:15 PM
> Subject: [openstack-dev] [Keystone] Nominating Brad Topol for
> Keystone-Spec core
>
> Hello all,
>
> I w
To add to Jarret's response:
I think this section of the SDK wiki
might help: https://wiki.openstack.org/wiki/SDKs#_javascript_
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, O
onment -> https://github.com/openstack/keystone/blob/master/tox.ini#L53
Which just kicks off this script ->
https://github.com/openstack/keystone/blob/master/tools/debug_helper.sh
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
Phone:
1-905-41
users / groups rules
Add domain support
Make groups a wildcard
Federated Keystone and Horizon
Completely open-ended, there isn't much
an expectation that we deliver this in Juno, but it's something we should
start thinking about.
Docs for everything!
Regards,
Steve Martinelli
Software
ify any number of roles
to be delegated in an OAuth Access Token, the only limitation I can think
of, is that only projects are supported, not domains.
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 W
h interfaces https://github.com/openstack/keystone/blob/master/etc/policy.json#L109..L114
have the same policy as the trust ones, (user_id:%(trust.trustor_user_id)s).
#1 is a bit more work, it would definitely be a new blueprint.
I'll see what I can do about providing
a more realistic
This seems like a good place to start:
https://github.com/openstack/python-ceilometerclient/blob/master/doc/source/index.rst
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, ON L6G 1C7
Modify the files, save the changes, and
restart the service.
(I usually use `screen -r` switch to
the service, ctrl+c, then re-run the command that launches the service.)
Thanks,
Steve
Matthew Oliver wrote on
04/24/2014 01:53:18 AM:
> From: Matthew Oliver
> To: "OpenStack Development Mailing
FWIW - Big +1 from me, Andreas always seems to have an
answer for whatever the infra question is.
Always very helpful and quick to respond. Definitely
a great candidate for project-config!
- Steve
cor...@inaugust.com (James E. Blair) wrote on 09/26/2014
11:35:02 AM:
> From: cor...@inaugust.com (
Again, FWIW, another +1 for Anita, for all the reasons
mentioned my James.
cor...@inaugust.com (James E. Blair) wrote on 09/26/2014
11:34:48 AM:
> From: cor...@inaugust.com (James E. Blair)
> To: openstack-dev@lists.openstack.org,
> Date: 09/26/2014 11:38 AM
> Subject: [openstack-dev] [infra] N
I think it depends on what you mean by
'external identity provider'
- I assume it's capable of speaking some sort of federation protocol. So
I'd rather explore adding more support for additional federation protocols/standards,
rather than making our own third backend.
Steve
Dave Walker wrote on
we could set up a job to publish under docs.o.org/api-wg pretty easily -
it seems like a good place to start to publish this content.
thanks for getting the repo all setup chris and jay.
Thanks,
_
Steve Martinelli
OpenStack Development - Keystone
Everett, I think the description is managed by this file:
https://github.com/openstack-infra/project-config/blob/master/gerrit/projects.yaml
- Steve
From: Everett Toews
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 10/22/2014 04:40 PM
Subject:Re:
FWIW, this looks good to me - looking forward to using it in
keystonemiddleware
Steve
From: Davanum Srinivas
To: openstack-dev@lists.openstack.org
Date: 11/05/2014 09:46 AM
Subject:[openstack-dev] [oslo][context] oslo.context repository
review request
Hello all,
At the D
ython-openstackclient from master?
Thanks,
_
Steve Martinelli
OpenStack Development - Keystone Core Member
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com
From: Itsuro ODA
To: openstack-dev@lists.openstack.org
Date: 11/12/2014 11:27 PM
Su
hanks,
_
Steve Martinelli
OpenStack Development - Keystone Core Member
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com
From: Rodrigo Duarte
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 11/13/2014 10:13 AM
Subject:Re: [openstack-d
You should probably email the openstack-dev
mailing list (openstack-dev@lists.openstack.org) or better yet, ask for
help in #openstack-nova on IRC.
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden
HTTP method and the endpoint. Thoughts?
Many apologies in advance for my pedantic-ness!
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, ON L6G 1C7
Canada
_
; ,
Date:
07/07/2014 01:39 PM
Subject:
Re: [openstack-dev]
[keystone][specs] listing the entire API in a new
spec
On Fri, Jul 4, 2014 at 12:31 AM, Steve Martinelli <steve...@ca.ibm.com>
wrote:
To add to the growing pains of keystone-specs,
one thing I've not
++
I always found this a bit too extra-cautious,
glad to see that it might go.
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, ON L6G 1C7
Canada
From:
Dolph Mathews
To
What are the benefits of doing this over
looking at the existing rechecks, and if not there opening a bug and rechecking
the new bug?
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, ON
.
Regards,
Steve Martinelli
Software Developer - Openstack
Keystone Core Member
Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com
8200 Warden Ave
Markham, ON L6G 1C7
Canada
From:
"Joe Jiang"
To:
openstack-dev@lists.openstack.org,
Date:
07/16/2014 07:37
Done - https://review.openstack.org/#/c/111865/
But it would be great if the swift team
could push this one too: https://review.openstack.org/#/c/111869/
(since it's the only *-specs on specs.openstack.org that doesn't look the
same)
Regards,
Steve Martinelli
Software Developer -
Unless I'm mistaken, the project ID should be a UUID.
Thanks,
_
Steve Martinelli | A4-317 @ IBM Toronto Software Lab
Software Developer - OpenStack
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com
From: Kurt Griffiths
To: OpenStac
,
_
Steve Martinelli | A4-317 @ IBM Toronto Software Lab
Software Developer - OpenStack
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com
From: "Miller, Mark M (EB SW Cloud - R&D - Corvallis)"
To: OpenStack Development Mailing List
,
Date
sing an oauth client, the delegate would input both the key and
secret; the client would then sign the request and send only the key and
*other oauth specific variables* over to the server side.
Thanks,
_________
Steve Martinelli | A4-317 @ IBM Toronto Software La
uld still need to
sign the request correctly (done only with the correct consumer
key/secret).
Thanks,
_________
Steve Martinelli | A4-317 @ IBM Toronto Software Lab
Software Developer - OpenStack
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com
Hi David,
I don't want to derail anything, as there are still open issues in your
note; but it's worth mentioning that the session fixation attack issue you
mentioned was in OAuth1.0, it was addressed in OAuth1.0a.
Thanks,
_____
Steve Martinell
Easy +1
Thanks,
_
Steve Martinelli | A4-317 @ IBM Toronto Software Lab
Software Developer - OpenStack
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com
From: "Yee, Guang"
To: OpenStack Development Mailing List
,
Dat
27;s
structured, then it's just a call to /auth/tokens.
Thanks,
_________
Steve Martinelli | A4-317 @ IBM Toronto Software Lab
Software Developer - OpenStack
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com
From: Steven Hardy
To: openstack-dev
Also, you can checkout out the api spec here:
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-oauth1-ext.md
Thanks,
_
Steve Martinelli | A4-317 @ IBM Toronto Software Lab
Software
- David Stanek for QA
- Dolph Matthews for Stable and VMT
I've updated https://wiki.openstack.org/wiki/CrossProjectLiaisons
accordingly
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
__
OpenStack Developme
ed!!
https://github.com/openstack/oslo-incubator/tree/master/openstack/common/apiclient
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
From: Sean Dague
To: openstack-dev@lists.openstack.org
Date: 2015/11/10 08:03 AM
Subject:Re: [openstack-dev] [oslo] Graduate cliuti
So I don't know the intricacies of the baremetal APIs, but hopefully I can
shed some light on best practices.
Do try to reuse the existing actions (
http://docs.openstack.org/developer/python-openstackclient/commands.html#actions
)
Do use "create", "delete", "set", "show" and "list" for basic CRU
As a -sdks regular, I wouldn't mind some of the API folks crashing the
channel :)
If it makes sense, then why not. There are already some folks that are
involved in both efforts (Everett).
Steve
From: Sean Dague
To: "OpenStack Development Mailing List (not for usage questions)"
objections
from the current stable-maint-core and keystone-stable-maint teams, then
I'd like to add him.
Thanks,
Steve Martinelli
Keystone Project Team Lead
__
OpenStack Development Mailing List (not for usage questio
Michael Krotscheck wrote on 2015/11/23 10:55:04 AM:
> From: Michael Krotscheck
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: 2015/11/23 10:56 AM
> Subject: [openstack-dev] [oslo] A special thank you to Davanum (Dims)
>
> Have you ever wanted to thank someone dir
So it's only for this time around (Mitaka-1) that I'll have to tag bugs as
fix-released, because the release automation will just leave a comment?
Going forward, the bugs will be automatically marked as fix-released, so
the automation won't change their states when we release?
I'd like to pin down a date and location for our mid-cycle meetup. I've
created a very short form for folks to fill out:
http://goo.gl/forms/uNsGSRdRLl
Depending on the number of responses received (normally we see about 20-30
folks at the mid-cycle), I may make a final call on the date and locat
I'd like to pin down a date and location for our mid-cycle meetup. I've
created a very short form for folks to fill out:
http://goo.gl/forms/uNsGSRdRLl
Depending on the number of responses received (normally we see about 20-30
folks at the mid-cycle), I may make a final call on the date and locat
23 responses later and it's settled, we'll be having the midcycle in Austin
TX between January 27-29. I've updated the wiki to reflect this update:
https://wiki.openstack.org/wiki/Sprints/KeystoneMitakaSprint
Looking forward to seeing everyone there!
- Steve
Steve Martinelli/To
hanks!
Steve Martinelli
OpenStack Keystone Project Team Lead
[0]
https://github.com/openstack/keystone/blob/b475040636ccc954949e6372a60dd86845644611/keystone/server/eventlet.py#L77-L80
[1]
https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/assignment/bac
ed to know how other projects approach this
subject. I think a roll call feature for -specs would be great, similar to
how there is one for governance changes. Do others just use +2/+2/+A? In
keystone we've often let specs sit for a little to give other cores a
chance to chime in. Thoughts?
Than
you probably want to propose a change to this file:
https://github.com/openstack-infra/project-config/blob/master/specs/specs.yaml
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
From: "GROSZ, Maty (Maty)"
To: "OpenStack Development Mailing List (not for
/openstack-infra/project-config/blob/master/specs/specs.yaml
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
Inactive hide details for "GROSZ, Maty (Maty)" ---2015/12/01 01:21:47
AM---Hey, All vitrage specs are written and kept in the v"GROSZ, Maty
(Maty)" ---201
to look
into this scenario and have suggestions?
- jlk
On Mon, Nov 30, 2015 at 10:26 AM, Steve Martinelli <
steve...@ca.ibm.com> wrote:
This post is being sent again to the operators mailing list, and i
apologize if it's duplicated fo
well said, +1 from me (via the osc-core team)
stevemar
From: Monty Taylor
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 2015/12/03 11:55 AM
Subject:[openstack-dev] [os-client-config] Proposing Morgan Fainberg
for core
Hey
+1, solid reasoning (surface area that infra hits vs osc), would love to
have the infra-core team onboard
stevemar
From: Monty Taylor
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 2015/12/03 11:53 AM
Subject:[openstack-dev] [os-client-co
d upcoming
deprecated functionality in Mitaka
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 server, but feel they are
constrained by Ap
I tossed up a patch to release 3.2.0:
https://review.openstack.org/#/c/254519/
stevemar
From: Jeremy Stanley
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 2015/12/07 09:56 PM
Subject:Re: [openstack-dev] [release][oslo] ImportError: No mo
icy/commit/b5f07dfe4cd4a5d12c7fecbc3954694d934de642
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
From: Timothy Symanczyk
To: "OpenStack Development Mailing List (not for usage questions)"
, "Kris G. Lindgren"
, Oguz Yarimtepe
,
ad
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Date: 05/25/2016 09:09 AM
>> Subject: Re: [openstack-dev] [keystone] New Core Reviewer (sent on
>> behalf of Steve Martinelli)
>>
On Thu, May 26, 2016 at 12:59 PM, Adam Young wrote:
> On 05/26/2016 11:36 AM, Morgan Fainberg wrote:
>
>
>
> On Thu, May 26, 2016 at 7:55 AM, Adam Young wrote:
>
>> Some mix of these three tests is almost always failing:
>>
>> gate-keystone-dsvm-functional-nv FAILURE in 20m 04s (non-voting)
>> g
Looks like Manila is using the service name instead of type
(X-OpenStack-Manila-API-Version) according to this link anyway:
http://docs.openstack.org/developer/manila/devref/api_microversion_dev.html
Keystone can follow the cross project spec and use the service type
(Identity instead of Keystone)
>
>
>
> http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
>
>
>
> The example already suggests what needs to be done in case of the identity
> project J
>
>
>
> --
>
> Goutham
>
>
>
> *From: *Steve Martine
+1 on the idea of running function tests to see the fallout. Right now
python-memcached is labelled as py3 compatible and in keystone our unit
tests pass, but I'm skeptical about its behavior in functional and tempest
tests.
On Jun 23, 2016 1:14 PM, "Sean Dague" wrote:
So, given that everything i
Thanks for that Clint!
On Jun 24, 2016 1:28 AM, "Clint Byrum" wrote:
> Excerpts from Doug Hellmann's message of 2016-06-23 08:37:04 -0400:
> > Excerpts from Doug Hellmann's message of 2016-06-13 15:11:17 -0400:
> > > I'm trying to pull together some information about contributions
> > > that Open
I think we want something a bit more organized.
Morgan tossed the idea of a keystone-docs repo, which could have:
- The FAQ Adam is asking about
- Install guides (moved over from openstack-manuals)
- A spot for all those neat and unofficial blog posts we do
- How-to guides
- etc...
I think it's
the keystone team is migrating these existing API sites from the api-site
repo to the keystone repo.
- http://developer.openstack.org/api-ref-identity-v3.html
- http://developer.openstack.org/api-ref-identity-v3-ext.html
- http://developer.openstack.org/api-ref-identity-v2.html
- http://de
PM, Jamie Lennox wrote:
>
>
> On 29 June 2016 at 09:49, Steve Martinelli wrote:
>
>> I think we want something a bit more organized.
>>
>> Morgan tossed the idea of a keystone-docs repo, which could have:
>>
>> - The FAQ Adam is asking about
>> -
I'm a bit late to the game here, and others have summed this up
excellently, but i'll add my 2c. I think option 2 is the way to go, user
and project IDs will absolutely work best as they are immutable.
On Fri, Jun 10, 2016 at 4:52 AM, Coles, Alistair
wrote:
> Thai,
>
>
>
> (repeating some of wha
The crux of this, as Dean stated, is if the library wants OSC to always be
pulled in (along with its many dependencies). We've seen folks include it
in requirements, test-requirements, or even not at all (just document that
OSC needs to be installed).
I tossed up the idea with the ironic team of l
There's a whole bunch of OpenStackClient plugins now (17 to be exact).
With [1] now merged, we run a non-voting job (check-osc-plugins) on each
plugin to check for commands that may conflict with each other. It tests
the master branch of each plugin, so we'll catch errors before the release.
The
The keystone spec freeze is on july 8th. I am in the process of going
through the open specs [1]
I will be commenting if I think it is a potential candidate for the Newton
based on how far along the spec is, its complexity, core reviewer attention
and priority. (Thanks Matt R for the wording)
I'd
I personally like this solution, it seems much more scalable. This follows
the same pattern of the API docs (moving the content to project repos),
which puts the onus back on the project team to maintain and create
documentation. I'm also hoping this results in less duplication between the
guides a
Just a reminder that we're having an API sprint this week, details are
here: https://etherpad.openstack.org/p/keystone-api-sprint
The goals is to get the APIs in the specs repo (most accurate and
up-to-date) [1] to match the APIs defined in the keystone repo (recently
migrated over from the api-si
The keystone project was one of the first to have a logo and I'm more than
happy to give it up for the sake of a consistent message across all
OpenStack projects.
I think it's fine if ironic and tripleo want to stick with their current
animals (luckily they are using logos that meet the new criter
snip
On Mon, Jul 11, 2016 at 1:15 PM, Jay Faulkner wrote:
>
>
> I think we could all be easily bribed if the foundation provided copious
> amounts of stickers to contributors with the new mascot designs on them. :P
>
I'm sure that can be arranged :]
__
I am OK with any of the proposed times.
stevemar
From: Richard Theis
To:
Date: 2016/04/05 11:46 AM
Subject:[openstack-dev] [osc] Meeting time preferences for OSC team
Here are my preferences:
1. even week: E.1 or E.4
2. odd week: O.3
Thanks,
Richard
> Dear All,
>
> This
ent/commit/a42570268915f42405ed0b0a67c25686b5db22ce
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
From: Matt Riedemann
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 2016/04/05 03:49 PM
Subject:[openstack-dev] [nova]
There was feedback from the murano team asking for it to stick around:
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090459.html
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
From: Brad Pokorny
To: "OpenStack Development Mailing List (not for
this would add to that pile.
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
From: Boris Pavlovic
To: OpenStack Development Mailing List
Date: 2016/04/06 03:27 PM
Subject:[openstack-dev] [tc][ptl][keystone] Proposal to split
authentication p
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
From: Dmitry Tantsur
To: "OpenStack Development Mailing List (not for usage questions)"
Date: 2016/04/08 01:43 PM
Subject:Re: [openstack-dev] [all][stackalytics] Gaming the St
Thanks for volunteering to organize, I genuinely appreciate it. I'm OK with
any of those weeks, the earlier the better IMO.
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
From: Morgan Fainberg
To: "OpenStack Development Mailing List (not for usage
+1, not sure if something that sophisticated is needed, but having a few
examples wouldn't hurt. I also go back to one that I have saved (
https://gist.github.com/stevemart/1f2a4e528606d178b7d1) and comment /
uncomment lines as needed.
The trouble with examples is that they have a tendency to bit
raded last release to address the second issue.
We have been emitting deprecation messages for both of these functions for
more than two releases, and voiced this on the mailing list (
http://lists.openstack.org/pipermail/openstack-operators/2015-November/009019.html
).
Thanks,
Steve Martinelli
://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Keystone
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
:
http://git.openstack.org/cgit/openstack/kiloeyes/tree/setup_horizon.sh
[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-April/092471.html
Thanks,
Steve Martinelli
OpenStack Keystone Project Team Lead
__
Or make use of openstacksdk instead of pulling in all the clients
stevemar
From: Jay Pipes
To: openstack-dev@lists.openstack.org
Date: 2016/04/19 03:11 PM
Subject:Re: [openstack-dev] [devstack] openstack client slowness /
client-as-a-service
On 04/19/2016 02:17
as per usual, we will cancel the meeting the week of the summit - see you
in austin!
Steve
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr
thanks to richard, tangchen, reepid and others for picking this up and
running with it; and thanks to armando for embracing OSC and putting it in
neutron's plan.
On Fri, Apr 22, 2016 at 6:33 PM, reedip banerjee wrote:
> Hi Richard,
> Thanks for the information :)
>
> Was waiting for it.
>
>
Comments inline...
On Mon, May 2, 2016 at 7:39 PM, Matt Fischer wrote:
> On Mon, May 2, 2016 at 5:26 PM, Clint Byrum wrote:
>
>> Hello! I enjoyed very much listening in on the default token provider
>> work session last week in Austin, so thanks everyone for participating
>> in that. I did not
sorry for the late notice - there are no items on the agenda and i think
most are still decompressing from the summit
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.open
ril/092298.html
[2] http://releases.openstack.org/newton/schedule.html
Thanks!
Steve Martinelli - Keystone PTL
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?
+100 Jay
On Wed, May 4, 2016 at 4:53 PM, Jay Pipes wrote:
> On 05/04/2016 01:08 PM, Chris Dent wrote:
>
>>
>> The plans for generic resource pools[1] include a suite of new
>> commands for creating and updating resource pools. In today's Nova
>> API meeting[2] and afterwards in #openstack-nova[3
1 - 100 of 280 matches
Mail list logo
