On 03/23/2012 10:10 PM, Jay Dobies wrote:
On 03/22/2012 09:03 PM, Nick Coghlan wrote:
On 03/23/2012 04:20 AM, Jay Dobies wrote:
This is one of those things that annoyed us in the beginning and after a
while of never getting around to fixing it, we developed blinders and
don't even notice anymore :)
This sprint I'm looking to get login/logout functionality into the v2
client, I'll make sure I don't fall into the same trap again.
If you're replacing the client then I won't worry about raising the bug.
While I'll be using my custom client (which hooks into the v1 client
authentication code) for PulpDist 0.1.0, the new pulp-admin integration
hooks are definitely something I want to look at for 0.2.0.
If you're curious about how my custom Pulp v2 API client currently
works, the docs are here:
http://readthedocs.org/docs/pulpdist/en/latest/cli.html
Nice docs :)
Sphinx + readthedocs is a very nice combo to work with. (I'd like to do
a proper site for PulpDist at some point, but it's hard to justify the
time required when it's just me working on it)
It looks like you've reduced the create/add importer stuff to a single
step in init. I'm doing the same thing for the RPM client and ran into a
problem whose solution you might be interested in.
The create repo call is pretty easy to make succeed, there's very little
that can go wrong. The add importer call, on the other hand, has a lot
of potential to fail due to invalid config. When that happens, I was
left with a created repo but no importer on it and no desire to expose
to the user where that distinction lies.
Ah, thanks. My approach to handling that case is to actually use a
"create_or_save_repo" operation in the client - if the POST to the
collection fails, it tries a PUT to the pre-existing repo instead.
If the importer addition fails, the partially initialised repo does get
left around on the Pulp server, but a subsequent init call should work
anyway.
This is due to the fact that the "init" command is intended to handle
both initialising a site from scratch and updating the configuration of
an existing site, so it needs to cover the case of overwriting a
pre-existing repo regardless.
However, there's still assorted dodginess in the way that works (in
particular, "init" will never delete repos from a Pulp server, but will
still clobber their entries in the site metadata), so I have to revisit
it at some point. For the moment it's in the "good enough for now" bucket.
Either way, assuming the REST API distinguishes between "failed to
create due to bad config" and "failed to create due to an existing repo
by that name", a combined call should simplify that part of the client
quite a bit.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Engineering Operations, Brisbane
_______________________________________________
Pulp-list mailing list
Pulp-list@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list
