On Tue, 2017-05-16 at 13:12 +0300, Ilias Stamatis wrote:
Hello,
Hey mate,
I'm going to add support for the memberOf plugin into the dsconf tool.
However, because this is going to be the first plugin to be configurable
through lib389, design decisions will affect all future plugins to be
supported.
I'd like thoughts on which approach would be more convenient for an admin.
Right now, there's an initial general design for all plugins here:
https://pagure.io/lib389/blob/master/f/lib389/cli_conf/plugin.py
This suggests that we do things the following way:
1. "dsconf instance plugin enable" and then it prompts us to enter the dn
of the plugin to enable.
2. "dsconf instance plugin config" and then it prompts again for a dn and
displays configuration options *specific* to that plugin
I think it might be more handy to avoid additional prompts and directly do
things like the following:
dsconf instance plugin memberof enable
dsconf instance plugin memberof fixup
I'm really happy with this syntax. We could make it:
dsconf instance memberof enable
And leave "plugin" for generic plugins?
However, this way we will end up with very long commands.
eg.
dsconf instance plugin memberof config modify "memberofattr"
"memberOf2"
I don't think we would use this. Perhaps:
dsconf instance memberof config # Would show config
dsconf instance memberof config <attr> # Show just that attr
dsconf instance memberof config <attr> <value> # Set this value
I wonder now about multivalue attrs for this. I can see why you are
worried about it getting a bit long.
Something that would help is:
dsconf instance memberof config edit
Which wuold be similar to ldapvi and open $EDITOR with the entry, then
commits the diff when you change it. That would certainly make this
easier.
For the cli, I think perhaps the long setting may be unavoidable because
we need to express add/mod/rep/delete. We could likely take a cisco like
view and do;
dsconf instance memberof config a <attr> <value>
where add is shortened to the unique value. IIRC argparse supports this.
which is huge.
With the second approach it's easier to write scripts based on dsconf
though.
Any thoughts on this?
Thanks for your really thoughtful email about this!
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane