[Swift-devel] a note on running coasters on osg's RENCI Engage site

[Allan Espinosa]

So in the current setup, the coaster service only binds to the public
address of the head node and not all the network devices?

On Mon, Jan 26, 2009 at 12:33 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:
> On Mon, 2009-01-26 at 12:28 -0500, Mats Rynge wrote:
>> Ben Clifford wrote:
>> > Coasters in the release don't work on RENCI Engage.
>> >
>> > I fiddled with this a bit before, and just fiddled with it a bit more.
>> >
>> > The external IP address of the cluster head node (152.54.1.231) is not
>> > accessible from the cluster worker nodes, which sit on a different
>> > network.
>> >
>> > The headnode *is* accessible from its IP address on that network,
>> > 192.168.1.11.
>> >
>> > Forcing the URI passed to workers to use that IP address instead of the
>> > automatically determined one is sufficient to make coasters work on the
>> > RENCI Engage site.
>>
>> I'm surprised that the private address was not used already. I mean,
>> isn't this the use case for putting the coaster forwarder on the
>> headnode in the first place? If you have outbound network connectivity,
>> the coaster daemons in the worker nodes could connect directly to the
>> host where swift is running on.
>
> Automatically figuring out which eth should be used is a tricky thing
> given that cluster configurations don't seem to follow some
> pre-established rule. Each sites does stuff in their own way, though
> most seem to have the head node accessible internally through the public
> head node address.
>