[Pulp-dev] CLI team meeting notes
ipanova at redhat.com
Fri Sep 25 12:37:40 UTC 2020
Senior Software Engineer| Pulp| Red Hat Inc.
"Do not go where the path may lead,
go instead where there is no path and leave a trail."
On Thu, Sep 24, 2020 at 7:15 PM Brian Bouterse <bmbouter at redhat.com> wrote:
> On Wed, Sep 23, 2020 at 3:31 PM Robin Chan <rchan at redhat.com> wrote:
>> Robin Chan
>> 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.
>> On Wed, Sep 23, 2020 at 12:45 PM David Davis <daviddavis at redhat.com>
>>> ## 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.
> I agree that in the long run we don't want having everything in one
> package; given our recent experience with all the dependencies we have
> during the release process this will add yet another drop to the
> 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
> 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
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev