[openstack-dev] [tc][election] non-candidacy for TC

[Steve Martinelli]

Folks, due to changes in my day job I will not be running in the next TC
election. I still intend to contribute to OpenStack whenever possible. I
look forward to seeing how the community continues to grow, change, and
approach new challenges.

I'd like to encourage others to step up to the challenge and run. It's an
excellent experience to learn more about yourself, OpenStack, and
governance of a large open source project.

Thanks for your time,
Steve
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][zuul] A Sad Farewell

[Steve Martinelli]

It was great working with and getting to know you over the years Jamie, you
did tremendous work with in keystone, particularly maintaining the
libraries. I'm sure you'll succeed in your new position, I'll miss our
late-night-east-coast, early-morning-aus chats. Keep in touch.

On Mon, Oct 2, 2017 at 10:13 PM, Jamie Lennox  wrote:

> Hi All,
>
> I'm really sad to announce that I'll be leaving the OpenStack community
> (at least for a while), I've accepted a new position unrelated to OpenStack
> that'll begin in a few weeks, and am going to be mostly on holiday until
> then.
>
> I want to thank everyone I've had the pleasure of working with over the
> last few years - but particularly the Keystone community. I feel we as a
> team and I personally grew a lot over that time, we made some amazing
> achievements, and I couldn't be prouder to have worked with all of you.
>
> Obviously I'll be around at least during the night for some of the Sydney
> summit and will catch up with some of you there, and hopefully see some of
> you at linux.conf.au. To everyone else, thank you and I hope we'll meet
> again.
>
>
> Jamie Lennox, Stacker.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Adding Kristi Nikolla to keystone-core

[Steve Martinelli]

Congrats Kristi! Well deserved indeed!

On Tue, Aug 15, 2017 at 3:00 PM, Lance Bragstad  wrote:

> I made the announcement in today's keystone meeting [0] that the current
> reviewers have decided to add Kristi Nikolla (knikolla) to the team.
>
> Kristi has been an extremely valuable asset to the team over the last
> couple of releases. He especially stepped up to the plate during Pike.
> He provides consistent and valuable feedback on reviews, actively
> participates in discussions about the project's future, and takes
> initiative when something needs to get done. In addition to that, he's
> been great about helping folks out in the channel and getting our Pike
> release candidate out the door.
>
> I'm excited to add Kristi to the keystone core group and I look forward
> to seeing him make positive changes. Thanks for all the dedication and
> hard work, Kristi!
>
> [0]
> http://eavesdrop.openstack.org/meetings/keystone/2017/
> keystone.2017-08-15-18.00.log.html#l-130
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Dev][OpenStackClient] - Running functional tests

[Steve Martinelli]

Looks like running tox will pass along any environment variables with the
prefix "OS_" from the shell to tox, see
https://github.com/openstack/python-openstackclient/blob/master/tox.ini#L55

So as long as you've sourced or exported a bunch of env. variables, you
should be ready to run tests. You don't and shouldn't run it with sudo
either.

On Tue, Jul 4, 2017 at 2:25 AM, nidhi.h...@wipro.com 
wrote:

> Hello all,
>
>
>
> I am running functional tests for openstackclient.
>
> By using this command sudo tox -efunctional
>
>
>
> *It gives me this error *
>
>
>
> setUpClass (openstackclient.tests.functional.volume.v3.test_
> snapshot.VolumeSnapshotTests)
>
> 
> -
>
>
>
> Captured traceback:
>
> ~~~
>
> Traceback (most recent call last):
>
>   File "openstackclient/tests/functional/volume/v3/test_snapshot.py",
> line 22, in setUpClass
>
> super(VolumeSnapshotTests, cls).setUpClass()
>
>   File "openstackclient/tests/functional/volume/v2/test_snapshot.py",
> line 31, in setUpClass
>
> cls.VOLLY
>
>   File "openstackclient/tests/functional/base.py", line 64, in
> openstack
>
> return execute('openstack ' + cmd, fail_ok=fail_ok)
>
>   File "openstackclient/tests/functional/base.py", line 41, in execute
>
> result_err)
>
> tempest.lib.exceptions.CommandFailed: Command 'openstack volume
> create -f json --size 1 ee1a858057464f15b6488ec4f3c1da5d' returned
> non-zero exit status 1.
>
> stdout:
>
>
>
> stderr:
>
> *Missing value auth-url required for auth plugin password*
>
>
>
>
>
> *Can someone tell me where do I need to configure environment variables*
>
> *So that functional tests run well?*
>
>
>
> *Any doc /url also will be helpful.*
>
>
>
> *Thanks*
>
> *Nidhi*
>
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] removing domain configuration upload via keystone-manage

[Steve Martinelli]

++ to what colleen said. I've always preferred using the file-backed
approach.

I think we deprecated it for completeness and to only have a single tool
for configuring LDAP-backed domains. If it's tested well enough and not
much effort to support then we should keep it around as an alternative
method for configuring LDAP-backed domains.

On Wed, Jun 28, 2017 at 4:53 PM, Colleen Murphy  wrote:

> On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad 
>> wrote:
>>
>>> Hi all,
>>>
>>> Keystone has deprecated the domain configuration upload capability
>>> provided through `keystone-manage`. We discussed it's removal in today's
>>> meeting [0] and wanted to send a quick note to the operator list. The
>>> ability to upload a domain config into keystone was done as a stop-gap
>>> until the API was marked as stable [1]. It seems as though file-based
>>> domain configuration was only a band-aid until full support was done.
>>>
>>> Of the operators using the domain config API in keystone, how many are
>>> backing their configurations with actual configuration files versus the API?
>>>
>>>
>>> [0] http://eavesdrop.openstack.org/meetings/keystone/2017/keysto
>>> ne.2017-06-27-18.00.log.html#l-167 [1] https://github.com/openstack/k
>>> eystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
>>>
>>  I am not clear on why we need to deprecate and remove file-backed domain
> configuration. The way I see it:
>
> * It's reflectve with the primary configuration, so I can copy over the
> chunks I need from keystone.conf into 
> /etc/keystone/domains/keystone.domain.conf
> without thinking too hard about it
> * It's convenient for deployment tools to just lay down config files
> * It's not that much extra effort for the keystone team to maintain (is
> it?)
>
> The use case for file-backed domain configs is for smaller clouds with
> just one or two LDAP-backed domains. There's not a real need for users to
> change domain configs so the file-backed config is plenty fine. I don't see
> a lot of gain from removing that functionality.
>
> I don't particularly care about the keystone-manage tool, if that goes
> away it would still be relatively easy to write a python script to parse
> and upload configs if a user does eventually decide to transition.
>
> As a side note, SUSE happens to be using file-backed domain configs in our
> product. It would not be a big deal to rewrite that bit to use the API, but
> I think it's just as easy to let us keep using it.
>
> Colleen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] documentation migration and consolidation

[Steve Martinelli]

Great to see this consolidation happen!

On Mon, Jun 26, 2017 at 4:09 PM, Lance Bragstad  wrote:

> Hey all,
>
> We recently merged the openstack-manuals admin-guide into keystone [0]
> and there is a lot of duplication between the admin-guide and keystone's
> "internal" operator-guide [1]. I've started proposing small patches to
> consolidate the documentation from the operator-guide to the official
> admin-guide. In case you're interested in helping out, please use the
> remove-duplicate-docs branch [2]. The admin-guide is really well written
> and it would be great to get some reviews from members of the docs team
> if possible to help us maintain the style and consistency of the
> admin-guide.
>
> Ping me if you have any questions. Thanks!
>
>
> [0] https://review.openstack.org/#/c/469515/
> [1] https://docs.openstack.org/developer/keystone/configuration.html
> [2]
> https://review.openstack.org/#/q/status:open+project:
> openstack/keystone+branch:master+topic:remove-duplicate-docs
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Colleen Murphy for core

[Steve Martinelli]

Yay! Very glad to see this happen. Thanks for all your work Colleen!

On Tue, May 2, 2017 at 2:15 PM, Lance Bragstad  wrote:

> Hey folks,
>
> During today's keystone meeting we added another member to keystone's core
> team. For several releases, Colleen's had a profound impact on keystone.
> Her reviews are meticulous and of incredible quality. She has no hesitation
> to jump into keystone's most confusing realms and as a result has become an
> expert on several identity topics like federation and LDAP integration.
>
> I'd like to thank Colleen for all her hard work and upholding the
> stability and usability of the project.
>
>
> Congratulations, Colleen!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][OSC] OpenStack Interpreter: A useful tool python interpreter tool for the OpenStack client libraries.

[Steve Martinelli]

Cool, thanks for sharing Adrian.

On Tue, May 2, 2017 at 12:11 AM, Adrian Turjak 
wrote:

> Hello OpenStack folks,
>
> As part of my dev work I recently put together a cool little tool which
> lets me have much easier access to the various OpenStack python clients
> in the scope of a python interpreter session. The first version was a
> little rough and without os-client-config support. The current version
> is now a plugin for the openstackclient and introduces a command that
> simply authenticates you, sets up the environment and helper tools, and
> then drops you into an ipython interactive session. The helper stuff is
> fairly simple, but combined with the features of ipython it really lets
> you start playing with the tools quickly, and by piggybacking onto
> openstackclient I get access to a lot of the niceties and inbuilt auth
> mechanisms.
>
> It is useful for learning, testing, or development against the various
> openstack client libraries, and even as an ops tool to quickly run some
> basic actions without having to resort to weird or silly bash command
> combinations.
>
> I personally use it to test out commands or libraries I'm not familiar
> with, or if I just need to work out what the output from something is.
> Often even doing once off admin actions that require parsing through and
> comparing different values and resources, but isn't worth writing a
> script for.
>
> My goal was to make something easy to use, and help almost anyone pick
> up and start using the various python clients without needing to dig
> through too much docs.
>
> https://pypi.python.org/pypi/openstack-interpreter
>
> Feedback is welcome!
>
> Cheers,
> Adrian Turjak
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][horizon] weekly meeting

[Steve Martinelli]

As someone who helped orchestrate the weekly sync-ups, I'll chime in. I
always intended for these meetings to end once we accomplished most of the
goals [1] we identified last summit. With most of the goals accomplished,
scaling back or ending them entirely seems appropriate. We can always start
them up again if our backlog grows again.

[1] https://etherpad.openstack.org/p/ocata-keystone-horizon

On Thu, Apr 20, 2017 at 3:46 PM, Lance Bragstad  wrote:

> I wonder if the meeting tooling supports a monthly cadence?
>
> On Thu, Apr 20, 2017 at 2:42 PM, Rob Cresswell <
> robert.cressw...@outlook.com> wrote:
>
>> It's been a week since the original email; I think we should scale back
>> to a monthly sync up. No preference on which week of the month it falls in.
>> Thanks!
>>
>> Rob
>>
>> On 13 April 2017 at 22:03, Lance Bragstad  wrote:
>>
>>> Happy Thursday folks,
>>>
>>> Rob and I have noticed that the weekly attendance for the
>>> Keystone/Horizon [0] meeting has dropped significantly in the last month or
>>> two. We contemplated changing the frequency of this meeting to be monthly
>>> instead of weekly. We still think it is important to have a sync point
>>> between the two projects, but maybe it doesn't need to be as often as we
>>> were expecting.
>>>
>>> Does anyone have any objections to making this a monthly meeting?
>>>
>>> Does anyone have a preference on the week or day of the month (i.e. 3rd
>>> Thursday of the month)?
>>>
>>> Once we have consensus on a time, I'll submit a patch for the meeting
>>> agenda.
>>>
>>> Thanks and have a great weekend!
>>>
>>> [0] http://eavesdrop.openstack.org/#Keystone/Horizon_Collabo
>>> ration_Meeting
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Arrivederci

[Steve Martinelli]

You'll be missed! Best of luck in your next adventure, they are very lucky
to have you.

On Wed, Mar 22, 2017 at 8:06 AM, Ian Cordasco 
wrote:

> Hi everyone,
>
> Friday 24 March 2017 will be my last day working on OpenStack. I'll remove
> myself from teams (glance, craton, security, hacking) on Friday and
> unsubscribe
> from the OpenStack mailing lists.
>
> I want to thank all of you for the last ~3 years. I've learned quite a bit
> from all of you. It's been a unique privilege to call the people in this
> community my colleagues. Treat each other well. Don't let minor technical
> arguments cause rifts in the community. Lift each other up.
>
> As for me, I'm moving onto something completely different. You all are
> welcome
> to keep in touch via email, IRC, or some other method. At the very
> least, I'll see y'all
> around PyCon, the larger F/OSS world, etc.
>
> --
> Ian Cordasco
> IRC/Git{Hub,Lab}/Twitter: sigmavirus24
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

[Steve Martinelli]

On Wed, Mar 8, 2017 at 2:04 PM, Andreas Jaeger  wrote:
>
> Very few people know about these URLs at all and there are only a few
> places that use it in openstack (I just send a few patches for those).
>

++

I had no idea they existed...
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] mascot

[Steve Martinelli]

this looks great!

On Mon, Feb 13, 2017 at 9:28 PM, Lance Bragstad  wrote:

> Good news! We just got the final revision for our official keystone mascot
> [0]!
>
> I have a note on my todo list to put together a basic chart deck with
> them. I'll send out a link for folks to use when I get them done.
>
> [0] https://www.dropbox.com/sh/0owldvy0u5y4yk9/AAB5Q95wYj-
> oaiisneKbnEiDa?dl=0
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

[Steve Martinelli]

On Thu, Feb 2, 2017 at 10:33 AM, Mike Bayer  wrote:
>
>
> well, let me blow your mind and agree, but noting that this means, *we
> drop SQLite also*.   IMO every openstack developer should have
> MySQL/MariaDB running on their machine and that is part of what runs if you
> expect to run database-related unit tests.   Targeting just one database is
> very handy but if you really want to use the features without roadblocks,
> you need to go all the way.


+ let's drop SQLite while we're at it
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] removing Guang Yee (gyee) from keystone-core

[Steve Martinelli]

Due to inactivity and a change in his day job, Guang was informed that he
would be removed from keystone-core, a change he understands and supports.

I'd like to publicly thank Guang for his years of service as a core member.
He juggled upstream and downstream responsibilities at HP while bringing
real world use cases to the table.

Thanks for everything Guang, o\

Steve
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] gate jobs - papercuts

[Steve Martinelli]

On Tue, Jan 31, 2017 at 12:49 PM, Davanum Srinivas 
wrote:

> Folks,
>
> Here's the list of job failures that failed in the gate queue.
> captured with my script[1][2] since around 10:00 AM today. All jobs
> failed with just one bad test.
>
> http://logs.openstack.org/48/423548/11/gate/gate-keystone-
> python27-db-ubuntu-xenial/a1f55ca/
>- keystone.tests.unit.test_v3_auth.TestMFARules
>
> 


This was due to a race condition between token issuance and validation,
should be fixed.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Steve Martinelli]

On Sun, Jan 29, 2017 at 8:05 PM, Kendall Nelson 
wrote:

> PTL Nomination is now over. The official candidate list is available on
> the election website[0].
>

It's great to see only 1 project was without a PTL!


> There is only 1 project without candidates, so according to this
> resolution[1], the TC we'll have to appoint a new PTL for OpenStack UX.
>

The UX project was briefly discussed at a recent TC meeting (see the end of
the log) [1], with Piet stepping down there was some discussion about
whether or not it needs to be a standalone project, or can turn into a
working group (like the API working group).

Oh, Thierry sent something out to the mailing list already [2], no replies
:(

[1]
http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-03-20.00.log.html
[2]
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109622.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Requirements] Freeze

[Steve Martinelli]

Hey Matthew,

The OpenStackClient team will be posting patches to bump the minimum level
of python-openstacksdk to the latest release 0.9.13 (out today). We'll also
be releasing a new python-openstackclient version (3.8.0), which should
also be the minimum version.

On Tue, Jan 24, 2017 at 3:22 PM, Matthew Thode 
wrote:

> We are going to be freezing Thursday at ~20:00 UTC.
>
> So if you need any changes we'll be needing needing them in soon, with
> reasoning.  Thanks.
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone]Error while setting up a keystone development environment

