[jboss-dev] Public IP address used by JBoss AS

[Brian Stansberry]

On 05/26/2010 10:51 AM, Bela Ban wrote:
>
>
> Brian Stansberry wrote:
>> Putting this on jboss-dev, as my guess is 3/4 of the work is
>> discussing a bit. Particularly interested in hearing from Mr. Boot, ALR.
>>
>> What we're talking about is https://jira.jboss.org/browse/JBAS-8001
>> which is a proposal to allow some standard aliases for IP addresses
>> that the AS would resolve to something meaningful on the local
>> machine. The purpose is to make it easier to use the AS in a cloud
>> environment where the user can't know addresses in advance. Proposed
>> aliases are:
>>
>> - GLOBAL: picks a global (public) address
>> - SITE_LOCAL: an address starting with 192.168.x.x or 10.0.x.x
>> - LINK_LOCAL: a link local address, ie. starting with 169.x.x.x or
>> 254.x.x.x
>> - NON_LOOPBACK: picks any non-loopback address
>> - LOOPBACK: picks a loopback address
>>
>> My current take on this is if we did it for AS 6 we'd implement it in
>> the org.jboss.Main class.[1] Basically we'd alter the command line
>> processing for -b, -Djboss.bind.address and -Djgroups.bind_addr to
>> detect the above aliases and replace with the appropriate value.
>>
>> IMO we would *not* allow these values as a general configuration
>> option, e.g. in a -jboss-beans.xml:
>>
>> <!-- Not supported -->
>> <property name="bindAddress">PUBLIC</property>
>
> -100 IMO: a user may want to define an address based on some criteria,
> so the above makes perfect sense ! I can even envisage that we support
> something like this later:
>
> <property name="bindAddress">192.168.*,274.2.*,SITE_LOCAL</property>,
>
> which means that we should try to pick a site local address starting
> with 192.168, if not found a global IP address starting with 274.*, and
> if still not found, go and grab any site local address.
>
> All of this logic can be centralized (in JGroups it is in 1 place) and
> used everywhere.
>

If there is a single place where such configuration is allowed (e.g. an 
AS 7 domain configuration document) and all services that need to 
consume the value must get it from the domain model, fine. But that 
ain't how AS 6 works. And this discussion started with a request to get 
something in M4, so that's what I'm talking about. :)

In AS 6, this kind of logic cannot be centralized in a single place. 
Just in clustering alone, the AS deals with 4 separate projects that 
each have their own configuration parsers.

>
>> That would be too much work, since as soon as you allow it one
>> configuration document you should allow it everywhere.
>
> Yes, but again, if this is centralized, this should be simple. In
> JGroups, processing of all IP addresses (IpAddress, InetAddress, or
> lists thereof) is done in 1 place (via annotations).
>
>> The weakness of only using it via Main's command line processing is if
>> people only want to use, for example, PUBLIC, in one spot, not as a
>> global value like -b. If we want to help with that, perhaps we could
>> use a system property namespace, and have Main check for properties in
>> that namespace and resolve them. For example:
>>
>> -Djboss.bind.address.myfoosocket=PUBLIC
>>
>> My instinct though is to *not* support that. First, to me there is no
>> clear use case. Second, in AS 7 I'm pretty sure we are going to want
>> to move away from system properties as a core way of configuring the
>> AS, so let's not add new system property-based features in 6.
>
> IMO, GLOBAL, SITE_LOCAL, LOOPBACK etc are *IP addresses*, as good as the
> dotted decimal notation (192.168.1.5) ! They are simply resolved at boot
> time, versus statically.
>
> If we allow for these keywords to be used with -b, then it would be
> weird for users not to be able to use them in XML config files or as
> system properties !
>
>


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat