+1 The host.address and host.subnet.address has always been confusing, at least for me, and especially so for figuring out what SshMachineLocation is going to do. Having a dedicated sensor for the management address with unambiguous purpose for SshMachineLocation (and others!) seems obvious to me!
Thanks Richard. On 6 December 2016 at 16:26, Sam Corbett <[email protected]> wrote: > Summary: > > Brooklyn conflates the management address of an entity with its public > address. I want to break this by publishing a new sensor called > management.host.address on entities that use JcloudsLocation and using it > in preference to host.address when creating SSH connections and polling > feeds. Its value is the entity's host.subnet.address if that is accessible, > otherwise host.address. > > Some background: > > JcloudsLocation makes a guess at the best host and port to use for SSH > connections to each instance. The value it chooses subsequently informs a > variety of entity sensors, most importantly the "host.address" sensor which > itself informs the address at which various feeds are polled and other > sensors like "main.uri". Right now Brooklyn always prefers a value from the > set of "public" addresses returned by the cloud. Internally to > JcloudsLocation the value that is picked is referred to as the "management > host and port", but by subsequently using it for host.address we conflate > it with the publicly accessible address. > > An obvious change to make to this is to have Brooklyn use the private > address for SSH connections when it's on the same subnet as the thing it > has provisioned. In order to do this without mucking up all of the existing > assumptions I propose we introduce a new sensor called > "management.host.address", whose value is a reachable private address, if > one exists, and otherwise the value chosen for the public address. When > creating SSH connections SshMachineLocation would check for the management > address and fall back to its current behaviour if it's unset. > > An alternative is to have SshMachineLocation itself work out whether it > can connect to a private address. I do not like this option because we > would be unable to reuse the information that a private address is better > in entity feeds and BrooklynAccessUtils. > > Svet raised the excellent point that we risk having an instance's private > address match an irrelevant machine on the same network as Brooklyn. To > resolve this he suggests that we change the check for reachability to also > test credentials rather than simply trying to open a socket as happens at > the moment. > > I'm going to start on an implementation of this. Any feedback or questions? > > Sam >
