On 05/27/12 04:58 AM, Shawn Walker wrote:
On 05/23/12 16:58, Tim Foster wrote:
This brings me to something that wasn't accounted for in this set of
changes: composition.
Good point, I hadn't thought about composition (and address that in
general in the next mail)
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
So a new unit test is definitely needed for composition and proxied
sources. To trigger composition behaviour, you need two or more http
repositories configured as origins for a publisher that contain
different sets of packages. You should then set one of the origins to
be proxied, preferably with alternate proxy configurations, to verify
the results.
I could certainly write that..
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.
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.
[ item 2. above]
$ pkg set-publisher --no-refresh -G http://foo test
pkg set-publisher: Repository origin 'http://foo/' matches more than one
origin
To add to Danek's other comment, I would say that to the user that's not
another origin -- it's the same origin with different sets of configuration.
Ok.
So the error might be less confusing as "Repository origin 'http://foo/'
has multiple proxy configurations. To remove all configurations,
--proxy \* must also be specified."
...in short, try to lead them to the solution for removing all matching
proxy configurations. I'm not thrilled with that wording either, but
I'm looking for something else here.
Keep in mind that most of our users still think that publisher ==
repository == single uri. They're confused enough by the possibility of
composition as it is.
Yep. I'll talk a bit more in the next mail..
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
