So it seems pretty clear to me this needs a bit more thought. Shawn Walker wrote:
> 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 > > * unreachable uri/proxy pairs for a given origin will cause connection > timeouts and could significantly delay initial transfers Seems like we need better handling for unreachable hosts, then, possibly as a prerequisite for this change. > * 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) How would the catalog responses be different? Different HTTP headers that could cause caching to be screwy or different payload? If the latter, then how would that happen aside from a broken proxy? Would this be a significantly different situation than pulling catalogs through the different proxies now? > 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. That would be pretty cool indeed, though not something I would think necessary for the first pass. > >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 still haven't looked at the code, so I may be off here. But I thought that Tim's change involved multiple RepositoryURI? objects, each with its own configuration, and the output of pkg publisher displayed them like that, but that the stored configuration was as you describe -- a single URI string, with multiple possible configurations. I agree that the UI (at least the display) isn't the best, but the output of pkg publisher has been, IMO, underwhelming for some time, so I'm not especially concerned about that. If I understand Tim's rationale for the multiple RepositoryURI objects was so that the statistics collection would allow the ones that weren't available to automatically fall out of contention. Would it be reasonable to have a single RepositoryURI object per origin, with multiple possible configurations, and let the stats collect at the config level, rather than at the origin level? That would let users continue to manage by URI. > 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. Yeah ... the packagemanager can't break because of this change. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
