Responses inline. David
On Wed, Jun 10, 2020 at 4:07 PM Robin Chan <rc...@redhat.com> wrote: > Sorry to bring back this thread, but I am thinking through some > operational aspects and want to make sure that my assumptions are correct > and won't impact things later on (have been accounted for in the design). > > 1. Any documentation requirements? Since there are both core and plugin > commands. A user on a pulp instance would be able to find out what commands > are available to them (in other words not needing to know which plugins are > installed). Perhaps being able to ship/make available this same information > as an actor knowing which plugins I am shipping (or should be there). > I had imagined that the CLI would be mostly self-documenting with help screens to display commands and their options, etc. but I think documenting CLI workflows would be really helpful. Going through and providing docs for every command would be painstaking to write and maintain unless we could automate it. > > 2. I can see an operator wanting to update or patch the cli > without changing other pulp software - so I'm assuming this is a separate > deliverable or would this be just part of core/plugins? If they are > separate I guess a new cli may be released when needed but if not pulp > software can continue to be updated. My brain can't put together the words > to describe that dependency relationship, but hopefully that workflow is > clear. > Yes, I think the CLI would be a separate deliverable which would be released independently of pulpcore/plugins. That way, for example, you could install the CLI on a system to control a remote Pulp instance without having to install Pulp. > > I'm coming from a mindset that a minimal set of commands might be > available initially and that it will be easy to add new ones as the need > becomes clear and patch a system without causing concern that other things > are changed. However I do see this might be a short term problem to solve. > > > On Mon, May 11, 2020 at 3:21 PM Brian Bouterse <bmbou...@redhat.com> > wrote: > >> I think having the commands namespaced by the plugin name would be an >> organized way to see what capabilities a given plugin is shipping. I >> imagine for pulpcore's commands they could be namespaced under 'core' or >> 'pulpcore'. >> >> Also +1 to 'pulp' command name. >> >> On Mon, May 11, 2020 at 6:42 AM David Davis <davidda...@redhat.com> >> wrote: >> >>> In some places, the API in Pulp 3 is very different from Pulp 2 but >>> where it's possible and makes sense, I think we will want to do this. >>> Perhaps this is a good argument for having plugin name after the "pulp" >>> command (eg "pulp rpm ...", "pulp file ..."). >>> >>> David >>> >>> >>> On Thu, May 7, 2020 at 8:47 AM Konstantin M. Khankin < >>> khankin.konstan...@gmail.com> wrote: >>> >>>> Is it an option to keep the Pulp 2 CLI syntax as much as possible? >>>> >>>> чт, 7 мая 2020 г. в 15:28, Dennis Kliban <dkli...@redhat.com>: >>>> >>>>> On Thu, May 7, 2020 at 7:13 AM Tatiana Tereshchenko < >>>>> ttere...@redhat.com> wrote: >>>>> >>>>>> +1 to `pulp` command. >>>>>> >>>>>> I think for me as a user, the most logical would be to have a plugin >>>>>> name first and then follow the URL pattern. >>>>>> The majority of commands are plugin specific. If I work with multiple >>>>>> plugins, it also makes it easy for me as a user to just change the plugin >>>>>> name in front for the commands which have the same structure in different >>>>>> plugins. >>>>>> It also makes it visually clear that I work with a specific plugin, >>>>>> in comparison to when the plugin name is somewhere in the 3rd/4th place. >>>>>> It will also allow not to guess in commands like the `pulp >>>>>> repositories rpm rpm` which one is the plugin name and which one is a >>>>>> repo >>>>>> type. >>>>>> >>>>>> I agree that this would make much more clear to the user which 'rpm' >>>>> is the plugin type and which 'rpm' is the resource type. >>>>> >>>>> >>>>>> +1 for >>>>>> pulp rpm content packages >>>>>> pulp rpm repositories rpm >>>>>> pulp rpm repositories mirror >>>>>> ... >>>>>> >>>>>> On Wed, May 6, 2020 at 7:58 PM Dennis Kliban <dkli...@redhat.com> >>>>>> wrote: >>>>>> >>>>>>> On Wed, May 6, 2020 at 12:30 PM David Davis <davidda...@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Matthias and I met today to go over some plans for a prototype. I >>>>>>>> wrote some notes[0] down. As part of the prototype, we'd propose two >>>>>>>> deliverables (one this week and one next week): >>>>>>>> >>>>>>>> 1. A set of ~2-3 click commands that use the bindings to interact >>>>>>>> with Pulp >>>>>>>> 2. Some openapi-generator templates that will be able to generate >>>>>>>> such commands from the schema >>>>>>>> >>>>>>>> There is a question we had about how the commands for typed >>>>>>>> resources will be structured in the CLI. To illustrate with two >>>>>>>> endpoints: >>>>>>>> >>>>>>>> >>>>>>> We should call the command 'pulp' instead of pulp-cli. >>>>>>> >>>>>>> >>>>>>>> # rpm.package content (/pulp/api/v3/content/rpm/packages/): >>>>>>>> - pulp-cli rpm content packages ... >>>>>>>> - pulp-cli content rpm packages ... >>>>>>>> - pulp-cli rpm packages content ... >>>>>>>> - ??? >>>>>>>> >>>>>>> >>>>>>> I was thinking we should structure the commands similar to the URLs >>>>>>> in the REST API. >>>>>>> >>>>>>> pulp content rpm packages >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> # file.file repositories (/pulp/api/v3/repositories/file/file/): >>>>>>>> - pulp-cli file repositories file ... >>>>>>>> - pulp-cli repositories file file ... >>>>>>>> - pulp-cli file file repositories ... >>>>>>>> - ??? >>>>>>>> >>>>>>>> pulp repositories file >>>>>>> >>>>>>> Plugins that provide multiple types of the same resource would need >>>>>>> to be more descriptive. Though I can see a practical reason for >>>>>>> requiring >>>>>>> all resources to be that descriptive. >>>>>>> >>>>>>> pulp repositories rpm rpm >>>>>>> pulp repositories rpm mirror >>>>>>> >>>>>>> >>>>>>> >>>>>>>> [0] https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig?view#Prototype >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Apr 30, 2020 at 1:42 PM David Davis <davidda...@redhat.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Today we met to discuss some ideas for a technical design for how >>>>>>>>> the CLI would work. Here's a copy of our notes: >>>>>>>>> >>>>>>>>> https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig#Technical-discussion >>>>>>>>> >>>>>>>>> And there is a rough design in the document as well: >>>>>>>>> >>>>>>>>> https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig#Design >>>>>>>>> >>>>>>>>> I have also entered the CLI user stories from our meeting last >>>>>>>>> week into redmine under the Pulp CLI project: >>>>>>>>> >>>>>>>>> https://pulp.plan.io/versions/93 >>>>>>>>> >>>>>>>>> And I've filed a user story that we talked about today that would >>>>>>>>> handle sync, publish, and distribution of repos. Feedback welcome: >>>>>>>>> >>>>>>>>> https://pulp.plan.io/issues/6626 >>>>>>>>> >>>>>>>>> Matthias and I are planning to meet next week to look at creating >>>>>>>>> a proof of concept that would provide 2-3 commands. If anyone is >>>>>>>>> interested >>>>>>>>> in joining us, please let me know and I can add you. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Apr 28, 2020 at 8:06 AM David Davis <davidda...@redhat.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I've also started working on some questions about how the CLI >>>>>>>>>> will work. Feel free to add some of your own: >>>>>>>>>> >>>>>>>>>> https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig?view#Technical-discussion >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Apr 28, 2020 at 8:05 AM David Davis < >>>>>>>>>> davidda...@redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> I have set up a meeting to discuss the CLI technical design. >>>>>>>>>>> Below are the details. I think a video conference might be easier >>>>>>>>>>> for >>>>>>>>>>> technical discussion but am open to consider meeting on >>>>>>>>>>> #pulp-meeting again. >>>>>>>>>>> >>>>>>>>>>> URL: https://meet.google.com/vgx-bzbb-wnh >>>>>>>>>>> Date/time: April 30, 2020 at 9:00am ET (1pm UTC) >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Apr 24, 2020 at 10:29 AM David Davis < >>>>>>>>>>> davidda...@redhat.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Today we met in #pulp-meeting on freenode to discuss the user >>>>>>>>>>>> stories for a Pulp 3 CLI MVP. The document with the user stories is >>>>>>>>>>>> available below. I'd like to ask for any feedback from users or >>>>>>>>>>>> plugin >>>>>>>>>>>> writers. >>>>>>>>>>>> >>>>>>>>>>>> The goal of the CLI MVP is to cover the pulp_file happy path >>>>>>>>>>>> (sync, publish, distribute) and make it possible for plugin >>>>>>>>>>>> writers to >>>>>>>>>>>> generate and write their own commands. I'm imagining that plugins >>>>>>>>>>>> will >>>>>>>>>>>> release their own sets of CLI commands after we complete the >>>>>>>>>>>> initial MVP. >>>>>>>>>>>> >>>>>>>>>>>> https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig >>>>>>>>>>>> >>>>>>>>>>>> Feedback is welcome. I plan to enter these user stories into >>>>>>>>>>>> redmine next week. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>> Pulp-dev mailing list >>>>>>>> pulp-...@redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> pulp-...@redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>> _______________________________________________ >>>>> Pulp-list mailing list >>>>> Pulp-list@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-list >>>> >>>> >>>> >>>> -- >>>> Ханкин Константин >>>> _______________________________________________ >>>> Pulp-list mailing list >>>> Pulp-list@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-list >>> >>> _______________________________________________ >>> Pulp-list mailing list >>> Pulp-list@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-list >> >> _______________________________________________ >> Pulp-dev mailing list >> pulp-...@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >
_______________________________________________ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list