Hey Danek,
Apologies for the late reply - your mail got lost in my inbox.
On 03/20/12 08:47 AM, Danek Duvall wrote:
Looks exciting. Just a couple of comments ...
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?
Older clients would fail on those origins, anyway, right? I don't think
there's a compatibility issue sufficient to bump either version.
Ok - I've tested snv_151a with one of these config files, and yes, it
just doesn't see the additional proxied origins, it just sees a single
instance of an origin at a given URI and otherwise passes through the
contents of the origin_info property.
It becomes a little more complex if someone removes an origin with 151a
pkg bits, causing the origin_info property to become stale when viewed
on gate-tip bits. I'll try to deal with that gracefully.
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'] ]
Why a generic name like "info" for something so specific? Either
"origin_proxies" (or just "proxies"; why have separate ones for origins and
for mirrors?) or make "origin_info" be a dictionary that maps keys (such as
"proxies") to lists of tuples pairing URLs with their proxies, which can
then later be extended to have other keys (like key/cert like you point out
later).
Right was called "_info" because I was foreseeing other stuff eventually
being stored here. I was using a list of lists to try to keep the
config file format as simple as possible.
Talking to Shawn this week, he was eager for the config file format to
remain easy for humans to read/edit. I don't have a problem converting
to a dictionary instead, since at least there'd be key/value pairs,
rather than a mysterious list of ordered values - Shawn?
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/
I'm not thrilled with the proxy:// bit. I kinda see it for the ones which
go through the zone proxy, but I don't see why it's necessary here. I find
it confusing visually, and I don't believe there's any standard that makes
it acceptable for general use.
Sure - this was really to try to unify the "pkg publisher" output
between the global and non-global zones, and to disambiguate proxied
URIs from ones which we communicate directly with.
I'm happy to drop the "proxy://" prefix, but if I do that, I'd really
want to do it for both system publisher URIs as well as GZ publishers.
In that case, we get:
$ pkg publisher
PUBLISHER TYPE STATUS URI
foo origin online http://foo/
baz origin online http://baz/
bar origin online http://bar/
bar origin online http://bar/
Eventually we could add a -o flag to pkg publisher to allow two new
fields, "method" and "proxy" (we can bikeshed about those names later,
"method" feels wrong), then we could do something like:
$ pkg publisher -o publisher,method,uri,proxy
PUBLISHER METHOD URI PROXY
foo proxy http://foo/ http://webcache:8080
baz direct http://baz/ http://www-proxy:80
bar proxy http://bar/ http://www-proxy2:80
bar proxy http://bar/ -
Within a zone, we'd have:
root@test:~# pkg publisher -o publisher,type,method,proxy
PUBLISHER TYPE METHOD URI PROXY
solaris (syspub) origin proxy http://foo http://localhost:1008
How does that sound? I'd like to work on 'publisher -o' after this
putback, probably as part of 7133972 (and friends - we have a few -o
bugs/rfes) as though. With this putback proxy information would only be
shown in "pkg publisher <publisher>" output.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
