[Pulp-dev] Pulp CLI MVP User Stories

Dana Walker dawalker at redhat.com
Thu May 17 17:38:23 UTC 2018


>
>
> The CLI will need to make some assumptions for the user: publisher name,
> distribution name, auto publish, auto distribute, and maybe others.


Are most of our users comfortable with these assumptions being made?

The goal for the CLI should be to reduce this to a single step.


+1 to this goal and the five new use cases listed, otherwise, what's the
point of doing the CLI work when HTTPie works.

Dana Walker

Associate Software Engineer

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

On Thu, May 17, 2018 at 11:52 AM, Dennis Kliban <dkliban at redhat.com> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180517/6f301e09/attachment.htm>


More information about the Pulp-dev mailing list