If we get netsplit, we end up with the inability to issue/renew DHCP leases. For a zone with a single DHCP service, it may be fine to just store DHCP leases in RAM (or flush to local disk) and then write those out to etcd when it's writable again.
But if we begin supporting multiple netcore DHCP servers in a single zone, they really need to share state, which means they need to be able to write out to etcd. I think that use case will require something special, such as possibly a separate etcd cluster dedicated to the local zone. I'd still want the full global etcd cluster as well (especially for DNS!). We'll have to think on this.
For the moment, prior to supporting multiple DHCP services in a single zone, we should probably be able to get away with in-memory workaround for the etcd read-only state, as long as we backfill once we get write access again. Possibly we should only ever use that in-memory state when we're in read-only and not an always-on sort of thing, or we need to wire it up to watch for updates from etcd to invalidate the local cache.
Note: This issue was migrated from https://bitbucket.org/dustywilson/netcore/issues/12 originally created on 2015-07-29 by Dusty Wilson. It was not evaluated in any way for freshness and validity. Note that this was originally Issue 12 at Bitbucket but was created as issue 11 at GitHub.
If we get netsplit, we end up with the inability to issue/renew DHCP leases. For a zone with a single DHCP service, it may be fine to just store DHCP leases in RAM (or flush to local disk) and then write those out to etcd when it's writable again.
But if we begin supporting multiple netcore DHCP servers in a single zone, they really need to share state, which means they need to be able to write out to etcd. I think that use case will require something special, such as possibly a separate etcd cluster dedicated to the local zone. I'd still want the full global etcd cluster as well (especially for DNS!). We'll have to think on this.
For the moment, prior to supporting multiple DHCP services in a single zone, we should probably be able to get away with in-memory workaround for the etcd read-only state, as long as we backfill once we get write access again. Possibly we should only ever use that in-memory state when we're in read-only and not an always-on sort of thing, or we need to wire it up to watch for updates from etcd to invalidate the local cache.
Note: This issue was migrated from https://bitbucket.org/dustywilson/netcore/issues/12 originally created on 2015-07-29 by Dusty Wilson. It was not evaluated in any way for freshness and validity. Note that this was originally Issue 12 at Bitbucket but was created as issue 11 at GitHub.