On 05/27/12 16:48, Tim Foster wrote:
On 05/27/12 04:58 AM, Shawn Walker wrote:
On 05/23/12 16:58, Tim Foster wrote:
...
As far as I can tell, with the current
implementation, composition breaks as soon as a proxy is configured for
one of the origins. This is because composition was designed with the
assumption that RepositoryURI objects (origin objects) for a publisher
can be matched solely based on URI. And that only one object would have
a matching URI.
If you look at pkg.client.image.Image.get_pkg_repo(), you'll see that it
checks for all pub.repository.origins that have a matching URI by
performing an 'x in list'-style check. Since __eq__ has been completely
changed in pkg.client.publisher, this no longer works as expected.
Are you sure? In the gate, we have modules/client/image.py with
2776 pub = self.get_publisher(prefix=pfmri.publisher)
2777 repo = copy.copy(pub.repository)
2778 norigins = [
2779 o for o in repo.origins
2780 if o.uri in slist
2781 ]
so that will still work because we're selecting by o.uri
You're right; I had misread that, and I just finished checking through a
bunch of other paths second-guessing whether alternate sources +
composition worked as I expected.
...
The other issue (which I touched on briefly in my other reply) is that
pkg.client.publisher for catalog composition purposes assumes that all
repository.origins for a publisher are reachable. So multiple proxied
sources doesn't make much sense with our current architecture, since the
only reason I can see to do that is because sometimes different proxies
are needed to reach an origin.
My reason for wanting duplicate URIs with multiple proxies was really to
try to take advantage of the transport for unusual network
architectures, having it pick the fastest route, auto-tuning if a given
proxy wasn't able to access the upstream repository as fast another (or
our direct) direct route was.
If that seems like a far-fetched requirement (I admit, it is) the other
thing that's been in my mind while working on this, is that every time I
consider "proxy" as an origin property, I've also tried to think about
what happens when we have multiple SSL keys/certs with the same URI, and
that doesn't seem as far-fetched as multiple proxies for a given URI.
And that brings up the next "fun" point. If and when we support
key/cert specified at the origin level, is the user going to have to
manage the key/cert at per-origin, per-proxy level instead? Also, I
wonder if any proxies can require their own key/cert to access in
addition to whatever is being proxied.
In addition, when multiple proxies are involved, content could differ,
and composition assumes that it can store and manage catalogs for a
publisher's origins based on a hash of the origin URI alone. Changing
that would require an incompatible image format rev.
Urgh - I definitely do not want to rev the image format.
So the primary concern is that different proxies could return different
responses depending on their caching mechanisms (or lack thereof).
That's why I'm concerned about the fact that composition currently
relies on URI as a unique identifier. If we want to allow for the
possibility of different responses for the same URI because of different
proxies, that would require some significant changes to composition.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
