On Tue, May 24, 2011 at 03:55:19PM -0700, [email protected] wrote: > On Wed, May 25, 2011 at 10:49:48AM +1200, Tim Foster wrote: > > Sure. One other solution might be to have the zone-proxy-client > > instances simply do nothing in the face of a missing connection to the > > zone-proxyd (perhaps it could write a single SMF log entry to that > > effect, but leave the client service online) > > That's certainly something that would be easy to implement. The > original idea was that the proxy clients would try for a time, but give > up eventually. That way the clients would survive a transient failure > of the proxy daemon, but go into maintenance if there was a > configuration problem on the system. It could be changed to simply try > to connect to the proxy daemon forever, but that would make it less > obvious that there's a problem with the rendezvous between the client > and daemon. >
i think that having the zoneproxy client fail (or enter maintenance) if it can't reach the zoneproxy server is the right thing todo. the zoneproxy is a transport, if the server half is missing the client service should report that by entering the maintenance state. now, given kristers previous fixes for updating the zone proxy server when the sysrepo config is updated, i think we're better off not refreshing the zoneproxy server. just leave that service running. if a user manually disables the sysrepo, well, they get what they ask for. i don't think the zones proxy service should enter the maintenance state. i think it's ok to just have pkg commands inside the zone fail. ed _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
