The main goal of the CLI is to make it easier (than using the REST API
and http) for admins to perform routine tasks. It seems likely that A
CLI /could/ provide an improvement by reducing the REST syntax
complexity without combining the steps to complete a task. Also, I
think we should consider the frequency of tasks & steps. For example: I
would anticipate that work flows involving creating and deleting of
repositories, remotes, publishers and distributions are performed with
relatively low frequency. And, each of those will likely happen with
different frequency. Work flows involving sync & publish would be
performed with relatively high frequency. Updating resources (perhaps
except Distribution) don't seem likely to be a regular thing.
My point is: I think that providing high level, task oriented,
combination CLI commands won't provide enough value to justify the
effort. An admin running (1) complex command (think pulp-admin) rather
than 3-4 simple commands does not seem like an improvement. Especially
since the CLI would probably need to provide the simple commands a well
for work flows not accounted for. For example: Edit a remote. Or,
would the admin need to use the REST API for that?
The pulp-admin CLI provided value not because it combined things but
because it managed auth and reduced syntax complexity.
On 05/17/2018 10:52 AM, Dennis Kliban wrote:
The use cases we outlined earlier provide very little value over using
httpie to interact with the REST API directly. I'd like to propose 5
new use cases:
* As a CLI user, I can create a repository, a remote, a publisher,
and a distribution with a single command.
* As a CLI user, I can create a repository version, a publication,
and update the distribution with a single command.
* As a CLI user, I can list remote types available on the Pulp server.
* As a CLI user, I can list publisher types available on the Pulp
server.
* As a CLI user, I can list all repositories available on the Pulp
server.
The use cases proposed at the beginning on this thread require the
user to perform 4 steps before any content can be synced:
1) Create repository
2) Create remote
3) Create publisher
4) Create distribution
The goal for the CLI should be to reduce this to a single step. The
CLI will need to make some assumptions for the user: publisher name,
distribution name, auto publish, auto distribute, and maybe others.
However, this will allow the user to use a single command to create a
repository that's ready for sync/publish.
Sync/Publish/Distribute workflow can also be 3 steps:
1) Create a new repository version
2) Create a new publication
3) Update distribution
The goal here is to also reduce this to a single step.
The other use cases are auxiliary.
Questions? Thoughts? Ideas?
-Dennis
On Mon, May 14, 2018 at 11:58 AM, Dana Walker <dawal...@redhat.com
<mailto:dawal...@redhat.com>> wrote:
+1
Dana Walker
Associate Software Engineer
Red Hat
<https://www.redhat.com>
<https://red.ht/sig>
On Tue, May 8, 2018 at 10:31 AM, Jeremy Audet <jau...@redhat.com
<mailto:jau...@redhat.com>> wrote:
A configuration file in the user's home dir, right?
Yes, exactly.
Can we make sure to avoid placing configuration files directly
in users home directories, and instead place them into
directories like ~/.config? This is in line with the XDG Base
Directory Specification
<https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>.
The spec is pretty straightforward, but Pulp Smash uses pyxdg
<https://www.freedesktop.org/wiki/Software/pyxdg/> to avoid
mistakes. There's two big benefits to doing this:
* Less clutter in home directories.
* Guidance on what to do with other types of files, such as
cached files and runtime files.
Projects such as git, htop, lftp, mpd, neovim, tmuxinator,
boybo, and more do this.
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
