Re: [openstack-dev] [keystone] removing Guang Yee (gyee) from keystone-core
+1!!! Thanks Guang for all your hard work and your outstanding contributions to Keystone. You were always a pleasure to work with. I wish you all the best on your new adventure! --Brad Brad Topol, Ph.D.IBM Distinguished EngineerOpenStack(919) 543-0646Internet: bto...@us.ibm.comAssistant: Kendra Witherspoon (919) 254-0680 - Original message -From: Henry Nash <henryna...@mac.com>To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>Cc:Subject: Re: [openstack-dev] [keystone] removing Guang Yee (gyee) from keystone-coreDate: Thu, Feb 2, 2017 10:36 AM Thanks, Guang, for your valuable contributions.Henry> On 2 Feb 2017, at 05:13, Steve Martinelli <s.martine...@gmail.com> wrote:>> 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__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Pike PTL
+1! Great job Steve Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Henry Nash <henryna...@mac.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 11/23/2016 11:08 AM Subject:Re: [openstack-dev] [keystone] Pike PTL Steve, It’s been a pleasure working with you as PTL - an excellent tenure. Enjoy taking some time back! Henry On 21 Nov 2016, at 19:38, Steve Martinelli <s.martine...@gmail.com> wrote: one of these days i'll learn how to spell :) On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli < s.martine...@gmail.com> 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 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] oaktree - a friendly end-user oriented API layer - anybody want to help?
No Morgan. You were supposed to stay quiet on this so we could spread vial behind the scenes rumors on how Monty is trying to bring back CORBA!!! My apologies to all the young folks not familiar with CORBA... On a serious note this work has the potential to be extremely valuable and I am look forward to seeing how it matures. Is there an easy way for busy folks to stay up to date on how this progresses? Ideally the interop challenge work (which is continuing forward) should hopefully be able to take advantage of the innovations that this project will deliver. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg <morgan.fainb...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 11/15/2016 08:42 PM Subject:Re: [openstack-dev] oaktree - a friendly end-user oriented API layer - anybody want to help? On Tue, Nov 15, 2016 at 5:16 PM, Jay Pipes <jaypi...@gmail.com> wrote: Awesome start, Monty :) Comments inline. On 11/15/2016 09:56 AM, Monty Taylor wrote: Hey everybody! At this past OpenStack Summit the results of the Interop Challenge were shown on stage. It was pretty awesome - 17 different people from 17 different clouds ran the same workload. And it worked! However, one of the reasons it worked is because they all used the Ansible modules we wrote that are based on the shade library that contains the business logic needed to hide vendor differences in clouds. That means that there IS a fantastic OpenStack interoperability story - but only if you program in Python. That's less awesome. With that in mind - I'm pleased to announce a new project that aims to address that - oaktree. oaktree is a gRPC-based API porcelain service for OpenStack that is based on the shade library and I'd love some help in writing it. Basing oaktree on shade gets not only the business logic. Shade already understands a multi-cloud world. And because we use shade in Infra for nodepool, it already has caching, batching and thundering herd protection sorted to be able to hand very high loads efficiently. So while oaktree is new, the primary logic and fundamentals are all shade and are battle-tested. ++ muy bueno. The barrier to deployers adding it to their clouds needs to be as low as humanly possible. So as we work on it, ensuring that we keep it dead-simple to install, update and operate must be a primary concern. Where are we and what's next? oaktree doesn't do a whole lot that's terribly interesting at the moment. We have all of the development scaffolding and gate jobs set up and a few functions implemented. oaktree exists currently as two repos - oaktree and oaktreemodel: http://git.openstack.org/cgit/openstack/oaktree http://git.openstack.org/cgit/openstack/oaktreemodel oaktreemodel contains the Protobuf definitions and the build scripts to produce Python, C++ and Go code from them. The python code is published to PyPI as a normal pure-python library. The C++ code is published as a source tarball and the Go code is checked back in to the same repo so that go works properly. Very nice. I recently started playing around with gRPC myself for some ideas I had about replacing part of nova-compute with a Golang worker service that can tolerate lengthy disconnections with a centralized control plane (hello, v[E]CPE!). It's been (quite) a few years since I last used protobufs (hey, remember Drizzle?) but it's been a blast getting back into protobufs development. Now that I see you're using a similar approach for oaktree, I'm definitely interested in contributing. oaktree depends on the python oaktreemodel library, and also on shade. It implements the server portion of the gRPC service definition. Currently, oaktree can list and search for flavors, images and floating ips. Exciting right? Most of the work to expose the rest of the API that shade can provide at the moment is going to be fairly straightforward - although in each case figuring out the best mapping will take some care. We have a few major things that need some good community design. These are also listed in a todo.rst file in the oaktree repo which is part of the docs: http://oaktree.readthedocs.io/en/latest/ The auth story. The native/default auth for gRPC is oauth. It has the ability for pluggable auth, but that would raise the barrier for new languages. I'd love it if we can come up with a story that involves making API users in keystone and authorizing them to use oaktree via an oauth transaction. ++ > The keystone auth backends currently are all about integrating with other auth man
Re: [openstack-dev] [keystone] new keystone core (breton)
Congratulations Boris!!! Very well deserved!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Steve Martinelli <s.martine...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 10/31/2016 03:51 PM Subject:[openstack-dev] [keystone] new keystone core (breton) 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 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
I have known Mr. Taylor for many years and I would like to come out as his first endorser for his big league thoughts and recommendations below. Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Monty Taylor <mord...@inaugust.com> To: openstack-dev@lists.openstack.org Date: 09/29/2016 07:29 PM Subject:Re: [openstack-dev] TC candidacy On 09/29/2016 06:14 PM, Clint Byrum wrote: > https://review.openstack.org/379850 > > Let's make OpenStack great again. > > If you don't know me, I'm very good. The code and designs I make > are tremendous, and I intend to contribute to the TC bigly. The other > candidates are sad, and they want OpenStack to be a third world project, > no good. > > OpenStack, could be the greatest cloud in the history of clouds, but to > get there, you need me, to make sure our clouds are the greatest. We > need to test the clouds, I'm talking about EXTREME cloud vetting, > EXTREME cloud vetting. You know the other TC's are laughing at us, > because we don't have such a great TC. > > The biggest problem we have is people rewriting parts of OpenStack in Go. > They're bringing threads, they're compiled, with errors handled at the > point of return, and some of them, I assume, are good programmers. So > when I'm elected to the TC, I will build a wall, and make Go pay for it. > > ... > > Ok if you're still reading and you don't take things too seriously, > then hello. I'm Clint Byrum, known as "SpamapS" on IRC, and I want to > serve you on the OpenStack Technical Committee. You may recognize me > from various scalability and deployment discussions. > > OpenStack has a number of challenges that face it in the immediate. There > is a crisis of identity that we're only just now wrapping our arms > around, and a question about whether or not this should be something > decided at a centralized level by the TC or not. Are we a toobox? Are > we a product? Can we be both? These are real things, and the TC should > debate them. However, I don't think the TC should force the community to > do anything it doesn't want to do as a whole. If the community really > wants to end the big tent, we should listen, inform, and debate, and > decide whether or not we think it is in the best interest to do so based > on our own expertise, the experience thus far, and a plan to go forward. > > It is my personal belief that the big tent has largely been a success > for OpenStack project teams, but created a problem of confusion that we > should resolve. The recent efforts to more clearly define OpenStack have > been positive, and I would like to help the TC continue down that road. > > In fact, I have recently started an Architecture Working Group to help > define and shape what OpenStack is at a technical design level. Whether > pieces have been evolved apart from one another, or specifically designed > and built to spec, OpenStack hasn't done a good job of writing some > of those things down. I believe the Architecture Working Group will > be capable of improving that, and I want the TC to have some of that > influence built in. > > So, if you want to see more design, consensus building, and an eye for > scaling on the TC, then please consider casting a vote for me. I nominate this email to be the best email ever sent to an OpenStack list. In fact, I think we should replace the entire TC with this email. This email shall be our leader and I, for one, welcome it gladly. __ 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] new core reviewer (rderose)
Shh! Let them get the leg irons welded shut on him first :-). Pay no attention Ron... Congratulations! Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg <morgan.fainb...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 09/02/2016 12:55 PM Subject:Re: [openstack-dev] [keystone] new core reviewer (rderose) On Sep 2, 2016 08:44, "Brad Topol" <bto...@us.ibm.com> wrote: > > Congratulations Ron!!! Very well deserved!!! > > --Brad > > > Brad Topol, Ph.D. > IBM Distinguished Engineer > OpenStack > (919) 543-0646 > Internet: bto...@us.ibm.com > Assistant: Kendra Witherspoon (919) 254-0680 > > Steve Martinelli ---09/01/2016 10:47:49 AM---I want to welcome Ron De Rose (rderose) to the Keystone core team. In a short time Ron has shown a v > > From: Steve Martinelli <s.martine...@gmail.com> > > To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> > Date: 09/01/2016 10:47 AM > > Subject: [openstack-dev] [keystone] new core reviewer (rderose) > > > > > 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 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 > Ahahaha! Another person to direct questions to now! ;) Congrats Ron! __ 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] new core reviewer (rderose)
Congratulations Ron!!! Very well deserved!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Steve Martinelli <s.martine...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 09/01/2016 10:47 AM Subject:[openstack-dev] [keystone] new core reviewer (rderose) 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 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] [magnum] 2 million requests / sec, 100s of nodes
Thanks Ricardo! This is very exciting progress! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Ton Ngo/Watson/IBM@IBMUS To: "OpenStack Development Mailing List \(not for usage questions \)" <openstack-dev@lists.openstack.org> Date: 06/17/2016 12:10 PM Subject:Re: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes Thanks Ricardo for sharing the data, this is really encouraging! Ton, Inactive hide details for Ricardo Rocha ---06/17/2016 08:16:15 AM---Hi. Just thought the Magnum team would be happy to hear :)Ricardo Rocha ---06/17/2016 08:16:15 AM---Hi. Just thought the Magnum team would be happy to hear :) From: Ricardo Rocha <rocha.po...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 06/17/2016 08:16 AM Subject: [openstack-dev] [magnum] 2 million requests / sec, 100s of nodes Hi. Just thought the Magnum team would be happy to hear :) We had access to some hardware the last couple days, and tried some tests with Magnum and Kubernetes - following an original blog post from the kubernetes team. Got a 200 node kubernetes bay (800 cores) reaching 2 million requests / sec. Check here for some details: https://openstack-in-production.blogspot.ch/2016/06/scaling-magnum-and-kubernetes-2-million.html We'll try bigger in a couple weeks, also using the Rally work from Winnie, Ton and Spyros to see where it breaks. Already identified a couple issues, will add bugs or push patches for those. If you have ideas or suggestions for the next tests let us know. Magnum is looking pretty good! Cheers, Ricardo __ 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
Re: [openstack-dev] New core reviewers nomination for TOSCA-Parser and or Heat-Translator project [tosca-parser][heat-translator][heat]
Bob, Miguel, Bharath and Mathiue, CONGRATULATIONS!!! Very well deserved!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Sahdev P Zala/Durham/IBM@IBMUS To: "OpenStack Development Mailing List \(not for usage questions \)" <openstack-dev@lists.openstack.org> Date: 06/06/2016 09:32 PM Subject:Re: [openstack-dev] New core reviewers nomination for TOSCA-Parser and or Heat-Translator project [tosca-parser][heat-translator][heat] Thanks core team for your +1 vote. Welcome new core - Bob, Miguel, Bharath and Mathiue. Thanks again for your great contribution!! Regards, Sahdev Zala From:Sahdev P Zala/Durham/IBM@IBMUS To:"OpenStack Development Mailing List \(not for usage questions\)" <openstack-dev@lists.openstack.org> Date:05/31/2016 09:30 AM Subject:[openstack-dev] New core reviewers nomination for TOSCA-Parser and or Heat-Translator project [tosca-parser][heat-translator][heat] Hello TOSCA-Parser and Heat-Translator core team, I would like to nominate following current active contributors to the tosca-parser and or heat-translator project as core reviewers to speed up the development. They are contributing for more than six months and has remained one of the top five contributors for a mentioned project(s). Please reply to this thread or email me with your vote (+1 or -1) by EOD June 4th. [1] Bob Haddleton: Bob is a lead developer for the TOSCA NFV specific parsing and translation in the tosca-parser and heat-translator projects respectively. Bob actively participates in IRC meetings and other discussion via emails or IRC. He is a also a core reviewer in OpenStack Tacker project. I would like to nominate him for core reviewer position for both tosca-parser and heat-translator. [2] Miguel Caballar: Miguel is familiar with TOSCA for long time. He is an asset for the tosca-parser project and has been bringing lot of new use cases to the project. He is a second lead developer overall for the project at present. I would like to nominate him for core reviewer position in tosca-parser. [3] Bharath Thiruveedula: Bharath is actively contributing to the heat-translator project. He knows project well and has implemented important blueprints during the Mitaka cycle including enhancement to the OSC plugin, automatic deployment of translated templates and dynamic querying of flavors and images. Bharath actively participates in IRC meetings and other discussion via emails or IRC. I would like to nominate him for the core reviewer position in heat-translator. [4] Mathieu Velten: Mathieu is familiar with TOSCA for long time as well. He is brining new use cases regularly and actively working on enhancing the heat-translator project with needed implementation. He also uses the translated templates with real time deployment with Heat for his work on project Indigo DataCloud [5]. He knows project well and was the second lead developer for the project during the Mitaka cycle. I would like to nominate him for the core reviewer position in heat-translator. [1] http://stackalytics.com/?release=all=tosca-parser=commits_id=bob-haddleton and http://stackalytics.com/?release=all=heat-translator=commits_id=bob-haddleton [2] http://stackalytics.com/?release=all=tosca-parser=commits_id=micafer1 [3] http://stackalytics.com/?release=all=heat-translator=commits_id=bharath-ves [4] http://stackalytics.com/?release=all=commits=heat-translator_id=matmaul [5] https://www.indigo-datacloud.eu/ Thanks! Regards, Sahdev Zala RTP, NC __ 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
Re: [openstack-dev] [keystone] New Core Reviewer (sent on behalf of Steve Martinelli)
CONGRATULATIONS Rodrigo!!! Very well deserved!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Lance Bragstad <lbrags...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 05/25/2016 09:09 AM Subject:Re: [openstack-dev] [keystone] New Core Reviewer (sent on behalf of Steve Martinelli) Congratulations Rodrigo! Thank you for all the continued and consistent reviews. On Tue, May 24, 2016 at 1:28 PM, Morgan Fainberg <morgan.fainb...@gmail.com > wrote: I want to welcome Rodrigo Duarte (rodrigods) to the keystone core team. Rodrigo has been a consistent contributor to keystone and has been instrumental in the federation implementations. Over the last cycle he has shown an understanding of the code base and contributed quality reviews. I am super happy (as proxy for Steve) to welcome Rodrigo to the Keystone Core team. Cheers, --Morgan __ 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
Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project
If Termie comes out of retirement to respond to a thread are there really any winners??? :-) --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Monty Taylor <mord...@inaugust.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 04/08/2016 01:10 PM Subject:Re: [openstack-dev] [tc][ptl][keystone] Proposal to split authentication part out of Keystone to separated project On 04/08/2016 11:12 AM, Andy Smith wrote: > Aahahahahhahahahhaahhahahahahahahahahhahhahahahahhahaha This is the indication that this thread wins. > On Thu, Apr 7, 2016 at 6:23 AM Lance Bragstad <lbrags...@gmail.com > <mailto:lbrags...@gmail.com>> wrote: > > In response to point 2.2, the progress with Fernet in the last year > has exposed performance pain points in keystone. Finding sensible > solutions for those issues is crucial in order for people to adopt > Fernet. In Mitaka we had a lot of discussion that resulted in > landing several performance related patches. > > As of today, we're already focusing on scalability, performance, and > simplicity. I'm afraid a project split would only delay the work > we're doing right now. > > On Wed, Apr 6, 2016 at 5:34 PM, Morgan Fainberg > <morgan.fainb...@gmail.com <mailto:morgan.fainb...@gmail.com>> wrote: > > > > On Wed, Apr 6, 2016 at 6:29 PM, David Stanek > <dsta...@dstanek.com <mailto:dsta...@dstanek.com>> wrote: > > > On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic > <bpavlo...@mirantis.com <mailto:bpavlo...@mirantis.com>> wrote: > > > 2) This will reduce scope of Keystone, which means 2 things > 2.1) Smaller code base that has less issues and is > simpler for testing > 2.2) Keystone team would be able to concentrate more on > fixing perf/scalability issues of authorization, which > is crucial at the moment for large clouds. > > > I'm not sure that this is entirely true. If we truly just > split up the project, meaning we don't remove functionality, > then we'd have the same number of bugs and work. It would > just be split across two projects. > > I think the current momentum to get out of the authn > business is still our best bet. As Steve mentioned this is > ongoing work. > > -- David > > > What everyone else said... but add in the need then to either > pass the AuthN over to the Assignment/AuthZ api or bake it in > (via apache module?) and we are basically where we are now. > > Steve alluded to splitting out the authentication bit (but not > to a new service), the idea there is to make it so AuthN is not > part of the CRUD interface of the server. All being said, AuthN > and AuthZ are going to be hard to split into two separate > services and with exception of the unfounded "scope" benefit, we > already can handle most of what you've proposed with zero > changes to Keystone. > > Cheers, > --Morgan > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > < http://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://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 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] changes to keystone-core!
CONGRATULATIONS Dave and Samuel. Very well deserved!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: "Steve Martinelli" <steve...@ca.ibm.com> To: openstack-dev <openstack-dev@lists.openstack.org> Date: 01/27/2016 05:17 PM Subject:[openstack-dev] [keystone] changes to keystone-core! Hello everyone! We've been talking about this for a long while, and I am very pleased to announce that at the midcycle we have made changes to keystone-core. The project has grown and our review queue grows ever longer. Effective immediately, we'd like to welcome the following new Guardians of the Gate to keystone-core: + Dave Chen (davechen) + Samuel de Medeiros Queiroz (samueldmq) Happy code reviewing! Steve Martinelli OpenStack Keystone Project Team Lead __ 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][all] Move from active distrusting model to trusting model
Tom brings up a good point. With a clear direction and support from the foundation/Thierry I'm confident we can make any version of these models work. I know in the situation I described if the policy was clear that it was okay and if I knew we could pull in Thierry to help resolve any disputes then I'm comfortable we could resolve any issues with a trusting model. I do however hope most patches end up being reviewed by multiple folks coming from different perspectives. The distrust model helped force that. So even if we moved to a more trusting model I'm hoping we see lots of reviews from folks coming from different perspectives and not lots of reviews where a single perspective group think prevails. Happy Thanksgiving! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Tom Fifield <t...@openstack.org> To: openstack-dev@lists.openstack.org Date: 11/25/2015 01:06 AM Subject:Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model On 24/11/15 19:20, Dolph Mathews wrote: > Scenarios I've been personally involved with where the > "distrustful" model either did help or would have helped: > > - Employee is reprimanded by management for not positively reviewing & > approving a coworkers patch. > > - A team of employees is pressured to land a feature with as fast as > possible. Minimal community involvement means a faster path to "merged," > right? > > - A large group of reviewers from the author's organization repeatedly > throwing *many* careless +1s at a single patch. (These happened to not > be cores, but it's a related organizational behavior taken to an extreme.) > > I can actually think of a few more specific examples, but they are > already described by one of the above. > > It's not cores that I do not trust, its the organizations they operate > within which I have learned not to trust. I think this is a good summary of people's fears and practical experience. Though, It seems that those cases above are derived from not understanding how we work, rather than out of deliberate malice. We can fix this kind of stuff with education :) Putting this out there - over at the Foundation, we're here to Protect and Empower you. So, if you've ever been reprimanded by management for choosing not to abuse the community process, perhaps we should arrange an education session with that manager (or their manager) on how OpenStack works. > On Monday, November 23, 2015, Morgan Fainberg <morgan.fainb...@gmail.com > <mailto:morgan.fainb...@gmail.com>> wrote: > > Hi everyone, > > This email is being written in the context of Keystone more than any > other project but I strongly believe that other projects could > benefit from a similar evaluation of the policy. > > Most projects have a policy that prevents the following scenario (it > is a social policy not enforced by code): > > * Employee from Company A writes code > * Other Employee from Company A reviews code > * Third Employee from Company A reviews and approves code. > > This policy has a lot of history as to why it was implemented. I am > not going to dive into the depths of this history as that is the > past and we should be looking forward. This type of policy is an > actively distrustful policy. With exception of a few potentially bad > actors (again, not going to point anyone out here), most of the > folks in the community who have been given core status on a project > are trusted to make good decisions about code and code quality. I > would hope that any/all of the Cores would also standup to their > management chain if they were asked to "just push code through" if > they didn't sincerely think it was a positive addition to the code base. > > Now within Keystone, we have a fair amount of diversity of core > reviewers, but we each have our specialities and in some cases > (notably KeystoneAuth and even KeystoneClient) getting the required > diversity of reviews has significantly slowed/stagnated a number of > reviews. > > What I would like us to do is to move to a trustful policy. I can > confidently say that company affiliation means very little to me > when I was PTL and nominating someone for core. We should explore > making a change to a trustful model, and allow for cores (regardless > of company affiliation) review/approve code. I say this since we > have clear steps to correct any abuses of this policy change. > > With all that said, here is the proposal I would like to set forth: > > 1. Code reviews still
Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model
Lance makes some very good points below. I agree fully with them. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Lance Bragstad <lbrags...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 11/24/2015 09:56 AM Subject:Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model I think one of the benefits of the current model was touched on earlier by dstanek. If someone is working on something for their organization, they typically bounce ideas of others they work with closely. This tends to be people within the same organization. The groups developing the feature might miss different perspectives on solving that particular problem. Bringing in a fresh set of eyes from someone outside that organization can be a huge benefit for the overall product. I don't think that is the sole reason to keep the existing policy, but I do think it's a positive side-effect. On Tue, Nov 24, 2015 at 6:31 AM, David Chadwick <d.w.chadw...@kent.ac.uk> wrote: Spot on. This is exactly the point I was trying to make David On 24/11/2015 11:20, Dolph Mathews wrote: > Scenarios I've been personally involved with where the > "distrustful" model either did help or would have helped: > > - Employee is reprimanded by management for not positively reviewing & > approving a coworkers patch. > > - A team of employees is pressured to land a feature with as fast as > possible. Minimal community involvement means a faster path to "merged," > right? > > - A large group of reviewers from the author's organization repeatedly > throwing *many* careless +1s at a single patch. (These happened to not > be cores, but it's a related organizational behavior taken to an extreme.) > > I can actually think of a few more specific examples, but they are > already described by one of the above. > > It's not cores that I do not trust, its the organizations they operate > within which I have learned not to trust. > > On Monday, November 23, 2015, Morgan Fainberg < morgan.fainb...@gmail.com > <mailto:morgan.fainb...@gmail.com>> wrote: > > Hi everyone, > > This email is being written in the context of Keystone more than any > other project but I strongly believe that other projects could > benefit from a similar evaluation of the policy. > > Most projects have a policy that prevents the following scenario (it > is a social policy not enforced by code): > > * Employee from Company A writes code > * Other Employee from Company A reviews code > * Third Employee from Company A reviews and approves code. > > This policy has a lot of history as to why it was implemented. I am > not going to dive into the depths of this history as that is the > past and we should be looking forward. This type of policy is an > actively distrustful policy. With exception of a few potentially bad > actors (again, not going to point anyone out here), most of the > folks in the community who have been given core status on a project > are trusted to make good decisions about code and code quality. I > would hope that any/all of the Cores would also standup to their > management chain if they were asked to "just push code through" if > they didn't sincerely think it was a positive addition to the code base. > > Now within Keystone, we have a fair amount of diversity of core > reviewers, but we each have our specialities and in some cases > (notably KeystoneAuth and even KeystoneClient) getting the required > diversity of reviews has significantly slowed/stagnated a number of > reviews. > > What I would like us to do is to move to a trustful policy. I can > confidently say that company affiliation means very little to me > when I was PTL and nominating someone for core. We should explore > making a change to a trustful model, and allow for cores (regardless > of company affiliation) review/approve code. I say this since we > have clear steps to correct any abuses of this policy change. > > With all that said, here is the proposal I would like to set forth: > > 1. Code reviews still need 2x Core Reviewers (no change) > 2. Code can be developed by a member of the same company as both > core reviewers (and approvers). > 3. If the trust that is being given via this new po
Re: [openstack-dev] [oslo] A special thank you to Davanum (Dims)
+++ Dims is awesome. And so are the other folks mentioned on this thread Happy Thanksgiving folks! Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Joshua Harlow <harlo...@fastmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 11/23/2015 01:56 PM Subject:Re: [openstack-dev] [oslo] A special thank you to Davanum (Dims) Dims is my hero ;) Lol, this thread is interesting :-P -Josh Amrith Kumar wrote: > Yes, let’s talk about dims while he isn’t here. I’ll second what Michael > and Steve have to say. Dims has been a great guy to work with and he’s > been a great resource. > > On one occasion, I needed some openstack folks to help (in person) at > very short notice. Dims (and Kamesh, also of Mirantis) drove over an > hour each and we did a very well received presentation about OpenStack! > > So yes, ++ to all the adjectives! > > -amrith > > *From:*Steve Martinelli [mailto:steve...@ca.ibm.com] > *Sent:* Monday, November 23, 2015 11:23 AM > *To:* OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [oslo] A special thank you to Davanum (Dims) > > Michael Krotscheck <krotsch...@gmail.com <mailto:krotsch...@gmail.com>> > wrote on 2015/11/23 10:55:04 AM: > >> From: Michael Krotscheck <krotsch...@gmail.com > <mailto:krotsch...@gmail.com>> >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org>> >> Date: 2015/11/23 10:56 AM >> Subject: [openstack-dev] [oslo] A special thank you to Davanum (Dims) >> >> Have you ever wanted to thank someone directly, but they're not on >> IRC so you can't pester them there? Well, dims isn't on IRC right >> now, so he has to put up with being told he's awesome in public :). >> >> Thank you, dims, for helping me out on my work in oslo middleware. > >> You've been calm, helpful, eternally patient, friendly, and nothing >> short of amazing. > > ++ to all those adjectives, dims is pretty awesome and incredibly helpful > > > >> The straw that broke the camel's back, in this >> case, was that you fixed a bug, which I introduced, quietly and >> quickly, without any kind of big public drama. >> >> Thank you for that, and for everything else that I mentioned. You, >> sir, are a better man than I. :) >> >> Michael >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > 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 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][all] Move from active distrusting model to trusting model
Hi Morgan, So lots of good points below. However I am pulled in two directions on this topic. For small projects (e.g. pycadf, heat-translator) there are so few cores and the project is small in size that we as project cores permit two people from the same company as the code author to both +2 and then +A. On these projects we simply could not make progress if we did not have this trusting model. For the larger projects like Cinder, the trusting model has led to trouble in the past. I have seen where if there was a piece of code where the following happens: * Employee from Company A writes code * Other Employee from Company A reviews code * Third Employee from Company A reviews and approves code. Then what can happen is the community looks at that code as Company A's code not the community code. Thus when there are bugs in that code they come back to company A and say "You put this code in all by yourself, its buggy and you need to maintain it all by yourself".If I was working for company B that seems like a pretty natural reaction especially if it turns out the code requires lots of maintenance. This was a real scenario and I was on the side (Company A) getting the spanking from folks from a very irritated company B. So to avoid the perception of a single company owning a piece of code, at IBM our policy for major projects like Cinder, Nova and currently many parts of Keystone (except pycadf) is to make sure we do not do the following for major OpenStack projects: * Employee from Company IBM writes code * Other Employee from Company IBM reviews code * Third Employee from Company IBM reviews and approves code. Again for certain small projects we relax this rule. And certainly we could discuss relaxing this rule for larger portions of Keystone if needed. But as a general policy we strive to stick to the distrust model as much as we can as the "perception of impropriety" that exists with the trusting model can result in tangible headaches. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg <morgan.fainb...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 11/23/2015 12:08 PM Subject:Re: [openstack-dev] [keystone][all] Move from active distrusting model to trusting model On Mon, Nov 23, 2015 at 8:51 AM, Dmitry Tantsur <dtant...@redhat.com> wrote: On 11/23/2015 05:42 PM, Morgan Fainberg wrote: Hi everyone, This email is being written in the context of Keystone more than any other project but I strongly believe that other projects could benefit from a similar evaluation of the policy. Most projects have a policy that prevents the following scenario (it is a social policy not enforced by code): * Employee from Company A writes code * Other Employee from Company A reviews code * Third Employee from Company A reviews and approves code. This policy has a lot of history as to why it was implemented. I am not going to dive into the depths of this history as that is the past and we should be looking forward. This type of policy is an actively distrustful policy. With exception of a few potentially bad actors (again, not going to point anyone out here), most of the folks in the community who have been given core status on a project are trusted to make good decisions about code and code quality. I would hope that any/all of the Cores would also standup to their management chain if they were asked to "just push code through" if they didn't sincerely think it was a positive addition to the code base. Thanks for raising this. I always apply this policy in ironic not because I don't think we're trustful with my colleagues. The problem I'm trying to avoid is members of the same company having the same one-sided view on a problem. A change of this policy doesn't preclude reaching out for more view points, and that should always be done. This is part of trusting the cores to know when this is valuable. :) Thanks for joining the convo here! Now within Keystone, we have a fair amount of diversity of core reviewers, but we each have our specialities and in some cases (notably KeystoneAuth and even KeystoneClient) getting the required diversity of reviews has significantly slowed/stagnated a number of reviews. This is probably a fair use case for not applying this rule. What I would like us to do is to move to a trustful policy. I can confidently say that company affiliation means very little to me when I was PTL and nominating someone for core. We should explore making a change to a trustful model, and allow for cores (regardless of company affiliation)
Re: [openstack-dev] Troubleshooting cross-project comms
+1 That's an extremely good suggestion!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Sean McGinnis <sean.mcgin...@gmx.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 11/04/2015 10:36 AM Subject:Re: [openstack-dev] Troubleshooting cross-project comms On Wed, Nov 04, 2015 at 07:30:51AM -0500, Sean Dague wrote: > On 10/28/2015 07:15 PM, Anne Gentle wrote: > > Has anyone considered using #openstack-dev, instead of a new meeting > room? #openstack-dev is mostly a ghost town at this point, and deciding > that instead it would be the dedicated cross project space, including > meetings support, might be interesting. > >-Sean +1 - That makes a lot of sense to me. > > -- > 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 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] PTL non-candidacy
Thank you Morgan for your outstanding leadership, tremendous effort, and your dedication to OpenStack and Keystone in particular. It has been an absolute pleasure getting to work with you these past few years. And I am looking forward to working with you in your new role!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg <morgan.fainb...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 09/10/2015 05:44 PM Subject:[openstack-dev] [keystone] PTL non-candidacy As I outlined (briefly) in my recent announcement of changes ( https://www.morganfainberg.com/blog/2015/09/09/openstack-career-act-3-scene-1/ ) I will not be running for PTL of Keystone this next cycle (Mitaka). The role of PTL is a difficult but extremely rewarding job. It has been amazing to see both Keystone and OpenStack grow. I am very pleased with the accomplishments of the Keystone development team over the last year. We have seen improvements with Federation, Keystone-to-Keystone Federation, Fernet Tokens, improvements of testing, releasing a dedicated authentication library, cross-project initiatives around improving the Service Catalog, and much, much more. I want to thank each and every contributor for the hard work that was put into Keystone and its associated projects. While I will be changing my focus to spend more time on the general needs of OpenStack and working on the Public Cloud story, I am confident in those who can, and will, step up to the challenges of leading development of Keystone and the associated projects. I may be working across more projects, but you can be assured I will be continuing to work hard to see the initiatives I helped start through. I wish the best of luck to the next PTL. I guess this is where I get to write a lot more code soon! See you all (in person) in Tokyo! --Morgan __ 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] Liberty SFE Request -DynamicPolicies
I am a +1 on this as well. I agree with Guang Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Yee, Guang guang@hp.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 07/13/2015 02:24 PM Subject:Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies ++! Per my understanding, the work, and therefore the risks, are fairly compartmentalized. The upside is this will pave the way for a much richer authorization management system. Guang From: Adam Young [mailto:ayo...@redhat.com] Sent: Monday, July 13, 2015 10:15 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies On 07/03/2015 08:36 AM, Samuel de Medeiros Queiroz wrote: Hi Thierry, Thanks for clarifying. A Spec Freeze Exception is what I was supposed to ask for. Rectifying: On behalf of the team working on the Dynamic Policies subject, I would like to ask for a *Spec Freeze Exception* in Liberty for it. This one is an important lead in to a lot of other work. Getting just this in to Liberty allows us to focus the remainder of the work on Dynamic policy inside Keystone. Please approve. Thanks, Samuel de Medeiros Queiroz Thierry Carrez wrote: samuel wrote: [...] On behalf of the team working on the Dynamic Policies subject, I would like to ask for a Feature Freeze Exception in Liberty for it. Liberty Feature Freeze is on September 3rd, so I doubt you need a feature freeze exception at this time. I suspect that would be a spec freeze exception or some other Keystone-specific freeze exception ? https://wiki.openstack.org/wiki/FeatureFreeze __ 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
Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
How big a work item is this? Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Thai Q Tran/Silicon Valley/IBM@IBMUS To: OpenStack Development Mailing List \(not for usage questions\) openstack-dev@lists.openstack.org Date: 06/04/2015 02:20 PM Subject:Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team I am interested but not sure how much time I have this release cycle. I can take on a more hands-off approach and help review to make sure that magnum-ui is align with future horizon directions. -Steven Dake (stdake) std...@cisco.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org From: Steven Dake (stdake) std...@cisco.com Date: 06/04/2015 11:03AM Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -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 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] SPFE: Authenticated Encryption (AE) Tokens
I am a vote of Yes for the Authenticated Encryption (AE) Token specification receiving a Spec Freeze exception. This approach has tremendous potential to significantly improve Keystone and POC code already exists. I feel there is enough runway that it is worth trying to move forward with this spec in this release cycle. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Lance Bragstad lbrags...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 02/13/2015 02:52 PM Subject:[openstack-dev] [keystone] SPFE: Authenticated Encryption (AE)Tokens Hello all, I'm proposing the Authenticated Encryption (AE) Token specification [1] as an SPFE. AE tokens increases scalability of Keystone by removing token persistence. This provider has been discussed prior to, and at the Paris summit [2]. There is an implementation that is currently up for review [3], that was built off a POC. Based on the POC, there has been some performance analysis done with respect to the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4]. The Keystone team spent some time discussing limitations of the current POC implementation at the mid-cycle. One case that still needs to be addressed (and is currently being worked), is federated tokens. When requesting unscoped federated tokens, the token contains unbound groups which would need to be carried in the token. This case can be handled by AE tokens but it would be possible for an unscoped federated AE token to exceed an acceptable AE token length (i.e. 255 characters). Long story short, a federation migration could be used to ensure federated AE tokens never exceed a certain length. Feel free to leave your comments on the AE Token spec. Thanks! Lance [1] https://review.openstack.org/#/c/130050/ [2] https://etherpad.openstack.org/p/kilo-keystone-authorization [3] https://review.openstack.org/#/c/145317/ [4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/ __ 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] Proposing Marek Denis for the Keystone Core Team
+1! Marek has been an outstanding Keystone contributor and reviewer! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: David Stanek dsta...@dstanek.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 02/10/2015 12:58 PM Subject:Re: [openstack-dev] [Keystone] Proposing Marek Denis for the Keystone Core Team +1 On Tue, Feb 10, 2015 at 12:51 PM, Morgan Fainberg morgan.fainb...@gmail.com wrote: Hi everyone! I wanted to propose Marek Denis (marekd on IRC) as a new member of the Keystone Core team. Marek has been instrumental in the implementation of Federated Identity. His work on Keystone and first hand knowledge of the issues with extremely large OpenStack deployments has been a significant asset to the development team. Not only is Marek a strong developer working on key features being introduced to Keystone but has continued to set a high bar for any code being introduced / proposed against Keystone. I know that the entire team really values Marek’s opinion on what is going in to Keystone. Please respond with a +1 or -1 for adding Marek to the Keystone core team. This poll will remain open until Feb 13. -- Morgan Fainberg __ 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 -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.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] Nominating Brad Topol for Keystone-Spec core
Keystone cores and ATC's, Thank you very much for the nomination and your positive feedback. I feel very honored to have receive this nomination. I have thoroughly enjoyed collaborating with all of you for these past several years. I look forward to our continued collaboration and am confident that our talented group of folks will continue to drive outstanding innovations in the Keystone project. Regards, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg morgan.fainb...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 01/23/2015 12:53 PM Subject:Re: [openstack-dev] [Keystone] Nominating Brad Topol for Keystone-Spec core Based upon the feedback to this thread, I want to congratulate Brad Topol as the newest member of the Keystone-Specs-Core team! —Morgan On Jan 18, 2015, at 11:11 AM, Morgan Fainberg morgan.fainb...@gmail.com wrote: Hello all, I would like to nominate Brad Topol for Keystone Spec core (core reviewer for Keystone specifications and API-Specification only: https://git.openstack.org/cgit/openstack/keystone-specs ). Brad has been a consistent voice advocating for well defined specifications, use of existing standards/technology, and ensuring the UX of all projects under the Keystone umbrella continue to improve. Brad brings to the table a significant amount of insight to the needs of the many types and sizes of OpenStack deployments, especially what real-world customers are demanding when integrating with the services. Brad is a core contributor on pycadf (also under the Keystone umbrella) and has consistently contributed code and reviews to the Keystone projects since the Grizzly release. Please vote with +1/-1 on adding Brad to as core to the Keystone Spec repo. Voting will remain open until Friday Jan 23. Cheers, Morgan Fainberg __ 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] OSAAA-Policy
+1! Makes sense. --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg morgan.fainb...@gmail.com To: Adam Young ayo...@redhat.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 12/08/2014 06:07 PM Subject:Re: [openstack-dev] [Keystone] OSAAA-Policy I agree that this library should not have “Keystone” in the name. This is more along the lines of pycadf, something that is housed under the OpenStack Identity Program but it is more interesting for general use-case than exclusively something that is tied to Keystone specifically. Cheers, Morgan -- Morgan Fainberg On December 8, 2014 at 4:55:20 PM, Adam Young (ayo...@redhat.com) wrote: The Policy libraray has been nominated for promotion from Oslo incubator. The Keystone team was formally known as the Identity Program, but now is Authentication, Authorization, and Audit, or AAA. Does the prefeix OSAAA for the library make sense? It should not be Keystone-policy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Online midcycle meetup
Angus, This may sound crazy but what if in addition to having the online meetup you denoted two different locations as an optional physical meetup? That way you would get some of the benefits of having folks meet together in person while not forcing everyone to have to travel across the globe. So for example, if you had one location in Raleigh and one wherever else folks are co-located you could still get the benefits of having some group of folks collaborating face to face. Just a thought. --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Angus Salkeld asalk...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 11/19/2014 06:56 PM Subject:[openstack-dev] [Heat] Online midcycle meetup Hi all As agreed from our weekly meeting we are going to try an online meetup. Why? We did a poll (https://doodle.com/b9m4bf8hvm3mna97#table) and it is split quite evenly by location. The story I am getting from the community is: We want a midcycle meetup if it is nearby, but are having trouble getting finance to travel far. Given that the Heat community is evenly spread across the globe this becomes impossible to hold without excluding a significant group. So let's try and figure out how to do an online meetup! (but let's not spend 99% of the time arguing about the software to use please) I think more interesting is: 1) How do we minimize the time zone pain? 2) Can we make each session really focused so we are productive. 3) If we do this right it does not have to be midcycle but when ever we want. I'd be interested in feedback from others that have tried this too. -Angus ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] [storyboard] Goodbye Infra on Launchpad, Hello Infra on StoryBoard
This looks very cool!!! Is it ready for the rest of the other projects to start using as well? Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Michael Krotscheck krotsch...@gmail.com To: openstack-in...@lists.openstack.org, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, openst...@lists.openstack.org, Date: 11/19/2014 07:23 PM Subject:[openstack-dev] [infra] [storyboard] Goodbye Infra on Launchpad, Hello Infra on StoryBoard The OpenStack Infrastructure team has successfully migrated all of the openstack-infra project bugs from LaunchPad to StoryBoard. With the exception of openstack-ci bugs tracked by elastic recheck, all bugs, tickets, and work tracked for OpenStack Infrastructure projects must now be submitted and accessed at https://storyboard.openstack.org. If you file a ticket on LaunchPad, the Infrastructure team no longer guarantees that it will be addressed. Note that only the infrastructure projects have moved, no other OpenStack projects have been migrated. This is part of a long-term plan to migrate OpenStack from Launchpad to StoryBoard. At this point we feel that StoryBoard meets the needs of the OpenStack infrastructure team and plan to use this migration to further exercise the project while we continue its development. As you may notice, Development on StoryBoard is ongoing, and we have not yet reached feature parity with those parts of LaunchPad which are needed for the rest of OpenStack. Contributions are always welcome, and the team may be contacted in the #storyboard or #openstack-infra channels on freenode, via the openstack-dev list using the [storyboard] subject, or via StoryBoard itself by creating a story. Feel free to report any bugs, ask any questions, or make any improvement suggestions that you come up with at: https://storyboard.openstack.org/#!/project/456 We are always looking for more contributors! If you have skill in AngularJS or Pecan, or would like to fill in some of our documentation for us, we are happy to accept patches. If your project is interested in moving to StoryBoard, please contact us directly. While we are hesitant to move new projects to storyboard at this point, we would love working with you to determine which features are needed to support you. Relevant links: • Storyboard: https://storyboard.openstack.org • Team Wiki: https://wiki.openstack.org/wiki/StoryBoard ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystyone] Mid-Cycle Meetup Planning
I have filled out the form and very much look forward to attending!!! Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg morgan.fainb...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 11/11/2014 08:20 PM Subject:[openstack-dev] [Keystyone] Mid-Cycle Meetup Planning I am trying to pin down a location for our mid-cycle meetup, I need to get an idea of who will be joining us at the Keystone meetup. I’ve included a couple questions relating to Barbican in the case we can double-up and have a day of overlap like the Juno meetup. I apologize for the delay, this should have been sent out by the end of the summit or earlier. As details are available I’ll provide updates. Due to timing (so that people can get visas, get travel approval, etc as soon as possible), I will be making a final call on dates by the end of this week and location as soon as the space is confirmed, so your prompt responses are super important! http://goo.gl/forms/4W7xVM9x49 Cheers, Morgan___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] How can we get more feedback from users?-- Great idea Angus!
Angus, Makes sense. We need to make the process of being able to provide user experience feedback a pleasant user experience in itselt :-). I went to https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group but could not see an easy way to provide feedback from this page. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Angus Salkeld asalk...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 10/26/2014 07:20 AM Subject:Re: [openstack-dev] [all] How can we get more feedback from users?-- Great idea Angus! On Sat, Oct 25, 2014 at 1:20 AM, Brad Topol bto...@us.ibm.com wrote: +100! Angus this is awesome!!! Anyway to get one of these for each project? Anyone can make an etherpad, but as Tim suggested I think we need to work with the Application Ecosystem WG to do this in a consistent way. I'll look into doing that. https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group -Angus Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From:Sandy Walsh sandy.wa...@rackspace.com To:OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date:10/24/2014 09:46 AM Subject:Re: [openstack-dev] [all] How can we get more feedback from users? Nice work Angus ... great idea. Would love to see more of this. -S From: Angus Salkeld [asalk...@mirantis.com] Sent: Friday, October 24, 2014 1:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] How can we get more feedback from users? Hi all I have felt some grumblings about usability issues with Heat templates/client/etc.. and wanted a way that users could come and give us feedback easily (low barrier). I started an etherpad ( https://etherpad.openstack.org/p/heat-useablity-improvements) - the first win is it is spelt wrong :-O We now have some great feedback there in a very short time, most of this we should be able to solve. This lead me to think, should OpenStack have a more general mechanism for users to provide feedback. The idea is this is not for bugs or support, but for users to express pain points, requests for features and docs/howtos. It's not easy to improve your software unless you are listening to your users. Ideas? -Angus___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] How can we get more feedback from users?-- Great idea Angus!
+100! Angus this is awesome!!! Anyway to get one of these for each project? Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Sandy Walsh sandy.wa...@rackspace.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 10/24/2014 09:46 AM Subject:Re: [openstack-dev] [all] How can we get more feedback from users? Nice work Angus ... great idea. Would love to see more of this. -S From: Angus Salkeld [asalk...@mirantis.com] Sent: Friday, October 24, 2014 1:32 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [all] How can we get more feedback from users? Hi all I have felt some grumblings about usability issues with Heat templates/client/etc.. and wanted a way that users could come and give us feedback easily (low barrier). I started an etherpad ( https://etherpad.openstack.org/p/heat-useablity-improvements) - the first win is it is spelt wrong :-O We now have some great feedback there in a very short time, most of this we should be able to solve. This lead me to think, should OpenStack have a more general mechanism for users to provide feedback. The idea is this is not for bugs or support, but for users to express pain points, requests for features and docs/howtos. It's not easy to improve your software unless you are listening to your users. Ideas? -Angus___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [All] API standards working group
I am interested in participating as well. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg morgan.fainb...@gmail.com To: Dolph Mathews dolph.math...@gmail.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 09/23/2014 08:01 PM Subject:Re: [openstack-dev] [Nova] [All] API standards working group -Original Message- From: Dolph Mathews dolph.math...@gmail.com Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: September 23, 2014 at 16:41:27 To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] [All] API standards working group I'd be interested in participating in this as well. I wrote Keystone's v3 Identity API Document Overview and Conventions [1] with an eye toward hopefully establishing *some* consistency across multiple projects (or at least having a starting ground with which to discuss and iterate on). [1] https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3.md#document-overview On Sep 23, 2014 6:22 PM, Jay Pipes wrote: On 09/23/2014 05:03 PM, Rochelle.RochelleGrober wrote: jaypi...@gmail.com on Tuesday, September 23, 2014 9:09 AM wrote: _Snip I'd like to say finally that I think there should be an OpenStack API working group whose job it is to both pull together a set of OpenStack API practices as well as evaluate new REST APIs proposed in the OpenStack ecosystem to provide guidance to new projects or new subprojects wishing to add resources to an existing REST API. Best, -jay */[Rocky Grober] /*++ */Jay, are you volunteering to head up the working group? Or at least be an active member? I’ll certainly follow with interest, but I think I have my hands full with the log rationalization working group./* Yes, I'd be willing to head up the working group... or at least participate in it. Best, -jay I would also be interested in participating in on this front. —Morgan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Stepping down as PTL
+1000!!! Dolph, you did a fantastic job leading the Keystone project. Many thanks for all of your efforts!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Jay Pipes jaypi...@gmail.com To: openstack-dev@lists.openstack.org, Date: 09/22/2014 11:03 AM Subject:Re: [openstack-dev] [keystone] Stepping down as PTL Just want to say thanks for your leadership over the years, Dolph. All the best, -jay On 09/22/2014 10:47 AM, Dolph Mathews wrote: Dearest stackers and [key]stoners, With the PTL candidacies officially open for Kilo, I'm going to take the opportunity to announce that I won't be running again for the position. I thoroughly enjoyed my time as PTL during Havana, Icehouse and Juno. There was a perceived increase in stability [citation needed], which was one of my foremost goals. We primarily achieved that by improving the communication between developers which allowed developers to share their intent early and often (by way of API designs and specs). As a result, we had a lot more collaboration and a great working knowledge in the community when it came time for bug fixes. I also think we raised the bar for user experience, especially by way of reasonable defaults, strong documentation, and effective error messages. I'm consistently told that we have the best out-of-the-box experience of any OpenStack service. Well done! I'll still be involved in OpenStack, and I'm super confident in our incredibly strong core team of reviewers on Keystone. I thoroughly enjoy helping other developers be as productive as possible, and intend to continue doing exactly that. Keep hacking responsibly, -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] PYTHONDONTWRITEBYTECODE=true in tox.ini
+1!!! This is awesome. I *always* ran into this was about to get find . -name *.pyc -delete tattooed on the inside of my forearm. Now I don't have to. Thanks!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Sean Dague s...@dague.net To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org, Date: 09/12/2014 07:40 AM Subject:[openstack-dev] [all] PYTHONDONTWRITEBYTECODE=true in tox.ini I assume you, gentle OpenStack developers, often find yourself in a hair tearing out moment of frustration about why local unit tests are doing completely insane things. The code that it is stack tracing on is no where to be found, and yet it fails. And then you realize that part of oslo doesn't exist any more except there are still pyc files laying around. Gah! I've proposed the following to Nova and Python novaclient - https://review.openstack.org/#/c/121044/ Which sets PYTHONDONTWRITEBYTECODE=true in the unit tests. This prevents pyc files from being writen in your git tree (win!). It doesn't seem to impact what pip installs... and if anyone knows how to prevent those pyc files from getting created, that would be great. But it's something which hopefully causes less perceived developer fragility of the system. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Kilo Cycle Goals Exercise
Monty, +1!! I fully agree!! How can I help :-)? Can we dedicate some design summit sessions to this topic? Ideally, having some stakeholder driven sessions where we can hear about the user experiences issues causing the most pain would be a good start to get this to become a focus area. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Monty Taylor mord...@inaugust.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 09/07/2014 08:15 PM Subject:Re: [openstack-dev] Kilo Cycle Goals Exercise On 09/03/2014 08:37 AM, Joe Gordon wrote: As you all know, there has recently been several very active discussions around how to improve assorted aspects of our development process. One idea that was brought up is to come up with a list of cycle goals/project priorities for Kilo [0]. To that end, I would like to propose an exercise as discussed in the TC meeting yesterday [1]: Have anyone interested (especially TC members) come up with a list of what they think the project wide Kilo cycle goals should be and post them on this thread by end of day Wednesday, September 10th. After which time we can begin discussing the results. The goal of this exercise is to help us see if our individual world views align with the greater community, and to get the ball rolling on a larger discussion of where as a project we should be focusing more time. If I were king ... 1. Caring about end user experience at all It's pretty clear, if you want to do things with OpenStack that are not running your own cloud, that we collectively have not valued the class of user who is a person who wants to use the cloud. Examples of this are that the other day I had to read a section of the admin guide to find information about how to boot a nova instance with a cinder volume attached all in one go. Spoiler alert, it doesn't work. Another spoiler alert - even though the python client has an option for requesting that a volume that is to be attached on boot be formatted in a particular way, this does not work for cinder volumes, which means it does not work for an end user - EVEN THOUGH this is a very basic thing to want. Our client libraries are clearly not written with end users in mind, and this has been the case for quite some time. However, openstacksdk is not yet to the point of being usable for end users - although good work is going on there to get it to be a basis for an end user python library. We give deployers so much flexibility, that in order to write even a SIMPLE program that uses OpenStack, an end user has to know generally four of five pieces of information to check for that are different ways that a deployer may have decided to do things. Example: - As a user, I want a compute instance that has an IP address that can do things. WELL, now you're screwed, because there is no standard way to do that. You may first want to try booting your instance and then checking to see if nova returns a network labeled public. You may get no networks. This indicates that your provider decided to deploy neutron, but as part of your account creation did not create default networks. You now need to go create a router, network and port in neutron. Now you can try again. Or, you may get networks back, but neither of them are labeled public - instead, you may get a public and a private address back in the network labeled private. Or, you may only get a private network back. This indicates that you may be expected to create a thing called a floating-ip. First, you need to verify that your provider has installed the floating-ip's extension. If they have, then you can create a floating-ip and attach it to your host. NOW - once you have those things done, you need to connect to your host and verify that its outbound networking has not been blocked by a thing called security groups, which you also may not have been expecting to exist, but I'll stop there, because the above is long enough. Every. Single. One. Of. Those. Cases. is real and has occurred across only the two public openstack clouds that infra uses. That means that our provisioning code takes every single one of them in to account, and anyone who writes code that wants to get a machine to use must take them all in to account or else their code is buggy. That's RIDICULOUS. So we should fix it. I'd say we should fix it by removing 1000% of the choices we've given deployers in this case, but I won't win there. So how about let's make at least one client library that encodes all of the above logic behind some simple task oriented API calls? How about we make that library not something which is just a repackaging of requests that does not contain intelligent, but instead something that is fundamentally usable. How about we have
Re: [openstack-dev] [all] The future of the integrated release
Hi Everyone, I have seen a ton of notes on this topic. Many of us have a lot invested in Ceilometer and want it to succeed. I don't want to focus on whether Ceilometer should be in the integrated release or not. To me the bigger issue is that if Ceilometer views itself as wanting to be a monitoring infrastructure for OpenStack it needs to be able to scale. If it is a tool that can handle high volume monitoring loads it will attract new contributors because more folks will use it and will want to contribute to it. I am happy to leave it to the Ceilometer team to figure out a redesign that enables them to scale. I have been asked in the past to be more concrete and make some suggested improvements. Here is a very short list: 1. Relying on oslo messaging (which is RPC based) simply won't scale when you have a high volume monitoring requirement. 2. Having to query the database first for doing triggers breaks when the database gets big. 3. There needs to be a way to keep the database from getting too large. Usually this means being able to move data from the database to a data warehouse and having the data warehouse available to handle data querying loads. Whenever the Ceilometer team feels they can scale significantly more than they do now I'm sure folks will take another look at it. When given a choice many of us want to reuse an Open Source option that meets our needs whether it has the fancy branding or not. In the near term many of us have to provide a monitoring solution. And many of us have folks on staff that have significant high volume monitoring experience and those folks feel there are some Open Source monitoring components that are a better foundation for providing high volume monitoring. So in summary I do hope there will be less focus on whether Ceilometer has fancy status or not and instead more focus on an open and frank dialogue on what can be done for Ceilometer to achieve its goal of being able to meet high volume monitoring requirements. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Clint Byrum cl...@fewbar.com To: openstack-dev openstack-dev@lists.openstack.org, Date: 08/21/2014 04:13 PM Subject:Re: [openstack-dev] [all] The future of the integrated release Excerpts from David Kranz's message of 2014-08-21 12:45:05 -0700: On 08/21/2014 02:39 PM, gordon chung wrote: The point I've been making is that by the TC continuing to bless only the Ceilometer project as the OpenStack Way of Metering, I think we do a disservice to our users by picking a winner in a space that is clearly still unsettled. can we avoid using the word 'blessed' -- it's extremely vague and seems controversial. from what i know, no one is being told project x's services are the be all end all and based on experience, companies (should) know this. i've worked with other alternatives even though i contribute to ceilometer. Totally agree with Jay here, I know people who gave up on trying to get any official project around deployment because they were told they had to do it under the TripleO umbrella from the pov of a project that seems to be brought up constantly and maybe it's my naivety, i don't really understand the fascination with branding and the stigma people have placed on non-'openstack'/stackforge projects. it can't be a legal thing because i've gone through that potential mess. also, it's just as easy to contribute to 'non-openstack' projects as 'openstack' projects (even easier if we're honest). Yes, we should be honest. The even easier part is what Sandy cited as the primary motivation for pursuing stacktach instead of ceilometer. I think we need to consider the difference between why OpenStack wants to bless a project, and why a project might want to be blessed by OpenStack. Many folks believe that for OpenStack to be successful it needs to present itself as a stack that can be tested and deployed, not a sack of parts that only the most extremely clever people can manage to assemble into an actual cloud. In order to have such a stack, some code (or, alternatively, dare I say API...) needs to be blessed. Reasonable debates will continue about which pieces are essential to this stack, and which should be left to deployers, but metering was seen as such a component and therefore something needed to be blessed. The hope was that every one would jump on that and make it great but it seems that didn't quite happen (at least yet). Though Open Source has many advantages over proprietary development, the ability to choose a direction and marshal resources for efficient delivery is the biggest advantage of proprietary development like what AWS does. The TC process of blessing is, IMO, an attempt to compensate
Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project
Hi Eoghan, Thanks for the note below. However, one thing the overview below does not cover is why InfluxDB (http://influxdb.com/) is not being leveraged. Many folks feel that this technology is a viable solution for the problem space discussed below. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Eoghan Glynn egl...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 08/06/2014 11:17 AM Subject:[openstack-dev] [tc][ceilometer] Some background on the gnocchi project Folks, It's come to our attention that some key individuals are not fully up-to-date on gnocchi activities, so it being a good and healthy thing to ensure we're as communicative as possible about our roadmap, I've provided a high-level overview here of our thinking. This is intended as a precursor to further discussion with the TC. Cheers, Eoghan What gnocchi is: === Gnocchi is a separate, but related, project spun up on stackforge by Julien Danjou, with the objective of providing efficient storage and retrieval of timeseries-oriented data and resource representations. The goal is to experiment with a potential approach to addressing an architectural misstep made in the very earliest days of ceilometer, specifically the decision to store snapshots of some resource metadata alongside each metric datapoint. The core idea is to move to storing datapoints shorn of metadata, and instead allow the resource-state timeline to be reconstructed more cheaply from much less frequently occurring events (e.g. instance resizes or migrations). What gnocchi isn't: == Gnocchi is not a large-scale under-the-radar rewrite of a core OpenStack component along the lines of keystone-lite. The change is concentrated on the final data-storage phase of the ceilometer pipeline, so will have little initial impact on the data-acquiring agents, or on transformation phase. We've been totally open at the Atlanta summit and other forums about this approach being a multi-cycle effort. Why we decided to do it this way: The intent behind spinning up a separate project on stackforge was to allow the work progress at arms-length from ceilometer, allowing normalcy to be maintained on the core project and a rapid rate of innovation on gnocchi. Note that that the developers primarily contributing to gnocchi represent a cross-section of the core team, and there's a regular feedback loop in the form of a recurring agenda item at the weekly team meeting to avoid the effort becoming silo'd. But isn't re-architecting frowned upon? == Well, the architecture of other OpenStack projects have also under-gone change as the community understanding of the implications of prior design decisions has evolved. Take for example the move towards nova no-db-compute the unified-object-model in order to address issues in the nova architecture that made progress towards rolling upgrades unneccessarily difficult. The point, in my understanding, is not to avoid doing the course-correction where it's deemed necessary. Rather, the principle is more that these corrections happen in an open and planned way. The path forward: A subset of the ceilometer community will continue to work on gnocchi in parallel with the ceilometer core over the remainder of the Juno cycle and into the Kilo timeframe. The goal is to have an initial implementation of gnocchi ready for tech preview by the end of Juno, and to have the integration/migration/ co-existence questions addressed in Kilo. Moving the ceilometer core to using gnocchi will be contingent on it demonstrating the required performance characteristics and providing the semantics needed to support a v3 ceilometer API that's fit-for-purpose. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][oslo][ceilometer] Moving PyCADF from the Oslo program to Identity (Keystone)
+1 Makes a lot of sense to me as well!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: gordon chung g...@live.ca To: Davanum Srinivas dava...@gmail.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 07/25/2014 04:43 PM Subject:Re: [openstack-dev] [keystone][oslo][ceilometer] Moving PyCADF from the Oslo program to Identity (Keystone) Before we move ahead, I would like to hear from the other current pycadf and oslo team members, especially Gordon since he is the primary maintainer. this move makes sense to me. auditing and identity have a strong link and all of the pyCADF work done so far has been connected to Keystone in some form so it makes sense to have it fall under Keystone's expanded scope. as a sidebar... glad to have more help on pyCADF. cheers, gord___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Redesign of Keystone Federation
+1! Excellent summary and analysis Morgan! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Morgan Fainberg morgan.fainb...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 05/29/2014 01:07 PM Subject:Re: [openstack-dev] [keystone] Redesign of Keystone Federation I agree that there is room for improvement on the Federation design within Keystone. I would like to re-iterate what Adam said that we are already seeing efforts to fully integrate further protocol support (OpenID Connect, etc) within the current system. Lets be sure that whatever redesign work is proposed and accepted takes into account the current stakeholders (that are really using Federation) and ensure full backwards compatibility. I firmly believe we can work within the Apache module framework for Juno. Moving beyond Juno we may need to start implementing the more native modules (proposal #2). Lets be sure whatever redesign work we perform this cycle doesn’t lock us exclusively into one path or another. It shouldn’t be too hard to continue making incremental improvements (agile methodology) and keeping the stakeholders engaged. David and Kristy, the slides and summit session are a great starting place for this work. Now we need to get the proposal drafted up in the new Keystone-Specs repository ( https://git.openstack.org/cgit/openstack/keystone-specs ) so we can keep this conversation on track. Having the specification clearly outlined and targeted will help us address any concerns with the proposal/redesign as we move into implementation. Cheers, Morgan — Morgan Fainberg From: Adam Young ayo...@redhat.com Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: May 28, 2014 at 09:24:26 To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone] Redesign of Keystone Federation On 05/28/2014 11:59 AM, David Chadwick wrote: Hi Everyone at the Atlanta meeting the following slides were presented during the federation session http://www.slideshare.net/davidwchadwick/keystone-apach-authn It was acknowledged that the current design is sub-optimal, but was a best first efforts to get something working in time for the IceHouse release, which it did successfully. Now is the time to redesign federated access in Keystone in order to allow for: i) the inclusion of more federation protocols such as OpenID and OpenID Connect via Apache plugins These are underway: Steve Mar just posted review for OpenID connect. ii) federating together multiple Keystone installations I think Keystone should be dealt with separately. Keystone is not a good stand-alone authentication mechanism. iii) the inclusion of federation protocols directly into Keystone where good Apache plugins dont yet exist e.g. IETF ABFAB I though this was mostly pulling together other protocols such as Radius? http://freeradius.org/mod_auth_radius/ The Proposed Design (1) in the slide show is the simplest change to make, in which the Authn module has different plugins for different federation protocols, whether via Apache or not. I'd like to avoid doing non-HTTPD modules for as long as possible. The Proposed Design (2) is cleaner since the plugins are directly into Keystone and not via the Authn module, but it requires more re-engineering work, and it was questioned in Atlanta whether that effort exists or not. The method parameter is all that is going to vary for most of the Auth mechanisms. X509 and Kerberos both require special set up of the HTTP connection to work, which means client and server sides need to be in sync: SAML, OpenID and the rest have no such requirements. Kent therefore proposes that we go with Proposed Design (1). Kent will provide drafts of the revised APIs and the re-engineered code for inspection and approval by the group, if the group agrees to go with this revised design. If you have any questions about the proposed re-design, please don't hesitate to ask regards David and Kristy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi
Re: [openstack-dev] Proposed Logging Standards
So we are starting to add more cloud audit (aka CADF) support to OpenStack. We have support in Nova and infrastructure added to Ceilometer and I am starting to add this capability to keystone. This work is based on sending events to ceilometer. If this is related to the audit work below I would like to be included. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Scott Devoid dev...@anl.gov To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 01/28/2014 12:47 PM Subject:Re: [openstack-dev] Proposed Logging Standards For the uses I've seen of it in the nova api code INFO would be perfectly fine in place of AUDIT. We've found the AUDIT logs in nova useful for tracking which user initiated a particular request (e.g. delete this instance). AUDIT had a much better signal to noise ratio than INFO or DEBUG. Although this seems to have changed since Essex. For example nova-compute spits out AUDIT nova.compute.resource_tracker messages every minute even if there are no changes :-/ ~ Scott On Tue, Jan 28, 2014 at 11:11 AM, Everett Toews everett.to...@rackspace.com wrote: Hi Sean, Could 1.1.1 Every Inbound WSGI request should be logged Exactly Once be used to track API call data in order to discover which API calls are being made most frequently? It certainly seems like it could but I want to confirm. I ask because this came up as B Get aggregate API call data from companies willing to share it. in the user survey discussion [1]. Thanks, Everett [1] http://lists.openstack.org/pipermail/user-committee/2014-January/000214.html On Jan 27, 2014, at 7:07 AM, Sean Dague wrote: Back at the beginning of the cycle, I pushed for the idea of doing some log harmonization, so that the OpenStack logs, across services, made sense. I've pushed a proposed changes to Nova and Keystone over the past couple of days. This is going to be a long process, so right now I want to just focus on making INFO level sane, because as someone that spends a lot of time staring at logs in test failures, I can tell you it currently isn't. https://wiki.openstack.org/wiki/LoggingStandards is a few things I've written down so far, comments welcomed. We kind of need to solve this set of recommendations once and for all up front, because negotiating each change, with each project, isn't going to work (e.g - https://review.openstack.org/#/c/69218/) What I'd like to find out now: 1) who's interested in this topic? 2) who's interested in helping flesh out the guidelines for various log levels? 3) who's interested in helping get these kinds of patches into various projects in OpenStack? 4) which projects are interested in participating (i.e. interested in prioritizing landing these kinds of UX improvements) This is going to be progressive and iterative. And will require lots of folks involved. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] [glance] Heater Proposal
Lots of good discussion on this topic. One thing I would like to point out is that we get feedback that OpenStack has too many projects as it is and customers get confused on how much of OpenStack they need to install. So in the spirit of trying to help insure OpenStack does not continue to reinforce this perception, I am hoping that Heater functionality finds a home in either Glance or Heat. I don't have a preference of which. Either of these is superior to starting a new project if it can be avoided. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Randall Burt randall.b...@rackspace.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 12/05/2013 12:09 PM Subject:Re: [openstack-dev] [heat] [glance] Heater Proposal On Dec 5, 2013, at 10:10 AM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800: Why not just use glance? I've asked that question a few times, and I think I can collate the responses I've received below. I think enhancing glance to do these things is on the table: 1. Glance is for big blobs of data not tiny templates. 2. Versioning of a single resource is desired. 3. Tagging/classifying/listing/sorting 4. Glance is designed to expose the uploaded blobs to nova, not users My responses: 1: Irrelevant. Smaller things will fit in it just fine. Fitting is one thing, optimizations around particular assumptions about the size of data and the frequency of reads/writes might be an issue, but I admit to ignorance about those details in Glance. 2: The swift API supports versions. We could also have git as a backend. This feels like something we can add as an optional feature without exploding Glance's scope and I imagine it would actually be a welcome feature for image authors as well. Think about Ubuntu maintaining official images. If they can keep the ID the same and just add a version (allowing users to lock down to a version if updated images cause issue) that seems like a really cool feature for images _and_ templates. Agreed, though one could argue that using image names and looking up ID's or just using ID's as appropriate sort of handle this use case, but I agree that having image versioning seems a reasonable feature for Glance to have as well. 3: I'm sure glance image users would love to have those too. And image metadata is already there so we don't have to go through those discussions all over again ;). 4: Irrelevant. Heat will need to download templates just like nova, and making images publicly downloadable is also a thing in glance. Yeah, this was the kicker for me. I'd been thinking of adding the tenancy/public/private templates use case to the HeatR spec and realized that this was a good argument for Glance since it already has this feature. It strikes me that this might be a silo problem instead of an actual design problem. Folk should not be worried about jumping into Glance and adding features. Unless of course the Glance folk have reservations? (adding glance tag to the subject) Perhaps, and if these use cases make sense for the Glance users in general, I wouldn't want to re-invent all those wheels either. I admit there's some appeal to being able to pass a template ID to stack-create or as the type of a provider resource and have an actual API to call that's already got a known, tested client that's already part of the OpenStack ecosystem In the end, though, even if some and not all of our use cases make sense for the Glance folks, we still have the option of creating the HeatR service and having Glance as a possible back-end data store. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Support for external authentication (i.e. REMOTE_USER) in Havana
+1! Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Adam Young ayo...@redhat.com To: openstack-dev@lists.openstack.org Date: 10/30/2013 11:13 AM Subject:Re: [openstack-dev] [keystone] Support for external authentication (i.e. REMOTE_USER) in Havana On 10/30/2013 05:38 AM, Álvaro López García wrote: On Tue 29 Oct 2013 (17:04), Adam Young wrote: On 10/29/2013 12:18 PM, Tim Bell wrote: We also need some standardisation on the command line options for the client portion (such as --os-auth-method, --os-x509-cert etc.) . Unfortunately, this is not yet in Oslo so there would be multiple packages to be enhanced. There is a OS client talk on Wednesday that you should atend. Getting the Auth options striaght in a common client will be a huge benefit. Yes, indeed (and providing a set of common auth plugins like X509, basic, etc). Tim -Original Message- From: Alan Sill [mailto:kilohoku...@gmail.com] Sent: 29 October 2013 16:36 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone] Support for external authentication (i.e. REMOTE_USER) in Havana +1 (except possibly for the environmental variables portion, which could and perhaps should be handled through provisioning). THis is the Apache ENV dictionary, not system environemnte variables. This means that Apache modules can potentially pas on more than just the username or comparable authentication value. On Oct 29, 2013, at 8:35 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: Whilst on this topic, perhaps we should also expand it to discuss support for external authz as well. I know that Adam at Red Hat is working on adding additional authz attributes as env variables so that these can be used for authorising the user in keystone. It should be the same module in Keystone that handles the incoming request, regardless of whether it has only the remote user env variable, or has this plus a number of authz attribute env variables as well. I should like this module to end by returning the identity of the remote user in a standard internal keystone format (i.e. as a set of identity attributes), which can then be passed to the next phase of processing (which will include attribute mapping). In this way, we can have a common processing pipeline for incoming requests, regardless of how the end user was authenticated, ie. whether the request contains SAML assertions, env variables, OpenID assertions etc. Different endpoints could be used for the different incoming protocols, or a common endpoint could be used, with JSON parameters containing the different protocol information. Love this idea. We can discuss in the Federation session. I completely agree, but you are focusing on federation. Sorry, that comment was meant explicitly for the OpenID, SAML piece of it...but having said that: I see Federation as being the priamry reason that Keystone exists. It is rare that a dedicated user ID database will belong to the Cloud deployment. In the Enterprise, we cannot even count on a single Directory (Mergers and acquisitions make this unlikely) and in the public we need to be able to link users from remote IdPs. Federation is a lousyt term, in that it implies that this stuff is special. It is not. This stuff is Authorization at its core. Federation is just the name for smacking us out of the nearsightedness that has driven application development. Please take into account that external authentication and the REMOTE_USER stuff can be used without any federation at all. For example if an org is providing their users with X509 certificates and they want to use that for authentication instead of username/password. In this case there would be no authz, no mapping, etc., just authn. Oh, no, not at all...Authenticaion is not authorization. Authorization is based on authentication plus. It is that plus that is important. Yes, it may still be an LDAP call after the user logs in with the X509, we are not going to break that. But even in a non-federate case, it is likely that Authoriuzation attributes will be coming from the Web front end. Maybe we should rename external authentication to HTTPD authentication? Nope. Apache HTTPD is one potential front to a WSGI app, but not the only one. NOthing we are doing here is Apache specific, if we can help it. Ngnix and many other web front ends are out there. I just want to use Apache HTTPD as the common, understood sample Front end that provides a well documented set of strong security protocols. Lets continue to call it external, as that term was chosen after discussing this very topic. Regards, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] OpenLdap for Keystone
Hi Mark, in localrc you can modify the number of services installed using the values below. You can try uncommenting the last two lines shown below to dramatically reduce the amount of openstack software installed by devstack. #ENABLED_SERVICES=key,n-api,n-crt,n-obj,n-cpu,n-net,n-cond,cinder,c-sch,c-api,c-vol,n-sch,n-novnc,n-xvnc,n-cauth,horizon,mysql,rabbit,ldap #disable_all_services #enable_service key mysql swift rabbit Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Cindy Willman (919) 268-5296 From: Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 09/05/2013 12:22 PM Subject:Re: [openstack-dev] OpenLdap for Keystone Thanks Brad for the pointer. Is there any way to just install the OpenLdap piece and not the entire OpenStack? Mark From: Brad Topol [mailto:bto...@us.ibm.com] Sent: Thursday, September 05, 2013 5:37 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] OpenLdap for Keystone devstack has the ability to install keystone with openldap and configure them together. Look at the online doc for stack.sh on how to configure devstack to install keystone with openldap. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Cindy Willman (919) 268-5296 From:Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com To:OpenStack Development Mailing List openstack-dev@lists.openstack.org Date:09/04/2013 06:32 PM Subject:[openstack-dev] OpenLdap for Keystone Hello, I have been struggling trying to configure OpenLdap to work with Keystone. I have found a gazillion snippets about this topic, but no step-by-step documents on how to install and configure OpenLdap so it will work with current Keystone releases. I am hoping that someone has a tested answer for me. Thanks in advance, Mark Miller___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenLdap for Keystone
devstack has the ability to install keystone with openldap and configure them together. Look at the online doc for stack.sh on how to configure devstack to install keystone with openldap. Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Cindy Willman (919) 268-5296 From: Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 09/04/2013 06:32 PM Subject:[openstack-dev] OpenLdap for Keystone Hello, I have been struggling trying to configure OpenLdap to work with Keystone. I have found a gazillion snippets about this topic, but no step-by-step documents on how to install and configure OpenLdap so it will work with current Keystone releases. I am hoping that someone has a tested answer for me. Thanks in advance, Mark Miller___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core
+1 on Morgan. He is an outstanding contributor! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Cindy Willman (919) 268-5296 From: Dolph Mathews dolph.math...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 08/06/2013 03:22 PM Subject:[openstack-dev] Proposing Morgan Fainberg for keystone-core Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] A vision for Keystone
Agreed, but the history portion of what you wrote that that takes us from the beginning to where we are now today has all been implemented. That portion I thought could be added to the project as it really tells a nice narrative of why what you see in the keystone code base is actually there. Thanks. Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Cindy Willman (919) 268-5296 From: Adam Young ayo...@redhat.com To: openstack-dev@lists.openstack.org Date: 07/25/2013 09:59 PM Subject:Re: [openstack-dev] A vision for Keystone On 07/19/2013 10:56 AM, Brad Topol wrote: Adam, Your essay below is outstanding! Any chance part of it could be included within the keystone project documentation? I think having it in the project and at folks fingertips would really help folks that are trying to get up to speed with keystone! Thanks for the input. I think it could be included in the future, but we have along way to go to implement this vision, and we are moving toward it one step at a time. When we are closer, I will revise the essay to reflect reality and maybe more relevant details. At that point, yes, it can be part of the documentation. Thanks again for writing this up! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Cindy Willman (919) 268-5296 From:Adam Young ayo...@redhat.com To:OpenStack Development Mailing List openstack-dev@lists.openstack.org Date:07/18/2013 02:21 PM Subject:[openstack-dev] A vision for Keystone I wrote up an essay that, I hope, explains where Keystone is headed as far as token management. http://adam.younglogic.com/2013/07/a-vision-for-keystone/ It is fairly long (2000 words) but I attempted to make it readable, and to provide the context for what we are doing. There are several blueprints for this work, many of which have already been implemented. There is at least one that I still need to write up. This is not new stuff. It is just an attempt to cleanly lay out the story. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [cinder] Proposal for Ollie Leahy to join cinder-core
+1. Thanks to John and Sean for the excellent responses they provided below! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Cindy Willman (919) 268-5296 From: Sean Dague s...@dague.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Cc: Openstack \(openst...@lists.launchpad.net\) \(openst...@lists.launchpad.net\) openst...@lists.launchpad.net Date: 07/17/2013 02:49 PM Subject:Re: [openstack-dev] [Openstack] [cinder] Proposal for Ollie Leahy to join cinder-core On 07/17/2013 02:35 PM, John Griffith wrote: snip Just to point out a few things here, first off there is no guideline that states a company affiliation should have anything to do with the decision on voting somebody as core. I have ABSOLUTELY NO concern about representation of company affiliation what so ever. Quite frankly I wouldn't mind if there were 20 core members from HP, if they're all actively engaged and participating then that's great. I don't think there has been ANY incidence of folks exerting inappropriate influence based on their affiliated interest, and if there ever was I think it would be easy to identify and address. As far as don't need more I don't agree with that either, if there are folks contributing and doing the work then there's no reason not to add them. Cinder IMO does NOT have an excess of reviewers by a very very long stretch. The criteria here should be review consistency and quality as well as knowledge of the project, nothing more nothing less. If there's an objection to the individuals participation or contribution that's fine, but company affiliation should have no bearing. +1 The people that do great work on reviews, should really be your review team, regardless of affiliation. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
