www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Brooklyn not in http://people.apache.org/committers-by-project.html
Date Fri, 23 Jan 2015 16:00:51 GMT

> On Jan 23, 2015, at 7:48 AM, David Nalley <david@gnsa.us> wrote:
> On Fri, Jan 23, 2015 at 10:27 AM, Alan D. Cabrera <list@toolazydogs.com> wrote:
>>> On Jan 22, 2015, at 3:11 PM, Tony Stevenson <pctony@apache.org> wrote:
>>> Please note that there are some significant technical consequences to this (depending
upon the exact nature of the changes) - for example adding that to an ou that was a child
ou of the incubator )whcih it probably should be) will cause some of the services that query
ldap tp incorrectly classify them, and perhaps there misuse them etc.
>>> It's not all doom and gloom. I'd rather see effort into getting other data into
LDAP first - as this has been around for a long time, and the PPMC additions seems like such
a small win for such a huge effort investment, right now.  One day it will all be in LDAP.
>> And maybe the Incubator will be a thing of the past by that time.  ;)
>> Anyway, I’d still like to help unless someone else is already working on this.
> So my opposition to this is three fold.
> Today, LDAP is an authorization mechanism. More and more people are
> wanting it to become a source of truth. This difference is subtle, but
> a substantial one. For instance, if you look at the list of members
> per LDAP, you'll see folks who aren't actually members. There is a lot
> of technical debt present around in that arena that will have to be
> paid before we can began treating LDAP as a source of truth.
> We also have a lot of infra tooling built around the current way of
> doing things, including how projects in the incubator are graduated,
> how we handle authentication to various things and all of those are
> potentially affected, and would need to be reworked. That's not a good
> reason for not making changes, but it makes me reluctant to add all of
> this additional work and the need to pay this specific chunk of debt
> off right now given our other priorities. Part of that is looking at
> the opportunity cost to the foundation for not doing this work; in my
> mind that cost is that LDAP isn't authoritative and people maintain
> text files. Compared to what is on our plate, it's not close to being
> a priority just now.
> If, someone wanted to tackle this, and figures out all of the touch
> points and gets those fixed and working in a test environment first,
> more power to them, but even setting up the test environment is a
> non-trivial amount of work. And FWIW, I don't ever see the level of
> karma needed to make LDAP changes being changed - especially if we
> move to LDAP being a source of truth, if anything that may trigger a
> requirement that it be more restrictive than it is today.

Thanks for the concise and lucid exposition.  I totally understand where you’re coming from.

At the moment, we have untold documented and undocumented processes that fiddle with the disparate
and inconsistent set of metadata that represents the Apache Software Foundation.  There is
no way to get from “here” to “there” without building some kind of “interface”
that represents where we want to be, move all of our processes onto this new interface, then
start cleaning the disparate and inconsistent set of metadata behind the scenes.

I think that this interface should be a simple REST API. 

Once we have this REST API then all manner of tooling is possible and infra can start cleaning/refactoring
things at their own pace.


View raw message