On 05/13/12 22:35, Tim Foster wrote:
Hi there,
I've got a code review here that adds a configuration cache to the
system-repository, resulting in faster, more dependable startup.
(particularly important on boot, or in the face of slow or unreachable
package repositories)
I spent a while trying to get the right approach to determine when to
rebuild the cache. It's easy when the latest pkg(5) bits are running
on an image - we delete the cache in the same place we cause a
system-repository refresh on publisher-change.
It's harder when an older version of pkg(1) has manipulated an image
behind the scenes, giving us a stale cache[1]. Anyway, there's a
webrev at:
https://cr.opensolaris.org/action/browse/pkg/timf/sysrepo-config-cache/sysrepo-config-cache-webrev
Comments would be most welcome,
cheers,
tim
[1] When loading, pkg.sysrepo(1M) validates the format of the cache
file, and ensures that all publishers and URIs configured in the image
are indeed represented in the cache, which I believe is sufficient -
though that does allow that the cache may contain more URIs than the
image has configured: necessary, because the only way to determine
whether server-side redirects are still in place is to verify them :-(
I had looked at using the timestamp of the cache file vs.
<ImageInterface>.last_modified, but changes to that aren't limited to
simple publisher configuration changes unfortunately.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
sysrepo.py
line 317, 365 Nit: use open instead of file (at least I think we settled
on open)
line 326: shouldn't this also generate an error? or do we hit this if no
publishers are configured?
434,435,437: Why the change from tuples to lists?
Could you discuss briefly what happens in the situation where a user
adds a (currently) unreachable publisher with --no-refresh? (And perhaps
add a test case for it)
On the testing side of things, I don't think I see tests for a) an image
with no publishers and no packages installed or b) an image with no
publishers but packages installed. I think it's probably worth just
checking those two corner cases.
Is it the _follow_redirects bit of sysrepo.py that currently requires
that we have networking available and publishers are reachable? Anything
else?
Just to make sure I understand how this works...
When a user adds a publisher or an origin to an existing publisher, that
refreshes/restarts the sysrepo service. When it starts the next time, it
will look at the cached information. realize it's out of date since the
publisher or origin isn't in the cached info, and revert to existing
behavior?
I think though, when a user removes a publisher or origin, after the
restart/refresh, the sysrepo will continue using the previously cached
data? Have I missed something? If I haven't this seems like a problem
since the NGZ would have access to an origin/publisher that it
shouldn't, and perhaps worse, would still have that publisher configured
as a system publisher... In the bug, there's a mention of comparing
creation or modification times, I think that might work to fix this issue?
I have a couple of other concerns, though I'm not sure how major they are...
Is it possible to have the sysrepo use the cache as a fallback if
publishers aren't reachable? That seems like it might be the safer route.
If I'm reading the code right, if a server changes it server-side
redirections, the sysrepo would never pick up on that change and
wouldn't provide the right set of redirects in its configuration,
leading to transport errors. While I think that could happen now, at
least if sysrepo was restarted/refreshed, it would pick up on the new
redirects, with this, it seems like it would take a publisher change by
the user to cause it to pick up the new redirects.
Perhaps we could start up immediately with the cached info then
periodically after revalidate the redirects?
Thanks,
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