[Steve Martinelli]

why not use devstack [1] with a minimal local.conf (used to specify which
components to install) ?

[1] http://docs.openstack.org/developer/devstack/

minimal local.conf:

[[local|localrc]]
RECLONE=yes

# Credentials
DATABASE_PASSWORD=openstack
ADMIN_PASSWORD=openstack
SERVICE_PASSWORD=openstack
RABBIT_PASSWORD=openstack

# Services
ENABLED_SERVICES=rabbit,mysql,key
ENABLED_SERVICES+=,horizon

# Enable Logging
LOGFILE=/opt/stack/logs/stack.sh.log
VERBOSE=True
LOG_COLOR=True
SCREEN_LOGDIR=/opt/stack/logs

On Mon, Jan 23, 2017 at 8:39 AM, Daniel Gitu  wrote:

> Hello,
>
> I'm new to all this and I am in need of help to find out where I went
> wrong.
> This is a bit lengthy, I have left a blank space between the text and the
> error
> messages I received.
> I first set up and activated a virtual environment then cloned the keystone
> project into that environment.
> I then proceeded to cd into keystone and executed pip install -r
> requirements.txt and got the following errors:
>
> Failed building wheel for cryptography
> Failed cleaning build dir for cryptography
> Failed building wheel for netifaces
> Failed building wheel for pycrypto
> Command "/home/grenouille/openstack/bin/python -u -c "import
> setuptools, 
> tokenize;__file__='/tmp/pip-build-XqTJv_/cryptography/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-nFp6dT-record/install-record.txt --single-version-externally-managed
> --compile --install-headers /home/grenouille/openstack/inc
> lude/site/python2.7/cryptography" failed with error code 1 in
> /tmp/pip-build-XqTJv_/cryptography/
>
> The above errors were resolved by executing; sudo apt-get install
> build-essential libssl-dev libffi-dev python-dev and re-running
> pipinstall -r requirements.txt
> I ran sudo apt install tox and executed tox in the keystone directory
> As tox was installing dependencies the first line read:
>
> ERROR: invocation failed (exit code 1), logfile:
> /home/grenouille/openstack/keystone/.tox/docs  /log/docs-1.log
> ERROR: actionid: docs
>
> The final error message read:
>
> ERROR: could not install deps [-r/home/grenouille/openstack/
> keystone/test-requirements.txt, .[ldap,memcache,mongodb]]; v =
> InvocationError('/home/grenouille/openstack/keystone/.tox/docs/bin/pip
> install -chttps://git.openstack.org/cgit/openstack/requirements/plai
> n/upper-constraints.txt 
> -r/home/grenouille/openstack/keystone/test-requirements.txt
> .[ldap,memcache,mongodb] (see /home/grenouille/openstack/key
> stone/.tox/docs/log/docs-1.log)', 1)
>
>
> Regards,
> Daniel.
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ python-novaclient][ python-glanceclient][ python-cinderclient][ python-neutronclient] Remove x-openstack-request-id logging code as it is logged twice

[Steve Martinelli]

On Fri, Jan 20, 2017 at 10:53 PM, Kekane, Abhishek <
abhishek.kek...@nttdata.com> wrote:

> Hi Dims,
>
> Thank you for reply. I will propose a patch soon. Just for curiosity,
> keystoneauth1 >= 2.17.0 will not install 2.18.0?
>

It will, but if we make 2.18.0 the minimum then it will for sure install
only that level.

> In the latest keystoneauth1 version 2.18.0, x-openstack-request-id is
> logged
> > for every HTTP response. This keystoneauth1 version will be used for
> ocata.
> >
> > The same request id is also logged in 'request' method of SessionClient
> > class for python-novaclient, python-glanceclient, python-cinderclient and
> > python-neutronclient. Once requirements.txt is synced with
> > global-requirements and it uses keystoneauth1 version 2.18.0 and above,
> > x-openstack-request-id will be logged twice for these clients.
>

So I approved this change (sorry it took so long to review and merge), but
I didn't realize it was going to impact python-{nova | glance | cinder |
neutron}client. I think it's slightly unrealistic to ask four teams to
remove the logging in the last week we release clients (I'm assuming we
want to remove the functionality and not log things twice).

 - Would folks prefer I revert the keystoneauth change and re-release
without it, and we can bring it back in Pike?
- Do teams have the bandwidth to remove the request id logging in the next
few days?

Sorry for the confusion this caused.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] new os-api-ref warning, changes may be needed

[Steve Martinelli]

Thanks for addressing this in the keystone project Sean!

On Fri, Jan 20, 2017 at 12:41 PM, Sean Dague  wrote:

> We released a new os-api-ref yesterday which includes a few
> enhancements, including the anchor links on the website working as
> expected now.
>
> One of the things in there is a new warning when a parameter is used,
> and is not defined.
>
> https://github.com/openstack/keystone/blob/bc8a145de14e455a2a73824e8a84d9
> 2ac27aae1c/api-ref/source/v2-ext/ksec2-admin.inc#L31
> - as an example
>
> Which will generate an issue such as:
>
> Warning, treated as error:
> /home/sdague/code/openstack/keystone/api-ref/source/api-
> ref/source/v2-ext/ksec2-admin.inc:112
> .rst:: WARNING: No path parameter ``userId`` found in rest_parameter
> stanza.
>
>
> Long term, these really all need to be fixed, because this is specifying
> a parameter and giving the user no expectation about what it is and how
> it is used.
>
> In the short term, if this is too hard for teams to address, remove the
> '-W' from the sphinx_build line in your api-ref section, then work
> through the warnings, and make warnings enforcing when done.
>
> I've seen fails on keystone. But there may be fails other places as well.
>
> Keystone fix is here - https://review.openstack.org/#/c/423387 as an
> example of what might be needed to move forward for projects.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [osc][openstackclient][glance] broken image functional test

[Steve Martinelli]

hey glancerinos,

it seems the OSC gate is broken, several patches are failing the same way:

testtools.matchers._impl.MismatchError: !=:
reference = '''\
qcow2
True
4
5
d35ba06a07654721bb730ea154b9c6e7
'''
actual= u'''\
qcow2
False
4
5
d35ba06a07654721bb730ea154b9c6e7
'''


In short, the test used to use python-glanceclient's image update method to
set the "is_public" attribute of an image to True, but now it's returning
False, here's the actual OSC test:
https://github.com/openstack/python-openstackclient/blob/master/openstackclient/tests/functional/image/v1/test_image.py#L55-L61

here's an example test result:
http://logs.openstack.org/54/423154/1/check/gate-osc-dsvm-functional-ubuntu-xenial/f23fbfa/testr_results.html.gz

did something break? at first glance (hehe), it seems this patch may be to
blame?
https://github.com/openstack/glance/commit/265659e8c34865331568b069fdb27ea272df4eaa

stevemar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][ptl] not planning to serve as release PTL for Pike

[Steve Martinelli]

+++ Thanks for making it 100x easier to release new libraries, it's now
something I look forward to.

On Fri, Jan 13, 2017 at 3:11 PM, Davanum Srinivas  wrote:

> Many thanks for all the automation and all other initiatives Doug!
>
> On Fri, Jan 13, 2017 at 3:00 PM, Doug Hellmann 
> wrote:
> > I announced this at the release team meeting on 6 Jan, but thought
> > I should also post to the list as well:  I do not plan to serve as
> > the Release Management team PTL for the Pike release cycle.
> >
> > It has been my pleasure to serve as PTL, and we've almost finished
> > the automation work that I envisioned when I joined the team. Now
> > I would like to shift my focus to some other projects within the
> > community.  I will still be an active member of the Release Management
> > team, helping with new initiatives and reviews for releases.
> >
> > Doug
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Consistent Versioned Endpoints

[Steve Martinelli]

On Fri, Jan 13, 2017 at 7:39 AM, Sean Dague  wrote:

> On 01/12/2017 01:35 PM, Scott D'Angelo wrote:
> > TL;DR: Let's discuss Version Discovery and Endpoints in the Service
> > Catalog at the PTG in Atlanta.
> >
> > The topic of Versioning and the Endpoints discovered in the Service
> > Catalog was discussed in today's API Working Group Meeting[1].
> > A previous ML post[2] claimed:
> >
> > In a perfect world, every endpoint would return the same type of
> resource -
> > most likely the versions resource as described in the API WG
> Microversions
> > spec. It would also be nice if version negotiation can happen without
> > requiring authentication, the easiest path to which would be supporting
> the
> > 'max_version' and 'min_version' fields in the root versions resource.
> >
> > One problem is multiple versioned service names in the catalog for a
> > given service[3], as opposed to a single endpoint that would return
> > version info[4].
> >
> > Can we get to this "perfect world"? Let's discuss at the PTG.
> > It is my understanding that we do not have the ability to schedule a
> > time or room for such a cross-project discussion. Please chime in if
> > interested, and/or make your interest known to scottda, mordred, or
> edleafe.
>
> Happy to join in on this, it does seem weird there is no time / space
> for such things at PTG.
>
> We actually had a rough sketch of a plan last year here which would go a
> slightly different direction, and get that all up into the service
> catalog. That also ensures consistent schema enforcement, as it would
> all be through keystone.
>
> Definitely need keystone folks in the room to be able to make forward
> progress here I think, because part of the tension in the past has been
> understanding domain boundaries, and it would be a shame to do a ton of
> work in all the projects that could be easily done in one project, just
> because of communication gaps.
>

If theres a room I'll be there, and try to rope in other folks too.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] etherpad for ptg

[Steve Martinelli]

keystoners,

here is the link to the etherpad for the ptg:
https://etherpad.openstack.org/p/keystone-pike-ptg
here is a link to other project etherpads:
https://wiki.openstack.org/wiki/PTG/Pike/Etherpads

I'll announce this in our meeting today also.

- steve
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Feedback from driver maintainers about future of driver projects

[Steve Martinelli]

Hey Neil, it's entirely possible I missed some folks. Feel free to reply to
this thread.

I'll include some of the preamble and questions from my original note.

-

The TC has come up with two strategies for clarification: (1) Make sure
external drivers are properly listed and discoverable on OpenStack
websites, and (2) Establish a new "driver team" concept (see
https://review.openstack.org/#/c/403829/).

As maintainers for neutron, cinder and ironic drivers, we’re asking you for
your opinion on this matter. We need to know if we are solving the right
problem here.

Are driver teams looking for recognition? I.e. receiving ATC status, see
their work recognized as an official part of “OpenStack”?
Are driver teams looking for discoverability? I.e. having their drivers
listed together with all the other available drivers on the OpenStack
Marketplace or DriverLog websites ?
Are driver teams looking for documentation visibility? I.e. having an
official place to host configuration guides? On docs.o.org?
Are driver teams looking for independence? I.e. the ability to manage and
nominate their own core members?
Anything else we missed?

On Jan 10, 2017 5:55 AM, "Neil Jerram"  wrote:

> Hi Steve,
>
> On Tue, Jan 10, 2017 at 7:35 AM Steve Martinelli 
> wrote:
>
>> In preparation for the next TC meeting, a survey was sent out to driver
>> maintainers, here is a summary of the feedback that was gathered.
>>
>
> Did you send that survey to me, for networking-calico?  I'm afraid I don't
> recall it - so worried either that I missed, or that networking-calico was
> missed for some reason.
>
> Thanks,
>  Neil
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][all] Feedback from driver maintainers about future of driver projects

[Steve Martinelli]

In preparation for the next TC meeting, a survey was sent out to driver
maintainers, here is a summary of the feedback that was gathered.

Major observations

==

* Are drivers an important part of OpenStack? YES!

* Discoverability of drivers needs to be fixed immediately.

* It is important to have visibility in a central place of the status of
each driver.

* Perspective of a driver developer and a high level person at the company
should feel like they're part of something.

* OpenStack should stop treating drivers like second-class citizens. They
want access to the same resources (publish on docs.o.org, config guides,
etc).

* The initial wording about what constitutes a project was never intended
for drivers. Drivers are a part of the project. Driver developers
contribute to OpenStack by creating drivers.

Discoverability

===

* Consensus: It is currently all over the place. A common mechanism to view
all supported drivers is needed.

* Cinder list: http://docs.openstack.org/developer/cinder/drivers.html

* Nova list: http://docs.openstack.org/developer/nova/support-matrix.html

* Stackalytics list: http://stackalytics.openstack.org/report/driverlog

* Opinion: If we intend to use the marketplace (or anywhere on openstack.org)
to list in-tree and out-of-tree drivers, they should have CI results
available as a requirement. A driver that fails CI is not just a vendor
problem, it’s an OpenStack problem, it reflects poorly on OpenStack and the
project.

* Opinion: What constitutes a supported driver, why not list all drivers?

* Opinion: Fixing discoverability can be done independently of governance
changes. We have the option of tabling the governance discussion until we
get the discoverability properly fixed, and see then if we still need to do
anything more.

* Opinion: Between giving full access to vertical resources to driver
teams, and making the marketplace *the* place for learning about OpenStack
drivers, we would have solved at least the biggest portion of the problem
we're facing.

Driver projects - official or not?

==

* Fact: There is desire from some out-of-tree vendors to become ‘official’
OpenStack projects, and gain the benefits of that (access to horizontal
teams).

* Opinion: Let drivers projects become official, there should be no 3rd
party CI requirement, that can be a tag.

* Opinion: Do not allow drivers projects to become official, that doesn’t
mean they shouldn’t easily be discoverable.

* Opinion: We don't need to open the flood gates of allowing vendors to be
teams in the OpenStack governance to make the vendors developers happy.

* Fact: This implies being placed under the TC oversight. It is a
significant move that could have unintended side-effects, it is hard to
reverse (kicking out teams we accepted is worse than not including them in
the first place), and our community is divided on the way forward. So we
need to give that question our full attention and not rush the answer.

* Opinion: Consider https://github.com/openstack/driverlog an official
OpenStack project to be listed under governance with a PTL, weekly
meetings, and all that it required to allow the team to be effective in
their mission of keeping the marketplace a trustworthy resource for
learning about OpenStack driver ecosystem.

Driver developers

=

* Opinion: A driver developer that ONLY contributes to vendor specific
driver code should not have the same influence as other OpenStack
developers, voting for PTL, TC, and ATC status.

* Opinion: PTLs should leverage the extra-atcs option in the governance repo

In-tree vs Out-of-tree

==

* Cinder has in-tree drivers, but also has out-of-tree drivers when their
CI is not maintained or when minimum feature requirements are not met. They
are marked as ‘not supported’ and have a single release to get things
working before being moved out-of-tree.

* Ironic has a single out-of-tree repo:
https://github.com/openstack/ironic-staging-drivers -- But also in-tree
https://github.com/openstack/ironic/tree/master/ironic/drivers

* Neutron has all drivers out-of-tree, with project names like:
‘networking-cisco’.

* Many opinions on the “stick-based” approach the cinder team took.

* Opinion: The in-tree vs out-of-tree argument is developer focused.
Out-of-tree drivers have obvious benefits (develop quickly, maintain their
own team, no need for a core to review the patch). But a vendor that is
looking to make sure a driver is supported will not be searching git repos
(goes back to discoverability).

* Opinion: May be worth handling the projects that keep supported drivers
in-tree differently that we handle projects that have everything
out-of-tree.

thanks for reading! stevemar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc

Re: [openstack-dev] [keystone] Feedback for upcoming user survey questionnaire

[Steve Martinelli]

I quite like Boris' last suggestion, with a minor tweak:

"In your opinion, what keystone feature(s) requires more attention (select
all that apply): "federation", "performance", "policy", "scaling out",
"backend support", "ldap"."

Unless someone has another suggestion I'll stick to the above.

On Wed, Jan 4, 2017 at 9:18 AM, Lance Bragstad  wrote:

