Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-15 Thread Dave Walker
Hi Jesse and Andy,

Thanks muchly for outlining the reasoning and the direction.  The
vocal nature of this is more re-assuring.  It seems like the it was a
wise decision to start a fresh, based on the experiences of keystone
v1.

Initial impressions seem to be quite pleasing, thanks to all those who
were involved.

Kind Regards,

Dave Walker dave.wal...@canonical.com
Engineering Manager,
Ubuntu Server Infrastructure

On Tue, Feb 14, 2012 at 06:20:24PM -0800, Jesse Andrews wrote:
 The major lessons of keystone:
 
 While keystone served as an effective proof of concept for unified
 authentication (before keystone each component had its own
 users/passwords), it didn't get enough attention from other developers and
 integration with other core projects.
 
 The pain caused by not having shared authentication caused it to grow up
 too fast.  Keystone was in incubation during Diablo and is scheduled for
 official core at the Essex release.
 
 Going forward when something is added to core we need to make sure it has
 the project wide support necessary to present a consistent openstack during
 the transition and afterwards.
 
 As an example, before quantum becomes a core project we are documenting
 what becomes of Nova network and existing APIs.  Glance integration into
 nova was a good example where the image list API call proxies to glance.
 
 Additional if the code is vastly different, it is harder to get existing
 contributors to participate.
 
 The original keystone team had a hard task and didn't get enough time and
 help due to circumstances (some within their control and some not)
 
 Jesse
 
 
 On Feb 14, 2012 5:53 PM, Andy Smith andys...@gmail.com wrote:
 
  Hey there Joshua,
 
  Good question! `redux` started due to a variety of frustrations with the
 previous design that arose from decisions made early in the original
 development and were deemed infeasible to resolve in an evolutionary way.
 
  My team and the teams we work with closely felt we were in a good
 position to re-imagine some of those decisions while still providing a
 service that was functional (since we rely on it heavily for day to day
 work) and robust.
 
  There will certainly be bugs introduced by this move, but we have an
 extremely strong vested interest in fixing them rapidly and feel that the
 new code base will greatly improve our ability to do so.
 
  --andy
 
 
  On Tue, Feb 14, 2012 at 4:53 PM, Joshua Harlow harlo...@yahoo-inc.com
 wrote:
 
  Great!
 
  A question I never understood, why was a redux needed?
  Isn’t keystone “pretty” new anyway? Maybe I missed that message/memo.
  Was there some kind of “learnings/oops moment” that happened that we can
 all benefit from (and not repeat?).
 
  Sorry if this is a repeat...
 
 
  On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:
 
  tl;dr proposal to merge keystone redux: same API, same client, new
 service.  Please review and ask questions!
 
  FRIENDS, ROMANS
 
  We are gathered here today to celebrate the commencement of Keystone
 (redux) to fill the role of Keystone (henceforth known as legacy). It is
 with great pride that we propose this stand-up-fellow of a refactor to join
 the ranks of the other OpenStack projects.
 
  There will be differences, both in how you develop and how you use it,
 though we've tried to keep those to a minimum (it has the same API, client,
 and migration paths from existing deploys)
 
  You will notice that the code is organized rather differently in most
 cases, though still in line with the general form of OpenStack projects,
 and we use the standard tools and procedures you may be familiar with from
 work on a project like Nova.  (Your wrists will be shattered if you attempt
 to use double quotes where single quotes might better suffice.)
 
  The bulk of the work put into `redux` has been to reduce the complexity
 of and provide a more easily extensible version of `legacy` while still
 providing the features that the other projects require. We think we have
 been successful in this, and we hope you'll agree.
 
  Read on for more specifics.
 
  MERGE PROPOSAL:
 
  Please voice your comments  votes on the merge proposal:
 
*
 https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z
 
  Since this is a rather large merge, you can explore the code at github
 (reviews should happen in gerrit using the above link):
 
