On 05/23/12 10:10 AM, Shawn Walker wrote:
On 05/22/12 02:29, Tim Foster wrote:
I think there's confusion here. Any time the API changes (that is, the
set of parameters passed into functions or new functions are added or
removed), we bump the version. The only difference is how the list of
compatible versions changes.
Ok. That change was in the last webrev.
...
src/modules/client/publisher.py:
...
lines 613, 630, 658, 674, 723, 739, 767, 784:
These functions have had their operating semantics changed
incompatibly; previously, they would match solely on the URI.
hmm...
Now objects have to match both on proxy and URI. That's not
right. If I call remove_origin() with a single URI, then it
should remove any origins with that URI regardless of proxy.
Look at __eq__ and __ne__ in RepositoryURI.
I disagree. It's not that the semantics have changed, it's that the
identifying features of an origin/mirror have changed.
This is not a compatible change; the removal functions no longer remove
an origin if you don't also specify a matching proxy; that seems wrong.
They no longer remove a proxied-origin.
(which btw. didn't exist before: the system-repository used to maintain
a list of which origins to proxy, and which to contact directly - it
always used the same proxy for every origin)
Before now, all we needed to identify an origin was its URI, because
that's the only property it had. (since ssl keys/certs are publisher
properties at present, rather than origin properties)
With that in mind, I can't imagine why I'd want to have both a proxied
and un-proxied version of an origin as a user. Whether we need to do
that for the system repository seems irrelevant to the user, and I think
this significantly complicates our interface.
It's nothing to do with the system repository. By allowing multiple
URIs with different proxy values, the transport gets to choose the
optimum route to a repository - either directly, or via the proxy.
The intent here was, that say we had a custom proxy cache that had
cached some, (but perhaps not all) content, that we could take advantage
of that cache, but ultimately allow us to fall back to the direct route
if the cache itself had a slower route to the repository than we did,
for whatever reason.
The API and user interface both need to continue to work as they used to
here; if you specify an origin to remove, then remove the matching
origin. It also shouldn't be possible to have both a proxied and
unproxied version of the same origin.
Please rework this.
Groan.
Could I get a 2nd opinion please? I'll rework this if there's
consensus, but I spent a lot of time trying to get origins identified by
more than just their URI. In some places we were using the objects,
other places we were using just the string, it was pretty ugly imho, and
I've got it in a much better state now.
Looking ahead to when we have per-origin keys/certs, how do we treat them?
Should we allow users to configure multiple origins with the same URI
but different keys/certs [ a use-case: a key/cert pair will expire in a
few days, and the user wants to add a new key/cert pair now that doesn't
become valid till the old one expires. ]
Do we simply not support that, or go ahead and allow duplicate URIs with
different properties - the groundwork for that support is right here in
this changeset.
I didn't see anything in here to update .p5i to allow proxy to be
specified. How do you want to handle that?
I think we had this conversation before, I was initially thinking about
adding the proxy to the p5i format, but it was suggested that this could
be a bad idea:
http://mail.opensolaris.org/pipermail/pkg-discuss/2012-March/028807.html
suggesting that a server shouldn't be able to specify the proxy used for
its clients (unless I'm misunderstanding your question?)
Well, certainly it's a bad idea for the *server* to use p5i information
to do that, but as a general mechanism for moving transport
configuration from system to the next, I think it's desirable.
Ok, I'll see if I can dig up that work, and put it back in.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
