[Pulp-dev] Importer Name
austin at redhat.com
Tue Mar 13 22:43:42 UTC 2018
> On Mon, Mar 12, 2018 at 9:50 AM, Justin Sherrill <jsherril at redhat.com>
>> 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.
>> 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
> 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?
>> If you're serious about this, this would be something to ask current
>> users of pulp as it seems kind of a big deal.
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.
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev