Make export/import process simpler for CLI

[gerrod3]

Users should be able to export the repositories they want in one command and shouldn't need to know the difference between 'export' and 'exporter'. I propose we remove the 'export' commands and re-brand them under 'exporter'. Exporter should get two new subcommands: 'export' and 'history'.

The 'history' command would get three subcommands from the original 'export' command: 'list', 'show', and 'delete'. Export objects are basically history records of previous exports and thus would fit nicely under this context. If a user doesn't specify a subcommand when using 'history' the default behaviour should be 'list' so they can see all the export objects aka the history.

The new 'export' sub command will take over the original export's 'run' command. This command will have extra functionality to allow for the creation of an exporter so the whole process can be done in one command.

Examples:

with Exporter named foo:

$pulp exporter pulp export --name foo [export options]
Started export task. Task href: ...

with no Exporter:

$pulp exporter pulp export --base-path tmp/exports/ --repository file_repo file --repository rpm_repo rpm [export options]
Would you like to save these configurations? [y/n]
$y
Please give a name to the exporter config options:
$bar
Config options saved in exporter object bar
Started export task. Task href: ...

If the user would specify 'no' on saving the config options, the command would give the created exporter a default name. The other commands under 'exporter' should have their help descriptions updated to reflect the exporter's role as a config object.

A similar process should be applied to the 'importer' commands so that the experience is consistent.

[mdellweg]

I like the fact that the "exporter" can "export" and the result is an "export". This is like the "repository" can "sync" and the result is a "repository version".

[gerrod3]

So is that a +1 or -1 for the design? Using your example the repository version commands are under the repository command and I'm proposing we do a similar thing and place the export commands under the exporter ones.

I like the fact that the "exporter" can "export" and the result is an "export".

I don't like this. I think the wording is confusing when you use "export" to mean a verb and noun which is why I want to change the wording within the commands.

[daviddavis]

FWIW, I've always used the noun when working on the API due to the RESTful architecture (ie users create/read/update/delete exports). I have no objection to using the verb in the CLI but I think hiding exports will be difficult (and perhaps even unwise).

[mdellweg]

OK what about the "exporter" has a command "run" and the result is an "export"?
Whether we want to list and view and delete exports as a subcommand group of exporter is probably another question.

And yes, that was a +1...

[dkliban]

How about the following commands?

Create an exporter:

pulp exporter pulp create --name foo

Create an export:

pulp exporter pulp run --name foo

List exports:

pulp exporter pulp exports list --name foo

Delete an export:

pulp exporter pulp exports destroy --href <export href>

[mdellweg]

I still kind of dislike the pulp exporter pulp part, but i think i need to live with it for the time being. The rest looks good. Would the importer commands look similar?

[dkliban]

Yes, the importer commands would follow the same pattern.

[ggainey]

We have a new export/er type, FilesystemExporter/FilesystemExport. I tried to capture the above discussion, and roll in the implications of "we have another type", into a doc here : https://hackmd.io/@ggainey/import-export-cli

I'm proposing to close #619 and address it along with changing/cleaning up the CLI interaction w/ import/export under this issue.

Feel free to comment here or on the linked doc with suggestions.