<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 03/08/2018 11:13 AM, Austin
      Macdonald wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+Kyt=ooCh2q7VgjQysEK9dh+VRtGktiXNN29A-PGX47LpUO-A@mail.gmail.com">
      <meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">Motivation:
        <div>The name "importer" carries some inaccurate implications. </div>
        <div>1) Importers should "import". Tasks like "sync" will do the
          actual importing. The object only holds the configuration that
          happens to be used by sync tasks. </div>
        <div>2) Sync tasks on mirror mode remove content as well as add
          it, so "import" isn't quite right.</div>
        <div><br>
        </div>
        <div>Proposed name: Remote</div>
        <div><br>
        </div>
        <div>The inspiration for remote is "git remote". In git, remotes
          represent external repositories, which is almost exactly what
          our importers do. <br>
        </div>
      </div>
    </blockquote>
    I'm fairly apathetic to a name change.  It would be annoying to us
    in katello land, but not really a huge deal either way.  I don't
    think importer a bad name, as it does hold configuration around
    'importing'.  the fact that it itself doesn't actually do the
    importing is a technical detail and really isn't a big deal IMO.  
    User's likely wouldn't care, but for developers i guess its just
    weighing a more 'perfect' name to the work of changing everything
    (including documentation) at this stage. <br>
    <br>
    <blockquote type="cite"
cite="mid:CA+Kyt=ooCh2q7VgjQysEK9dh+VRtGktiXNN29A-PGX47LpUO-A@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        <div>-------------------------------------------------------</div>
        <div>Part 2: Trim the fields</div>
        <div><br>
        </div>
        <div>Currently, Importers have settings that can be categorized
          in 2 ways. I am proposing removing the "sync settings" from
          the Remote model:</div>
        <div><br>
        </div>
        <div>External Source information</div>
        <div>    name<br>
        </div>
        <div>
          <div>    feed_url</div>
          <div>    validate</div>
          <div>    ssl_ca_certificate</div>
          <div>    ssl_client_certificate</div>
          <div>    ssl_client_key</div>
          <div>    ssl_validation</div>
          <div>    proxy_url</div>
          <div>    username</div>
          <div>    password</div>
          <div><br>
          </div>
          <div>Sync settings</div>
          <div>    download_policy</div>
          <div>    sync_mode</div>
          <div><br>
          </div>
          <div>This had some advantages when Importers were related to
            Repositories. For example, having a repository.importer that
            always used the same sync mode made sense. However, the
            "how" to sync settings don't make much sense when importers
            and repositories are not linked. It seems very reasonable
            that a user might have 2 repositories that sync from the
            same source (ex EPEL). It does not make sense for them to
            have create an Importer for the EPEL repository twice or
            more just to change sync_mode or download policy. Instead of
            modeling these fields, I propose that they should POST body
            parameters.</div>
          <div><br>
          </div>
          <div>example</div>
          <div>   </div>
          <div>POST v3/remotes/1234/sync/ repositorty=myrepo_href
            sync_mode=additive, dl_policy=immediate</div>
          <div>
            <div>POST v3/remotes/1234/sync/ repositorty=myother_href
              sync_mode=mirror, dl_policy=deferred <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    So as a user using some future cli, i have to magically 'remember'
    these values?  If so, that seems like a bad user experience and
    kinda defeats the purpose of pulp holding configuration.  Could it
    be stored on the repository itself (or somewhere else) if it doesn't
    make sense to store on the importer/remote?   <br>
    <br>
    If you're serious about this, this would be something to ask current
    users of pulp as it seems kind of a big deal. <br>
    <blockquote type="cite"
cite="mid:CA+Kyt=ooCh2q7VgjQysEK9dh+VRtGktiXNN29A-PGX47LpUO-A@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div><br class="gmail-Apple-interchange-newline">
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Pulp-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>