ctubbsii commented on issue #1177: URL: https://github.com/apache/accumulo/issues/1177#issuecomment-1022625466
I think the bulk of the motivation for having it share class hierarchy with ServerContext is that it uses a lot of the utility code we wrote elsewhere that accepts a ServerContext, particularly for working with ZooKeeper stuff. But, it doesn't have to do that if it doesn't make sense to do so. Another hiccup that makes this frustrating is that ServerInfo uses ZooKeeper and HDFS objects in some of its constructors to do instanceId and instanceName lookups. This creates a chicken-egg bootstrap problem a bit. Ideally, ServerInfo should be an object representation of the configuration properties, and that is used to construct a ServerContext. It really shouldn't have stateful objects that do work like ZooKeeper connections. Those kinds of objects should exist in ServerContext. So, it should go something like: `SiteConfiguration` :arrow_right: `ServerInfo` :arrow_right: `ServerContext` (a composition something like: `new ServerContext(new ServerInfo(new SiteConfiguration()))`). However, because ServerInfo provides the instance ID, and because it may need to look up the instance ID from HDFS, or from an instance name to look it up in ZooKeeper, it has to create worker objects. This would be a lot simpler if the instance name was unique already and served as the instance ID as well. This would prevent being able to rename an instance, but if the instance name was included in the server config file (and the volumes had a sanity check to ensure it matched), we wouldn't need to do any lookups for the instance ID in `ServerInfo`. Currently, though, we have both instanceName and instanceId for Initialize, and neither for regular server bootups. Clients are expected to do a lookup of the instanceId from an instanceName, and servers are expected to look up from HDFS using `instance.volumes`. It's all very needlessly complex, but I think we're stuck with some of it for awhile. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
