> It is fine as is. However, the current best practice is to have
> resource agents shipped with the software it actually supports
> whenever possible. The interesting parts of a resource agent
> obviously have to do with the software it manages. Since we here
> have only occasionaly some expertise in other areas, the resource
> agent would benefit from more qualified critique from people
> involved in the respective software project.

If I find the time, I'll post this somewhere else so more experienced LDAP
people can have a look at it.

> It would be interesting to have this RA support multi-state.
> Last time I looked at openldap, it supported a master-slave setup
> where every slave was capable of answering queries, but all
> modifications went to the master instance. That fits well with
> the OCF multi-state resource concept.

If I can come up with something quickly, I'll look into it. I do think
however, that having a RA for LDAP is good to have even though it doesn't
support master-slave setups. Other people can add master-slave
functionality if they need it and send in patches.

> The monitor operation in the agent is very basic. An OCF RA
> should do better. Extra points if the query can be made
> configurable so that users can monitor whichever directory part
> is of most importance.

Will look into this.

> You should lower the severity to debug of the log message on
> success in the monitor operation. Otherwise, it's going to make
> to much noise.

Will do.

> Various sed scripts should be consolidated into one function
> dedicated to getting information from the slapd configuration.
> 
> config_file can be a directory. Better name it just config.
> 
> The slapd_validate_all() should return with OCF_ERR_INSTALLED
> instead of OCF_ERR_GENERIC.

Will do.

> The big for loop in validation is, well, big and unwieldy. Not
> sure if it's absolutely necessary to do this kind of validation.

Well, I ran into the problem myself a few times. I thought it would come in
handy.

> Not sure, but some bits look bash-specific. Either remove
> bashisms (preferred) or change #!/bin/sh to #!/bin/bash.

Did my best not to make it bash specific. I don't currently have another
system to test this on, I'll try to get something up quickly and test the
script on that.

> Though we don't have any particular coding style imposed, could
> you perhaps reduce the vertical white space somewhat. Seems like
> there are too many empty lines to me.

Will look into this.

> This is not exhaustive and there'd probably be more, but should
> keep you busy for a while :)
> 
> BTW, there has been once an openldap resource agent posted to
> this list, but unfortunately didn't get timely response (entirely
> my fault) and the author never responded to the late RA review.
> See http://marc.info/?l=linux-ha&m=123003594213018&w=2 and
> http://marc.info/?l=linux-ha&m=124327185429394&w=2

I read the thread. The script itself wasn't that good, but I did make sure
my version didn't have the issues people back then reported.

Regards,
Jeroen
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to