rsrchboy/log.txt

## log.txt
[11:12:30 AM] ‎rsrchboy‎: so
‎[11:12:57 AM] ‎rsrchboy‎: I had a great conversation about getting hosting/dns settings to what we want with kyle
‎[11:14:34 AM] ‎rsrchboy‎: I think we found a far easier way, that's generally applicable to non-remix dho sites, for people using us for domreg and dns (most, I suspect; all for us)
‎[11:16:08 AM] ‎john.swanson‎: ah, really? nice! what is it?
‎[11:16:23 AM] ‎rsrchboy‎: a combo of a couple things
‎[11:17:01 AM] ‎rsrchboy‎: one is that our current approach -- just manipulating dns records -- is doable, but doesn't integrate well into the way we manage dns
‎[11:18:51 AM] ‎rsrchboy‎: there's two way we really configure dns records: one is through a domainservice (there are multiple types: fully-hosted, mirroring, redirect, parked, etc, etc); the other is through custom dns records a consumer can enter
‎[11:19:42 AM] ‎rsrchboy‎: fwiw, these are stashed away in dreamhost.domain_service and the actual records/zones in dns.zone and dns.record
‎[11:20:23 AM] ‎rsrchboy‎: the domainservice type controls certain records; these are immutable when it comes to customer manipulation -- short of changing the hosting type
‎[11:20:38 AM] ‎rsrchboy‎: for other records, (almost) anything goes
‎[11:20:43 AM] ‎rsrchboy‎: but the former trumps the latter.
‎[11:22:49 AM] ‎john.swanson‎: ahh. i see
‎[11:24:03 AM] ‎rsrchboy‎: the domainservice types are largely customer-visible through the panel, e.g.: https://panel.dreamhost.com/index.cgi?tree=domain.manage -- then pick a domain and hit 'edit' under "web hosting"
‎[11:24:28 AM] ‎rsrchboy‎: argh -- tangent, do you know a good image pastebin (pref one that lets me delete?)
‎[11:24:41 AM] ‎rsrchboy‎: so.
‎[11:25:09 AM] ‎rsrchboy‎: the upshot is that even if the API currently exposed changing dns records, it won't change the hosting type.
‎[11:25:18 AM] ‎rsrchboy‎: it won't even be able to *tell* the hosting type
‎[11:25:30 AM] ‎rsrchboy‎: so anyone looking at it in the panel is going to go "wtf?!"
‎[11:25:34 AM] ‎john.swanson‎: huh.
‎[11:25:41 AM] ‎rsrchboy‎: ...and if they try to change it then our changes are frakked
‎[11:26:17 AM] ‎john.swanson‎: (don't know a good image pastebin, i mostly use s3cmd and dho)
‎[11:26:27 AM] ‎john.swanson‎: that makes sense
‎[11:26:31 AM] ‎rsrchboy‎: (ooo, that's a good point)
‎[11:26:50 AM] ‎rsrchboy‎: to be clear, our current plan would work, but would be incredibly fragile and confusing.
‎[11:27:41 AM] ‎rsrchboy‎: now, it's not unlikely that someone would want to host a static site on dho and not go through the remixer, right?
‎[11:28:36 AM] ‎rsrchboy‎: so the case for hosting to add a 'DHO hosted' domainservice isn't just one for us, but more generally applicable
‎[11:29:17 AM] ‎rsrchboy‎: ...I mean, we want to make it easy for people to both buy domains *and* point them at sites hosted in dho easily, right?
‎[11:30:37 AM] ‎rsrchboy‎: so it'd be a pretty easy business case to make that hosting / cloud should push to get a 'dho hosted' option in the panel, and the corresponding domain service created
‎[11:30:56 AM] ‎rsrchboy‎: that wouldn't be remix specific, but we could trivially use it.
‎[11:31:21 AM] ‎rsrchboy‎: (...even if they have to use our reverse-proxy to begin with)
‎[11:33:47 AM] ‎john.swanson‎: that would be pretty awesome
‎[11:33:59 AM] ‎john.swanson‎: and does seem like it knocks out a lot of the difficulties
‎[11:34:44 AM] ‎rsrchboy‎: that way: we only need "get/set this domain's hosting type (service)" api calls, users see it in the panel, and dho gets another boost
‎[11:34:57 AM] ‎john.swanson‎: yeah
‎[11:37:47 AM] ‎rsrchboy‎: one other thing I suspect we might not be too aware of over here: our domreg and hosting functionality are fairly distinct.  it's easily possible to host domains people haven't bought here; or for people to buy domains but not host them with us
‎[11:38:09 AM] ‎rsrchboy‎: ...either of those requires dns monkeying, but...
‎[11:39:28 AM] ‎rsrchboy‎: so it isn't -- surprisingly -- monolithic inside the hosting codebase
‎[11:40:17 AM] ‎rsrchboy‎: hey -- so I just realized the above was a rather decent summary.  to spare me rewriting it, would you object if I cut'n'paste it to send around?
‎[11:40:45 AM] ‎john.swanson‎: not at all!

...one thing I forgot to mention is that our dns records/zones/etc are all generated and updated
via the Dnsgenerator service, based off of the type of the domain service associated with a given
domain, as well as any custom records the customer has set.  We control this service by
manipulating the domain service type as well as the custom dns records in the database; the db
manipulations are handled by the Ndn::DNS::Zone and Ndn::DNS::Record classes (and instances
thereof).
	[11:12:30 AM] ‎rsrchboy‎: so
	‎[11:12:57 AM] ‎rsrchboy‎: I had a great conversation about getting hosting/dns settings to what we want with kyle
	‎[11:14:34 AM] ‎rsrchboy‎: I think we found a far easier way, that's generally applicable to non-remix dho sites, for people using us for domreg and dns (most, I suspect; all for us)
	‎[11:16:08 AM] ‎john.swanson‎: ah, really? nice! what is it?
	‎[11:16:23 AM] ‎rsrchboy‎: a combo of a couple things
	‎[11:17:01 AM] ‎rsrchboy‎: one is that our current approach -- just manipulating dns records -- is doable, but doesn't integrate well into the way we manage dns
	‎[11:18:51 AM] ‎rsrchboy‎: there's two way we really configure dns records: one is through a domainservice (there are multiple types: fully-hosted, mirroring, redirect, parked, etc, etc); the other is through custom dns records a consumer can enter
	‎[11:19:42 AM] ‎rsrchboy‎: fwiw, these are stashed away in dreamhost.domain_service and the actual records/zones in dns.zone and dns.record
	‎[11:20:23 AM] ‎rsrchboy‎: the domainservice type controls certain records; these are immutable when it comes to customer manipulation -- short of changing the hosting type
	‎[11:20:38 AM] ‎rsrchboy‎: for other records, (almost) anything goes
	‎[11:20:43 AM] ‎rsrchboy‎: but the former trumps the latter.
	‎[11:22:49 AM] ‎john.swanson‎: ahh. i see
	‎[11:24:03 AM] ‎rsrchboy‎: the domainservice types are largely customer-visible through the panel, e.g.: https://panel.dreamhost.com/index.cgi?tree=domain.manage -- then pick a domain and hit 'edit' under "web hosting"
	‎[11:24:28 AM] ‎rsrchboy‎: argh -- tangent, do you know a good image pastebin (pref one that lets me delete?)
	‎[11:24:41 AM] ‎rsrchboy‎: so.
	‎[11:25:09 AM] ‎rsrchboy‎: the upshot is that even if the API currently exposed changing dns records, it won't change the hosting type.
	‎[11:25:18 AM] ‎rsrchboy‎: it won't even be able to tell the hosting type
	‎[11:25:30 AM] ‎rsrchboy‎: so anyone looking at it in the panel is going to go "wtf?!"
	‎[11:25:34 AM] ‎john.swanson‎: huh.
	‎[11:25:41 AM] ‎rsrchboy‎: ...and if they try to change it then our changes are frakked
	‎[11:26:17 AM] ‎john.swanson‎: (don't know a good image pastebin, i mostly use s3cmd and dho)
	‎[11:26:27 AM] ‎john.swanson‎: that makes sense
	‎[11:26:31 AM] ‎rsrchboy‎: (ooo, that's a good point)
	‎[11:26:50 AM] ‎rsrchboy‎: to be clear, our current plan would work, but would be incredibly fragile and confusing.
	‎[11:27:41 AM] ‎rsrchboy‎: now, it's not unlikely that someone would want to host a static site on dho and not go through the remixer, right?
	‎[11:28:36 AM] ‎rsrchboy‎: so the case for hosting to add a 'DHO hosted' domainservice isn't just one for us, but more generally applicable
	‎[11:29:17 AM] ‎rsrchboy‎: ...I mean, we want to make it easy for people to both buy domains and point them at sites hosted in dho easily, right?
	‎[11:30:37 AM] ‎rsrchboy‎: so it'd be a pretty easy business case to make that hosting / cloud should push to get a 'dho hosted' option in the panel, and the corresponding domain service created
	‎[11:30:56 AM] ‎rsrchboy‎: that wouldn't be remix specific, but we could trivially use it.
	‎[11:31:21 AM] ‎rsrchboy‎: (...even if they have to use our reverse-proxy to begin with)
	‎[11:33:47 AM] ‎john.swanson‎: that would be pretty awesome
	‎[11:33:59 AM] ‎john.swanson‎: and does seem like it knocks out a lot of the difficulties
	‎[11:34:44 AM] ‎rsrchboy‎: that way: we only need "get/set this domain's hosting type (service)" api calls, users see it in the panel, and dho gets another boost
	‎[11:34:57 AM] ‎john.swanson‎: yeah
	‎[11:37:47 AM] ‎rsrchboy‎: one other thing I suspect we might not be too aware of over here: our domreg and hosting functionality are fairly distinct. it's easily possible to host domains people haven't bought here; or for people to buy domains but not host them with us
	‎[11:38:09 AM] ‎rsrchboy‎: ...either of those requires dns monkeying, but...
	‎[11:39:28 AM] ‎rsrchboy‎: so it isn't -- surprisingly -- monolithic inside the hosting codebase
	‎[11:40:17 AM] ‎rsrchboy‎: hey -- so I just realized the above was a rather decent summary. to spare me rewriting it, would you object if I cut'n'paste it to send around?
	‎[11:40:45 AM] ‎john.swanson‎: not at all!

	...one thing I forgot to mention is that our dns records/zones/etc are all generated and updated
	via the Dnsgenerator service, based off of the type of the domain service associated with a given
	domain, as well as any custom records the customer has set. We control this service by
	manipulating the domain service type as well as the custom dns records in the database; the db
	manipulations are handled by the Ndn::DNS::Zone and Ndn::DNS::Record classes (and instances
	thereof).