* https://github.com/openstack/keystone/tree/redux
* https://github.com/openstack-dev/devstack/tree/redux
 
  DELTA:
 
  The two major items we are working on adding to redux at time of
 writing.  Support for XML and LDAP integration.  We propose evaluating the
 merge with these known issues, as work is being done to re-add support
 before E4.
 
  State of XML (via Dolph Mathews)
 
 Work is underway to support the existing XSD/WADLs
 XML code in its current state is posted to
 https://review.openstack.org/#change,4037
 Our hope is to convert XML to/from python objects with minor 

Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-15 Thread Joshua Harlow
Cool,

Happy to learn that this happened earlier rather than later. Noticing something 
is broke is always easier to fix early on, rather than having to incremental 
re-factor it to a working (non-broke) state later on when its being widely used.

Thanks for the explanation.
Good stuff to learn from.

On 2/14/12 6:20 PM, Jesse Andrews anotherje...@gmail.com wrote:

The major lessons of keystone:

While keystone served as an effective proof of concept for unified 
authentication (before keystone each component had its own users/passwords), it 
didn't get enough attention from other developers and integration with other 
core projects.

The pain caused by not having shared authentication caused it to grow up too 
fast.  Keystone was in incubation during Diablo and is scheduled for official 
core at the Essex release.

Going forward when something is added to core we need to make sure it has the 
project wide support necessary to present a consistent openstack during the 
transition and afterwards.

As an example, before quantum becomes a core project we are documenting what 
becomes of Nova network and existing APIs.  Glance integration into nova was a 
good example where the image list API call proxies to glance.

Additional if the code is vastly different, it is harder to get existing 
contributors to participate.

The original keystone team had a hard task and didn't get enough time and help 
due to circumstances (some within their control and some not)

Jesse



On Feb 14, 2012 5:53 PM, Andy Smith andys...@gmail.com wrote:

 Hey there Joshua,

 Good question! `redux` started due to a variety of frustrations with the 
 previous design that arose from decisions made early in the original 
 development and were deemed infeasible to resolve in an evolutionary way.

 My team and the teams we work with closely felt we were in a good position to 
 re-imagine some of those decisions while still providing a service that was 
 functional (since we rely on it heavily for day to day work) and robust.

 There will certainly be bugs introduced by this move, but we have an 
 extremely strong vested interest in fixing them rapidly and feel that the new 
 code base will greatly improve our ability to do so.

 --andy


 On Tue, Feb 14, 2012 at 4:53 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:

 Great!

 A question I never understood, why was a redux needed?
 Isn't keystone pretty new anyway? Maybe I missed that message/memo.
 Was there some kind of learnings/oops moment that happened that we can all 
 benefit from (and not repeat?).

 Sorry if this is a repeat...


 On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

 tl;dr proposal to merge keystone redux: same API, same client, new service. 
  Please review and ask questions!

 FRIENDS, ROMANS

 We are gathered here today to celebrate the commencement of Keystone 
 (redux) to fill the role of Keystone (henceforth known as legacy). It is 
 with great pride that we propose this stand-up-fellow of a refactor to join 
 the ranks of the other OpenStack projects.

 There will be differences, both in how you develop and how you use it, 
 though we've tried to keep those to a minimum (it has the same API, client, 
 and migration paths from existing deploys)

 You will notice that the code is organized rather differently in most 
 cases, though still in line with the general form of OpenStack projects, 
 and we use the standard tools and procedures you may be familiar with from 
 work on a project like Nova.  (Your wrists will be shattered if you attempt 
 to use double quotes where single quotes might better suffice.)

 The bulk of the work put into `redux` has been to reduce the complexity of 
 and provide a more easily extensible version of `legacy` while still 
 providing the features that the other projects require. We think we have 
 been successful in this, and we hope you'll agree.

 Read on for more specifics.

 MERGE PROPOSAL:

 Please voice your comments  votes on the merge proposal:

   * 
 https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

 Since this is a rather large merge, you can explore the code at github 
 (reviews should happen in gerrit using the above link):

   * https://github.com/openstack/keystone/tree/redux
   * https://github.com/openstack-dev/devstack/tree/redux

 DELTA:

 The two major items we are working on adding to redux at time of writing.  
 Support for XML and LDAP integration.  We propose evaluating the merge with 
 these known issues, as work is being done to re-add support before E4.

 State of XML (via Dolph Mathews)

Work is underway to support the existing XSD/WADLs
XML code in its current state is posted to 
 https://review.openstack.org/#change,4037
Our hope is to convert XML to/from python objects with minor tweaks 
 where needed to meet the spec.
Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to 
 verify correctness, we hope to use a more pythonic tool in 

Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-15 Thread Andrew Clay Shafer
+1

Don't deprecate, until the bass drops... lesson learned.





On Wed, Feb 15, 2012 at 11:22 PM, Soren Hansen so...@linux2go.dk wrote:

 2012/2/14 Jesse Andrews anotherje...@gmail.com:
  The major lessons of keystone:

 Now that we're verbalising lessons learnt from Keystone, I'd like to add
 another thing from back in the Diablo days: We should only ever depend
 on code that already exists or is under our own release management. When
 Keystone was very young, we deprecated Nova's built-in auth system, but
 seeing as Keystone wasn't ready, nor was being tracked by our release
 manager, we ended up releasing Nova with a deprecated auth system and a
 preferred auth system that wasn't released yet. I'd like to avoid that
 happening again.

 --
 Soren Hansen | http://linux2go.dk/
 Senior Software Engineer | http://www.cisco.com/
 Ubuntu Developer | http://www.ubuntu.com/
 OpenStack Developer  | http://www.openstack.org/

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-14 Thread Joshua Harlow
Great!

A question I never understood, why was a redux needed?
Isn't keystone pretty new anyway? Maybe I missed that message/memo.
Was there some kind of learnings/oops moment that happened that we can all 
benefit from (and not repeat?).

Sorry if this is a repeat...

On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

tl;dr proposal to merge keystone redux: same API, same client, new service.  
Please review and ask questions!

FRIENDS, ROMANS

We are gathered here today to celebrate the commencement of Keystone (redux) to 
fill the role of Keystone (henceforth known as legacy). It is with great pride 
that we propose this stand-up-fellow of a refactor to join the ranks of the 
other OpenStack projects.

There will be differences, both in how you develop and how you use it, though 
we've tried to keep those to a minimum (it has the same API, client, and 
migration paths from existing deploys)

You will notice that the code is organized rather differently in most cases, 
though still in line with the general form of OpenStack projects, and we use 
the standard tools and procedures you may be familiar with from work on a 
project like Nova.  (Your wrists will be shattered if you attempt to use double 
quotes where single quotes might better suffice.)

The bulk of the work put into `redux` has been to reduce the complexity of and 
provide a more easily extensible version of `legacy` while still providing the 
features that the other projects require. We think we have been successful in 
this, and we hope you'll agree.

Read on for more specifics.

MERGE PROPOSAL:

Please voice your comments  votes on the merge proposal:

  * 
https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

Since this is a rather large merge, you can explore the code at github (reviews 
should happen in gerrit using the above link):

  * https://github.com/openstack/keystone/tree/redux
  * https://github.com/openstack-dev/devstack/tree/redux

DELTA:

The two major items we are working on adding to redux at time of writing.  
Support for XML and LDAP integration.  We propose evaluating the merge with 
these known issues, as work is being done to re-add support before E4.

State of XML (via Dolph Mathews)

   Work is underway to support the existing XSD/WADLs
   XML code in its current state is posted to 
https://review.openstack.org/#change,4037
   Our hope is to convert XML to/from python objects with minor tweaks where 
needed to meet the spec.
   Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to verify 
correctness, we hope to use a more pythonic tool in redux

State of LDAP (via Adam Young):

   LDAP code in its current state is posted to 
https://github.com/admiyo/keystone/tree/ldap2
   Unit tests pass against fakeldap, with the exception of the ones that check 
for uniqueness.  I suspect that is supposed to be enforced by SLAPD
   I am working on getting the scheme documented for the LDAP server, and for 
prepopulating Roles.
   Authentication against a live LDAP server works.  Roles and Tenants are 
