12:09 p.m.
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.
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 !
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
12:43 p.m.
New subject: Public IP address used by JBoss AS
On 05/26/2010 12:09 PM, Bela Ban wrote:
Brian Stansberry wrote:
> 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 we put the resolution logic inside of jboss-bootstrap, any MC
component can @Inject or <inject> the JBossASConfiguration and do
getBindAddress() (even if the input was something like "PUBLIC"). The
configuration initialization phase would resolve before the server comes up.
S,
ALR
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger
1:45 p.m.
New subject: Public IP address used by JBoss AS
On 05/26/2010 11:43 AM, Andrew Lee Rubinger wrote:
On 05/26/2010 12:09 PM, Bela Ban wrote:
> Brian Stansberry wrote:
>> 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 we put the resolution logic inside of jboss-bootstrap, any MC
component can @Inject or<inject> the JBossASConfiguration and do
getBindAddress() (even if the input was something like "PUBLIC"). The
configuration initialization phase would resolve before the server comes up.
If the goal is fine grained configuring what type of interface an
interface uses, then the closest mapping to:
<property name="bindAddress">PUBLIC</property>
is
<property name="bindAddress"><inject
bean="JBossASConfiguration"
property="publicAddress"/></property>
So that implies new properties in JBossASConfiguration.
Since this is really an API discussion, I'd still like to hear more
about what the real world use cases are. I get the one where a server
listens on interface X for external requests and uses interface Y for
internal to the cluster traffic. I can dream up others. What other ones
are actually used?
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
1:53 p.m.
New subject: Public IP address used by JBoss AS
On 05/26/2010 01:45 PM, Brian Stansberry wrote:
On 05/26/2010 11:43 AM, Andrew Lee Rubinger wrote:
> On 05/26/2010 12:09 PM, Bela Ban wrote:
>> Brian Stansberry wrote:
>>> 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 we put the resolution logic inside of jboss-bootstrap, any MC
> component can @Inject or<inject> the JBossASConfiguration and do
> getBindAddress() (even if the input was something like "PUBLIC"). The
> configuration initialization phase would resolve before the server
> comes up.
>
If the goal is fine grained configuring what type of interface an
interface uses, then the closest mapping to:
<property name="bindAddress">PUBLIC</property>
is
<property name="bindAddress"><inject
bean="JBossASConfiguration"
property="publicAddress"/></property>
So that implies new properties in JBossASConfiguration.
Is that true?
Why not allow input of bindAddress=="PUBLIC", which may resolve to
201.23.2.100 within the same property? Do we need to hang on to the
inputs or just resolve them to a real jboss.bind.address? So then it'd be:
<property name="bindAddress"><inject
bean="JBossASConfiguration"
property="bindAddress"/></property>
...which we already have.
S,
ALR
Since this is really an API discussion, I'd still like to hear more
about what the real world use cases are. I get the one where a server
listens on interface X for external requests and uses interface Y for
internal to the cluster traffic. I can dream up others. What other ones
are actually used?
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger
2:07 p.m.
New subject: Public IP address used by JBoss AS
On 05/26/2010 12:53 PM, Andrew Lee Rubinger wrote:
On 05/26/2010 01:45 PM, Brian Stansberry wrote:
> On 05/26/2010 11:43 AM, Andrew Lee Rubinger wrote:
>> On 05/26/2010 12:09 PM, Bela Ban wrote:
>>> Brian Stansberry wrote:
>>>> 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 we put the resolution logic inside of jboss-bootstrap, any MC
>> component can @Inject or<inject> the JBossASConfiguration and do
>> getBindAddress() (even if the input was something like "PUBLIC"). The
>> configuration initialization phase would resolve before the server
>> comes up.
>>
>
> If the goal is fine grained configuring what type of interface an
> interface uses, then the closest mapping to:
>
> <property name="bindAddress">PUBLIC</property>
>
> is
>
> <property name="bindAddress"><inject
bean="JBossASConfiguration"
> property="publicAddress"/></property>
>
> So that implies new properties in JBossASConfiguration.
Is that true?
Why not allow input of bindAddress=="PUBLIC", which may resolve to
201.23.2.100 within the same property? Do we need to hang on to the
inputs or just resolve them to a real jboss.bind.address? So then it'd be:
<property name="bindAddress"><inject
bean="JBossASConfiguration"
property="bindAddress"/></property>
...which we already have.
That leaves you with only one address. It doesn't support the equivalent
of the following for some service or combination of services:
<property name="externalAddress">PUBLIC</property>
<property name="intraClusterAddress">SITE_LOCAL</property>
The need for that kind of flexibility is the argument for being able to
resolve PUBLIC et al at any injection point.
>
> Since this is really an API discussion, I'd still like to hear more
> about what the real world use cases are. I get the one where a server
> listens on interface X for external requests and uses interface Y for
> internal to the cluster traffic. I can dream up others. What other ones
> are actually used?
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
2:09 p.m.
New subject: Public IP address used by JBoss AS
On 05/26/2010 02:07 PM, Brian Stansberry wrote:
On 05/26/2010 12:53 PM, Andrew Lee Rubinger wrote:
>
>
> On 05/26/2010 01:45 PM, Brian Stansberry wrote:
>> On 05/26/2010 11:43 AM, Andrew Lee Rubinger wrote:
>>> On 05/26/2010 12:09 PM, Bela Ban wrote:
>>>> Brian Stansberry wrote:
>>>>> 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 we put the resolution logic inside of jboss-bootstrap, any MC
>>> component can @Inject or<inject> the JBossASConfiguration and do
>>> getBindAddress() (even if the input was something like "PUBLIC").
The
>>> configuration initialization phase would resolve before the server
>>> comes up.
>>>
>>
>> If the goal is fine grained configuring what type of interface an
>> interface uses, then the closest mapping to:
>>
>> <property name="bindAddress">PUBLIC</property>
>>
>> is
>>
>> <property name="bindAddress"><inject
bean="JBossASConfiguration"
>> property="publicAddress"/></property>
>>
>> So that implies new properties in JBossASConfiguration.
>
> Is that true?
>
> Why not allow input of bindAddress=="PUBLIC", which may resolve to
> 201.23.2.100 within the same property? Do we need to hang on to the
> inputs or just resolve them to a real jboss.bind.address? So then it'd
> be:
>
> <property name="bindAddress"><inject
bean="JBossASConfiguration"
> property="bindAddress"/></property>
>
> ...which we already have.
>
That leaves you with only one address. It doesn't support the equivalent
of the following for some service or combination of services:
<property name="externalAddress">PUBLIC</property>
<property name="intraClusterAddress">SITE_LOCAL</property>
The need for that kind of flexibility is the argument for being able to
resolve PUBLIC et al at any injection point.
Ah OK.
Yeah, we'd need some API additions then. I'm looking forward to AS7 and
the Domain model; these bootstrap config props are currently a minimal
subset of everything available. Eventually they'll fade into the
domain, and the bootstrap props can be used for just that.
S,
ALR
>
>>
>> Since this is really an API discussion, I'd still like to hear more
>> about what the real world use cases are. I get the one where a server
>> listens on interface X for external requests and uses interface Y for
>> internal to the cluster traffic. I can dream up others. What other ones
>> are actually used?
>>
>
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger
2:48 a.m.
New subject: Public IP address used by JBoss AS
Brian Stansberry wrote:
Since this is really an API discussion, I'd still like to hear
more
about what the real world use cases are. I get the one where a server
listens on interface X for external requests and uses interface Y for
internal to the cluster traffic. I can dream up others. What other
ones are actually used?
Just to re-iterate: this cloud use case is very important. In most cloud
environments, you don't get a static IP address unless you use something
like elastic IP addresses (EC2) or some kludges to find out the IP
address and then resolve it via dyndns.org. Some cloud providers charge
extra for traffic on public IPs, and traffic on site-local IPs is free.
The latter of course could be used for JGroups traffic (discovery,
replication, distribution).
In my use case, as a matter of fact all traffic can use site-local IP
addresses except for the AJP connector: because it will be accessed by
httpd mod-cluster (in a different cloud), it needs a public IP.
This use case is really for running JBoss AS in the cloud
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
5174
days inactive
5175
days old
jboss-development@lists.jboss.org
6 comments
3 participants
participants (3)
-
Andrew Lee Rubinger -
Bela Ban -
Brian Stansberry