I suppose this comes down to a question of leaving the console as an external program (like in the past) or treating it like an internal component of Blur. I would vote for making it an internal component. So with that being said if we treat it like an internal component I think that we can trust that the console can just make use of the code in the blur-core module. Then the console will be treated like any other component in Blur (controller / shard servers).
Aaron On Wed, Oct 2, 2013 at 10:04 PM, Garrett Barton <[email protected]>wrote: > One could potentially wrap the blur zookeeper stuff > (o.a.b.m.ZooKeeperClusterStatus) with a client read only class where the > client cannot cause any damage. I do that with my zk stuff and it works > awesome. Same logic is shared for accessing the data. I have not looked at > o.a.b.m.ZooKeeperClusterStatus to see how easy that would be mind you. > On Oct 2, 2013 8:14 PM, "Aaron McCurry" <[email protected]> wrote: > > > The controller file is there for script startup, nothing more. Which > > brings me to another thought. So if you are going to run your own http > > server process for the console your only choice for finding out the > > controllers maybe to access ZooKeeper. I know this goes against what we > > have discussed before, but I would feel better about the console > accessing > > ZooKeeper if it used the same classes as Blur > > (o.a.b.m.ZooKeeperClusterStatus). That way as we change the logic in > > ZooKeeper you will have the same logic. You can retrieve the controllers > > from that class and then use the thrift api from there. > > > > I'm sorry for going back and forth on this, but the more I think about > it I > > don't see any other way. Other than to configure the controllers in > > somehow. Sort of a chicken and the egg problem. > > > > Although I do consider the access of ZooKeeper for Blur information to be > > private and should be protected for the most part, but I think that if > you > > use the same class that the controllers and shard server use it should be > > pretty safe. > > > > Thoughts? > > > > Aaron > > > > > > On Wed, Oct 2, 2013 at 7:24 PM, Chris Rohr <[email protected]> wrote: > > > > > Hi, > > > > > > I have found some interesting things with the quick start and wanted to > > see > > > if this is going to be an issue on real instances. > > > > > > 1. In the conf/controllers file it lists one node of localhost (no > port). > > > I tried to read that file and build the BlurClient connection string > > which > > > failed because there was no port. I ended up writing code to check for > > the > > > absence of a port and add 40010 but that feels wrong. > > > > > > 2. Like I said above the controllers file lists localhost but the > > > ControllerServerList call returns the name of my machine and a port. > > This > > > causes problems for me when I am trying to figure out which nodes are > > > offline. > > > > > > Thanks in advance, > > > Chris > > > > > >