> ++ to the suggestions Boris threw out. Answers to any of those would be
> valuable. In addition to that, I'd find any information about policy
> useful. Maybe something along the lines of "what changes to the policy
> files are you making, if any". This could be something that is asked
> OpenStack-wide (which I'm sure we've done at some point in the past) but it
> would also be interesting on a per-project basis.
>
> On Tue, Jan 3, 2017 at 3:05 PM, Boris Bobrov  wrote:
>
>> "What were you trying to accomplish with keystone but failed"
>> "What functionality in keystone did you try to use but it wasn't good
>> enough"
>> "In your opinion, what in keystone requires most attention"
>> with choices "federation", "performance", "policy", "backend support"
>> and some other options.
>>
>> On 12/30/2016 11:54 PM, Steve Martinelli wrote:
>> > We have the opportunity to ask one question on the
>> > upcoming user survey and we get to decide the audience to which we serve
>> > the question.
>> >
>> > __ __
>> >
>> > Our audience options are: USING, TESTING, or INTERESTED in Keystone (I
>> > think we should aim for USING or TESTING)
>> >
>> > __ __
>> >
>> > The question can take one of several forms; multiple choice (select one
>> > or more), or short answer.
>> >
>> > __ __
>> >
>> > Post your suggestions here or email them to me privately ASAP so I can
>> > respond to the team assembling the survey in sufficient time.
>> >
>> >
>> >
>> > stevemar
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] Feedback for upcoming user survey questionnaire

[Steve Martinelli]

We have the opportunity to ask one question on the upcoming user survey and
we get to decide the audience to which we serve the question.



Our audience options are: USING, TESTING, or INTERESTED in Keystone (I
think we should aim for USING or TESTING)



The question can take one of several forms; multiple choice (select one or
more), or short answer.



Post your suggestions here or email them to me privately ASAP so I can
respond to the team assembling the survey in sufficient time.


stevemar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] reminder: no meeting today

[Steve Martinelli]

see everyone next week, happy holidays!

stevemar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Intermittent gate failures across multiple projects

[Steve Martinelli]

Those look like they were introduced in the latest release, and related to
the OpenStackSDK refactoring that hit openstackclient networking commands.
We actually released the new version because folks were hitting similar
errors, but for more often used commands (like listing security groups or
IPs.)

Is the latest OSC affecting a gate for you?


On Dec 23, 2016 8:33 AM, "Andrey Kurilin"  wrote:

Hi eveyone!

I found two more failures related to openstackclient which had appeared
recently:

- "HttpException: Bad Request" while trying to set quotas via
openstackclient
  http://logs.openstack.org/43/414543/1/check/gate-rally-
dsvm-neutron-existing-users-rally/36518f0/console.html#_
2016-12-23_11_31_55_070176
- "'SecurityGroup' object has no attribute 'keys'" while creating new
security group
  http://logs.openstack.org/64/355264/5/check/gate-manila-
tempest-dsvm-mysql-generic-ubuntu-xenial-nv/9ff7aec/logs/
devstacklog.txt.gz#_2016-12-23_12_53_44_213

State of latest openstackclient doesn't look good to me :(


On Fri, Dec 23, 2016 at 5:24 AM, Tony Breeds 
wrote:

> On Thu, Dec 22, 2016 at 04:31:38PM -0800, John Villalovos wrote:
> > We believe the error is caused by a bad wheel for lxml 3.7.0 that was
> > pushed today to PyPi
> >
> > Thanks to everyone working together on this issue in #openstack-infra !
> >
> > A patch is proposed to blacklist that release and we are testing it now.
>
> The fix is now merged so if you're jobs failed with 'Illegal Instruction'
> feel
> free to recheck without swamping our CI.  I believe that eleastic-recheck
> should
> tell you if you match this case.
>
> Thanks to those that found the root cause and worked on the fix
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Proposing Steve Martinelli for project-team-guide core

[Steve Martinelli]

Thanks! Happy to help guard another gate :)

On Dec 22, 2016 4:52 AM, "Thierry Carrez"  wrote:

> Doug Hellmann wrote:
> > Excerpts from Thierry Carrez's message of 2016-12-20 16:18:15 +0100:
> >> Hi everyone,
> >>
> >> As you probably know, the OpenStack Project Team Guide is a piece of
> >> documentation geared towards project teams, to help them navigate the
> >> troubled and complex waters of being an official OpenStack team:
> >>
> >> http://docs.openstack.org/project-team-guide/
> >>
> >> Steve Martinelli has been doing a great job of proposing and reviewing
> >> changes proposed to the guide, and we can always use some help there, so
> >> I'd like to propose that he joins the core team.
> >>
> >
> > +1, Steve has been helpful with reviews lately.
>
> Added!
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Stepping down from core

[Steve Martinelli]

Sorry to see you go Matt. Thanks for everything you've done with in the
docs project, and thank you for always taking the time to field all the
setup questions in #openstack and #openstack-dev from the newcomers, it was
invaluable.

Hoping your new opportunity brings you much success.

On Wed, Dec 21, 2016 at 11:11 AM, Matt Kassawara 
wrote:

> Howdy!
>
> After several years of contributing to OpenStack documentation, a
> significant change in my career path warrants resigning from my role as a
> core reviewer. Working with the OpenStack community was a great experience
> and I hope it continues to grow... with sufficient documentation, of course.
>
> Cheers,
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] office hours starting January 6th

[Steve Martinelli]

Thanks for setting this up Lance!

You can count on me to join and smash some bugs.

On Wed, Dec 21, 2016 at 1:06 PM, Lance Bragstad  wrote:

> Hi folks!
>
> If you remember, last year we started a weekly bug day [0]. The idea was
> to dedicate one day a week to managing keystone's bug queue by triaging,
> fixing, and reviewing bugs. This was otherwise known as keystone's office
> hours.
>
> I'd like to remind everyone that we are starting up this initiative again,
> right after the New Year. Our first bug day this year will be Friday,
> January 6th, and it will be recurring every Friday after that.
>
> Previously, we used the etherpad [1] to track the status of patches and
> bugs through the day. This time around, I'd like to see if we can keep
> state out of the etherpad in favor of Gerrit dashboards and IRC (which are
> easier to log and track). The etherpad now consists of information about
> the event, which should eventually be moved into a wiki somewhere.
>
> I wanted to get this out the door before the holidays so that people can
> get it on their calendar. We can also use this thread to air out any
> questions about office hours before the January 6th.
>
> Thanks and have a safe holiday season!
>
> Lance
>
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/
> 2015-October/076649.html
> [1] https://etherpad.openstack.org/p/keystone-office-hours
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

[Steve Martinelli]

On Tue, Dec 20, 2016 at 4:39 PM, Clay Gerrard 
wrote:

>
> On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu  wrote:
>
>>
>>
>> $ openstack objectstore container  
>>
>> $ openstack container container  
>>
>> $ openstack secret container  
>>
>>
>>
>> Thoughts?
>>
>
> This is the closest thing I can see that's somewhat reasonable - with the
> obvious exception of "container container " - which is pretty gross.
>
> Here's the best list I could find of what's going on now:
>
> http://docs.openstack.org/developer/python-openstackclient/command-list.
> html
>
> The collision of top-level resource names is not new.  You see stuff like
> "volume create" & "server create" - but also "volume backup create" &
> "server backup create"- which is an obvious pattern to replicate for
> disambiguating top level name conflicts with similarly named
> (sub?)-resources between services - except apparently in an effort to keep
> things flat no one saw it coming with a name like "container".
>
> But IMHO an object-store "container" is not a top level OpenStack
> resource, is it?  I would think users would be happy to dump stuff into the
> object store using "object create" - and reasonably expect to use "object
> container create" to create a container *for their objects*?  This isn't a
> generic OpenStack "container" - you can't use this generic "container" for
> anything except objects?  Oddly, this pattern is already in use with the
> pre-existing "object store account" command?!
>

This was my initial thought when discussing the problem with Hongbin last
night.

We have three main "swift" resources in OSC -- "object store account",
"container" and "object". I think renaming "container" to "object store
container" is totally acceptable. The issue of deprecation comes into play,
we'll need to deprecate it and give it at least one cycle. Luckily, the zun
team isn't ready to publish a CLI just yet.

Alternatively, I don't mind "appcontainer".
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Allowing Teams Based on Vendor-specific Drivers

[Steve Martinelli]

At the last TC meeting [1] we discussed this topic and the various options
that were presented, here's a quick recap:

Options that will be removed, the patches for these options will be
abandoned:
  - Red (option 6), it had the least support
  - Hard black (option 1) in favor of soft black (option 2)
  - Hard white (option 3) in favor of soft white (option 4)

Remaining Options:
  - Soft black (option 2): default option, had no negative feedback,
represents the current status quo
  - Soft white (option 4): had some positive feedback, folks liked it's
simple solution
  - Grey (option 5): had the most positive feedback, but also the least
amount of detail

We'll continue to iterate on the remaining three options.

 - steve

[1]
http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.log.txt


On Mon, Nov 28, 2016 at 1:33 PM, Doug Hellmann 
wrote:

> The OpenStack community wants to encourage collaboration by emphasizing
> contributions to projects that abstract differences between
> vendor-specific products, while still empowering vendors to integrate
> their products with OpenStack through drivers that can be consumed
> by the abstraction layers.
>
> Some teams for projects that use drivers may not want to manage
> some or all of the drivers that can be consumed by their project
> because they have little insight into testing or debugging the code,
> or do not have the resources needed to manage centrally a large
> number of separate drivers. Vendors are of course free to produce
> drivers to integrate with OpenStack completely outside of the
> community, but because we value having the drivers as well as the
> more general support of vendor companies, we want to encourage a
> higher level of engagement by welcoming vendor-specific teams to
> be a part of our community governance.
>
> Our Requirements for New Projects list [0] includes a statement
> about establishing a "level and open collaboration playing field"
>
>   The project shall provide a level and open collaboration playing
>   field for all contributors. The project shall not benefit a single
>   vendor, or a single vendors product offerings; nor advantage
>   contributors from a single vendor organization due to access to
>   source code, hardware, resources or other proprietary technology
>   available only to those contributors.
>
> This requirement makes it difficult to support having teams focused
> on producing a deliverable that primarily benefits a single vendor.
> So, we have some tension between wanting to collaborate and have a
> level playing field, while wanting to control the amount of driver
> code that projects have to manage.
>
> I'm raising this as an issue because it's not just a hypothetical
> problem. The Cisco networking driver team, having been removed from
> the Neutron stadium, is asking for status as a separate official
> team [1]. I would very much like to find a way to say "yes, welcome
> (back)!"
>
> To that end, I've been working with fungi and ttx to identify all
> of our options. We've come up with a "spectrum", which I will try
> to summarize here but please read the associated governance patches
> for the full details. (Please note that although we've split up the
> work of writing the patches, each author may not necessarily support
> all of the patches he has submitted.)
>
> 1. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it effectively precludes official status
>for teams which only develop drivers for proprietary systems
>(hard black) [2]
>
>This would have the immediate effect of denying the Cisco team's
>request, as well as precluding future requests from similar teams.
>
> 2. A resolution reaffirming the "level playing field" requirement,
>and acknowledging that it does not necessarily preclude official
>status for teams which only develop drivers for proprietary
>systems (soft black) [3]
>
>This would allow driver-specific teams for systems as long as
>those drivers can be developed without access to proprietary
>information. The TC would have to consider how this applies to
>each team's request as it is evaluated.
>
> 3. A resolution and policy change removing the "level playing field"
>requirement (hard white) [4]
>
>This would completely remove the problematic wording from the
>governance documents (eliminate the restriction on benefiting a
>single company and consider access to specific information for
>some contributors to not be a problem).
>
> 4. A resolution and policy change loosening the "level playing field"
>requirement (soft white) [5]
>
>This would add an exception to the existing wording in the
>governance documents to exempt teams working only on drivers.
>They would still be subject to all of our other policies, unless
>similar exceptions are included.
>
> 5. Consider driver teams to be a completely different animal, defined
>in drivers.yaml i

Re: [openstack-dev] [keystone] Custom ProjectID upon creation

[Steve Martinelli]

I'm OK with the agreed approach in the patch, we restrict the ID being
specified to 32 character UUID4 string. And it only works on project
create, not update.

On Mon, Dec 5, 2016 at 1:20 PM, Andrey Grebennikov <
agrebenni...@mirantis.com> wrote:

> Hi keystoners,
> I'd like to open the discussion about the little feature which I'm trying
> to push forward for a while but I need some feedbacks/opinions/concerns
> regarding this.
> Here is the review I'm talking about https://review.openstack
> .org/#/c/403866/
>
> What I'm trying to cover is multi-region deployment, which includes
> geo-distributed cloud with independent Keystone in every region.
>
> There is a number of use cases for the change:
> 1. Allow users to re-use their tokens in all regions across the
> distributed cloud. With global authentication (LDAP backed) and same roles
> names this is only one missing piece which prevents the user to switch
> between regions even withing single Horizon session.
> 2. Automated tools responsible for statistics collection may access all
> regions using one token (real customer's usecase)
> 3. Glance replication may happen because the images' parameter "owner"
> (which is a project) should be consistent across the regions.
>
> What I hear all time - "you have to replicate your database" which from
> the devops/deployment/operations perspective is totally wrong approach.
> If it is possible to avoid Galera replication over geographically
> distributed regions - then API calls should be used. Moreover, in case of 2
> DCs there will be an issue to decide which region has to take over when
> they are isolated from each other.
>
> There is a long conversation in the comments of the review, mainly with
> concerns from cores (purely developer's opinions).
>
> Please help me to bring it to life ;)
>
> PS I'm so sorry, forgot to create a topic in the original message
>
> --
> Andrey Grebennikov
> Principal Deployment Engineer
> Mirantis Inc, Austin TX
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] Release management team draft logo

[Steve Martinelli]

A bit of colour should will go a long way here, black and brown would help
make it more obvious (IMO).

On Fri, Dec 2, 2016 at 4:05 AM, Thierry Carrez 
wrote:

> Doug Hellmann wrote:
> > Release team, please take a look at the attached logo and let me know
> > what you think.
>
> It's not immediately obvious to me it's a shepherd dog, but then I don't
> exactly know how to make that more obvious.
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Steve Martinelli]

This happened to us for keystone-specs [1]. I settled on removing the
reference to the README.rst from the doc folder. You can do the same by
removing [2].

[1] https://review.openstack.org/#/c/402878/
[2]
https://github.com/openstack/neutron-lib/blob/master/doc/source/readme.rst

On Wed, Nov 30, 2016 at 2:44 PM, Armando M.  wrote:

>
>
> On 30 November 2016 at 08:53, Michael Johnson  wrote:
>
>> Hi Flavio,
>>
>> These tags don't seem to be rendering/laying out well for octavia:
>> https://github.com/openstack/octavia/blob/master/README.rst
>>
>> Any pointers to get this corrected or is this part of the backend
>> rendering work you mentioned in the keystone message above?
>>
>>
> Actually I just noticed that this may break building docs locally for some
> envs as I now get in my env:
>
> Warning, treated as error:
> README.rst:None: WARNING: nonlocal image URI found:
> http://governance.openstack.org/badges/neutron-lib.svg
>
> I was aware of [1], and I am unsure on the next steps. Can some advise?
>
> Thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/229951/
>
>
>> Michael
>>
>> On Wed, Nov 30, 2016 at 1:34 AM, Flavio Percoco 
>> wrote:
>> > On 25/11/16 13:46 +, Amrith Kumar wrote:
>> >>
>> >> Flavio,
>> >>
>> >> I see a number of patches[1] which have been landed on this project
>> but I
>> >> find
>> >> that at least the ones that were landed for Trove, and a random
>> sampling
>> >> of
>> >> the others all to be different from what you proposed below[2] in one
>> >> important aspect.
>> >>
>> >> In [2] you proposed a structure where the title of the document; or the
>> >> first,
>> >> and most prominent heading, would be the existing heading of the
>> document,
>> >> and
>> >> the tags would be below that. In [2] for example, that was:
>> >>
>> >> "kombu - Messaging library for Python"
>> >>
>> >> and the tags would be in smaller font below that.
>> >
>> >
>> > Hi,
>> >
>> > Some fixes landed yesterday to improve the badges layout. For those
>> > interested,
>> > here's an example of what it looks like now:
>> >
>> > https://github.com/openstack/keystone
>> >
>> > Basically, the horizontal padding was reduced to the minimum needed and
>> the
>> > badges width was set to the total width of the image.
>> >
>> > Hope this helps,
>> > Flavio
>> >
>> >
>> >> What I see in [3] the patch for Trove and the proposed example [4] is:
>> >>
>> >> "Team and repository tags" as the first, and most conspicuous header,
>> and
>> >> the
>> >> header "Trove" below that.
>> >>
>> >> In some cases the second header is the same font as the "Team and
>> >> repository
>> >> tags" header.
>> >>
>> >> I think this change (these 124 changes) as proposed are not consistent
>> >> with
>> >> the proposal you made below, and certainly seem to be less suitable
>> than
>> >> that
>> >> proposal. The end product for the four trove repositories [4], [5],
>> [6],
>> >> and
>> >> [7]
>> >>
>> >> I think we should have a discussion on the ML whether we feel that this
>> >> new
>> >> structure is the appropriate one, and before some projects approve
>> these
>> >> changes and others don't that these be all marked WF-1.
>> >>
>> >> Thanks,
>> >>
>> >> -amrith
>> >>
>> >> [1] https://review.openstack.org/#/q/topic:project-badges
>> >> [2] https://github.com/celery/kombu/blob/master/README.rst
>> >> [3] https://review.openstack.org/#/c/402547/
>> >> [4] https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
>> >> [5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
>> >> [6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
>> >> [7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258
>> >>
>> >>
>> >>
>> >>
>> >>> -Original Message-
>> >>> From: Flavio Percoco [mailto:fla...@redhat.com]
>> >>> Sent: Thursday, October 13, 2016 7:07 AM
>> >>> To: OpenStack Development Mailing List (not for usage questions)
>> >>> 
>> >>> Subject: Re: [openstack-dev] [all][tc] Exposing project team's
>> metadata
>> >>> in
>> >>> README files
>> >>>
>> >>> On 12/10/16 11:01 -0400, Doug Hellmann wrote:
>> >>> >Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
>> >>> >> Greetings,
>> >>> >>
>> >>> >> One of the common complains about the existing project organization
>> >>> >> in the big tent is that it's difficult to wrap our heads around the
>> >>> >> many projects there are, their current state (in/out the big tent),
>> >>> >> their
>> >>> tags, etc.
>> >>> >>
>> >>> >> This information is available on the governance website[0]. Each
>> >>> >> official project team has a page there containing the information
>> >>> >> related to the deliverables managed by that team. Unfortunately, I
>> >>> >> don't think this page is checked often enough and I believe it's
>> not
>> >>> >> known
>> >>> by everyone.
>> >>> >>
>> >>> >> In the hope that we can make this information clearer to people
>> >>> >> browsing the many repos (most likely on github), I'd like to
>> propose
>> >>> >> that we include th

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Steve Martinelli]

Refresh (not from cache)?

On Wed, Nov 30, 2016 at 11:23 AM, Ben Nemec  wrote:

>
>
> On 11/30/2016 10:19 AM, Jason Rist wrote:
>
>> On 11/30/2016 11:18 AM, Ben Nemec wrote:
>>
>>>
>>>
>>> On 11/30/2016 03:34 AM, Flavio Percoco wrote:
>>>
 On 25/11/16 13:46 +, Amrith Kumar wrote:

> Flavio,
>
> I see a number of patches[1] which have been landed on this project
> but I find
> that at least the ones that were landed for Trove, and a random
> sampling of
> the others all to be different from what you proposed below[2] in one
> important aspect.
>
> In [2] you proposed a structure where the title of the document; or
> the first,
> and most prominent heading, would be the existing heading of the
> document, and
> the tags would be below that. In [2] for example, that was:
>
> "kombu - Messaging library for Python"
>
> and the tags would be in smaller font below that.
>

 Hi,

 Some fixes landed yesterday to improve the badges layout. For those
 interested,
 here's an example of what it looks like now:

 https://github.com/openstack/keystone

 Basically, the horizontal padding was reduced to the minimum needed
 and the
 badges width was set to the total width of the image.

>>>
>>> Any idea why there is so much vertical whitespace after the badges in
>>> https://github.com/openstack/instack-undercloud ?  It's all clickable so
>>> I'm thinking it must be coming from the badge image for some reason.
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> How much is 'so much'? I see at most 50 pixels?
>>
>>
> Strange, I see almost 200 pixels.  I also don't see the same thing on the
> keystone readme Flavio linked.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Stepping down from keystone core

[Steve Martinelli]

Marek, thanks for everything you've done in Keystone. It was loads of fun
to develop some of the early federation work with you back in the Icehouse
release! Good luck in whatever the future holds for you!

On Tue, Nov 22, 2016 at 5:18 PM, Marek Denis <
marek.denis+openst...@gmail.com> wrote:

> Hi,
>
> Due to my current responsibilities I cannot serve as keystone core
> anymore. I also feel I should make some space for others who will surely
> bring new quality to the OpenStack Identity Program.
>
> It's been a great journey, I surely learned a lot and improved both my
> technical and soft skills. I can only hope my contributions and reviews
> have been useful and made OpenStack a little bit better.
>
> I wish you all the best in the future.
>
> With kind regards,
> Marek Denis
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Pike PTL

[Steve Martinelli]

one of these days i'll learn how to spell :)

On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli 
wrote:

> Keystoners,
>
> I do not intend to run for the PTL position of the Pike development cycle.
> I'm sending this out early so I can work with folks interested in the role,
> If you intend to run for PTL in Pike and are interested in learning the
> ropes (or just want to hear more about what the role means) then shoot me
> an email.
>
> It's been an unforgettable ride. Being PTL a is very rewarding experience,
> I encourage anyone interested to put your name forward. I'm not going
> away from OpenStack, I just think three terms as PTL has been enough. It'll
> be nice to have my evenings back :)
>
> To *all* the keystone contributors (cores and non-cores), thank you for
> all your time and commitment. More importantly thank you for putting up
> with my many questions, pings, pokes and -1s. Each of you are amazing and
> together you make an awesome team. It has been an absolute pleasure to
> serve as PTL, thank you for letting me do so.
>
> stevemar
>
>
> 
>
> Thanks for the idea Lana [1]
> [1] http://lists.openstack.org/pipermail/openstack-docs/
> 2016-November/009357.html
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keytone] Pike PTL

[Steve Martinelli]

Keystoners,

I do not intend to run for the PTL position of the Pike development cycle.
I'm sending this out early so I can work with folks interested in the role,
If you intend to run for PTL in Pike and are interested in learning the
ropes (or just want to hear more about what the role means) then shoot me
an email.

It's been an unforgettable ride. Being PTL a is very rewarding experience,
I encourage anyone interested to put your name forward. I'm not going away
from OpenStack, I just think three terms as PTL has been enough. It'll be
nice to have my evenings back :)

To *all* the keystone contributors (cores and non-cores), thank you for all
your time and commitment. More importantly thank you for putting up with my
many questions, pings, pokes and -1s. Each of you are amazing and together
you make an awesome team. It has been an absolute pleasure to serve as PTL,
thank you for letting me do so.

stevemar




Thanks for the idea Lana [1]
[1]
http://lists.openstack.org/pipermail/openstack-docs/2016-November/009357.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [OpenStack-operators] [docs][upgrades] time to add official docs for upgrading services?

[Steve Martinelli]

On Thu, Nov 17, 2016 at 11:04 PM, darren chan 
wrote:

> Good timing, I was about to send a follow-up email about this spec.
>
> I agree, this content needs to be more visible, which is why the spec
> proposed to move upgrade notes to the Upgrades chapter in the Operations
> Guide. However, it seems like the general consensus is to keep content in
> project repos because it is more likely to be maintained there.
>
> Considering the Ocata development cycle is pretty short, we've already
> established our docs deliverables, and other projects are still developing
> upgrade notes, would links to the upgrade notes in the Ops Guide suffice in
> the interim? We can then propose and plan a better solution for Pike, such
> as in-tree official guides?
>
> Thoughts?
>
>
The project teams will always use the maintenance argument. But I
understand your concern, and in my initial draft to the mailing list i was
going to voice a similar statement. Maybe wait until teams have fleshed out
their various supported upgrade strategies?



> Darren
>
>
> On Friday, 18 November 2016, 13:33, Lana Brindley <
> openst...@lanabrindley.com> wrote:
>
>
> Isn't that more or less what this is?
>
> https://review.openstack.org/#/c/394261/
>
>
Yup! Thanks for reading my mind docs team :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [docs][upgrades] time to add official docs for upgrading services?

[Steve Martinelli]

In the keystone docs we have notes about how to upgrade between releases
[1], so does the nova team [2].

Is it time we create an official guides to [3] for this subject?

[1] http://docs.openstack.org/developer/keystone/upgrading.html
[2] http://docs.openstack.org/developer/nova/upgrade.html
[3] http://docs.openstack.org/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Weekly Policy Meeting

[Steve Martinelli]

May I could suggest another action item? I think we need clear use cases.
What policy and authorization capabilities are users expecting keystone to
have? What are the short-comings of the implementation we have today?

On Wed, Nov 16, 2016 at 1:06 PM, Lance Bragstad  wrote:

> We had some issues using Hangouts because we hit the maximum limit of
> attendees. To make it so that everyone could participate equally, we moved
> the meeting to #openstack-keystone [0]. I have an action item to propose an
> official meeting to the irc-meetings repository. Patch for the meeting is
> currently up for review and it will be at the same time, but in
> #openstack-meeting-cp instead of #openstack-keystone [1]. We do have a list
> of action items we came up with during the meeting:
>
>- ACTION ITEM: ayoung to repropose https://review.openstack.org/#
>/c/391624/
>- ACTION ITEM: lbragstad to create an official meeting
>   - Done: https://review.openstack.org/#/c/398500/
>- ACTION ITEM: the entire group to get familiar with Apache Fortress
>   - Docs: http://directory.apache.org/fortress/
>   - Example: http://xuctarine.blogspot.ru/2016/08/apache-fortress-
>   easiest-way-to-get-full.html
>- ACTION ITEM: the entire group to get familiar with OpenStack congress
>   - Docs: https://wiki.openstack.org/wiki/Congress
>- ACTION ITEM: the entire group to get familiar with
>https://github.com/admiyo/keystone/tree/url_patterns
><https://github.com/admiyo/keystone/tree/url_patterns>
>
> The first item on the agenda will be following up on any action items from
> previous meetings. I've already bootstrapped the next agenda in the meeting
> etherpad [2]. Thanks again to everyone who attended and I look forward to
> next week's meeting.
>
>
> [0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%
> 23openstack-keystone.2016-11-16.log.html#t2016-11-16T16:01:43
> [1] https://review.openstack.org/#/c/398500/
> [2] https://etherpad.openstack.org/p/keystone-policy-meeting
>
> On Wed, Nov 16, 2016 at 8:32 AM, Lance Bragstad 
> wrote:
>
>> Just sending out a reminder that we'll be having our first meeting in 90
>> minutes. You can find all information about our agenda in the etherpad [0]
>> as well as a link to the hangout [1].
>>
>> See you there!
>>
>> [0] https://etherpad.openstack.org/p/keystone-policy-meeting
>> [1] https://hangouts.google.com/call/pd36j4qv5zfbldmhxeeatq6f7ae
>>
>>
>> On Fri, Nov 11, 2016 at 8:33 AM, Lance Bragstad 
>> wrote:
>>
>>> I've added some initial content to the etherpad [0], to get things
>>> rolling. Since this is going to be a recurring thing, I'd like our first
>>> meeting to level set the playing field for everyone. Let's spend some time
>>> getting familiar with policy concepts, understand exactly how OpenStack
>>> policy works today, then we can start working on writing down what we like
>>> and don't like about the existing implementation. I'm sure most people
>>> interested in this work will already be familiar with the problem, but I
>>> want to make it easy for folks who aren't to ramp up quickly and get them
>>> into the discussion.
>>>
>>> Some have already started contributing to the etherpad! I've slowly
>>> started massaging that information into our first agenda. I'll continue to
>>> do so and send out another email on Tuesday as a reminder to familiarize
>>> yourselves with the etherpad before the meeting.
>>>
>>>
>>> Thanks!
>>>
>>>
>>> [0] https://etherpad.openstack.org/p/keystone-policy-meeting
>>>
>>> On Thu, Nov 10, 2016 at 2:36 PM, Steve Martinelli <
>>> s.martine...@gmail.com> wrote:
>>>
>>>> Thanks for taking the initiative Lance! It'll be great to hear some
>>>> ideas that are capable of making policy more fine grained, and keeping
>>>> things backwards compatible.
>>>>
>>>> On Thu, Nov 10, 2016 at 3:30 PM, Lance Bragstad 
>>>> wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> After hearing the recaps from the summit, it sounds like policy was a
>>>>> hot topic (per usual). This is also reinforced by the fact every release 
>>>>> we
>>>>> have specifications proposed to re-do policy in some way.
>>>>>
>>>>> It's no doubt policy in OpenStack needs work. Let's dedicate an hour a
>>>>

Re: [openstack-dev] [keystone] meeting format poll

[Steve Martinelli]

On Wed, Nov 16, 2016 at 9:10 AM, Jeremy Stanley  wrote:

> On 2016-11-15 17:23:49 -0500 (-0500), Steve Martinelli wrote:
> > I don't bother with the time slider, the meeting agenda is never deleted
> > from the etherpad, we just keep tacking on
>
> Oh, I see, using it as an append-only log (and hope nobody erases
> anything or the pad doesn't spontaneously corrupt, which we have
> seen happen from time to time). Well, 1. you could also just do the
> same thing with a wiki page, but more importantly 2. etherpads start
> to perform really poorly when your content reaches a certain size so
> you may find you have to periodically rotate to a fresh pad when it
> begins to bog down (keep on the lookout for that).
>

Yeah, i figured this will eventually happen, at which point we'll either
prune or move to a new one. As silly as it sounds, not having to log in has
made a noticeable difference -- it's not just me (or another ptl) setting
the agenda)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] meeting format poll

[Steve Martinelli]

On Tue, Nov 15, 2016 at 4:53 PM, Jeremy Stanley  wrote:

> On 2016-11-15 15:31:40 -0500 (-0500), Steve Martinelli wrote:
> > I really like the etherpad approach, its nice to see the history from
> > previous meetings
>
> Strange, I personally find it way easier to navigate the change
> history for a MediaWiki page than use the time slider in Etherpad:
>

I don't bother with the time slider, the meeting agenda is never deleted
from the etherpad, we just keep tacking on
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [osc][openstackclient][cliff] translation the command description in help

[Steve Martinelli]

On Tue, Nov 15, 2016 at 4:08 PM, Steve Martinelli 
wrote:

> $ find . -name '*.py' -exec sed -i .bak -e 's/""".*"""/_description=_("&")/g'
> {} \;
>
>
pep8 just burned me here, make sure you add a space between the = operator
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [osc][openstackclient][cliff] translation the command description in help

[Steve Martinelli]

The following is a PSA for all OpenStackClient plugins.

Matt Edmonds filed bug 1636209 [1] against OpenStackClient because the main
help message was not getting translated. In the example below, the "Create
new user" string was not translated (some of the help text was removed for
readability):


$ openstack user create --help
  usage: openstack user create [-h]
  ... [--password ] 

Create new user  <

positional arguments:
  New user name

optional arguments:
  --password < password>   Set user password


As it turns out, this was because we were setting this help message in a
docstring, which could not be marked for translation. cliff was
automatically picking up the docstring and using that (as-designed).

Doug Hellmann fixed the issue for cliff by allowing a class attribute [2],
and I proposed a patch for OpenStackClient [3]. Look for a new cliff
release soon, and a bump to the minimum version in global-requirements.

In case you want to do this in your plugin (assuming you are setup for
translations), and not handcraft 100+ lines, you can run the following
commands (this is what I used, and I'm sure someone will come up with a
better way of doing it)

$ find . -name '*.py' -exec sed -i .bak -e
's/""".*"""/_description=_("&")/g' {} \;
$ find . -type f -name '*.py.bak' -delete
$ git checkout examples/ releasenotes/ openstackclient/tests/

