[Pulp-dev] [Pulp-list] Pulp 3 CLI MVP

Robin Chan rchan at redhat.com
Wed Jun 10 20:06:23 UTC 2020


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 <bmbouter at 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 <daviddavis at 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.konstantin at gmail.com> wrote:
>>
>>> Is it an option to keep the Pulp 2 CLI syntax as much as possible?
>>>
>>> чт, 7 мая 2020 г. в 15:28, Dennis Kliban <dkliban at redhat.com>:
>>>
>>>> On Thu, May 7, 2020 at 7:13 AM Tatiana Tereshchenko <
>>>> ttereshc at 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 <dkliban at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On Wed, May 6, 2020 at 12:30 PM David Davis <daviddavis at 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 <daviddavis at 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 <daviddavis at 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 <daviddavis at 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 <
>>>>>>>>>> daviddavis at 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 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-list mailing list
>>>> Pulp-list at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-list
>>>
>>>
>>>
>>> --
>>> Ханкин Константин
>>> _______________________________________________
>>> Pulp-list mailing list
>>> Pulp-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-list
>>
>> _______________________________________________
>> Pulp-list mailing list
>> Pulp-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-list
>
> _______________________________________________
> 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/20200610/abdfafcd/attachment.htm>


More information about the Pulp-dev mailing list