[Pulp-list] Pulp CLI + Reposync Patch

[Michael DeHaan]

Devan Goodwin wrote:
> Greetings pulp-list,
>
> Attached is a patch (in mbox format for git-am) introducing the
> beginnigs of a pulp CLI and a couple initial commands. It's still rough
> around the edges, not using persistent data and not ready for system
> installation. 
>
> Command line script is in scripts/ and I've been running it like so:
>
>     (root at elaine)[scripts] # PYTHONPATH=../ ./pulp repo --sync-all
>
> Commands supported:
>
>     pulp repo --list
>     pulp repo --sync-all
>
> There's only one repository hard coded currently (packagekit) for
> testing purposes.
>
> After running --sync-all you'll have a "utopia" repo in /tmp/repos/.
>
> The generated config.repo file doesn't look right yet and I really don't
> know what it should look like yet.
>
> Some questions:
>
> 1. How do we want to support persistent storage of these repositories?
> (i.e. pulp repo add stores data where?)
>
>   

I sooo haven't worked on this, so here's my thoughts just on the idea of 
integrating it together with Cobbler
at a later date (so Cobbler can get out of the business of maintaining 
all the repo mirroring code).

How about just something simple and INI file like?  I can't imagine the 
list of repos getting that unwieldy, and that would still
allow them to be programmatically edited.  We don't have to go the crazy 
YAML route, but something like that is very easy
to share over IRC if someone gets into trouble.

Though if we want the Pulp WebUI to access the repos from the command 
line, we may want something more databasey.

(Of course the Pulp WebUI could just use the Pulp CLI's backing library 
to access things...which seems fine too).

Cobbler's yaml thing is pretty darn weird, but we can support different 
serializers -- so there's YAML or bsddb or if someone
later wants SQL/LDAP technically they could do it.

> 2. Does it make sense to have pulp CLI in the same project (or
> ultimately RPM) as the pulp TG UI? Wanted to see what people thought of
> this before attempting any kind of installation code.
>   

Depends on the answer to the above I guess, but I can see the want to 
install it without TurboGears in some
configurations... still, TurboGears doesn't imply it has to have X and 
all that.  

You could have it in the same tree, maybe it just builds seperate RPMs.

> 3. Should pulp CLI configuration options (i.e. the REPO_STORAGE_PATH) be
> configured in the TG configuration file or a new one that will most
> likely end up in /etc?
>   
I'd vote for the latter.

A TurboGears config file seems WebUI centric for something that is going 
to be tweaked by a CLI or other
tools as a library (and maybe later by XMLRPC stuff?)

> 4. Is the patch in this state suitable for pushing to master so others
> can build on it or does some or all of the above need to be addressed
> and first and then the whole shebang resubmitted?
>
> Other work assignments now appearing so will have limited time to
> address issues in the next little while but will attempt to do so as
> much as possible.
>
>
> Cheers,
>
> Devan
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list