[Pulp-dev] pulp-admin changes for Pulp 3?

[Kodiak Firesmith]

Thanks Michael, that's useful information.

The primary thing I'd wanted to take a crack at is a useful method for
dumping repos into an ASCII multi-column table from one pulp server and
feed that ASCII data into a wrapper script that uses each line to re-create
a repo.

>From lurking on the list for a while, and from moving from host to host
myself, I've often wanted to be able to quickly populate a fresh Pulp
installation with repo defs without messing with mongo or doing an
import/export operation of any sort.

For the repo defs file I was planning on splitting the information for each
repo into the following columns, which will likely be stolen from the -vv
output of pulp-admin rpm repo list --detail:

{repo_id}  {feed_url}  {relative_url}  {serve_http}  {feed_key_needed?}
 {retain_old_count}  ...

...Then I'd just feed each repo def into a wrapper script for pulp-admin
rpm repo create.

This doesn't preserve repo path permissions or anything, but for that sort
of use case I'd be more likely to use my previously figured out backup /
restore method to transfer the repos.

Then again this might be a good opportunity for me to just give in and
continue learning Python and start messing with Requests.

Once we're on django-rest and things look like they will be stable for a
couple years I'll probably put in more effort on a DB-agnostic
server-to-server import/export method for populating Pulp servers that
captures things like path permissions and roles and such, which appears to
be a use case that others also might find to be useful.

 - Kodiak

On Thu, Feb 16, 2017 at 4:35 PM, Michael Hrivnak <mhrivnak at redhat.com>
wrote:

> The REST API will be completely different. It will be auto-generated using
> django-rest-framework, which brings a lot of advantages. It should be very
> consistent, compliant, well-documented, and we might even be able to
> auto-generate client libraries. That said, the core behaviors and concepts
> will be largely the same as Pulp 2, so migrating a client from 2 to 3 will
> mostly just involve using different URLs and different-but-similar data
> structures.
>
> As for pulp-admin, we're not sure yet how easy it will be to make it work
> with Pulp 3. But I think we're getting close to a point where we'll be able
> to give that a try and see if it floats. This much is certain: there is a
> broad desire to replace pulp-admin completely. Things like pretty-printing,
> error handling, inconsistent exit codes, and the sheer amount of vertical
> space it uses to render data are some of the most frequently-observed rough
> edges. It's not all bad, but we could do better. It's just a matter of
> finding the time to get it prioritized. If it looks like making pulp-admin
> compatible with Pulp 3 will be a lot of work, we're likely to redirect that
> effort into a new client that is more likable.
>
> So given those choices, if you're comfortable scripting against the API
> directly, that's what I recommend. Although you can get a lot done with
> just a little bit of pulp-admin, so even if you have to re-do that
> integration in the future, it may be worth it for the low up-front cost.
>
> If you want to talk in more detail about what you'd like to automate, we
> could certainly help weigh the options.
>
> Michael
>
> On Thu, Feb 16, 2017 at 4:09 PM, Kodiak Firesmith <kfiresmith at gmail.com>
> wrote:
>
>> Hi folks,
>> Do we know yet how much (if at all) there will be backward compatibility
>> in the command suite and/or REST API for Pulp 3?
>>
>> I'm considering writing more extensive wrapper scripts around pulp-admin,
>> but didn't want to blow too much effort on it if they would become useless
>> w/ Pulp 3 arrives.
>>
>> Thanks!
>>  - Kodiak
>>
>> _______________________________________________
>> 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/20170216/a245c3ab/attachment.htm>