currently ignored.  Getting the schema straight needs to happen first.
   Should have working code in the next day or two.

BUGS:

We've been tagging bugs as redux that are against the rewrite.  You can view 
the full list at full bug list at 
https://bugs.launchpad.net/keystone/+bugs?field.tag=redux  We marked bugs that 
are needed to land before this merge as CRITICAL, and before E4 as HIGH.

Post Merge:

After merge we will continue improving Keystone, specifically:

 * Target critical/high bugs for E4
 * Work with downstream/packagers on changes needed for their distros
 * Work with tempest on test coverage
 * Another pass through the bugs  blueprints to update the state

Thanks to all the contributors to the rewrite:

Andy Smith
Anthony Young
Brian Waldon
Chmouel Boudjnah
Chuck Short
Dean Troyer
Devin Carlen
Dolph Mathews
James E. Blair
Jesse Andrews
Joe Heck
Justin Santa Barbara
Monty Taylor
Vishvananda Ishaya

HOYOOO!


p.s. wubwubwubSKRwubwub

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-14 Thread Andy Smith
Hey there Joshua,

Good question! `redux` started due to a variety of frustrations with the
previous design that arose from decisions made early in the original
development and were deemed infeasible to resolve in an evolutionary way.

My team and the teams we work with closely felt we were in a good position
to re-imagine some of those decisions while still providing a service that
was functional (since we rely on it heavily for day to day work) and robust.

There will certainly be bugs introduced by this move, but we have an
extremely strong vested interest in fixing them rapidly and feel that the
new code base will greatly improve our ability to do so.

--andy

On Tue, Feb 14, 2012 at 4:53 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  Great!

 A question I never understood, why was a redux needed?
 Isn’t keystone “pretty” new anyway? Maybe I missed that message/memo.
 Was there some kind of “learnings/oops moment” that happened that we can
 all benefit from (and not repeat?).

 *Sorry if this is a repeat*...


 On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

 tl;dr proposal to merge keystone redux: same API, same client, new
 service.  Please review and ask questions!

 FRIENDS, ROMANS

 We are gathered here today to celebrate the commencement of Keystone
 (redux) to fill the role of Keystone (henceforth known as legacy). It is
 with great pride that we propose this stand-up-fellow of a refactor to join
 the ranks of the other OpenStack projects.

 There will be differences, both in how you develop and how you use it,
 though we've tried to keep those to a minimum (it has the same API, client,
 and migration paths from existing deploys)

 You will notice that the code is organized rather differently in most
 cases, though still in line with the general form of OpenStack projects,
 and we use the standard tools and procedures you may be familiar with from
 work on a project like Nova.  (Your wrists will be shattered if you attempt
 to use double quotes where single quotes might better suffice.)

 The bulk of the work put into `redux` has been to reduce the complexity of
 and provide a more easily extensible version of `legacy` while still
 providing the features that the other projects require. We think we have
 been successful in this, and we hope you'll agree.

 Read on for more specifics.

 MERGE PROPOSAL:

 Please voice your comments  votes on the merge proposal:

   *
 https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

 Since this is a rather large merge, you can explore the code at github
 (reviews should happen in gerrit using the above link):

   * https://github.com/openstack/keystone/tree/redux
   * https://github.com/openstack-dev/devstack/tree/redux

 DELTA:

 The two major items we are working on adding to redux at time of writing.
 Support for XML and LDAP integration.  We propose evaluating the merge with
 these known issues, as work is being done to re-add support before E4.

 State of XML (via Dolph Mathews)

Work is underway to support the existing XSD/WADLs
XML code in its current state is posted to
 https://review.openstack.org/#change,4037
Our hope is to convert XML to/from python objects with minor tweaks
 where needed to meet the spec.
Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to
 verify correctness, we hope to use a more pythonic tool in redux

 State of LDAP (via Adam Young):

LDAP code in its current state is posted to
 https://github.com/admiyo/keystone/tree/ldap2
Unit tests pass against fakeldap, with the exception of the ones that
 check for uniqueness.  I suspect that is supposed to be enforced by SLAPD
I am working on getting the scheme documented for the LDAP server, and
 for prepopulating Roles.
Authentication against a live LDAP server works.  Roles and Tenants are
 currently ignored.  Getting the schema straight needs to happen first.
Should have working code in the next day or two.

 BUGS:

 We've been tagging bugs as redux that are against the rewrite.  You can
 view the full list at full bug list at
 https://bugs.launchpad.net/keystone/+bugs?field.tag=redux  We marked bugs
 that are needed to land before this merge as CRITICAL, and before E4 as
 HIGH.

 Post Merge:

 After merge we will continue improving Keystone, specifically:

  * Target critical/high bugs for E4
  * Work with downstream/packagers on changes needed for their distros
  * Work with tempest on test coverage
  * Another pass through the bugs  blueprints to update the state

 Thanks to all the contributors to the rewrite:

 Andy Smith
 Anthony Young
 Brian Waldon
 Chmouel Boudjnah
 Chuck Short
 Dean Troyer
 Devin Carlen
 Dolph Mathews
 James E. Blair
 Jesse Andrews
 Joe Heck
 Justin Santa Barbara
 Monty Taylor
 Vishvananda Ishaya

 HOYOOO!


 p.s. wubwubwubSKRwubwub


___
Mailing list: https://launchpad.net/~openstack
Post to : 

Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-14 Thread Dolph Mathews
There's probably several ways to answer this, but I'd say that the original
development of keystone was not sufficiently focused on it's integration
with other projects (and the focus on testing in general came late), while
redux was quite literally born from integration testing.

- Dolph

On Tue, Feb 14, 2012 at 6:53 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:

  Great!

 A question I never understood, why was a redux needed?
 Isn’t keystone “pretty” new anyway? Maybe I missed that message/memo.
 Was there some kind of “learnings/oops moment” that happened that we can
 all benefit from (and not repeat?).

 *Sorry if this is a repeat*...


 On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

 tl;dr proposal to merge keystone redux: same API, same client, new
 service.  Please review and ask questions!

 FRIENDS, ROMANS

 We are gathered here today to celebrate the commencement of Keystone
 (redux) to fill the role of Keystone (henceforth known as legacy). It is
 with great pride that we propose this stand-up-fellow of a refactor to join
 the ranks of the other OpenStack projects.

 There will be differences, both in how you develop and how you use it,
 though we've tried to keep those to a minimum (it has the same API, client,
 and migration paths from existing deploys)

 You will notice that the code is organized rather differently in most
 cases, though still in line with the general form of OpenStack projects,
 and we use the standard tools and procedures you may be familiar with from
 work on a project like Nova.  (Your wrists will be shattered if you attempt
 to use double quotes where single quotes might better suffice.)

 The bulk of the work put into `redux` has been to reduce the complexity of
 and provide a more easily extensible version of `legacy` while still
 providing the features that the other projects require. We think we have
 been successful in this, and we hope you'll agree.

 Read on for more specifics.

 MERGE PROPOSAL:

 Please voice your comments  votes on the merge proposal:

   *
 https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

 Since this is a rather large merge, you can explore the code at github
 (reviews should happen in gerrit using the above link):

   * https://github.com/openstack/keystone/tree/redux
   * https://github.com/openstack-dev/devstack/tree/redux

 DELTA:

 The two major items we are working on adding to redux at time of writing.
 Support for XML and LDAP integration.  We propose evaluating the merge with
 these known issues, as work is being done to re-add support before E4.

 State of XML (via Dolph Mathews)

Work is underway to support the existing XSD/WADLs
XML code in its current state is posted to
 https://review.openstack.org/#change,4037
Our hope is to convert XML to/from python objects with minor tweaks
 where needed to meet the spec.
Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to
 verify correctness, we hope to use a more pythonic tool in redux

 State of LDAP (via Adam Young):

LDAP code in its current state is posted to
 https://github.com/admiyo/keystone/tree/ldap2
Unit tests pass against fakeldap, with the exception of the ones that
 check for uniqueness.  I suspect that is supposed to be enforced by SLAPD
I am working on getting the scheme documented for the LDAP server, and
 for prepopulating Roles.
Authentication against a live LDAP server works.  Roles and Tenants are
 currently ignored.  Getting the schema straight needs to happen first.
Should have working code in the next day or two.

 BUGS:

 We've been tagging bugs as redux that are against the rewrite.  You can
 view the full list at full bug list at
 https://bugs.launchpad.net/keystone/+bugs?field.tag=redux  We marked bugs
 that are needed to land before this merge as CRITICAL, and before E4 as
 HIGH.

 Post Merge:

 After merge we will continue improving Keystone, specifically:

  * Target critical/high bugs for E4
  * Work with downstream/packagers on changes needed for their distros
  * Work with tempest on test coverage
  * Another pass through the bugs  blueprints to update the state

 Thanks to all the contributors to the rewrite:

 Andy Smith
 Anthony Young
 Brian Waldon
 Chmouel Boudjnah
 Chuck Short
 Dean Troyer
 Devin Carlen
 Dolph Mathews
 James E. Blair
 Jesse Andrews
 Joe Heck
 Justin Santa Barbara
 Monty Taylor
 Vishvananda Ishaya

 HOYOOO!


 p.s. wubwubwubSKRwubwub


 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-14 Thread Jesse Andrews
The major lessons of keystone:

While keystone served as an effective proof of concept for unified
authentication (before keystone each component had its own
users/passwords), it didn't get enough attention from other developers and
integration with other core projects.

The pain caused by not having shared authentication caused it to grow up
too fast.  Keystone was in incubation during Diablo and is scheduled for
official core at the Essex release.

Going forward when something is added to core we need to make sure it has
the project wide support necessary to present a consistent openstack during
the transition and afterwards.

As an example, before quantum becomes a core project we are documenting
what becomes of Nova network and existing APIs.  Glance integration into
nova was a good example where the image list API call proxies to glance.

Additional if the code is vastly different, it is harder to get existing
contributors to participate.

The original keystone team had a hard task and didn't get enough time and
help due to circumstances (some within their control and some not)

Jesse


On Feb 14, 2012 5:53 PM, Andy Smith andys...@gmail.com wrote:

 Hey there Joshua,

 Good question! `redux` started due to a variety of frustrations with the
previous design that arose from decisions made early in the original
development and were deemed infeasible to resolve in an evolutionary way.

 My team and the teams we work with closely felt we were in a good
position to re-imagine some of those decisions while still providing a
service that was functional (since we rely on it heavily for day to day
work) and robust.

 There will certainly be bugs introduced by this move, but we have an
extremely strong vested interest in fixing them rapidly and feel that the
new code base will greatly improve our ability to do so.

 --andy


 On Tue, Feb 14, 2012 at 4:53 PM, Joshua Harlow harlo...@yahoo-inc.com
wrote:

 Great!

 A question I never understood, why was a redux needed?
 Isn’t keystone “pretty” new anyway? Maybe I missed that message/memo.
 Was there some kind of “learnings/oops moment” that happened that we can
all benefit from (and not repeat?).

 Sorry if this is a repeat...


 On 2/14/12 4:38 PM, Andy Smith andys...@gmail.com wrote:

 tl;dr proposal to merge keystone redux: same API, same client, new
service.  Please review and ask questions!

 FRIENDS, ROMANS

 We are gathered here today to celebrate the commencement of Keystone
(redux) to fill the role of Keystone (henceforth known as legacy). It is
with great pride that we propose this stand-up-fellow of a refactor to join
the ranks of the other OpenStack projects.

 There will be differences, both in how you develop and how you use it,
though we've tried to keep those to a minimum (it has the same API, client,
and migration paths from existing deploys)

 You will notice that the code is organized rather differently in most
cases, though still in line with the general form of OpenStack projects,
and we use the standard tools and procedures you may be familiar with from
work on a project like Nova.  (Your wrists will be shattered if you attempt
to use double quotes where single quotes might better suffice.)

 The bulk of the work put into `redux` has been to reduce the complexity
of and provide a more easily extensible version of `legacy` while still
providing the features that the other projects require. We think we have
been successful in this, and we hope you'll agree.

 Read on for more specifics.

 MERGE PROPOSAL:

 Please voice your comments  votes on the merge proposal:

   *
https://review.openstack.org/#q,I2cb5b198a06848f42f919ea49e338443131e263e,n,z

 Since this is a rather large merge, you can explore the code at github
(reviews should happen in gerrit using the above link):

   * https://github.com/openstack/keystone/tree/redux
   * https://github.com/openstack-dev/devstack/tree/redux

 DELTA:

 The two major items we are working on adding to redux at time of
writing.  Support for XML and LDAP integration.  We propose evaluating the
merge with these known issues, as work is being done to re-add support
before E4.

 State of XML (via Dolph Mathews)

Work is underway to support the existing XSD/WADLs
XML code in its current state is posted to
https://review.openstack.org/#change,4037
Our hope is to convert XML to/from python objects with minor tweaks
where needed to meet the spec.
Existing XML tests in legacy use a GUI tool http://www.soapui.org/ to
verify correctness, we hope to use a more pythonic tool in redux

 State of LDAP (via Adam Young):

LDAP code in its current state is posted to
https://github.com/admiyo/keystone/tree/ldap2
Unit tests pass against fakeldap, with the exception of the ones
that check for uniqueness.  I suspect that is supposed to be enforced by
SLAPD
I am working on getting the scheme documented for the LDAP server,
and for prepopulating Roles.
Authentication against a live LDAP server 

Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-14 Thread Nathanael Burton
Are keystone light and keystone redux the same thing? Or is one just a
light beer?
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-14 Thread Jesse Andrews
Yes

Light was the codename when it was an internal tool.

The first version was a couple hundred lines and supported all core APIs.

After it was decided it would be more effective to flesh out light than
continue to tweak the existing code base, it became the redux branch of the
official keystone repository.
On Feb 14, 2012 6:29 PM, Nathanael Burton nathanael.i.bur...@gmail.com
wrote:

 Are keystone light and keystone redux the same thing? Or is one just a
 light beer?

 ___
 Mailing list: https://launchpad.net/~openstack
 Post to : openstack@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~openstack
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Re: [Openstack] Keystone: Redux (Dubstep Remix)

2012-02-14 Thread Devin Carlen
I agree fully with Jesse.  I think given the timelines the first cut of 
Keystone was great.  Moving forward we'll also have more folks that are 
burdened (honored?) with operating it in production environments which means 
that more rubber meets the road kinds of issues will be identified and dealt 
with quickly. 

Keystone was originally pushed into core a bit too soon, but this was simply a 
byproduct of the fact that the need for it was very real.  All the groundwork 
done to unify the projects was a huge benefit to the community.  Before that 
point, most of the time when someone was working on OpenStack, they were 
really just working on one individual component in an isolated environment.  
Keystone forced the issue for the community and led to the creation of the 
fabulous DevStack project.  This integration made it far simpler to do 
integration testing, and projects like Tempest greatly benefited from it as 
well.

Devin 


On Tuesday, February 14, 2012 at 6:20 PM, Jesse Andrews wrote:

 The major lessons of keystone:
 While keystone served as an effective proof of concept for unified 
 authentication (before keystone each component had its own users/passwords), 
 it didn't get enough attention from other developers and integration with 
 other core projects.
 The pain caused by not having shared authentication caused it to grow up too 
 fast.  Keystone was in incubation during Diablo and is scheduled for official 
 core at the Essex release.
 Going forward when something is added to core we need to make sure it has the 
 project wide support necessary to present a consistent openstack during the 
 transition and afterwards.
 As an example, before quantum becomes a core project we are documenting what 
 becomes of Nova network and existing APIs.  Glance integration into nova was 
 a good example where the image list API call proxies to glance.
 Additional if the code is vastly different, it is harder to get existing 
 contributors to participate.
 The original keystone team had a hard task and didn't get enough time and 
 help due to circumstances (some within their control and some not)
 Jesse
 

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp