<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 04/22/2014 04:29 AM, Pavel Březina
      wrote:<br>
    </div>
    <blockquote cite="mid:53562855.6050603@redhat.com" type="cite">Hi,
      <br>
      I'm sending some patches that I'll use for OpenLMI provider. It
      supports few modifications of sssd.conf through augeas.
      <br>
      <br>
      For the moment, I think we should not bound to any particular API
      so even though I made it a separate object, I don't have any
      intentions to make it publicly usable library.
      <br>
      <br>
      This code will be used from D-Bus responder. I may extend the API
      if needed.
      <br>
    </blockquote>
    <br>
    <br>
    I have a conceptual problem with this approach. Sorry to throw the
    wrench when a lot of work has been done. But I have not seen this
    coming. I read there thesis and there was nothing about augeas
    there, actually there was nothing about the architecture of the
    actual management at all. That was one of the parts of my feedback.<br>
    <br>
    So why augeas? <br>
    <br>
    I thought that we will use the python API instead of doing it in C.
    That was the whole reason why i have not added this same capability
    to manipulate the configuration and save it.<br>
    <br>
    In general I think that if we want to do changes in C we should
    stick to libini_config and use it to make the modifications. <br>
    I see several reasons for that approach: <br>
    * we want one place to merge files and make modifications, if there
    are two unrelated pieces of code that do that we will have problems.
    We already have two we actually adding third: python, ding-libs
    merge code and now augeas<br>
    * we want to rely on the syntax checking in future. When this part
    is added you can not only validate the data coming from the config
    file but would also prevent modifications that can potentially lead
    to misconfiguration because you are sticking a logical value instead
    of string or number and vice verse.<br>
    <br>
    So I am strongly against bringing augeas without a higher level
    strategy here. I can see bringing augeas only if we try to
    consolidate on it in the long run but I am not sure it is the idea
    due to the two points above.<br>
    <br>
    I would say that adding the functionality to ding-libs is pretty
    trivial. I can tun around a patch pretty quickly if we decide to do
    it this way.<br>
    Something to discuss first though...<br>
    <br>
    Thanks<br>
    Dmitri<br>
    <br>
    <blockquote cite="mid:53562855.6050603@redhat.com" type="cite">
      <br>
      Unit tests are attached.
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.</pre>
  </body>
</html>