[Pulp-dev] Pulp3 MVP Refinement Next Steps

[Mihai Ibanescu]

There is always an exception to everything, of course.

Metadata-only units (package_group for instance) require some special
attention.

I am not familiar with openapi/coreapi, I will need to read some docs.

Maybe instead of having a single pulp-admin that can do everything for
everybody, it covers all the common parts between all repository types and
units, and unit-specific things are extended via the REST API.

Otherwise, coming up with a command-line tool that is extensible may be a
bit too much.

I don't think there was disagreement that pulp-admin's CLI options are
unwieldy. Maybe starting with a proposal for re-organizing it would help
identify where the new-style extensions would drop in.

For instance, if we were to name it pulp-cli instead of pulp-admin:

pulp-cli repo {plugin-type} [create|update|list]
pulp-cli content {plugin-type} [copy|upload|search]

etc.

Then you may have drop-in plugins for handling repo/rpm/resolve which would
add a resolve option specific to rpm only.


On Fri, Mar 10, 2017 at 12:31 PM, Brian Bouterse <bbouters at redhat.com>
wrote:

> Mihai, David, It sounds like the CLI client runs entirely off of the
> server side definition. That sounds really great because the CLI installs
> with exactly 1 package and is always aware of the capabilities of the
> server.
>
> Since we are using Django Rest Framework for Pulp3, we can have the server
> produce openapi or coreapi descriptions of our API automatically so the CLI
> could just use that. I wonder if there is a coreapi or openapi CLI tooling
> that is Python based. Anyways, here are the related docs for DRF [0].
>
> Maybe someone wants to create a wiki page with these ideas?
>
> [0]: http://www.django-rest-framework.org/topics/api-clients/
>
> -Brian
>
> On Fri, Mar 3, 2017 at 4:09 PM, David Davis <daviddavis at redhat.com> wrote:
>
>> This is essentially what foreman and katello do, and it works great. They
>> get an json export of the REST API structure from the server and then map
>> each endpoint to a command and the parameters to options. One can still
>> override the default functionality for each command (or add extra commands)
>> but for most commands, there isn't any code required.
>>
>>
>> David
>>
>> On Fri, Mar 3, 2017 at 2:50 PM, Mihai Ibanescu <mihai.ibanescu at gmail.com>
>> wrote:
>>
>>> I am throwing this out there as a proposal, not necessarily to make it
>>> on the MVP list, only for people to tell me to take a hike. I like hikes!
>>>
>>> There is an incredible amount of boilerplate in setting up a pulp
>>> plugin. I would like to see this decrease as much as possible.
>>>
>>> For this iteration, I would like to bring up the admin client.
>>>
>>> Maybe I don't see the full picture, but it seems theoretically possible
>>> for the pulp admin client to function at a minimal level without having an
>>> admin extension installed. In my limited experience, it seemed like a lot
>>> of the information we put in an admin extension can be queried from the
>>> server.
>>>
>>> So my proposal would be: come up with a primitive set of operations that
>>> are provided by the admin client for all plugin types and all their
>>> implemented units.
>>>
>>> The operations could be:
>>> * Repository level: create, delete, enumerate/search; add distributors,
>>> edit importer configuration etc.
>>> * Content level: query, upload, delete, copy
>>> * Others I can't think of right now
>>>
>>> Those operations could be extended if the plugin supports a unique
>>> operation.
>>>
>>> Why am I bringing this up? Because the REST API was mentioned, and said
>>> API may have to be extended with additional information to enable the
>>> baselevel functionality of the admin client to work.
>>>
>>> /me preemptively goes for a hike
>>>
>>>
>>> On Fri, Mar 3, 2017 at 10:47 AM, Brian Bouterse <bbouters at redhat.com>
>>> wrote:
>>>
>>>> I received positive feedback from the MVP 'Authentication' refinement
>>>> call this past Tuesday. We produced this revised section [0]. We also
>>>> produced a "3.1+ post MVP ideas list" here [1].
>>>>
>>>> We plan to go through each section of the MVP, but I want to schedule
>>>> the four most time sensitive first. Time sensitive here means: "things we
>>>> need nailed down based on the order we will develop them in".
>>>>
>>>> Please identify the four most time sensitive areas in this doodle poll
>>>> [2] by 10PM UTC on Monday March 6.
>>>>
>>>> [0]: https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl
>>>> e_Product#Authentication
>>>> [1]: https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
>>>> [2]: http://doodle.com/poll/7v2kzi7p6gruzvdv
>>>>
>>>> Thanks!
>>>> Brian
>>>>
>>>> _______________________________________________
>>>> 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/20170310/a3b6fcbb/attachment.htm>