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  wrote:

> 2012/2/14 Jesse Andrews :
> > 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-15 Thread Soren Hansen
2012/2/14 Jesse Andrews :
> 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


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"  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"  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  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"  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.
>>>  

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 
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"  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 
> 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"  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/W

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


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" 
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 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
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"  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 
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"  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 docume

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 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"  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/~o

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 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"  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
>
>
_

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"  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