On Thu, May 13, 2010 at 04:50:10PM -0500, Shawn Walker wrote: > >I think you've misunderstood what I'm suggesting. I'm not saying that > >we should have two configuration files. Rather, I'm saying that if we > >want to avoid arbitrary mirror configuration, we should deprecate the > >existing configuruation file, auto-generate config information for all > >cases where it's possible, and then have a new configuration file that's > >required for origins and optional for mirrors, or whatever permutation > >makes sense. > > That's fine, but that doesn't mean we need to remove the existing > cfg_cache logic to achieve what you want.
I think you still don't understand. I said that this was one possible solution to the problem, not the only solution. > Right, which is why I pointed out the information would be optional. > Again, the functionality is *already* available today, and those bad > configurations are already available today. So removing > functionality based on existing bad configurations doesn't seem like > a reasonable justification to me. So we should continue to give out bad or meaningless configuration data? > Again, I don't think existing bogus config data is a valid reason to > remove this from the list of possible operations. When we decide > later to actually use this functionality, then the same bad > configurations will still be a problem. I've given more examples than just bogus config data. Regardless, you're correct that when you actually decide to use this functionality the bad configurations will still be a problem. How do you plan to deal with this? I've proposed a solution that results in correct behavior for mirrors, and doesn't harm origins. > The depot BUI currently requires (and assumes) that a valid > configuration file is available. If you really need to be able to > run without a pre-supplied one, then you need to auto-generate one > for the client mirror case as part of this putback. I didn't > realise that this functionality would be attempting to use the > client's cfg_cache. It's not attempting to use the client's cfg_cache. I'm pointing out a problem with using the client image-root as the image root for this depot. We tested the BUI without configuration file earlier in this code review and found that everything worked. I don't understand this particular objection. > >Also, in terms of overall depot architecture, you said that you're > >prefer the mDNS mirror not to have a separate set of options in the > >repository or depot. This means that in src/depot.py we do a little bit > >of setup: the plugin, and mandatory repository options, but then don't > >treat this as a special case. It's not obvious to me how we handle the > >publisher/0 case unless we make the mdns mirror it's own option. I'd > >prefer to generalize this to all mirrors until we really have a reason > >to provide configuration information through a mirror's publisher/0 > >operation. > > We do really have a reason. As I said before, it is *planned* (and > there are already bugs open for this) to take advantage of this > information in the BUI, etc. You're not making any attempt to answer the previous point about depot architecture. Would you rather I introduce a separate set of repository and depot options for mDNS mode? Previously, you were opposed to something this specific. > I don't see the point of removing functionality that I'm only going > to add back later that's going to hit some of the same potential > issues that you're indicating above. I'm removing the functionality now, because it's not providing anything useful to the clients in its current form. In order to get this information to be useful to the clients, we need the new on-disk format, and the ability to determine, based upon the files on disk, what publishers the mirror contains. I can't guess what your implementation of this will look like; it's awkward for me to write code to interface with something that doesn't yet exist. > Given all of what you said above, I'd argue that there's a large gap > here in implementation, because valid configuration information is > expected and required for the BUI. I don't understand this comment. Would you please clarify? Thanks, -j _______________________________________________ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
