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). 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. 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-dev@redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> Pulp-dev@redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>> _______________________________________________ >>>> Pulp-list mailing list >>>> pulp-l...@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-list >>> >>> >>> >>> -- >>> Ханкин Константин >>> _______________________________________________ >>> Pulp-list mailing list >>> pulp-l...@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-list >> >> _______________________________________________ >> Pulp-list mailing list >> pulp-l...@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-list > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev