[389-devel] 389 DS nightly 2019-05-23 - 93% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/05/23/report-389-ds-base-1.4.1.2-20190522gita8bc2e3.fc29.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] On the command line tools ....
Hi all, I've had this thought and email in mind for a while, so I think it's time for me to write out some thoughts. I think there is a difference in the command line tools today from what I had envisaged, to what they became. Now of course, there are lots of reasons for this - Simon and Mark have done awesome work here, and the team picked up after my uhh ... "untimely eviction" we'll say, when I went through a lot of troubling personal issues. So you know, lots of <3 for the team being fantastic and patient with me despite my apparent insanity :) So I think what happened is that because I didn't expect this, communication didn't happen, I didn't support everyone and didn't communicate what I had in mind. I'm basically going to take this one on myself. What this has led to is a pretty different approach - where I took a task-oriented approach, Simon and Mark in the design of the new web-console have taken an attribute-setting approach. What does this mean? Let's take replication as an example: I would have created the tools to look more like: # Setup a first master dsconf instance_a replication initialise-topology # Join a second master, doing a re-init as needed and setting up replication managers etc. dsconf instance_b replication join-as-master --master instance_a # Join a third master ... dsconf instance_c replication join-as-master --master instance_a # Make sure the agreements between a-b-c are full mesh dsconf instance_a relication ensure-agreement instance_b dsconf instance_a relication ensure-agreement instance_c ... This could have actually been a different tool like dsrepl or something which may even be more expressive, to coordinate replication as a topology rather than per-server focussed. An attribute-setting approach though is more like (this is made up in my head, not reflective of current actual command, just for the point of ideological discussion): dsconf instance_a changelog init dsconf instance_a replication_manager create dsconf instance_a replica init --rid=10 dsconf instance_b changelog init dsconf instance_b replication_manager create dsconf instance_a replica init --rid=11 dsconf instance_a replication_agreement create --to=instance_b The point here - I have always wanted to make the tools abstract from the gory horrid details that exist in cn=config. Setting attributes by hand wasn't what I "envisaged". The goal of these tools was such that you never had to know about these attributes or objects at all. Now, people can always go an edit cn=config, I'll never stop that. If someone wants to use ldapmodify to admin their server, absolutely go ahead. But if I use a cli tool like this, I want it to abstract toward tasks that help me get my job done. I don't want to be an expert in remembering every single attribute on cn=replica, I want to just have two servers replicate. (sorry to bash-on replication, it's just a good example of a task that is reasonable complex to configure). For me this is hard emotionally, because I feel like lib389, and the ds* tools are really creations of my love and passion, to improve things in the ways I always wanted 389 to be as the product I want to use, and enjoy using. To make tooling that encapsulates all our amazing knowledge and experience inside of highly accessible commands. Which then leads me to be sad about how things turned out because it's not the way "I wanted" (again, I feel like this failure is my responsibility due to what happened last year, not the fault of anyone else - everyone else has done their absolute best). I would propose to change this - but I feel we are now wedged on change by two things: * Red Hat have documented these tools, and it's a big ask to get them to re-document everything. * The cockpit console uses these tools in a special --json mode ( I would have created a dscockpit command that just handled the --json mode, rather than trying to make a tool do two jobs well.). This means rewriting cockpit integration * Time - heaps of time has already gone into these tools now, can we really justify undoing all that effort for this? Which is a bit why I'm writing this - Should I stop my task-oriented-vision and complaining that I have been doing, and accept what we have today? - Do we want to try and pivot to change based on the ideas I have? - Do I build something in parallel to satisfy my selfish desires, and to supplement what we have? I don't know. But I think it's important to have this discussion as a team, including our emotional investments, concerns, visions and desires so that we can choose whats best. It's not good if we are "in-fighting" over the things we are doing, that helps no one - and neither does people feeling like their work isn't appreciated or respected (and I'm worried I have come off as disrespectful, which I am sorry for). We should be unified in what we want to do and achieve. So I'd appreciate advice here. What
[389-devel] Re: Logging future direction and ideas.
> On 22 May 2019, at 22:36, Ludwig Krispenz wrote: > > > On 05/17/2019 12:44 AM, William Brown wrote: > > I think this would be a "final goal", so to formalise the stages: > > * Add build tooling and a simple (dummy) log thread as a "getting started". > Supplement with documentation on wiki. > * Fill-in the log thread to support an "operation log", and add basic > operation log hooks in the server. > * Fill in more operation log points in the server to build detail > * change slapi_log_err to log to the new rust thread, continue to generate > error file > * change slapi_log_audit to log to the new rust thread, continue to generate > audit file > * change slapi_log_access to log to the new rust thread, continue to generate > access file. > * remove former logging code > >>> I wonder if we really could have one api eg slapi_log_* and different >>> implementations, keep the current, implement a new one and allow to chose >> I don't think I understand this comment, could you explain a bit more what >> you have in mind? > what I wanted to say is that right now for logging we have a split in "what" > and "how", a function wants to log something calls slapi_log_* and provides > the loglevel, type (_err, _access), and information (formatstring and > params). It does not know or care about log buffering, log rotation, they > could even all go to the same file, if it is a dedicated thread or > > If we want to change logging I would like to keep this separation, and if we > want to concentrate on performance we should first address the "how" part, > doin all together might be too big a task and too much work. And we would not > have to throw away the current impelmentation, it could be configured "how" > slapi_log _* perform theit task. Sounds good. I think (?) that we agree on the design and the approach to coding this then, including the configuring the "how". Perhaps to be more specific, you'd amend the goal as: > * Add build tooling and a simple (dummy) log thread as a "getting started". > Supplement with documentation on wiki. > * Fill-in the log thread to support an "operation log", and add basic > operation log hooks in the server. > * Fill in more operation log points in the server to build detail > * change slapi_log_err to log to the new rust thread, continue to generate > error file > * change slapi_log_audit to log to the new rust thread, continue to generate > audit file > * change slapi_log_access to log to the new rust thread, continue to generate > access file. ^ These three would become: * Add a configuration item for async or legacy log processing for the slapi_log_* types, default to "legacy". * Once more confident, default to "async" for slapi_log_* to use the new rust thread > * remove former logging code Is that what you had in mind? > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] Re: Logging future direction and ideas.
On 05/17/2019 12:44 AM, William Brown wrote: I think this would be a "final goal", so to formalise the stages: * Add build tooling and a simple (dummy) log thread as a "getting started". Supplement with documentation on wiki. * Fill-in the log thread to support an "operation log", and add basic operation log hooks in the server. * Fill in more operation log points in the server to build detail * change slapi_log_err to log to the new rust thread, continue to generate error file * change slapi_log_audit to log to the new rust thread, continue to generate audit file * change slapi_log_access to log to the new rust thread, continue to generate access file. * remove former logging code I wonder if we really could have one api eg slapi_log_* and different implementations, keep the current, implement a new one and allow to chose I don't think I understand this comment, could you explain a bit more what you have in mind? what I wanted to say is that right now for logging we have a split in "what" and "how", a function wants to log something calls slapi_log_* and provides the loglevel, type (_err, _access), and information (formatstring and params). It does not know or care about log buffering, log rotation, they could even all go to the same file, if it is a dedicated thread or If we want to change logging I would like to keep this separation, and if we want to concentrate on performance we should first address the "how" part, doin all together might be too big a task and too much work. And we would not have to throw away the current impelmentation, it could be configured "how" slapi_log _* perform theit task. ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
