Hi Ed, Thanks for taking a look,
On Mon, 2011-05-16 at 17:59 -0700, Edward Pilatowicz wrote: > On Fri, May 13, 2011 at 02:18:02PM +1200, Tim Foster wrote: > > http://cr.opensolaris.org/~timf/sysrepo-refactor-webrev/ > --------- > general > > - not this putback, but could pkg.sysrepo be updated to detect http > redirected repositories and fail in that case as well? I'm hoping to just fix that bug sooner rather than later (though yes, not this putback) If we detect redirected http repositories, I don't think it's much more work to simply add the correct RewriteRules into the httpd.conf. Hopefully not famous last words :-) > - you still reference the old zoneproxy pkg and svc names in a bunch of > places. Right, the webrev above was only the package renaming portion. I've got a new webrev that does the service renaming and everything else here (though I may have missed a few instances before, admittedly) http://cr.opensolaris.org/~timf/sysrepo-refactor-webrev-1 I've left the c-programs alone. > --------- > src/brand/common.ksh > > - please prefix service names with svc:// Fixed, but I'm using svc:/foo not svc://foo, unless you prefer svc://localhost/foo instead? > --------- > src/pkg/manifests/*.p5m > > - shouldn't the info.repository* attributes be automatically added via > some kind of pkg mogrify entries? (if there isn't a bug filed on this > perhaps there should be?) Yes, I've filed: 18362 We should have a transform to add info.repository_* values to the build and have included the fix in this webrev. > --------- > src/svc/svc-pkg-sysrepo > > - say that the global zones publisher configuration has been update and > hence a refresh has been triggered. but pkg.sysrepo fails because we > now have an unsupported repository. svc-pkg-sysrepo will return an > error, but it won't kill httpd or htcacheclean. so what happens in > this scenario? will smf kill them off for us? or will the continue > to run with an incorrect configuration? Good question. At this point in the pkg.sysrepo code, we've torched the old configuration, intending to write a new one, but haven't yet refreshed apache. Having dropped to maintenance, the httpd processes are still there, but won't respond to requests (due to the now-missing static syspub/0 response file) From Apache's point of view, proxying would still work, but here's why that alone isn't enough: Setting an unsupported publisher in the GZ and dropping to maintenance also results in the zones-proxyd service stopping, which causes the zones-proxy-client to try to restart in all zones, which eventually drops to maintenance too: [ May 17 15:16:06 Executing start method ("/usr/lib/zones/zoneproxy-client -s localhost:1008"). ] Timed out trying to reach proxy [ May 17 15:19:06 Method "start" exited with status 95. ] Fixing the problem by disabling that unsupported publisher in the GZ, then doing an 'svcadm clear system-repository' will start the zones-proxyd service again. If we fix the problem before any of zones have had their zones-proxy-clients drop to maintenance (that is, while they're still re-running their start method script, which has a long, 300 second timeout) the clients can then connect to the zones-proxyd and everything's rosy again. If not, despite fixing the problem in the GZ, we need to clear the maintenance state of each zone-proxy-client (one per zone) manually. I think setting an infinite timeout would be better for this client service, but would welcome comments. > --------- > src/pkg/manifests/system%252Fzones%252Fbrand%252Fipkg.p5m > > - should depend on the zones proxy and the system-repository package. Fixed. > --------- > src/pkg/manifests/system%252Fzones%252Fproxy.p5m > > - we're still not generating automatic dependencies, right? if so then > this package needs a bunch of manual dependencies. at a minimum we > probably want: > system-repository (gz only) > the packaging system Yes, still no automatic dependencies here. I've added the manual dependencies (to the renamed package/pkg/zones-proxy package) Thanks again for the review, cheers, tim _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
