/etc/hosts on the hosts is not packaged

[Evan Broder]

invirt-cluster-config expects $hostname-internal to exist for all of the host machines, which XVM accomplishes with an /etc/hosts file. This file is not packaged.

We could either treat this as site-local configuration that should be handled in an XVM-specific way, or we could argue that the information is required by Invirt, so Invirt should generate the /etc/hosts file from additional config fields.

I'm not sure at which level this should be handled, so I'm attaching the bug to both projects.

[Greg Price (gregprice)]

On Fri, Dec 12, 2008 at 09:01:21PM -0000, Evan Broder wrote:
> invirt-cluster-config expects $hostname-internal to exist for all of the
> host machines, which XVM accomplishes with an /etc/hosts file. This file
> is not packaged.
>
> We could either treat this as site-local configuration that should be
> handled in an XVM-specific way, or we could argue that the information
> is required by Invirt, so Invirt should generate the /etc/hosts file
> from additional config fields.

I don't think $hostname-internal should be required/assumed by Invirt;
it's just a convention that happens to make sense for us as we're
running on a backend network. Probably the right answer is to add a
field to each host in the config file saying how clustering should
address it, and default to the normal hostname.

Greg

[Greg Price (gregprice)]

On Mon, Dec 15, 2008 at 11:32:22AM -0500, Sam Hartman wrote:
> I'm uncomfortable with the default to the normal hostname given what
> we know of the clustering code's security model.

Hmm, that's a fair point.

> When I worked on this I intended to create a hosts file template and
> generate it, but never got around to doing that.

But it doesn't seem very clean to have Invirt take over the /etc/hosts
file -- the sysadmin might have other entries they want to put there,
and they may also have some other convention for naming their internal
interfaces (e.g., $hostname.internal). Better is probably to add a
field to each host for its internal name / the name clustering should
use, and require it to be present rather than have a default.

Greg

[Greg Price (gregprice)]

On Mon, Dec 15, 2008 at 01:55:10PM -0500, Sam Hartman wrote:
> >>>>> "Greg" == Greg Price <email address hidden> writes:
>
> Greg> But it doesn't seem very clean to have Invirt take over the
> Greg> /etc/hosts file -- the sysadmin might have other entries
> Greg> they want to put there,
>
> How realistic is it to use invirt without giving invirt most of a dom0.
> I do agree that a better model would be to construct a list of
> things that we need in /etc/hosts and to make sure all those entries
> are there.

I think it's realistic to use Invirt and have some other related nodes
with local names, say on backend networks, that want to go in
/etc/hosts. If there were an /etc/hosts.d/ it'd be reasonable to drop
something in there, based on asking the sysadmin for both internal
hostnames and internal IP addresses in master.yaml.

As there isn't, and since the sysadmin has to take deliberate steps in
any case to set up a backend network (they have to plug it in! and
configure IP addresses, too), it seems most straightforward to just
let them manage /etc/hosts directly, and tell us in master.yaml what
hostnames they chose.

Greg

[Evan Broder (broder)]

Yeah, I think I agree with Greg on this one. This seems like an XVM problem, not an Invirt problem.