On Wed, Jun 29, 2011 at 08:02:58PM -0700, Tim Foster wrote: > Hi Ed, > > On Wed, 2011-06-29 at 17:45 -0700, Edward Pilatowicz wrote: > > On Wed, Jun 29, 2011 at 04:01:32PM -0700, Tim Foster wrote: > > > http://jurassic/~timf/sysrepo-errors-webrev > > > i don't understand the mako stuff, so hopefully someone else does. > > more comments below. > > ed > > Ok :-) > > > general > > > > - why are we allowing callers to set http_timeout? i'm wary of all the > > tunables we're exposing via smf. i realize we haven't commited to > > stability for these interfaces, so i guess we can change them at will, > > but do we really exepct folks to tune this stuff themselves? (and if > > so, won't they be angry when we come along and decide we know better > > and remove or change tunables?) > > Yes, I was nervous of this too and understand the concern. I'm not sure > how to reasonably auto-tune what the http timeout should be for checking > redirects. > > We've got a an SMF limit of 60 seconds for the start method at present, > but a user with slow connections to a bunch of repositories could > conceivably hit that while checking for http redirects, at which point > our service drops to maintenance, all packaging operations break for all > zones on the system, and non-booted zones won't be able to boot, which > feels severe. > > If we allow users to tune the timeout (assuming they don't still hit the > SMF timeout), the worst that happens is that only publishers which are > sitting behind redirects break, and we leave a trail in the SMF log > saying when that happens. Packaging operations would only fail for any > redirected publishers that had hit their http_timeout. > > Maybe we could use some computation based on how long Apache takes to > start on a typical system, subtracted from our 60 sec SMF start timeout > divided by the number of mirrors + origins times two (assuming one > redirect per URL - though we've no idea how many redirects there will be > at runtime, though urllib2 caps it at 10) I'll investigate whether it's > possible to decay (decrease) the timeout the more redirects urllib2 runs > across en route to the final destination, which might also help. > > That's all bit hand-wavy though, I can try it out, but better > suggestions are welcome :-/ >
i don't mind having private tunables for us to tweak and test with, but i'd rather not expose all those knobs to users. in the case above i'd recommend that the user: - increase the (already public) smf service start timeout - stop configuring repos that have so many redirects. :) ed _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
