[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] Pulp CLI + Reposync Patch

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
Command line script is in scripts/ and I've been running it like so:

    (root 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.




Pulp-list mailing list
Pulp-list redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]