On 05/27/12 17:08, Tim Foster wrote:
...
Fair enough, so as far as I can tell, the decision we need to take is:
1. don't allow multiple proxies per-URI, but introduce a precedent for
set-publisher to set origin-level properties, which we might break for
the next release
2. allow them, and live with the breakage
3. don't introduce this wad yet
At this stage, I'm leaning heavily towards 3. Given my question about
what it means to have multiple origins configured - that is, when are we
doing composition, and when are we allowing redundancy, it might be
useful to be able to do:
pkg set-origin --allow-failure --proxy http://bar http://foo
if we wanted the transport to not throw errors when http://bar was
unreachable, but simply move on to the next available URI configured for
that publisher.
(Danek please add to or correct anything here if needed.)
So feel free to respond to Danek and I, but we just spent some time
talking about this, and we think most of your work can go back for U1,
but there are some changes that need to be made. Please don't take
these as set in stone or design by fiat; feel free to respond with
concerns and work out alternatives:
In particular, it is believed that RepositoryURI is the wrong point of
abstraction for the proxy configuration information.
Specifically, this is (roughly) the model from the webrev:
Publisher
.repository
Repository
.origins = [
RepositoryURI
.uri = http://example.com
.proxy = http://proxy1
RepositoryURI
.uri = http://example.com
.proxy = http://proxy2
]
It is believed that this is the desired model instead:
Publisher
.repository
Repository
.origins
RepositoryURI
.uri = http://example.com
.proxies = [
ProxyURI (new object)
.uri = http://proxy2
]
This model accomplishes a few things:
1) allows storage of configuration to be done at the level of the
object that it's about instead of duplicating that information (for
example, storage and management of key/cert information)
2) makes the API changes backwards compatible with clients such as the
packagemanager (proxy configuration won't be visible, but won't be
lost, and removal of proxy by URI alone will continue to work)
To accommodate the above, the changes to the various remove_* and
update_* methods of pkg.client.publisher.Repository should be reverted.
(The .update_* methods are completely unused, I would go ahead and
update their docstrings to mark them as deprecated and then add a note
to client_api_versions.txt when doing so; we should remove them in the
future once we verify no other consumers are using them.)
As for the pkg.client.publisher.Repository add_* methods, I have a few
suggestions for possible (different) implementations:
1) the 'proxy=' parameter should become a 'proxies=' parameter that
can contain a list of either URI strings (which will be converted
automatically to ProxyURI objects) or ProxyURI objects
2) revert the changes to the add_* methods; implement
add_origin_proxy and remove_origin_proxy methods, etc. that accept
a origin URI and a proxy uri and any configuration info specific
to the proxy
3) revert the changes to the add_* methods; require API consumers to
simply provide complete RepositoryURI objects with appropriate
ProxyURI objects assigned already. Trying to squeeze a tiered
object structure info a flat set of parameters leads to tears
anyway.
However, while the proposed data model above allows for multiple proxies
per-origin, it is believed that until we find resolutions for some of
the various transport issues that are currently open, we should not
allow multiple proxies for the same origin (although the data model can
prepare for that possibility internally). So there should be some sort
of exception raised if an attempt to have more than one for a single
origin is made.
To make the above changes work with the rest of what you have, I would
then suggest you create a ProxiedURI object that inherits from
RepositoryURI and adds the .proxy, .runtime_proxy, and .key propeties
that you can use in the various transport modules.
pkg.client.transport __gen_repo can be changed to yield ProxiedURI
objects instead of yielding the normal RepositoryURI objects; these can
be created on the fly (and cached if necessary, although I don't think
it will be).
Finally, please note that Danek really only had feedback about the data
model (that is, the structure of the objects internally); the specific
implementation suggestions here are largely my own. They likely need
further vetting before implementation.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
