On Nov 6, 2013, at 4:22 PM, Glen Barber wrote: > On Thu, Nov 07, 2013 at 12:13:49AM +0000, Teske, Devin wrote: >> So what hard-coding are you talking about? >> > > You are trying to hard-code hostnames for a service in the FreeBSD > src/ tree, when it is *absolutely* unnecessary. > Not all hostnames are equal. As you know, pkg.freebsd.org is one that you would never deny. So just as pkg.freebsd.org is "different" from a normal hostname, pkg.eu.freebsd.org and pkg.us-east.freebsd.org and pkg.us-west.freebsd.org are similarly "different" (in the same way). I'm not trying to hard-code any ol' hostnames... I'm trying to hardcode the hostnames which can be administered to point to one or more grouped servers. You talk about how pkg.freebsd.org is unique because we can simply change where it points... I'm talking about doing the same thing for the other 3 names we have which were designed for the same thing. I think that you're thinking that: pkg.eu.freebsd.org pkg.us-east.freebsd.org pkg.us-west.freebsd.org Will somehow change? The only way they would change is in the same way that you would change pkg.freebsd.org -- I don't know how much clearer I can make this. >> You talk about how "if a node goes down we take it out of DNS" >> but that has absolutely nothing to do with me because I'm not >> putting A/AAAA-resolving names in the menu. >> > > I did not once say anything about A or AAAA records. > You talked about a node going down. A node has a A or quad-A record. The name for that node is served via the SRV record. Read the above paragraph again carefully. I said "A/AAAA-resolving names" That is equivalent to "node name" and you were talking about "what if a node goes down." And my answer to that was... I don't care if a node goes down, because I'm not using node names in the menu. >> You do realize don't you that pkg.eu.f.o is a locale-specific name >> that will eventually hold potentially many-more European server >> names, right? >> > > So? > So, the name "pkg.eu" is never going to change. It, like pkg.freebsd.org will just have modified SRV records to track the European nodes. >> You do realize that the actual European server is *NOT* pkg.eu, >> right? >> > > *Sigh*... > Your sign leads me to be concerned that there is a false assumption that the DNS name that serves the SRV records should be a one-to-one mapping. There's absolutely no reason whatsoever to dedicate an entire locale specific domain to one SRV record. That's silly. As we grow, this domain -- which is decidedly locale-specific by way of its actual name -- should be used for what it was intended... a locale abstraction of many-to-one. >> You do realize that while the name pkg.f.o may wholly encompass >> all the mirrors, that this will not always be true, right? >> > > No, you are wrong. > I surely hope I am not. You're saying that: + We'll never have more than one server in Europe. + We'll never have more than one server in the West Coast of the USA. + We'll never have more than one server in the East Coast of the USA. That makes me very sad. Very sad indeed. I envisaged a growth that would have had dozens upon dozens of servers all throughout, and the locale-specific domains would then return geographically based SRV records (of which we administer on the back-end). >> I have no idea what you're talking about with the updating of config >> files. >> > > Clearly. If you hard-code anything other than pkg.FreeBSD.org in > bsdconfig, now clusteradm has to become aware of it, and make sure that > record *always* exists, no matter what the endpoint is. > http://lists.freebsd.org/pipermail/freebsd-pkg/2013-October/000107.html According to that mail, clusteradm *should* already be away of the three I mentioned... pkg.eu, pkg.us-east, and pkg.us-west > This nonsense happened with sysinstall, and anything else that used the > FTP mirror list. And when a node disappears, for whatever reason, it is > an absolute nightmare to sort out. > I have to continue to beat the drum... You had to do that in sysinstall, because the names that were used there were A/quad-A resolving names (node names). Just as pkg.freebsd.org is not one of those names... pkg.eu and pkg.us-* are not like the names used in sysinstall. So please... tell me again, how or why you would *ever* have to modify pkg.eu or pkg.us-* ??? > For the last time, you do not need to have *any* host entries other than > 'pkg.FreeBSD.org'. Period. > Until you acknowledge that pkg.eu and pkg.us-* are of the same pedigree as pkg.f.o, I assume that you are still confusing this list of names with a traditional list of names like sysinstall had. >> That being said... that name should not go away unless we no longer >> have even one single server in Europe. >> > > This has nothing to do with bsdconfig. Try to see my larger point. > Oh, I agree... I'm looking forward to the big picture when pkg.eu returns more than one SRV record. I'm looking forward to the day that pkg.us-east and pkg.us-west return more than one SRV record. I'd like to some day see: + pkg.freebsd.org use geo2ip to return SRV of closest entries + pkg.eu to return multiple SRV records for multiple European mirrors + pkg.us-* to similarly return multiple SRV records Can't you see what I'm going for? It's a lot larger in scale than what we have now. Why not strive to attain a full-scale CDN and geo-location awareness? I think it's foolish to get locked into this notion that we have to have one-to-one sub-mapping of SRV records under the main guy. >> Oh, and by the way... >> >> The name "pkg.f.o" does *NOT* resolve to "pkg.eu"... pkg.eu is a sibling >> name that is disassociated -- it was actually *designed* to be used for >> this. > > So was pkg.FreeBSD.org. It is why I do *NOT* want you to hard-code > anything other than that. > You misread what I stated... pkg.eu was designed for the same purpose as pkg.f.o In every way. -- Devin > Glen > _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC