[Pulp-dev] Pulp CLI MVP User Stories

Sat May 19 17:31:55 UTC 2018

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180519/e9f363b2/attachment.htm>