[Pulp-dev] Pulp CLI MVP User Stories

[Jeff Ortel]

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 <dawalker at redhat.com 
> <mailto:dawalker at 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 <jaudet at redhat.com
>     <mailto:jaudet at 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 at redhat.com <mailto:Pulp-dev at redhat.com>
>         https://www.redhat.com/mailman/listinfo/pulp-dev
>         <https://www.redhat.com/mailman/listinfo/pulp-dev>
>
>
>
>     _______________________________________________
>     Pulp-dev mailing list
>     Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>     https://www.redhat.com/mailman/listinfo/pulp-dev
>     <https://www.redhat.com/mailman/listinfo/pulp-dev>
>
>
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180518/7759ed49/attachment.htm>