On 05/25/12 03:34 PM, Danek Duvall wrote:
Shawn Walker wrote:
I've asked Danek to respond to this, but here's my primary issue:
* I don't believe that most users are going to want to manage multiple
versions of the same origin
That is, I don't believe it's useful to support multiple proxies for a
single origin, and even if we can, I don't think the user wants to manage
each one of those as separate origins.
In the meeting, Bart brought up the canonical use case: a laptop that moves
between a proxied environment (inside) and a non-proxied environment
(outside), and wants to access external origins from both environments.
This would be very nice for Oracle folks who have homeunix.com or whatever
configured. It probably wouldn't matter for anyone whose company didn't
have a firewall policy from 1995.
Except that the transport system and the catalog composition work I did
isn't designed to support that kind of usage, at least it's not intended
to be squeezed into how origins/mirrors are currently structured and used.
So there are going to be a few very ugly failures possible with that
configuration:
* implicit refreshes and set-publisher operations will fail since one
of the origins is unreachable; because the implementation here is
creating unique RepositoryURI objects for each URI / Proxy pair
* composition can break because origin is considered the unique key
and now with the potential for a proxy to interfere with the output
catalog responses may not be identical, especially if both origins
are reachable (that is, same URI, different proxy configs)
* unreachable uri/proxy pairs for a given origin will cause connection
timeouts and could significantly delay initial transfers
If we really wanted to support that sort of configuration, we need to be
able to tie origins to a specific nwam location profile so that when
users move between networks, specific origins can be disabled/enabled
automatically.
I think given that we don't expect many people to use this, we shouldn't
expect many people to get confused by this. Fixed machines almost
certainly won't have any origins with more than one proxy, assuming they
have any proxy needs at all, and that probably covers 99% of our customer
base. And I'd guess that even for mobile machines, this is highly unlikely
to be used. But the complexity isn't ridiculous, and the flexibility
allows those few folks to do what they need.
I'm inclined to believe that multiple versions of the same origin may be
simply more rope :-(
We would need to make sure that any other metadata associated with origins
isn't added orthogonally to proxies -- that is, you shouldn't have to name
the full tuple of an origin's metadata in order to refer to it. That
suggests that users might need a way to name the configured origins. Right
now, that's effectively its proxy, but that's not a good handle going
forward.
But that's one of my primary issues here; to a user, they aren't
managing unique pairs of (origin, proxy). They're managing origins, and
there's a set of proxies and/or keys/certs they can use for that origin.
Only in our internal implementation is it practical to view them as
pairs and exposing that through the user interface at the CLI level
concerns me.
I'm also concerned that someone might not fix this in the packagemanager
before U1 ships; the changes made to the pkg.client.publisher API here
are incompatible. That is, as soon as you add proxied sources, the
current implementation breaks existing API consumers.
However, I will admit that if we actually want to support this, I don't
see good alternatives as some sort of identifier is necessary to be able
to manage them.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
