[Pulp-dev] Pulp CLI MVP User Stories

Mon May 21 13:56:03 UTC 2018

> that the CLI does no "single call" operations. Those are already handled
veyr well by httpie.

If a user wants for example to update an object
(repo/remote/distribution/etc), then they have to switch from the CLI to
httpie?

David

On Mon, May 21, 2018 at 9:43 AM, Brian Bouterse <bbouters at redhat.com> wrote:

> 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/5868d508/attachment.htm>