[Pulp-dev] Pulp3 MVP Refinement Next Steps
bbouters at redhat.com
Fri Mar 10 17:31:15 UTC 2017
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 .
Maybe someone wants to create a wiki page with these ideas?
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.
> On Fri, Mar 3, 2017 at 2:50 PM, Mihai Ibanescu <mihai.ibanescu at gmail.com>
>> 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
>> 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
>> 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>
>>> I received positive feedback from the MVP 'Authentication' refinement
>>> call this past Tuesday. We produced this revised section . We also
>>> produced a "3.1+ post MVP ideas list" here .
>>> 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
>>>  by 10PM UTC on Monday March 6.
>>> : https://pulp.plan.io/projects/pulp/wiki/Pulp_3_Minimum_Viabl
>>> : https://pulp.plan.io/projects/pulp/wiki/31+_Ideas_(post_MVP)
>>> : http://doodle.com/poll/7v2kzi7p6gruzvdv
>>> 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