[Pulp-dev] Pulp CLI MVP User Stories

Mon May 21 13:43:57 UTC 2018

I want to share my take on the httpie versus CLI question. Overall I think
the CLI should only support workflows and here's why. When the user is
providing the data, httpie provides a great tool for that data to be input
either via args (just like a cli) or via json snippets. The hallmark of
this usage is that the user already knows the data and can easily form a
httpie call with CLI args, or the json data file. User's don't have to be a
"programmer" to do this. The tool already exists.

Contrast that httpie usage against a "workflow" tool. The hallmark of the
workflow tool is that it's using data from one response and feeding it into
the next or a future call. Without a workflow tool, for a non-programmer
user, parsing a response and then feeding it into a future call will always
be a manual, errorprone, copy-pasta process. I think this is where the
sweet spot is for the CLI; it's for non-programmer-users, who would need to
take response data and feed it back into future calls which is hard for
them.

So for ^ reasoning I'm lead to these conclusions:

(1) that the CLI does no "single call" operations. Those are already
handled veyr well by httpie.
(2) I believe I'm +1 to not releasing Pulp3 with a CLI because I think that
would allow us to avoid guessing at requirements. If we wait a bit, the
users will declare what they want very clearly.

On Sat, May 19, 2018 at 1:31 PM, David Davis <daviddavis at redhat.com> wrote:

> Let me ask: could we ship the MVP with just a REST API? I don’t see any
> Pulp users clamoring at this point for a CLI or WebUI. It sounds like we
> are maybe trying to solve a problem that doesn’t exist at this point.
>
> Maybe we can focus on getting the MVP shipped. Then we can get feedback
> from the community as to what sorts of UIs and UI features they’d like to
> see.
>
>
> David
>
> On Sat, May 19, 2018 at 11:54 AM, Dennis Kliban <dkliban at redhat.com>
> wrote:
>
>> On Fri, May 18, 2018 at 3:54 PM, Dana Walker <dawalker at redhat.com> wrote:
>>
>>>
>>>> The pulp-admin CLI provided value not because it combined things but
>>>> because it managed auth and reduced syntax complexity.
>>>>
>>>
>>> Here's a (perhaps naive, please humor me) question--does it reduce
>>> syntax complexity enough over httpie to bother with at all?  Now that we
>>> have a Django app, would most users either a) be comfortable enough with
>>> the REST API or b) prefer to see an actual Django web UI instead of the CLI?
>>>
>>>
>> Most users of the CLI would probably prefer a UI. In situations where the
>> UI is limiting the interaction possibilities, the user would probably
>> prefer to use the REST API directly or via bindings for the language of
>> their choice.
>>
>> With that in mind, I think it is worth exploring adding the Django
>> Admin[0] site to Pulp. We could perform just a little bit of configuration
>> and expose all the models we are interested in exposing. The hard part
>> would creating templates for the sync and publish workflows.
>>
>> [0] https://docs.djangoproject.com/en/2.0/ref/contrib/admin/
>>
>>
>>> Just curious about the typical users.
>>>
>>> Dana Walker
>>>
>>> Associate Software Engineer
>>>
>>> Red Hat
>>>
>>> <https://www.redhat.com>
>>> <https://red.ht/sig>
>>>
>>> On Fri, May 18, 2018 at 1:30 PM, Jeff Ortel <jortel at redhat.com> wrote:
>>>
>>>> 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>
>>>> 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>
>>>>> 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
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pulp-dev mailing listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> 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/20180521/a05feca6/attachment.htm>