Thanks for reading!
Steve

[1] https://bugs.launchpad.net/python-openstackclient/+bug/1636209
[2] https://review.openstack.org/#/c/397321/
[3] https://review.openstack.org/#/c/396939/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] meeting format poll

[Steve Martinelli]

I really like the etherpad approach, its nice to see the history from
previous meetings

On Tue, Nov 15, 2016 at 2:39 PM, Lance Bragstad  wrote:

> Hey folks,
>
> In today's keystone meeting, Morgan mentioned that we had the ability to
> go back to using OpenStack Wikis for meeting agendas. I created a poll to
> get feedback [0].
>
> Let's keep it open for the week and look at the results as a team at our
> next meeting.
>
> Thanks!
>
> [0] https://goo.gl/forms/Gs4lZxgktRzlwHAn2
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

[Steve Martinelli]

Its been a few days now, and I think we're OK. We are not seeing the
tempest failures related to race conditions like we saw before. No major CI
breaks, there seems be an uptick in failures, but those look like they are
timeouts and not related (i hope!). Thanks to everyone who worked on this!

On Thu, Nov 3, 2016 at 10:11 AM, Steve Martinelli 
wrote:

> As a heads up to some of keystone's consuming projects, we will be
> changing the default token format from UUID to Fernet. Many patches have
> merged to make this possible [1]. The last 2 that you probably want to look
> at are [2] and [3]. The first flips a switch in devstack to make fernet the
> selected token format, the second makes it default in Keystone itself.
>
> [1] https://review.openstack.org/#/q/topic:make-fernet-default
> [2] DevStack patch: https://review.openstack.org/#/c/367052/
> [3] Keystone patch: https://review.openstack.org/#/c/345688/
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Weekly Policy Meeting

[Steve Martinelli]

Thanks for taking the initiative Lance! It'll be great to hear some ideas
that are capable of making policy more fine grained, and keeping things
backwards compatible.

On Thu, Nov 10, 2016 at 3:30 PM, Lance Bragstad  wrote:

> Hi folks,
>
> After hearing the recaps from the summit, it sounds like policy was a hot
> topic (per usual). This is also reinforced by the fact every release we
> have specifications proposed to re-do policy in some way.
>
> It's no doubt policy in OpenStack needs work. Let's dedicate an hour a
> week to policy, analyze what we have currently, design an ideal solution,
> and aim for that. We can bring our progress to the PTG in Atlanta.
>
> We'll hold the meeting openly using Google Hangouts and record our notes
> using etherpad.
>
> Our first meeting will be Wednesday, November 16th from 10:00 AM – 11:00
> AM Central (16:00 - 17:00 UTC) and it will reoccur weekly.
>
> Hangout: https://hangouts.google.com/call/pd36j4qv5zfbldmhxeeatq6f7ae
> Etherpad: https://etherpad.openstack.org/p/keystone-policy-meeting
>
> Let me know if you have any other questions, comments or concerns. I look
> forward to the first meeting!
>
> Lance
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Anyone want to meetup at KubeCon?

[Steve Martinelli]

You can try finding Brad Topol, he's presently at Kubecon and familiar with
all things Keystone.

On Tue, Nov 8, 2016 at 4:49 PM, Stephen McQuaid 
wrote:

> We have been developing a keystone authz webhook for easy integration.  If
> anyone is interested we can look at open-sourcing it
>
>
>
> Stephen McQuaid
>
> *Sr. Software Engineer | Kubernetes & Openstack*
>
> *GoDaddy*
>
>
>
> M: 484.727.8383 | O: 669.600.5852
>
> smcqu...@godaddy.com
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

[Steve Martinelli]

On Sat, Nov 5, 2016 at 6:15 PM, Jay Pipes  wrote:

> On 11/05/2016 01:15 AM, Steve Martinelli wrote:
>
>> The keystone team has a new spec being proposed for the Ocata release,
>> it essentially boils down to adding properties / metadata for projects
>> (for now) [1].
>>
>
> Yes, I'd seen that particular spec review and found it interesting in a
> couple ways.


Please comment on it :)

I've added nova and cinder here since the APIs that are being proposed
>> are more or less carbon copies of what is available through their APIs
>> (for server and volumes, respectively). What has been your project's
>> experience with handling metadata / properties? I assume that its been
>> there a while and you can't remove it. If you could go back and redo
>> things, would you do it another way? Would you take a more purist stance
>> and enforce more strict APIs, metadata be damned?
>>
>
> Yes. I would get rid of the server metadata API that is in the Compute
> API. I believe the server tags API in the Compute API is appropriate for
> user-defined taxonomy of servers. For non user-defined things like system
> metadata, I prefer to have schema-defined attributes that are standardize
> and typed but a structured "properties" API can be useful as long as the
> key and value fields are indexable and reasonably sized.
>

Interesting, I'll add this to the review and see how some if the folks
proposing the new APIs would find that as suitable for their use cases. For
reference: http://developer.openstack.org/api-ref/compute/


> I also added horizon because i'm curious about the impact this causes
>> when representing a resource.
>>
>> Personally, I am for the idea, we've had numerous requests from
>> operators about providing this support and I like to make them happy.
>>
>
> I am most concerned actually about the resistance from some in the
> Keystone contributor community to storing quota *limits* [1] for users and
> projects. Right now, every service project needs to store information about
> quota limits for all users and projects, and the services each do this
> annoyingly differently. Keystone is the thing that stores attributes of a
> user or a project. Limits of various quantitative resources in the system
> are an attribute of a user or a project. This information belongs in
> Keystone, IMHO, with a good REST API that other services can use to grab
> this information.
>

Actually, this summit was the first I've heard of it (more so than just a
passing idea with no one up for doing the work). We talked about it at our
unconference session and Boris Bobrov (breton) has a few TODOs on the topic
(post to ML and create a spec
https://etherpad.openstack.org/p/ocata-keystone-unconference )
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][nova][cinder][horizon][all] properties / metadata for resources

[Steve Martinelli]

The keystone team has a new spec being proposed for the Ocata release, it
essentially boils down to adding properties / metadata for projects (for
now) [1].

We have somewhat had support for this, we have an "extras" column defined
in our database schema, whatever a user puts in a request that doesn't
match up with our API, those key-values are dumped into the "extras"
column. It's not a pleasant user experience, since you can't really "unset"
the data easily, or grab it, or update it. There's actually been patches to
keystoneclient for getting around this, but its rather hacky and hardcodes
a lot of values [2] [3]

I've added nova and cinder here since the APIs that are being proposed are
more or less carbon copies of what is available through their APIs (for
server and volumes, respectively). What has been your project's experience
with handling metadata / properties? I assume that its been there a while
and you can't remove it. If you could go back and redo things, would you do
it another way? Would you take a more purist stance and enforce more strict
APIs, metadata be damned?

I also added horizon because i'm curious about the impact this causes when
representing a resource.

Personally, I am for the idea, we've had numerous requests from operators
about providing this support and I like to make them happy.

[1] https://review.openstack.org/#/c/36/
[2] https://review.openstack.org/#/c/375239/
[3] https://review.openstack.org/#/c/296246/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][solum] is solum-infra-guestagent an unmaintained project?

[Steve Martinelli]

bump, still hoping to get feedback on this

On Fri, Oct 28, 2016 at 1:23 AM, Steve Martinelli 
wrote:

> When reviewing the projects necessary for the ocata community-wide goal,
> (to remove old oslo-incubator code [1]) I noticed that solum-infra-guest
> agent has had *very* few commits, 13 in total [2]. Almost half of which
> were project cleanup type changes that all projects did. The last patch of
> significance was over 2 years ago (Sept 2014).
>
> I'm inquiring as to the status of the project, and what we should do about
> it? It's still being maintained by the good will of some community members,
> but it's eating up time nonetheless.
>
> [1] https://etherpad.openstack.org/p/ocata-goal-oslo
> [2] https://github.com/openstack/solum-infra-guestagent/commits/master
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

[Steve Martinelli]

Thanks Alex and Emilien for the quick answer. This was brought up at the
summit by Adam, but I don't think we have to prevent keystone from changing
the default. TripleO and Puppet can still specify UUID as their desired
token format; it is not deprecated or slated for removal. Agreed?

On Thu, Nov 3, 2016 at 10:23 AM, Alex Schultz  wrote:

> Hey Steve,
>
> On Thu, Nov 3, 2016 at 8:11 AM, Steve Martinelli 
> wrote:
> > As a heads up to some of keystone's consuming projects, we will be
> changing
> > the default token format from UUID to Fernet. Many patches have merged to
> > make this possible [1]. The last 2 that you probably want to look at are
> [2]
> > and [3]. The first flips a switch in devstack to make fernet the selected
> > token format, the second makes it default in Keystone itself.
> >
> > [1] https://review.openstack.org/#/q/topic:make-fernet-default
> > [2] DevStack patch: https://review.openstack.org/#/c/367052/
> > [3] Keystone patch: https://review.openstack.org/#/c/345688/
> >
>
> Thanks for the heads up. In puppet openstack we had already
> anticipated this and attempted to do the same for the
> puppet-keystone[0] module as well.  Unfortunately after merging it, we
> found that tripleo wasn't yet prepared to handle the HA implementation
> of fernet tokens so we had to revert it[1].  This shouldn't impact
> anyone currently consuming puppet-keystone as we define uuid as the
> default for now. Our goal is to do something similar this cycle but
> there needs to be some further work in the downstream consumers to
> either define their expected default (of uuid) or support fernet key
> generation correctly.
>
> Thanks,
> -Alex
>
> [0] https://review.openstack.org/#/c/389322/
> [1] https://review.openstack.org/#/c/392332/
>
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][tripleo][ansible][puppet][all] changing default token format

[Steve Martinelli]

As a heads up to some of keystone's consuming projects, we will be changing
the default token format from UUID to Fernet. Many patches have merged to
make this possible [1]. The last 2 that you probably want to look at are
[2] and [3]. The first flips a switch in devstack to make fernet the
selected token format, the second makes it default in Keystone itself.

[1] https://review.openstack.org/#/q/topic:make-fernet-default
[2] DevStack patch: https://review.openstack.org/#/c/367052/
[3] Keystone patch: https://review.openstack.org/#/c/345688/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Steve Martinelli]

Testing upgrades without downtime is definitely something we need to
improve. At the summit Dolph Mathews (dolphm on irc) was also looking at
testing out the new upgrade flow. I'm not sure what his plans are, but
getting in contact with him would be a good first step.

On Wed, Nov 2, 2016 at 3:44 AM, Julia Odruzova 
wrote:

> Hi Keystone team!
>
>
> I'm currently investigating OpenStack components upgradability. I saw that
> a few months ago there was a mail thread
>
> about Grenade multinode testing job for Keystone [1]. As far as I
> understand it was decided to test how stable Keystone works
>
> with master DB and to test how different Keystone versions work together
> in a multi-node installation. A lot of work was done
>
> to allow upgrades without downtime for Keystone since that time, so now it
> seems that Keystone is ready for testing discussed cases.
>
>
> I was wondering if anybody work on it already? Such tests would be very
> useful for keeping Keystone upgradable, so if nobody
>
> is working on it, I would like to tackle this task. Would it be OK?
>
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> February/085781.html
>
> –
>
> Thanks,
>
> Julia Odruzova,
>
> Mirantis, Inc.
>
> irc: jvarlamova
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] new keystone core (breton)

[Steve Martinelli]

I want to welcome Boris Bobrov (breton) to the keystone core team. Boris
has been a contributor for some time and is well respected by the keystone
team for bringing real-world operator experience and feedback. He has
recently become more active in terms of code contributions and bug
triaging. Upon interacting with Boris, you quickly realize he has a high
standard for quality and keeps us honest.

Thanks for all your hard work Boris, I'm happy to have you on the team.

Steve Martinelli
stevemar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][solum] is solum-infra-guestagent an unmaintained project?

[Steve Martinelli]

When reviewing the projects necessary for the ocata community-wide goal,
(to remove old oslo-incubator code [1]) I noticed that solum-infra-guest
agent has had *very* few commits, 13 in total [2]. Almost half of which
were project cleanup type changes that all projects did. The last patch of
significance was over 2 years ago (Sept 2014).

I'm inquiring as to the status of the project, and what we should do about
it? It's still being maintained by the good will of some community members,
but it's eating up time nonetheless.

[1] https://etherpad.openstack.org/p/ocata-goal-oslo
[2] https://github.com/openstack/solum-infra-guestagent/commits/master
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][Design Session] Where to propose extensions to trusts?

[Steve Martinelli]

On Fri, Oct 21, 2016 at 5:01 AM, Johannes Grassler 
wrote:

> Hello,
>
> I've got a last minute proposal, or rather two of them for the Keystone
> side of
> the design sessions in Barcelona. I guess it's something that would fit the
> Authorization work session on Friday (09:00-09:40) but I'm not sure I can
> simply add it on the Etherpad. Also, I may not able to attend the session
> in
>

The Authorization work session is more than appropriate, please go ahead
and add the items to the etherpad. Do try to be there in person, it'll make
things easier. If you can't make the session then you can always pop into
another keystone session or lurk around until the end of one where we can
talk.


> person since I'll need to join the Barbican session in the same time slot
> as
> well[0], so I'd appreciate an alternative venue if that's possible.

Hence I'll put them forth here for now:
>
> 1. Scope extensions for trusts
> ==
>
> Various services (Magnum, Heat, maybe Neutron LBaaS soon) use Keystone
> trusts to
> grant their service users or dedicated trustee users limited rights for
> various
> purposes, such as deferred operations on behalf of the user or providing
> access to
> certificate containers. These trusts can only be limited to a set of roles
> in a
> given project right now. The Admin guide mentions an endpoint limitation
> on top of
> that, but I haven't found any code in Keystone for handling that. I played
> with it
> a bit and found that every keyword argument Keystone doesn't know what to
> do
> with ends up in the trust table's `extra` column, but there's no code for
> doing
> anything with it as far as I can tell. It would be a useful thing, though
> and
> implementing it goes hand in hand with my proposal: I'd like to see an
> ability
> to scope trusts to:
>
>   1) A subset of endpoints (i.e. "This trust may only access Barbican's
> internalURL and nothing else")
>   2) A fixed path (i.e. "This trust may only access
> /v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)
>   3) A fixed URL (i.e. "This trust may only access
>  http://192.168.123.20:9311/v1/secrets/238ca94d-6115-4fe6-
> b41f-c445eeb47df8)
>
> The main thing I'm currently interested in is whether this is feasible. If
> so,
> I'd be happy to work on a blueprint and implementation. I believe this is
> really important to allow services and users to limit trusts to exactly the
> access level needed and not a bit more.
>
>
> 2. Lightweight trusts
> =
>
> When Keystone trusts are created the current practice is to either
>
>   1) Delegate the trust to a service user using the trust (example: Heat)
>   2) Create a dedicated trustee user for delegating the trust to (example:
>  Magnum)
>
> (1) is fine as far as I'm concerned, but I think (2) could do with some
> improvement. The dedicated trustee user will have a user name and password
> that
> needs to be used to authenticate as that user (along with a trust ID to
> consume
> the trust). I'd rather see a long-lived trust token scoped to the trust
> that
> can be extended upon expiry for that purpose. Just like a regular token, in
> other words. For the following reasons:
>
>   1) Everybody who creates such a user will have different idea of a secure
>  password length. A token is generated by keystone in a centralized
> manner
>  and always of a sufficient length to make for a secure secret.
>   2) It requires third party software that may need to authenticate as the
>  trustee to be aware of trusts. Example: Kubernetes' Cinder volume
> driver
>  (used by Magnum). Most such software should be able to handle an auth
>  token, on the other hand.
>   3) There is less cleanup required after the trust has served its purpose:
>  only the trust needs to be deleted at that point, but no trustee user.
>
> Comments on these two proposals (and advice on a suitable forum for
> discussing
> them at the summit) would be greatly appreciated. Thank you!
>
> Cheers,
>
> Johannes
>
>
> Footnotes:
>
> [0] In a pinch I could probably ask a colleague to stand in for me, but I'd
> prefer a solution where I can be present for both discussions.
>
> --
> Johannes Grassler, Cloud Developer
> SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> Maxfeldstr. 5, 90409 Nürnberg, Germany
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][ptl] pausing releases until 1 Nov

[Steve Martinelli]

On Oct 20, 2016 5:15 PM, "Emilien Macchi"  wrote:
>
> On Thu, Oct 20, 2016 at 9:27 PM, Doug Hellmann 
wrote:
> > It's late in the week and the release and infra teams need to see
> > to our travel preparations. I am declaring the releases repository
> > frozen until the Tuesday after summit, 1 Nov.
> >
> > If there are critical security related issues that require a release
> > before 1 Nov, please contact me directly via email.
> >
> > Doug
>
> I take this opportunity to thank doug/dims/ttx for their hard work on

+ tonyb

> release management; they always help PTLs in a productive and
> responsive way to reach the goals.
> As a PTL, I always feel happy to deal with release management assisted
> by such a great team, with nice tools like reno and openstack/releases
> repo.

+1000

> Thanks again,
> --
> Emilien Macchi
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] meeting canceled next week (oct 25 2016)

[Steve Martinelli]

due to the summit we'll be canceling the meeting next week.

stevemar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] running non-devstack jobs in Python projects aka "it works outside devstack"

[Steve Martinelli]

On Thu, Oct 13, 2016 at 10:30 PM, Davanum Srinivas 
wrote:

>
> Matt, Emilien,
>
> there's one more option, run jobs daily and add the output to the
> openstack health dashboard.
> example - http://status.openstack.org/openstack-health/#/g/build_
> name/periodic-ironic-py35-with-oslo-master


But that only runs against what is merged on master right? I think Emilien
wants to catch changes that break before they are merged.

Emilien, I think it's also worth noting which projects you intend to make
these changes to? Just "core" projects + projects that tripleO uses (heat +
ironic) + projects that have burned you in the past (OSC)? Or do you plan
on covering all projects?

Finding a balance between not enough testing, and overusing infra resources
is tricky, we should only aim for high value targets like the ones listed
above. I can't imagine this being run on all check jobs everywhere.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][horizon] keystone/horizon integration session in barcelona

[Steve Martinelli]

The keystone team had a spare fishbowl session, and we decided to use it to
collaborate with the horizon team on a few long standing issues we've had
between the two projects.

You can view the session online:
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16907

Details here:
Wed 26, 3:55pm-4:35pm
Keystone: Keystone/Horizon integration session (Fishbowl)
https://etherpad.openstack.org/p/ocata-keystone-horizon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][stable] Moving stable/mitaka to Phase-II and liberty to Phase-III

[Steve Martinelli]

On Mon, Oct 10, 2016 at 5:34 PM, Tony Breeds 
wrote:

> On Mon, Oct 10, 2016 at 08:42:48AM +0200, Ihar Hrachyshka wrote:
>
> > I think it would also make sense to *release* on the boundary of the
> switch;
> > so that it’s clear which phase a release followed.
>
> What do PTLs / stable CPLs think?
>

I would be for this, or at least encourage it. I've tried to do this with
keystone as well. When one release wraps up, I go through potential
candidates to backport and release a new version. I did this with mitaka
when we tagged newton rc1 (
https://github.com/openstack/releases/commit/1b0f12e1691fca956ae8d69cbc41737958a0a27f),
and I did this with liberty when we tagged mitaka rc1.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-docs] Admin guide in-tree?

[Steve Martinelli]

On Oct 9, 2016 6:57 PM, "Lana Brindley"  wrote:
>
> Why the rush?

I think its more eagerness than rush. Project teams made a lot of head way
with the API ref and install guides being in-tree that they want to keep
the momentum with the admin guide.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] design session schedule and etherpads

[Steve Martinelli]

Hey Keystoners,

I've created an initial draft of the keystone design session schedule. A
live view is at [1]. I'm attaching the times, etherpads, and descriptions
for each fishbowl / work session. So please start priming the etherpads
with content. Also bookmark them!

You'll notice we have one fishbowl session left, I'm taking suggestions for
what we should discuss during that time. I would prefer it to be something
that everyone can participate in, rather than a very targeted design
discussion that is better left for a work session.


Wed 26, 4:05pm-4:45pm
Keystone: Newton retrospective (Fishbowl)
https://etherpad.openstack.org/p/keystone-newton-retrospective

Wed 26, 4:55pm-5:35pm
Keystone: TBD (Fishbowl)

Thu 27, 12:00pm-12:40pm
Keystone: Unconference (Fishbowl)
https://etherpad.openstack.org/p/ocata-keystone-unconference

Thu 27, 12:50pm-1:30pm
Keystone: Ocata priorities (Fishbowl)
https://etherpad.openstack.org/p/ocata-keystone-priorities

Thu 27, 2:50pm-3:30pm
Keystone: Work session (Federation)
https://etherpad.openstack.org/p/ocata-keystone-federation

Thu 27, 3:40pm-4:20pm
Keystone: Work session (Testing)
https://etherpad.openstack.org/p/ocata-keystone-testing

Thu 27, 4:30pm-5:10pm
Keystone: Work session (Documentation)
https://etherpad.openstack.org/p/ocata-keystone-documentation

Fri 28, 10:00am-10:40am
Keystone: Work session (Authorization)
https://etherpad.openstack.org/p/ocata-keystone-authorization

Fri 28, 10:50am-11:30am
Keystone: Work session (Authentication)
https://etherpad.openstack.org/p/ocata-keystone-authentication

Fri 28, 12:00pm-12:40pm
Keystone: Work session (Scaling and Performance)
https://etherpad.openstack.org/p/ocata-keystone-scaling

Fri 28, 12:50pm-1:30pm
Keystone: Work session (Integration)
https://etherpad.openstack.org/p/ocata-keystone-integration

Fri 28, 3:00pm-7:00pm
Keystone: Contributors meetup
(No etherpad)


[1]
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Keystone%3A
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Project name DB length

[Steve Martinelli]

On Mon, Oct 3, 2016 at 10:52 AM, gordon chung  wrote:
>
>
> the original thread died pretty quickly; it didn't seem like an issue to
> anyone or needed fixing... if only there was a global council that
> worked on such technical things :P
>
>
ah great idea, perhaps we should call it a committee :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] TC candidacy

[Steve Martinelli]

I’d like to also toss my name into the ring. I’m announcing my candidacy
for a
position on the OpenStack Technical Committee.

-- About me
I have served as the Keystone PTL for the Mitaka and Newton cycles, and will
again serve as the PTL for the Ocata cycle. I’ve also contributed heavily to
python-openstackclient in it’s early days, where I am remain an active
core-reviewer. I am also a core member in a few Oslo projects (oslo.cache
and
oslo.policy) and OpenStackClient projects (os-client-config and cliff). I’ve
contributed reviews and patches to many repos over my time -- ranging from
devstack, infra, python-*client, openstack-manuals, you name it!

I’ve been contributing to OpenStack since early 2013, as part of a small
group
of IBMers dedicated to working entirely upstream. I can happily say that I
continue this same role today. Most of my work on OpenStack has been focused
on making Keystone and OpenStack more enterprise ready while trying to
improve
usability and manageability of OpenStack.

-- Bracing for the Big Crunch
The explosive growth that occurred as a result of the Big Tent was expected
and
phenomenal. I believe the decision brought great innovation, accelerated
adoption at a time when it was needed, and allowed competing projects to
co-exist. A natural reaction to such growth is unfortunately, a leveling
off or
contraction phase. We already saw hints of this in the last round of PTL
elections [1] . I believe this trend will continue. This is OK and
completely
natural, the strongest projects will continue to survive. We have seen this
pattern in many other technologies. The TC should be prepared for this
eventuality, and set minimum standards that projects should meet (not unlike
what is proposed by the OpenStack-wide goals).

-- Organizing the Big Tent
The big tent lumped all the projects together in an unorganized way, take a
quick look at the list [2]. I believe this has been a large source of
confusion
to the end consumer. There are projects that a consumer would never deploy
(docs, infra, etc), there are projects that a consumer will use one of
(openstack-ansible, puppet, chef, etc), these logical groupings go on. We
don't
provide enough guidance on which sets of projects are good groupings to
consider using together. It is critical for the OpenStack community to
reduce
the adoption pains experienced by our consumers. Everything can live in the
big tent, but let’s make the big tent a bit more organized.

-- Let’s get Opinionated
I also believe OpenStack needs to be a bit more opinionated. We have a bad
habit of trying to please everyone, and I’d like for that to stop. We’ll
end up
pleasing nobody at all. We don’t need more optional features, we need to pay
down technical debt. We need to focus on OpenStack-wide goals that create a
more consistent project that is focused and more consumable; improving the
quality of OpenStack as a whole. This is something I will be enforcing in
the
Ocata cycle for Keystone, and I encourage others to do the same.

-- Creating OpenStack-wide goals
OpenStack is mature, it’s now 6 years old. It’s (past?) time we tackle the
hard
issues at an OpenStack-wide level. I'd like to see the TC focus on goals
that
not only increase adoption of OpenStack but also make OpenStack easier to
manage and help to improve our ability to have new consumers of OpenStack
stick
with OpenStack. I believe the key to this success is to work closely with
our
operator friends. Having the Project Team Gathering (PTG) [3] will help get
the
right folks in the room to talk about the important issues.

Working on OpenStack has brought me a great deal of fun and joy. I look
forward
to working on OpenStack in any capacity and would be honored to be on the
TC.

Thanks for reading,
Steve

Stackalytics: http://stackalytics.com/?user_id=stevemar
Foundation Profile: https://www.openstack.org/community/members/profile/8430
Freenode: stevemar
Twitter: https://twitter.com/stevebot

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104170.html
[1] https://governance.openstack.org/reference/projects/index.html
[2] https://www.openstack.org/ptg/

I've also submitted the required patch to the election repo:
https://review.openstack.org/#/c/379799/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Project name DB length

[Steve Martinelli]

We may have to ask Adam or Dolph, or pull out the history textbook for this
one. I imagine that trying to not bloat the token was definitely a concern.
IIRC User name was 64 also, but we had to increase to 255 because we're not
in control of name that comes from external sources (like LDAP).

On Wed, Sep 28, 2016 at 11:06 PM, Adrian Turjak 
wrote:

> Hello Keystone Devs,
>
> Just curious as to the choice to have the project name be only 64
> characters:
> https://github.com/openstack/keystone/blob/master/keystone/
> resource/backends/sql.py#L241
>
> Seems short, and an odd choice when the user.name field is 255 characters:
> https://github.com/openstack/keystone/blob/master/keystone/
> identity/backends/sql_model.py#L216
>
> Is there a good reason for it only being 64 characters, or is this just
> something that was done a long time ago and no one thought about it?
>
> Not hugely important, just seemed odd and may prove limiting for
> something I'm playing with.
>
> Cheers,
> Adrian Turjak
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC candidacy

[Steve Martinelli]

On Wed, Sep 28, 2016 at 2:49 PM, gordon chung  wrote:

>
>
> On 28/09/2016 12:41 PM, Chris Dent wrote:
> >
> > * Information is not always clear nor clearly available, despite
> >   valiant efforts to maintain a transparent environment for the
> >   discussion of policy and process. There is more that can be done
> >   to improve engagement and communication. Maybe the TC needs
> >   release notes?
>
> +1 to release notes or something of that like. i was asked to give an
> update on the TC internally and it seems the only information out there
> is to read through backlog of meeting logs or track the items that do
> get raised to ML. even then, it's hard to define what deliverables were
> achieved in the cycle.
>
>
FWIW, the resolutions that passed are listed here:
https://governance.openstack.org/



> i found this updates page[1] but it seemed a little sparse so i imagine
> other stuff happened. i think more of this would help explain what the
> TC does and where it hopes to go because to be frank, i'm not sure what
> is in the scope of TC and what is not and i've been following the list
> and meetings for a while.
>
> [1] http://www.openstack.org/blog/category/technical-committee-updates/
>
> cheers,
>
> --
> gord
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon][keystone] retiring python-keystoneclient-kerberos

[Steve Martinelli]

Hi there,

I would like to retire the python-keystoneclient-kerberos repo [1]. The
repo was pretty basic, it had a single auth plugin. The logic has since
been copied over to keystoneauth1 and provided you have kerberos libraries
installed the plugin will be available to you. The last release of
python-keystoneclient-kerberos  was on May 23rd 2016, which included a
deprecation warning. Note that the last release was version 0.3, so we're
talking very pre-1.0.

AFAICT, nothing uses the library any longer [2]. The only consumer that did
use it is django-openstack-auth-kerberos, which is switched over to
keystoneauth1, but has not been released in quite some time (Jun 9, 2015).
[3]

Selfishly, from a keystone perspective, I think we're in the clear and can
retire the repo. But I'm tagging horizon here to see what their plans are
for the django-openstack-auth-kerberos repo.

I think we need another release of django-openstack-auth-kerberos or a new
release of django_openstack_auth that also uses setuptools to optionally
install the kerberos libraries (this is what we did in keystoneauth).

Thoughts?
stevemar

[1] https://github.com/openstack/python-keystoneclient-kerberos
[2]
http://codesearch.openstack.org/?q=keystoneclient_kerberos&i=nope&files=&repos=
[3]
https://github.com/openstack/django-openstack-auth-kerberos/blob/master/requirements.txt#L9
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [osc][keystone] User Project List

[Steve Martinelli]

On Wed, Sep 21, 2016 at 6:34 PM, Adrian Turjak 
wrote:

> 
>
> What I'd like to do is one of these two options:
> - "openstack user project list", a command which will get your id from
> your authed token and used it directly with the keystoneclient as such:
> "keystoneclient.projects.list(user='')" which will pipe the
> call correctly to: "/v3/users/{user_id}/projects"
>


>
>
- or update "openstack project list" with a "--auth-user" flag that ignores
> all other options and directly filters the project list by your token's
> user id. This type of option is already present in the "role assignment
> list" command. From a UX standpoint part of me feels that project list
> should default to --auth-user if your token doesn't have admin roles, but
> I'm not sure how easy that would be to do.
>

I prefer this one. The issue with defaulting to --auth-user (this was
proposed at one point) is that it breaks the existing behaviour (listing
all projects).
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [osc][keystone] User Project List

[Steve Martinelli]

On Wed, Sep 21, 2016 at 1:04 PM, Dolph Mathews 
wrote:

>
> I should also express a +1 for something along the lines of your original
> proposal. I'd go so far as to suggest that `openstack show user` (without a
> user ID or name as an argument) should return "me" (the authenticated
> user), as I think that'd be a better user experience.
>

That should be fixed in openstackclient 3.0.0 --
https://github.com/openstack/python-openstackclient/commit/337d013c94378a4b3f0e8f90e4f5bd745448658f
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] Design session ideas for Barcelona

[Steve Martinelli]

Keystoners and Keystone enthusiasts,

We're tracking ideas for design sessions on an etherpad [1] -- so please
help populate the etherpad!

The ideas will then be prioritized and grouped together into fishbowl
sessions (tokens, authorization, operators, authentication, etc) at a later
date.

[1] https://etherpad.openstack.org/p/keystone-ocata-summit-brainstorm

Thanks,
Steve Martinelli
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] gate-keystoneclient-dsvm-functional-ubuntu-xenial is broken

[Steve Martinelli]

Since September 14th the keystoneclient functional test job has been
broken. Let's be mindful of infra resources and stop rechecking the patches
there. Anyone have time to investigate this?

See patches https://review.openstack.org/#/c/369469/ or
https://review.openstack.org/#/c/371324/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Too many mails on announce list again :)

[Steve Martinelli]

I think bundling the puppet, ansible and oslo releases together would cut
down on a considerable amount of traffic. Bundling or grouping new releases
may not be the most accurate, but if it encourages the right folks to read
the content instead of brushing it off, I think thats worth while.

On Mon, Sep 19, 2016 at 10:04 PM, Tom Fifield  wrote:

> Hi all,
>
> Last November, we discussed the OpenStack-announce list, defined its
> purpose more finely and moved some internal library announcements to
> -dev[1].
>
> For reference, we describe the list as:
>
> """
> Subscribe to this list to receive important announcements from the
> OpenStack Release Team and OpenStack Security Team.
>
> This is a low-traffic, read-only list.
> """
>
> Unfortunately, the traffic on this list again regularly exceeds 100
> messages a month - worse than last time we talked about it.
>
> The feedback continues to come in from users that they find it more 'spam'
> than 'source of important announcements', which is not good news!
>
> Quite a lot of the email rush tends to come from when a particular project
> releases multiple 'components' at once. A fine effort of release
> management, but in the current system each component's release triggers its
> own email.
>
> For example, today the puppet team has been doing some great work with a
> 9.3.0 release. Many modules were updated. That's an "important
> announcement" for many of our users.
>
> However, to get the "low-traffic" bit, we need to make that 1 email,
> instead of 30 :)
>
>
> At least, that's my thinking. What's yours?
>
>
> Regards,
>
>
> Tom
>
>
>
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-Dece
> mber/082182.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][ptl][election] PTL candidacy

[Steve Martinelli]

Hey everyone,

I'd like to continue to serve as the PTL of the keystone project for the
Ocata release. I served as PTL of the keystone project for the Mitaka and
Newton development cycles. I find the role to be extremely rewarding, and
would be honoured to continue to serve in the same capacity, if you'll have
me.

During the Mitaka development cycle we accomplished many blueprints and hit
some important goals, here are a few off the top of my head:

  - Python 3 compatibility (for unit tests)
  - Credential encryption
  - PCI support for passwords
  - Running migration tests on non-sqlite backends
  - API docs are migrated and fully updated
  - Introduced the `keystone doctor` helper

For the Ocata release I'd like to take advantage the short development
cycle to aggressively pay down some of the technical debt we've accumulated
and also improve user and operator experience. I'd like to limit new
features to a minimum (maybe 3-5) my short list is the following:

  - Multi Factor Auth (MFA) support
  - Improving the federated identity mapping engine
  - Tackle the issue with long running operations timing out
  - Handle federated authentication without apache libraries
  - Functional tests with non-standard deployments (ldap, federated
identity)

With the exception of MFA support, all the features listed above match the
theme of paying down technical debt or improving user experience.

>From a non-technical perspective, I'd like to do the following:

  - Improve communication and engagement with our direct downstream
consumers (OSA, tripleo, etc)
  - Continue to work with operators. Create specifications based on real
world use cases that are driven by operators facing issues with
performance, usability, scalability, and upgrades.
  - Appoint a bug czar or perform weekly bug triages and monthly bug
squashes

Lastly, I'd like to thank anyone that contributed to keystone during the
Newton release. I'm very excited for what Ocata will bring and look forward
to working on it in any capacity.

Thanks for reading,
stevemar

Link to the election repo change: https://review.openstack.org/#/c/371899/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] Retrospective for Newton

[Steve Martinelli]

I like what Matt [1] and Armando [2] have done for post-mortems /
retrospectives, so I'm borrowing both. Rather than use our specs repo I
think we should just use an etherpad [3] for now. Please help fill it in
and give feedback on how the release went. I'll start priming the content
now but would like to discuss the content in Barcelona.

As Matt said: I know it's fun to troll, but please keep it constructive and
respectful.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103814.html
[2] https://review.openstack.org/#/c/360207/12

*** [3] https://etherpad.openstack.org/p/keystone-newton-retrospective ***


Thanks,
Steve
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][FFE][keystone][release] block keystonemiddleware 4.0.0

[Steve Martinelli]

We're more than happy with that outcome, and may have already started the
patch ;) https://review.openstack.org/#/c/370011/

On Wed, Sep 14, 2016 at 5:10 AM, Ihar Hrachyshka 
wrote:

> Steve Martinelli  wrote:
>
> A bug was recently filed against keystone [1]. As of the Newton release we
>> depend on a class being public -- BaseAuthProtocol instead of
>> _BaseAuthProtocol [2]. Which was introduced in 4.1.0 [3].
>>
>> The current requirement for keystonemiddleware is:
>>   keystonemiddleware>=4.0.0,!=4.1.0,!=4.5.0
>>
>> Blocking 4.0.0 would logically make it:
>>   keystonemiddleware>=4.2.0,!=4.5.0
>>
>> I've pushed a patch to the requirements repo for this change [4]. I'd
>> like to know if blocking the lower value makes sense, I realize it's
>> advertised, but we're up to 4.9.0 now.
>>
>> Unfortunately, many projects depend on keystonemiddleware, but (luckily
>> ?) this should only be server side projects [5], most of which are going
>> through their RC period now.
>>
>
> I suggest instead keystone closes the gap on their side, by falling back
> to _BaseAuthProtocol class if public one is not present. No requirement
> updates, no delay in rc1, just some time for keystone folks to be aware
> that the private class in 4.0.+ series is to be considered kinda public for
> their own usage.
>
> Ihar
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [requirements][FFE][keystone][release] block keystonemiddleware 4.0.0

[Steve Martinelli]

A bug was recently filed against keystone [1]. As of the Newton release we
depend on a class being public -- BaseAuthProtocol instead of
_BaseAuthProtocol [2]. Which was introduced in 4.1.0 [3].

The current requirement for keystonemiddleware is:
  keystonemiddleware>=4.0.0,!=4.1.0,!=4.5.0

Blocking 4.0.0 would logically make it:
  keystonemiddleware>=4.2.0,!=4.5.0

I've pushed a patch to the requirements repo for this change [4]. I'd like
to know if blocking the lower value makes sense, I realize it's advertised,
but we're up to 4.9.0 now.

Unfortunately, many projects depend on keystonemiddleware, but (luckily ?)
this should only be server side projects [5], most of which are going
through their RC period now.

Thanks for reading,
Steve

[1] https://bugs.launchpad.net/keystone/+bug/1623091
[2]
https://github.com/openstack/keystone/blob/master/keystone/middleware/auth.py#L38
[3]
https://github.com/openstack/keystonemiddleware/commit/54cba09855fd366875391cbd25c3b3c346ff7a1b
[4] https://review.openstack.org/#/c/369624/2
[5]
http://codesearch.openstack.org/?q=keystonemiddleware&i=nope&files=requirements.txt&repos=
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Why not OAuth 2.0 provider?

[Steve Martinelli]

>
> Would you please shed some light on how to configure Keystone for OAuth1?
> Thank you very much.
>

There is some documentation in the API but nothing formally written out:
http://developer.openstack.org/api-ref/identity/v3-ext/index.html


>
> I am trying to develop OAuth 2 client for Keystone. We will contribute our
> OAuth 2 client source code to the community if we can use Google/Facebook
> to log in to OpenStack through OAuth 2 client.
>
>
Currently you can setup keystone to work with Google / Facebook and other
social logins. If you've setup keystone to use Shibboleth (which you did, I
snipped that part of the message), then you can set it up to use these
social logins as well. See documentation here:
http://docs.openstack.org/developer/keystone/federation/federated_identity.html#id4


> Thanks.
>
> Best regards,
>
> Winston Hong
> Ottawa, Ontario
> Canada
>
>
> Steve Martinelli  Jun 27, 2016, 10:57 PM
>
> > So, the os-oauth routes you mention in the documentation do not make
> > keystone a proper oauth provider. We simply perform delegation (one user
> > handing some level of permission on a project to another entity) with
> the
> > standard flow established in the oauth1.0b specification.
> >
> > Historically we chose oauth1.0 because one of the implementers was very
> > much against a flow based on oauth2.0 (though the names are similar,
> these
> > can be treated as two very different beasts, you can read about it here
> > [1]). Even amongst popular service providers the choice is split down
> the
> > middle, some providing support for both [2]
> >
> > We haven't bothered to implement support for oauth2.0 since there has
> been
> > no feedback or desire from operators to do so. Mostly, we don't want
> > yet-another-delegation mechanism in keystone, we have trusts and
> oauth1.0;
> > should an enticing use case arise to include another, then we can
> revisit
> > the discussion.
> >
> > [1] https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/
> > [2] https://en.wikipedia.org/wiki/List_of_OAuth_providers
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Puppet OpenStack PTL non-candidacy

[Steve Martinelli]

Thanks for your leadership, dedication and hard work over the last 18
months. I've always enjoyed working with you to resolve the gate failures
(despite being a cause of said failures :] )


On Fri, Sep 9, 2016 at 12:05 PM, Emilien Macchi  wrote:

> Hi,
>
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
>
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
>
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
>
> Again, a big thank you for those who work with me,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSC] Tenant Resource Cleanup

[Steve Martinelli]

There's been a bug filed against OSC to implement ospurge for cleaning up
resources in (compute, network, storage, image and identity) [1] for a
while now. As Jordan said, this is something we want to be modular, and
pluggable, so other OSC plugins could extend this clean up command.

[1] https://bugs.launchpad.net/python-openstackclient/+bug/1584596

On Wed, Sep 7, 2016 at 10:42 AM, Jordan Pittier 
wrote:

>
> On Wed, Sep 7, 2016 at 4:18 PM, Boris Bobrov  wrote:
>
>> Hello,
>>
>> I wonder if it would be worth integrating ospurge into openstackclient.
>>
>> Are there any osc sessions planned at the summit?
>>
>>
>> Hi,
> I am the current "PTL" of the openstack/ospurge project. The project is
> still alive and we have some small contributions from time to time, which
> proves that there's definitively a need for a project purger tool.
>
> It would be great if there were an official/widely used tool to do that,
> maybe OSC is the best place. One advice to who ever wants to have another
> stab at it: make the thing modular from the start. (in ospurge we now have
> a fat file of 900LoC that's hard to maintain and I regularly have to "say
> no" to people trying to extend it to clean resources of the new a-la-mode
> openstack service).
>
>
>> On 09/07/2016 04:05 PM, John Davidge wrote:
>>
>>> Hello,
>>>
>>> During the Mitaka cycle we merged a new feature into the
>>> python-neutronclient called ’neutron purge’. This enables a simple CLI
>>> command that deletes all of the neutron resources owned by a given
>>> tenant. It’s documented in the networking guide[1].
>>>
>>> We did this in response to feedback from operators that they needed a
>>> better way to remove orphaned resources after a tenant had been deleted.
>>> So far this feature has been well received, and we already have a couple
>>> of enhancement requests. Given that we’re moving to OSC I’m hesitant to
>>> continue iterating on this in the neutron client, and so I’m reaching
>>> out to propose that we look into making this a part of OSC.
>>>
>>> Earlier this week I was about to file a BP, when I noticed one covering
>>> this subject was already filed last month[2]. I’ve spoken to Roman, who
>>> says that they’ve been thinking about implementing this in nova, and
>>> have come to the same conclusion that it would fit better in OSC.
>>>
>>> I would propose that we work together to establish how this command will
>>> behave in OSC, and build a framework that implements the cleanup of a
>>> small set of core resources. This should be achievable during the Ocata
>>> cycle. After that, we can reach out to the wider community to encourage
>>> a cross-project effort to incrementally support more projects/resources
>>> over time.
>>>
>>> If you already have an etherpad for planning summit sessions then please
>>> let me know, I’d love to get involved.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> [1] http://docs.openstack.org/mitaka/networking-guide/ops-resour
>>> ce-purge.html
>>> [2] https://blueprints.launchpad.net/python-openstackclient/+spe
>>> c/tenant-data-scrub
>>>
>>> 
>>> Rackspace Limited is a company registered in England & Wales (company
>>> registered number 03897010) whose registered office is at 5 Millington
>>> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy
>>> policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This
>>> e-mail message may contain confidential or privileged information
>>> intended for the recipient. Any dissemination, distribution or copying
>>> of the enclosed material is prohibited. If you receive this transmission
>>> in error, please notify us immediately by e-mail at ab...@rackspace.com
>>> and delete the original message. Your cooperation is appreciated.
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

[Steve Martinelli]

>
> On 09/02/2016 01:53 PM, Doug Hellmann wrote:
>
>> Excerpts from Thierry Carrez's message of 2016-09-02 12:15:33 +0200:
>
> I agree with Sean: increasing the variety of technologies used increases
>>> the system complexity, which in turn requires more skills to fully
>>> understand and maintain operationally. It should only be done as a last
>>> resort, with pros and cons carefully weighted. We really should involve
>>> operators in this discussion to get the full picture of arguments for
>>> and against.
>>>
>>
Two quick remarks about involving operators. First, see Matt Fischer's
reply to the thread, we have a great operator-developer experience with
Matt (he was one of the first folks looking at Fernet tokens), he
volunteered to out any triggers we write on his MySQL Galera cluster.
Secondly, the use of triggers was brought up at the OpenStack Ansible
midcycle, where several operators were present, and as I understand it,
felt positive about the idea.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] new core reviewer (rderose)

[Steve Martinelli]

I want to welcome Ron De Rose (rderose) to the Keystone core team. In a
short time Ron has shown a very positive impact. Ron has contributed
feature work for shadowing LDAP and federated users, as well as enhancing
password support for SQL users. Implementing these features and picking up
various bugs along the way has helped Ron to understand the keystone code
base. As a result he is able to contribute to the team with quality code
reviews.

Thanks for all your hard work Ron, we sincerely appreciate it.

Steve
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

[Steve Martinelli]

The keystone team is pursuing a trigger-based approach to support rolling,
zero-downtime upgrades. The proposed operator experience is documented here:

  http://docs.openstack.org/developer/keystone/upgrading.html

This differs from Nova and Neutron's approaches to solve for rolling
upgrades (which use oslo.versionedobjects), however Keystone is one of the
few services that doesn't need to manage communication between multiple
releases of multiple service components talking over the message bus (which
is the original use case for oslo.versionedobjects, and for which it is
aptly suited). Keystone simply scales horizontally and every node talks
directly to the database.

Database triggers are obviously a new challenge for developers to write,
honestly challenging to debug (being side effects), and are made even more
difficult by having to hand write triggers for MySQL, PostgreSQL, and
SQLite independently (SQLAlchemy offers no assistance in this case), as
seen in this patch:

  https://review.openstack.org/#/c/355618/

However, implementing an application-layer solution with
oslo.versionedobjects is not an easy task either; refer to Neutron's
implementation:


https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db

Our primary concern at this point are how to effectively test the triggers
we write against our supported database systems, and their various
deployment variations. We might be able to easily drop SQLite support (as
it's only supported for our own test suite), but should we expect variation
in support and/or actual behavior of triggers across the MySQLs, MariaDBs,
Perconas, etc, of the world that would make it necessary to test each of
them independently? If you have operational experience working with
triggers at scale: are there landmines that we need to be aware of? What is
it going to take for us to say we support *zero* dowtime upgrades with
confidence?

Steve & Dolph
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Upcoming OpenStackClient 3.0 Release (Monday)

[Steve Martinelli]

Yes, known bug, try with version 3.0.1

On Aug 22, 2016 3:46 PM, "Andrey Pavlov"  wrote:

> I have an issue with new openstack client -
>
> openstack client is installed in new virtual env. it version is 3.0.0
> os-client-config!=1.19.0,>=1.13.1 (from osc-lib>=0.4.0->python-
> openstackclient)
>
> I set credentials via environment OS_PROJECT_NAME, OS_USERNAME,
> OS_PASSWORD, OS_AUTH_URL.
>
> and 'openstack --debug image list' gets me an error -
>
> _validate_auth() takes exactly 3 arguments (4 given)
> Traceback (most recent call last):
>   File 
> "/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/cliff/app.py",
> line 250, in run
> self.initialize_app(remainder)
>   File "/home/apavlov/emccode/.venv/local/lib/python2.7/site-
> packages/openstackclient/shell.py", line 154, in initialize_app
> argparse=self.options,
>   File "/home/apavlov/emccode/.venv/local/lib/python2.7/site-
> packages/os_client_config/config.py", line 1067, in get_one_cloud
> raise e
> TypeError: _validate_auth() takes exactly 3 arguments (4 given)
> Traceback (most recent call last):
>   File 
> "/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/osc_lib/shell.py",
> line 135, in run
> ret_val = super(OpenStackShell, self).run(argv)
>   File 
> "/home/apavlov/emccode/.venv/local/lib/python2.7/site-packages/cliff/app.py",
> line 250, in run
> self.initialize_app(remainder)
>   File "/home/apavlov/emccode/.venv/local/lib/python2.7/site-
> packages/openstackclient/shell.py", line 154, in initialize_app
> argparse=self.options,
>   File "/home/apavlov/emccode/.venv/local/lib/python2.7/site-
> packages/os_client_config/config.py", line 1067, in get_one_cloud
> raise e
> TypeError: _validate_auth() takes exactly 3 arguments (4 given)
>
> END return value: 1
>
>
> It worked very well with version 2.X
> Is it a known bug?
>
> Regards,
> Andrey.
>
>
>
>
> On Mon, Aug 22, 2016 at 4:08 AM, Dean Troyer  wrote:
>
>> We're excited to pre-announce the release of OSC 3.0.0. The release is
>> expected to be approved by the release team during their working hours on
>> Monday 22 Aug 2016.
>>
>> This is a **huge** release, and we shuffled things around so we've bumped
>> our major version. We tried our darndest to not break anything, and where
>> applicable we deprecated things instead. We have a small number of
>> known, documented breaking changes, which is why we did a major version
>> bump, please keep this in mind when upgrading.
>>
>> We've added a lot of support:
>>   - We now use keystoneauth for all authentication and client sessions: from
>> that we will get support for various federated identity protocols as
>> they are added (saml, openid connect), kerberos, time-base one-time
>> password, any auth plugin in keystoneauth).
>>   - Support for various languages: we fixed some basic unicode issues
>> with OSC, resulting in a much cleaner experience when using non-English
>> languages.  Additional important unicode fixes are being made in cliff
>> and will get picked up automatically by all releases of OSC when those are
>> released.
>>   - Lots of new networking commands and additional options for existing
>> ones.  Too many to list them all here: support for networks, ports,
>> subnets, ip addresses, routers, network RBAC, security group, etc.
>>   - Bulk deletion support for nearly all delete commands: when deleting
>> resources supply as many as you want and we'll try to delete them all,
>> and report on any that failed.
>>   - Under the hood we moved a chuck of the common and low-level bits of
>> OSC into a new `osc-lib` repository to expose them as a documented and
>> stable library API.  This is now all available to OSC plugins without
>> having to depend on OpenStackClient itself.  The osc-lib dependency list is
>> very short, and most of those will already be used by plugins. This also
>> led to a restructuring of the CLI parsing and shell configuration code to
>> remove some duplication and overlap with os-client-config and isolate the
>> remainder in osc-lib.  osc-lib 1.0 has already been released and is now
>> available for use by plugins.
>>
>> The known breaking changes are:
>>   - The `ip floating` commands have been renamed to `floating ip` --
>> check the help output for details.  The old commands are still present but
>> deprecated and no longer appear in help output.
>>   - Finding role assignments for a user or project using the `roles list`
>> command has been deprecated, folks should use `role assignment list` for
>> this operation.
>>
>> The usual patch will be automatically created to bump the
>> upper-constaints of OSC. Where possible, we encourage projects that depend
>> on OSC (puppet, osc-plugins, tripleo, etc) to propose a patch that uses the
>> Depends-On mechanism (depends on the upper-constaints change), to ensure
>> your gate won't break.
>>
>> Thank you to the entire OSC team, we have had a lot of new contributors
>> this year, many of them working hard on the 

[openstack-dev] [keystone] newton midcycle recap

[Steve Martinelli]

Hey Keystoners!

I’ve written up a summary for a few of the technical aspects of the
mid-cycle [1]. Dolph has written up a mid-cycle retrospective [2]. For a
full summary see the etherpad [3].

We came out of the mid-cycle with a lot of TODOs, here is a summary of the
action items.

everyone
  - Review the code for bp views [4]
  - Review the code for bp PCI [5]
  - Review the code for bp credential encryption [6]
  - Review the spec and code for MFA
  - Spend 10 minutes looking at bugs and blueprints you own, mark as
invalid | fix released or implemented | obsolete as needed

ayoung
  - Modify policy files of each project so they can use “is_admin_project”
and document how to upgrade

bknudson
  - Come up with a list of reviews/examples that violated the idea of
tracking/deploying master. Use that list of anti-patterns to generate solid
code review documentation so we are less likely to do it again.

breton
  - Implement bp ldap-preprocessing [7]

dolphm
  - Implement bp keystone-doctor [8] (DONE)
  - Create a performance doc, bootstrap it with content (DONE)

henrynash:
  - Finalize the rolling upgrade spec
  - Implement support for rolling upgrades
  - Write up a reseller spec using sub domains including the auth URL idea
(Ocata)

jamielennox
  - Implement the work bp views [4]
  - Create spec to resolve long running operations problem

lamt
  - Create a spec for notifications for PCI events

rderose
  - Implement bp PCI [5]

roxanaghe
  - Create a facade for keystone LDAP code to make it nicer to use in the
identity backend.   Compare performance of ldap3 vs pyldap

stevemar
  - Submit bugs for RFEs for keystone doctor (DONE)
  - Bump implementation of Unified Delegation to Ocata (DONE)

henrynash or bknudson
  - Change federation shadow mapping to use the existing ID mapping (LDAP
already uses it) (Ocata)

bknudson and karthikb
  - Propose patches to oslo.policy for improvements to external
authorization

[1]
https://developer.ibm.com/opentech/2016/07/28/openstack-keystone-newton-mid-cycle/

[2] http://dolphm.com/retrospective-on-openstack-midcycles
[3] https://etherpad.openstack.org/p/keystone-newton-midcycle
[4] https://review.openstack.org/#/q/topic:bp/views
[5] https://review.openstack.org/#/q/topic:bp/pci-dss
[6] https://review.openstack.org/#/q/topic:bp/credential-encryption
[7] https://blueprints.launchpad.net/keystone/+spec/ldap-preprocessing
[8] https://blueprints.launchpad.net/keystone/+spec/keystone-manage-doctor
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] Listing of volume fails while using openstack client

[Steve Martinelli]

try running the command with --debug when it fails. normally that error
happens when the client can't reach the host, does the IP address and port
number look correct?

On Thu, Jul 28, 2016 at 8:57 AM, varun bhatnagar 
wrote:

> Hi,
>
> I am using OpenStack Mitaka.
> I am trying to list volumes using openstack client, the command works
> sometimes but sometimes it fails:
>
> openstack volume list
> Unable to establish connection to
> http://10.33.237.104:8776/v2/3cbbffce04d9463e8cb8d3ca6480ed92/volumes/detail
>
> openstack volume list
>
> +--+--+---+--+-+
> | ID   | Display Name | Status| Size |
> Attached to |
>
> +--+--+---+--+-+
> | dfab04ce-5ad3-4787-8342-3e76afd877a0 | testvol  | available |1 |
> |
>
> +--+--+---+--+-+
>
>
> Can anyone please tell me what is wrong here.
>
> BR,
> Varun
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Plugins for all

[Steve Martinelli]

On Fri, Jul 22, 2016 at 2:08 PM, Hayes, Graham  wrote:

>   * OpenStack Client
>
> OpenStack CLI privileged projects have access to more commands, as
> plugins cannot hook in to them (e.g. quotas)
>

It's been OSC's intention to allow for command hooking, we just don't
really know how to do that just yet :\


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Steve Martinelli]

You can create a new ocata directory if one is not present

On Jul 18, 2016 7:24 PM, "Adrian Turjak"  wrote:

>
>
> On 19/07/16 03:31, Steve Martinelli wrote:
> > I think the change you posted could very much just
> > replace the existing password plugin in keystone (
> > https://review.openstack.org/#/c/343422/) and not be it's own plugin.
> >
> > How about a specification instead?
> > https://github.com/openstack/keystone-specs :)
> > It's unlikely to land in Newton, but would be a candidate for O.
> >
>
> Will do. I'll edit my patch/blueprint to be clear that this is a
> replacement for password that does not affect normal username/password
> functionality, just adds MFA support, and write a spec for the O release.
> :)
>
> Although looking at that repo, since there isn't a folder yet for O,
> should I just throw it in ongoing?
>
> As for your gerrit comments:
> > Is there a reason you created totp_password plugin and not just added
> to the existing password plugin?"
>
> Mainly I wasn't sure if this was something people wanted and I didn't
> want to propose replacing the default password auth module as I thought
> an optional second plugin would be easier to get people to approve.
> Turns out I was wrong!
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] project mascot -- turtle!

[Steve Martinelli]

We have decided it will be a turtle. (hard shell, security, get it!)

A poll was created, anyone who had 2 or more commits in a keystone project
during the Mitaka or Newton release had a vote. The options were made by
active keystone developers during a meeting. Poll results are here [1], in
case there is a conflict/copyright issue/etc. we can go with #2 (or #3 or
...) on the list.

[1] http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_3b96ec71a39af395
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Reviewing coverage jobs set up

[Steve Martinelli]

see inline comment

On Mon, Jul 18, 2016 at 2:09 PM, Andreas Jaeger  wrote:

> While looking at coverage jobs to enable them to allow use of
> constraints in post jobs (something which has just been introduced and
> needs some more testing before we take on the other jobs), I noticed
> that we have quite a few coverage
> jobs that are failing.
>
> In general, I think coverage jobs should be run as check job so
> that you know how the coverage changes. Running them only in the post
> job means that in practice nobody sees the output of the job.
>

Yes please! I never understood why they were run as post jobs. In keystone
we've had it running as a check/gate job for a while without hiccups.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Steve Martinelli]

More comments inline.

On Mon, Jul 18, 2016 at 9:13 AM, Adrian Turjak 
wrote:

> Ok. So it sounds like I'm not entirely off track and this will probably be
> the road we go down for our deployment until we have a better option. We
> need an MFA solution, and this doesn't seem like too terrible an option.
>
> Basically after a bunch of digging this was the only solution I found that
> wouldn't break everything, still cover our requirements, maybe let us do
> something interesting with CLI tools.
>
> For the UX thing, we're likely going to edit our horizon login form to
> have an optional passcode field and have the form concatenate before
> passing it to the keystone client. Having a proper two-step login process
> with passcode entry on a second page didn't really seem to be viable with
> stock keystone and mostly stock horizon so this seemed easier and workable.
>
This was the disconnect I had, I initially envisioned this as a two-step
process, but I'm happy to be wrong. Didn't realize that appending the
passcode is a common practice.

> A side UX part that is good here though is that the CLI is still usable
> without any extra work. Just enter your password+passcode and it works.
> Although for the CLI and clients we are actually looking at options to
> allow a sort of wrapper script to connect to a Yubikey and ask for a
> passcode. I'm not sure how doable that is, but anything that let's us do
> MFA while still working as simply as using envvars is good. Would be
> interesting if we can get something working with a Yubikey.
>
Making sure we have CLI, python bindings (via a keystoneauth plugin) and
horizon support is of course the most important, but it seems like the
first two are freebies. I think the change you posted could very much just
replace the existing password plugin in keystone (
https://review.openstack.org/#/c/343422/) and not be it's own plugin.

As for the MFA on one project but not another... That doesn’t really work.
> MFA only makes sense on a per user basis. Plus if you need an account for
> API actions and automation, you make another user with limited roles, but
> trying to make something like MFA work on a per project basis is something
> we ruled out very early. For my testing I never actually bothered even
> setting or using the project field on the credentials construct as it
> seemed redundant
>
If you do push a specification forward, then I think this is a fine
limitation to state.

> The best way to think about it I've found  is: imagine the horizon UX. You
> are logged into one project without MFA and then you swap to another that
> somehow now magically does need MFA. How do you enforce that? How do you
> log the user out, and make them enter MFA to then move to the other
> project? You are logged in already, with a valid token, how could you even
> tag that token as not logged via MFA? There are so many problems, and so
> many questions.
>
> Good point.


> MFA on a per project basis might be doable, but with a lot of pain and
> refactoring it seems like, none of which is worth it, and most of which
> makes for awful UX.
>
++

> At any rate, I would love to help if I can in this area, as it is
> something that interests me and something that we are going to be doing for
> our deployment. If worth the effort, I can polish up and write tests for
> the plugin I've written. It may not be the best solution long term, but it
> is the only one that seemed workable with what is present in OpenStack and
> without considerable effort.
>
> At the very least, I'll do a full write up as to what we end up doing with
> our deployment, and how that went for us.
>
How about a specification instead?
https://github.com/openstack/keystone-specs :)
It's unlikely to land in Newton, but would be a candidate for O.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] meeting canceled this week (7/19/2015)

[Steve Martinelli]

Many of us are traveling that day to get to the midcycle, so cancelling the
meeting this week. Enjoy your time back!

stevemar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Multi-factor Auth with Keystone and TOTP

[Steve Martinelli]

Several comments inline

On Mon, Jul 18, 2016 at 12:20 AM, Adrian Turjak 
wrote:

> Hello,
>
> I've been looking at options for doing multi-factor auth (MFA) on our
> infrastructure and I'm just wanting to know if the option I've decided
> to go with seems sensible.
>
> As context, we are running stock Keystone (to be backed by LDAP), we
> wanted to be able to enable MFA on a per user basis, and a user with MFA
> enabled should either be blocked from using the APIs or required MFA to
> use the APIs.
>
>
We discussed adding MFA support in Newton at the Austin summit and didn't
come to a happy conclusion (aside from "let federated users have MFA since
it's built in"). Part of the trouble was deciding where to enforce MFA.
Should a user *always* require MFA just because he has a TOTP credential?
What if the user has multiple projects, and wants MFA to access projectA,
but not projectB.


> I was looking at the current TOTP module in keystone, but seeing as that
> simply adds another optional Auth method to keystone it seems fairly
> useless for our needs. Unless I'm missing something, there seems to be
> no way in Keystone to enforce "use these two auth methods together". Is
> that the case? If not, it is something that has been considered? Or it
> is assumed people will write their own auth plugins rather than
> combining existing ones?
>

It was definitely not assumed that folks would write there own auth
plugins. The TOTP auth plugin was meant to be just be an alternative to
password auth. We had hoped it would provide the building blocks for MFA,
but see above comment.

>From there I went toward writing our own Keystone Auth plugin and had a
> lot of success with that. The current iteration is a combination of the
> password and totp plugins where for users with TOTP credentials we
> expect a 6 digit password appended to the password. In the config I then
> replace the default password plugin with my own.
>

I assume appending the TOTP password to the regular password is gonna be a
big 'nope' from UX folks :)
Though points for being clever and avoiding the whole negotiate/challenge
the user for extra information.


>
> In testing this seems to work as intended. All normal users are
> unaffected while users with a TOTP credential now must append their
> passcode to their password.
>
> I've made a blueprint for this plugin:
> https://blueprints.launchpad.net/keystone/+spec/password-totp-plugin
>
> and the code I am currently testing is in the associated review:
> https://review.openstack.org/#/c/343422/
>
> If this plugin is useful to others, and this seemed like a sensible
> solution, I will write some unit tests and work on getting it merged.
>
>
> So, my main question, does this plugin seem like a sensible solution to
> MFA in OpenStack in the way we needed or are there other paths I should
> be going down?
>
> Cheers,
> -Adrian Turjak
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone][docs] API sprint results

[Steve Martinelli]

First of all, thanks to everyone who participated, the API sprint was a
huge success. We've converted nearly all of our old APIs (published on
specs.openstack.org) over to the proper API site (
http://developer.openstack.org/api-ref.html). We've got a few patches in
flight, and a few TODOs that haven't begun yet, but things are looking
positive. The end result of this is: we will no longer be publishing APIs
to specs.openstack.org and we'll place our existing ones in an `attic`
folder.

By the numbers:
- 10 unique patch authors
- 40 patches merged
- 8 patches in progress

We used the `keystone-api-sprint` topic:
https://review.openstack.org/#/q/topic:keystone-api-sprint

Here's the etherpad we used, which contains more detail:
https://etherpad.openstack.org/p/keystone-api-sprint

Again, thanks to everyone who wrote and reviewed patches for this effort.

stevemar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev