Hi there,
I'm making good progress in getting us granular configuration of web
proxies, allowing some origins/mirrors use proxies set in the image, yet
still allowing others to contact repositories directly.
The current unit tests all pass with these bits now, and my manual tests
are also looking good, but I do still need to write new unit tests.
With these changes, older pkg bits reading new config files will fail to
proxy URLs, but will otherwise still function. However, I'm not sure
whether the changes here should really constitute an ImageConfig version
bump, and if so, what the consequences of that are? Perhaps a client
API bump as well?
The intent is to add two new properties, "origin_info" and
"mirror_info", each of which take a list of lists (tuples, maybe?). In
each element, we store the URI, and the proxy used to access that URI.
So in the pkg5.image config file, this looks something like:
origins = ['http://foo', 'http://bar', 'http://baz']
origin_info = [ ['http://foo', 'http://webcache:8080'],
['http://bar', 'http://www-proxy:80'],
['http://bar', 'http://www-proxy2:80'],
['http://baz', 'None'] ]
which translates to the the 'pkg publisher' output below:
timf@kura[36] pkg publisher
PUBLISHER TYPE STATUS URI
foo origin online proxy://http://foo/
baz origin online http://baz/
bar origin online proxy://http://bar/
bar origin online proxy://http://bar/
timf@kura[37] pkg publisher bar
Publisher: bar
Alias:
Origin URI: proxy://http://bar/
Proxy: http://www-proxy2:80
SSL Key: None
SSL Cert: None
Origin URI: proxy://http://bar/
Proxy: http://www-proxy:80
SSL Key: None
SSL Cert: None
Client UUID: 064cf0d2-7195-11e1-b4ab-d4bed990482b
Catalog Updated: March 19, 2012 07:28:07 AM
Enabled: Yes
We reuse the "proxy://" prefixes introduced with the system repository
work, as that seemed like the path of least surprise, though a -o option
to 'pkg publisher' would be nice to be able to display what the proxies
actually are, without the long form 'pkg publisher <pub>' output)
We allow duplicate origin/mirror RepositoryURI objects iff they use
different proxies. The thinking is, that transport could do optimization
if it has several paths to the repository. I've a bit of work yet to do
to make this work properly in client/transport/stats.py which currently
keys simply by URI alone)
Ultimately, we could the origin_info and mirror_info properties that are
stored per-origin/mirror (say to include ssl key/certs), but that's not
this webrev.
A draft of what I've got so far, which isn't ready for review, but might
be useful for context is at:
https://cr.opensolaris.org/action/browse/pkg/timf/draft-granular-proxies/draft-granular-proxies-webrev/
I'd appreciate any comments people might have on the approach here (even
if they're "Wait, stop - are you mad!?") In the meantime, I'll get
started on the tests.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
