comanage-dev - Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?
Subject: COmanage Developers List
List archive
- From: Dan Pritts <>
- To: Benn Oshrin <>
- Cc:
- Subject: Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?
- Date: Tue, 24 Aug 2010 18:52:06 -0400
as it turns out we have been proceeding down a somewhat similar path
for the VO known as Internet2. Things with comanage were very much
not clear so at the beginning of the year we started off on our own.
we've of course got our own CRM system to integrate with (imis).
we pretty quickly decided we would build something very co-manage-like
with a central sql store, and provision out of there to ldap, possibly
managed by grouper (at a first cut we would probably do something quicker
and dirtier). We'd also have some synchronization with imis, and we'd
attempt to use the same domestication methods and code as comanage.
we should probably sync up what we've gotten done with what you're
planning. My colleage IJ Kim is our internal developer who's done most
of the work. either he or i is on vacation until after labor day but
maybe you and the two of us might get together for a brain dump afterward.
On Tue, Aug 24, 2010 at 03:53:26PM -0400, Benn Oshrin wrote:
> I suspect implementing a stand-alone core with no external dependencies
> (other than perhaps a web server and a database server) will end up
> being the starting point, with the ability subsequently added to replace
> components as appropriate (Grouper, LDAP, etc.)
It sounds like a central comanage system as you imagine it would not
include an ldap server? How are you planning to get group information
out to the apps? I must not understand you properly.
>
> Though it's possible some functionality will be significantly simplified
> by having a cached set of data in the database even when external
> components are used...
we came to that conclusion pretty quickly.
>
> -Benn-
>
> On 8/23/10 12:17 PM, Dan Pritts wrote:
> >It seems obvious that the DIY people will want lightweight and pretty
> >likely that a big provider will want configurable. So maybe this really
> >comes down to "who is the audience."
> >
> >
> >that said, there are lots and lots of apps out there that need an SQL
> >db nowadays.
> >
> >the person running a DIY CO will probably be some grad student who's
> >done a little LAMP work, so an SQL database will be more familiar than
> >an ldap server. And personally, having done plenty of both, i'd rather
> >deal with mysql than openldap any day.
> >
> >In the heavyweight world you end up needing an LDAP interface anyway,
> >whether it is provisioning ldap from sql, or a sql backend for ldap.
> >(of course ldap general wisdom is that an sql db is not a good backend
> >for ldap :)
> >
> >In either case, though, I think that good software development can hide
> >the complexity of LDAP from the administrator, probably more than will
> >be possible with an LDAP-centric approach. It's just a matter of coding
> >it up, right?
> >
> >
> >
> >
> >On Mon, Aug 23, 2010 at 11:18:37AM -0400, Benn Oshrin wrote:
> >>I'd be interested in some feedback or discussion about two different
> >>models for the implementation of COordinate (the backend
> >>middleware-esque engine).
> >>
> >>The lighter weight approach is very much similar to the existing demo,
> >>with almost all data stored in third-party applications such as LDAP,
> >>Grouper, etc. The advantages of this approach include faster
> >>implementation and no need for a SQL Server.
> >>
> >>The heavier weight approach starts to look a little more like a
> >>traditional institutional identity management system, including an
> >>underlying SQL database for most or all data. The advantages of this
> >>approach include abstraction away from specific technologies, as well as
> >>easier integration for more sophisticated needs (such as reporting
> >>servers).
> >>
> >>A third model would be a hybrid or pluggable approach, but for purposes
> >>of this thread I think it makes sense to focus on the two ends of the
> >>spectrum.
> >>
> >>To the extent possible, I'd like to consider these options in the
> >>context of the requirements of the entities likely to run this software,
> >>including DIY COs such as LIGO and CaaS providers such as Penn State for
> >>ESWN.
> >>
> >>Thoughts?
> >>
> >>-Benn-
> >
> >
> >danno
> >--
> >Dan Pritts, Sr. Systems Engineer
> >Internet2
> >office: +1-734-352-4953 | mobile: +1-734-834-7224
danno
--
Dan Pritts, Sr. Systems Engineer
Internet2
office: +1-734-352-4953 | mobile: +1-734-834-7224
- [comanage-dev] COmanage COordinate: How Much Should It Weigh?, Benn Oshrin, 08/23/2010
- Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?, Dan Pritts, 08/23/2010
- Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?, Benn Oshrin, 08/24/2010
- Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?, Dan Pritts, 08/24/2010
- Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?, Benn Oshrin, 08/24/2010
- Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?, Dan Pritts, 08/24/2010
- Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?, Benn Oshrin, 08/24/2010
- Re: [comanage-dev] COmanage COordinate: How Much Should It Weigh?, Dan Pritts, 08/23/2010
Archive powered by MHonArc 2.6.16.