> On 28 Jan 2021, at 19:13, Angel Bosch Mora <abosch@xxxxxxxxxxxxxxxx> wrote:
>
>>>> As sysadmin I create a lot of script to install/manage services
>>>> and is confusing having commands that change that often.
>>
>> You may find it "more stable" to use lib389 directly rather than the
>> CLI then. I think the team should talk about the CLI having an
>> "interface guarantee", and today I don't think I personally would
>> want to commit to that (but the team hasn't decided on this). I
>> still see room to change and grow the CLI in ways that may be
>> breaking, but the core of lib389 today seems "pretty stable".
>>
>
>
> I understand your recommendation but I don't think I'm going to do that, and I think I "shouldn't" do that.
>
> my job as sysadmin is installing, managing, mantaining and monitoring, and dsconf wrapping is just what I need.
> If I have, for example, a command that tells me if a drive is out of space I don't expect to change that command over the years on different linux systems with different versions.
>
> I understand that 389 is under heavy refactoring these last years, I'm just a little bit tired of version conditionals in my recipes (and by the way, I can't find an easy method to check the version with dsconf/dsctl, worth a feature request?).
>
>
> so taking my own example I just expect that `dsconf instance plugin retro-changelog enable' is still valid a year/version later.
The problem here is that there is a difference between "a command line that is good for humans" and "a command line that is good for machine/API consumption".
If we target good for APIs, and commit to making the CLI interface "stable", then we lose the possibility to improve things for humans. LDAP has a reputation for being difficult to administer, and this is just a small step to fixing that. But to commit to CLI interface stability means we would stop being able to progress on this front. We would again become stagnant, and I don't want to see that after we have made so much progress already.
But we *do* have something that *is* API stable - our python API. We *have* to maintain that and it's behaviours, and at this point it's core has not undergone significant churn. It's also much easier to script and manipulate compared to shell. In a recent email I sent this example to someone:
from lib389 import DirSrv
import logging
log = logging.getLogger()
log.setLevel(logging.DEBUG)
ds = DirSrv(verbose=True, external_log=log)
ds.remote_simple_allocate(ldapuri="ldaps://ldapuri", binddn="", password="")
ds.open()
from lib389.config import Config
dsconfig = Config(ds)
dsconfig.set('nsslapd-port', '389')
Alternately, we have another interface that *is* stable and we strongly commit to keeping it the same - our cn=config and ldap interface that you can directly modify.
Regardless, as a project we need to discuss what level of CLI interface stability we want to commit to - today you must assume that it is *not* a commitment we are making.
>
>
> again, please take my point of view as a frustrated admin with too many tasks to do and too little beers to take on my free time (everything is closed right now in Mallorca :P)
I too was once upon a time, a frustrated admin with too many tasks and too little time. Some of the initial code for the python tooling you use today was written when I was in that role, and it's what inspired me to want to make this CLI better for human admins. But for programmatic tasks, you should always use a programming language like python. I used to use python to script satellite 5 via it's api for example.
And maybe it's hard/frustrating to hear today, because it seems like more work, but any process/progress is like that. For you to learn python would be a challenge in the short term, but long term it will pay off multiple times over.
Hope that helps,
>
>
> cheers,
>
> abosch
> -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona remitent. Abans d'imprimir aquest missatge, pensau si es realment necessari.
> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
