[Pulp-dev] CLI team meeting notes

Brian Bouterse bmbouter at redhat.com
Thu Sep 24 17:12:31 UTC 2020


On Wed, Sep 23, 2020 at 3:31 PM Robin Chan <rchan at redhat.com> wrote:

>
> Robin Chan
>
> She/Her/Hers
>
> Satellite Software Engineering Manager - Pulp
>
> Red Hat <https://www.redhat.com>
>
> IRC: rchan
>
> Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> <https://www.redhat.com>
>
>
>
> On Wed, Sep 23, 2020 at 12:45 PM David Davis <daviddavis at redhat.com>
> wrote:
>
>> ## Sept 23, 2020
>>
>> * [david] Finish CLI PoC demo and upload to asciinema
>> * Send out email to pulp-list about PoC?
>>     * Include asciinema
>>     * How to install, use CLI
>>     * Ask for feedback
>>     * Contact mcorr first and see what she recommends
>> * Should we meet regularly?
>>     * Meet again in two weeks
>>     * Hopefully have some user feedback
>> * We need a decision about where to have the cli code
>>     * it's not urgent.
>>     * for now, keep using a single repo
>>
> I was hoping someone would chime in here on what would be the cli
> experience of a plugin that isn't in the pulp org - say debian or chef?
> What would be simplest? Or is there an option that would be hard to change
> back the other way? This seems like a pretty important decision. I'd like
> to see some use cases or requirements that might help determine a decision
> or rule out any. And I'd like to hear from other stakeholders.
>
I agree simplicity is key. Here are some questions/thoughts I have to try
to determine what simple looks like

One question I have is: will plugins have custom commands. I suspect the
answer is yes because even if the CLI package itself is smart enough to
auto-produce all the generic commands from the API spec, I suspect in most
cases plugins will want "custom commands".

So if that's a yes, how will they ship those? While it's simple to add them
to the one CLI repo, it's complicated for users to get the "right" version
for them when it's all in one package. In fact that may be impossible. So
not as simple, but likely more usable would be for any custom CLI commands
to ship as a "CLI plugin package" aka a python package that will give extra
commands and have this auto-release when the plugin itself releases. What
wouldn't be simple is an additional repo for each plugin that would require
additional complexity at each plugin release.

The final question I wonder about is testing: How will CI be done on these
commands? My take is probably simplistic, but CI it anywhere plugin bits
are released from so if that's one main repo for the CLI CI those parts
there, and then CI any custom commands from repos where they are released
from.

This is what I was thinking about, but I am ok with anything the CLI teams
would be better or simpler.


>
>> * Supporting multiple versions of pulpcore and plugins
>>     * For now, use conditional statements when needed
>> * Versioning of the CLI
>>     * Needs more thought
>>
>> David
>> _______________________________________________
>> 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/20200924/031efc95/attachment.htm>


More information about the Pulp-dev mailing list