On Wed, May 18, 2011 at 02:46:19PM +1200, Tim Foster wrote:
> 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
> >
> > - 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.
>
i haven't had time to review these additional changes.
i'm not going to be able to look at these till later.
> > ---------
> > 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?
>
that's fine.
> > ---------
> > 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.
>
cool.
> > ---------
> > 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:
>
ok. so the service still goes into maintenance. that's good. i guess
killing off the ht* processes is unnecessary.
> 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.
>
so the cascade effects are pretty unfortunate. perhaps we can have a
follow up fix where pkg set-publisher checks if the sysrepo is running,
and if so refuses to configure unsupported file repositories?
> > ---------
> > 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)
>
sounds good.
ed
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
