Dne 3.10.2014 v 17:02 Martin Kosek napsal(a):
On 10/03/2014 04:59 PM, Jan Cholasta wrote:
Dne 3.10.2014 v 16:47 Petr Vobornik napsal(a):
On 3.10.2014 16:24, Martin Kosek wrote:
NACK. I will not comment on mechanics, if you get an ACK from Honza, it
is good enough. I just do not like the API. It is hard to guess what
"host-add-retrieve-keytab" means. That word does not even make much
sense.
Can we use something more readable? For example:
ipa host-add-allowed-operation HOSTNAME --operation read_keys
--users=STR --groups STR
ipa host-add-allowed-operation HOSTNAME --operation write_keys
--users=STR --groups STR
and
ipa host-remove-allowed-operation HOSTNAME --operation read_keys
--users=STR --groups STR
ipa host-remove-allowed-operation HOSTNAME --operation write_keys
--users=STR --groups STR
Same with services. At least to me, it looks more readable.
Thanks,
Martin
Seems to me as adding of allowed operation. Not allowing an operation.
+1
What about:
ipa host-allow-retrieve-keytab HOSTNAME --users=STR --groups STR
ipa host-disallow-retrieve-keytab HOSTNAME --users=STR --groups STR
ipa host-allow-create-keytab HOSTNAME --users=STR --groups STR
ipa host-disallow-create-keytab HOSTNAME --users=STR --groups STR
I like these the best. Maybe with a -to or -by suffix.
or if we expect more operations in a future:
ipa host-allow-operation HOSTNAME --operation read-keys --users=STR
--groups STR
ipa host-disallow-operation HOSTNAME --operation read-keys --users=STR
--groups STR
ipa host-allow-operation HOSTNAME --operation write-keys --users=STR
--groups STR
ipa host-disallow-operation HOSTNAME --operation write-keys --users=STR
--groups STR
or if we want to keep 'add' and 'remove' in command names:
ipa host-add-retrieve-keytab-right HOSTNAME --users=STR --groups=STR
ipa host-add-create-keytab-right HOSTNAME --users=STR --groups=STR
ipa host-remove-retrieve-keytab-right HOSTNAME --users=STR --groups=STR
ipa host-remove-create-keytab-right HOSTNAME --users=STR --groups=STR
personally I'm not a fan o the --operation switch, but could be
persuaded by a 'future' usage.
Not a fan either, because it is not consistent with the rest of the
framework.
Also, non-optional options are not really options.
Right. Though mandatory options is a concept already existing in FreeIPA
framework in many places.
That does not make it right.
What I see as a deal breaker is that with
--operation switch, we are ready for dozens of potential future
operations. With operation hardcoded in command name, we are not.
I don't see dozens of operations coming in the near future, there's no
need for a premature optimization like this.
Also note that framework internals can be changed more easily (to
achieve more consistency) than API.
I would rather avoid ad-hoc "enhancements" that add more complexity and
untransparentness (if that's a word) to the framework, we already have
enough of these IMHO.
Martin
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
