[Pulp-dev] Pulp CLI MVP User Stories

[David Davis]

Overall, I am hesitant to start with complex CLI commands. Instead I had
hoped to start with basic, auto-generated CLI commands which we could then
build off to add more complex commands in the future.

Questions/responses inline though.

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 think this may be true for the first iteration of the CLI, but successive
iterations will handle more complex use cases.


> 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.
>
> How would users do things like update objects? Like what if I want to edit
the URL I am syncing a repo from?


>
> 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.
>

I think this is very brittle given the mutability of object names. Users
couldn’t use both the CLI and REST API. They’d have to pick or choose or
else run the risk of disconnecting objects.

Also, how do we support things in the future like multiple remotes for a
repo or shared remotes between repos?


>
> 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
>
>
>
>
>
A couple more questions:

How would we handle things in the future that are plugin-specific like
content upload/creation?

Also, would this CLI use auto-generation at all? Or would it rely entirely
on custom code? I assume the latter which means this would be similar to
the Pulp 2 CLI in which every new API change required a change to the CLI
code.


David

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
>>
>>
>
> _______________________________________________
> 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/4421d9e6/attachment.htm>