On Nov 25, 2009, at 3:32 PM, Leif Hedstrom wrote: > On 11/25/2009 03:51 PM, Bryan Call wrote: >> We also need to worry about stability too. We have a lot of changes in the >> tree that are untested and we don't have any automated testing to verify all >> the changes we have already made to the Apache tree don't have any hidden >> gems (bugs). There has to be a balance with breaking compatibility moving >> forward and having a stable code base. >> >> APIs are something that should be very stable since it requires real work >> (human time) to make the change. Files that can be blown away and recreated >> over time should be considered less important. I don't think we need to >> have a major version number bump for files, but we do for APIs breaking. >> > > What do you mean "files"? Like the hostdb? Then yes, that's not a huge deal. > Making changes to the cache could be very distruptive. It could be > prohibitively expensive for someone to have to blow away TBs of cache just > for doing a minor Traffic Server upgrade (I certainly would think twice > before doing that myself). >
I am talking about internal files created by traffic server, cache and hostdb being a couple of them. For someone with a large setup they would roll out software to a few servers at a time. Most caches have a Zipfian distribution and would have a working set that would populate the cache to a stable cache hit ratio is a few hours, this has been my experience with very large databases. If we feel it is a major disruption then we should do a major version bump for cache incompatibility or make changes in a way that offers backwards compatibility through a configuration setting. >> I haven't seen many requests for caches over 512GB per server. I think it >> is important to have this change, more for partitions sizes and the >> potential to reduce the number of partitions (reduces the seeking for >> writes). >> > > Hmmm, internally at Y!, there is at least one very large deployment with > 2.5TB of cache per machine (Wretch). I don't know what the "outside" world > would do, but 512GB is not a huge cache, particularly in a forward proxy > setup. > Yes, you just proved my point. There are few people (not many) that have large caches. You can add Search Crawler and Flickr (that doesn't use TS) to the list. This is a minority of the users and a minority of the traffic. Few groups are asking for larger caches. >> For the first release I would like to see less changes so we can move over >> to it quicker within Yahoo!. If we try to push to much into the release we >> are going to have a harder time moving over to the Apache tree. >> > > That's a "management" decision we have to make. I'd rather break things now > that are difficult to break later, that would include: > > * APIs (InkAPI, Remap API, any CLI APIs), in particular newer APIs like > the Cache plugin APIs needs to be finalized. > * ABIs (for above) > * Disk cache (RAM cache doesn't matter, since it's volatile) > * Any changes related to complete the 64-bit support (e.g. objects > 2GB), > possibly related to APIs. > > > I'd also argue that if we don't make sure that upgrading within the 2.x > "branch" can be done internally at Y! without major disturbance, we'll never > get the ASF version successfully used internally. This is one thing we've > been really good about at Y! so far, there's been very few changes that would > cause an upgrade to be disruptive for our users. > The list that you have above are reasons groups will be less likely to move to the Apache branch. People will have to modify their plugins and wipe their caches. According to you this is "very distruptive". > I'd suggest we come up with a list of the requirements for what needs to be > done in the "2.x" branch, and then freeze it. I'd be hard to convince that > addressing the issues listed above is not one of those requirements :). You haven't addressed anything about stability and how we are going to test all the changes. There have been a lot of changes to the Apache tree that haven't been fully tested. Also, there have been a lot of changes that have happened and are happening to the internal branches that haven't made it to the Apache branch yet. This reminds me of when we tried to (or are we still trying to) stabilize the 1.17 branch and there was a lot of push to add in features (SRV, string_get_ref, redirect, etc). These features created instability and were not properly tested. I don't think anyone wants to go down that road again... -Bryan
