On 05/22/12 16:15, Tim Foster wrote:
On 05/23/12 10:10 AM, Shawn Walker wrote:
[snip]
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.
Ok, here's a second opinion:
I think the way things are in the webrev are the right way to go. It
doesn't change things for the large percentage of users who won't ever
bother setting per-origin proxies. For the small subset of users who
desire to use this advanced feature, it gives them full flexibility for
options in how they configure their images. I see no reason that an
origin must be identified solely by it's uri, and I see potential
flexibility by changing that restriction.
Further, I completely agree that how we were identifying origins was a
mysterious and confusing hodge-podge and I found the structure Tim put
into place in this webrev to make things far easier and simpler to code
and understand.
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.
I'd suggest this be a separate put back. I can't see much of a reason
that p5i support must be there when the rest of this lands and I'd like
more time to think about the security and proper UI around when pkg
should and shouldn't respect a proxy set in a p5i file. We can say "a
server shouldn't put proxy into a p5i file", but once the slot for the
info is there, a confused publisher might do just such a thing.
Brock
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
