<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">On Mon, Mar 12, 2018 at 9:50 AM, Justin Sherrill <span dir="ltr"><<a href="mailto:jsherril@redhat.com" target="_blank">jsherril@redhat.com</a>></span> wrote:</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div><br></div></div></blockquote></span>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.<span> </span><br><span class="gmail-"><br></span></div></blockquote></blockquote><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">The reason for making this change despite it being "one more thing" is that the subtle changes we have already made changes the role of Importers significantly. When Importers were one-to-one with Repositories, it was reasonable to assume that sync_mode and download_policy would be the same for each sync. However, without that relationship, multiple repositories can "sync from" a single external source (hopefully modeled as a Remote) and I don't think it makes sense to assume that they will use the same sync settings.</span> </div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-"></span>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?  <span> </span><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.<span> </span></div></blockquote></blockquote><div><br></div><div>You are right about this problem, and while I want to change how this will work at a base level, it should eventually be abstracted for the end-user (more on this below). Unfortunately, the CLI usability problem will exist even if we leave the sync settings on the Importer/Remote. Objects in Pulp 3 are referenced *exclusively* by href, which uses a UUID (not natural key) and should not be generated by users. This is the main reason I have argued that we should not release an auto-generated CLI, because it would be (IMO) less useful than httpie. One long term partial solution to this is a CLI that bundles multiple commands. For instance, the user would specify repo and importer names and the CLI would retrieve the appropriate href from the rest api and then make the call. </div><div><br></div><div>A simpler option (-0 from me) would be just to move sync_mode from the Importer to the Repository, but I don't think this would play very well for repos that sync with multiple importers.</div><div><br></div><div>This doesn't address the concern of having to remember sync_mode though. For this issue, I have a couple of ideas. First is the possibility of repeating a task (briefly mentioned in the "Plugin relationship to tasks" thread). Another concept I've been considering is an option (again, inspired by git) to "set-upstream" for a repository. This would provide users a way to indicate that a particular repository is set up to sync from a particular importer/remote using particular settings.this</div></div></div></div>