On 05/13/10 03:36 PM, johan...@opensolaris.org wrote:
On Thu, May 13, 2010 at 01:50:14PM -0500, Shawn Walker wrote:
I'm trying to allow the repository administrator to *optionally*
specify what publisher's data is being mirrored to assist clients in
configuration and/or validation in the future.
This seems out of scope, since we don't know what the future
requirements for configuration validation may be.
See below for why I don't agree.
Note that I didn't say you change the validate() check, etc. I'm
just wanting to change it so that *if* the administrator has
supplied the information, then assume it's valid.
This is part of my concern. In the current model, administrators are
required to supply a cfg_cache. So far as I can tell, they seem to copy
/ paste it from somewhere else. If this is the typical behavior, it
would be sensible to generate something else by default, and only
provide information if explicitly supplied by an administrator. We'd
need to create an alternate configuration file in order to accomplish
this, since we have no way of determining whether the cfg_cache was put
there by someone trying to be careful, or by a quick/dirty cut paste.
An alternate configuration file because someone screwed up the actual
configuration file doesn't seem logical :/
That's a level of complexity I don't think I want to go to.
Again, I don't think bad configuration should preclude the ability to
provide potentially valuable information.
Nevermind that even if you have disabled the publisher response, that
doesn't change what the depot BUI is going to show (the depot BUI is
supposed to show what publisher's data is being mirrored).
...
Yes, but my suggested change above doesn't preclude that. It does
empower the administrator in the single publisher case (which I
believe is the more common case for mirrors) to provide more useful
information to the client.
I think that over time, single publisher mirrors are going to become
less common. We've developed a variety of ideas about mirroring
content, many of which contain data from multiple upstream sources.
Yes, but it will still be useful at a later date to know *which* publishers.
And actually, over time, the data is going to become partitioned by
publisher, it won't be in one big blob as it it's stored now in the case
you're describing.
Note that the client doesn't yet use this information, but I would
like it to be available so that it could be used if provided.
I think that we will want the client to use this information. When it
actually becomes possible to determine what publishers are being
mirrored, I would imagine that we'd want to change the mirror discovery
code to only include sources for publishers we're interested in
downloading data from. Based upon the architecture we have right now,
though, it's premature to add such a feature.
Except you're actually *removing* this feature now, so it's not really
adding it. Right now, a mirror will respond to the publisher response
based on the configuration provided.
If that wasn't already true, I might agree with you.
I was thinking you could add a set of unit tests that simply return
successful if pybonjour couldn't be imported.
Since PyBonjour isn't in the gate, and we have no guarantee that the
mdns daemon is running, how about I write a test that enables mirror
detection and verifies that the client can successfully complete an
install. That should be sufficient to catch some breakage.
That might work assuming that only the mirror had the necessary file data.
Cheers,
-Shawn
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
