Proposal for improving handling complex types in CLI
by Tomaž Cerar
Hi guys,
there ware some discussions on how we should improve handling complex types
of attribute bit better in CLI.
For most part that was about Map & List types.
After some discussions with few of you I came up with plan / ideas what all
options are there for us to improve on.
you can see current state of proposed enhancements at
https://gist.github.com/ctomc/91055a6f4e7502dcd130
In short, I propose to add set of map-* and list-* global operations and
improve :read-attribute & :write-attribute
with EL like syntax for reading / updating map, list and generic complex
attributes.
Let me know what you think about it, especially Console & CLI folks.
--
tomaz
9 years, 8 months
Customizing a provisioned server
by Stuart Douglas
Hi everyone,
Work on the provisioning tool is now well underway, so I would like to
revisit something I mentioned in my original email, which is allowing
the provisioning tool to customize a provisioned server.
I think there are a few options here, some more palatable than others.
In no particular order:
1) Customize the XML directly
Using this approach we would just directly customize the XML
configuration files. This would basically require the use of XSLT
(yuck), or require us to basically invent our own version of XSLT (even
more yuck). Even though this approach will work, and will be fairly easy
to implement, I think it would really suck from an end-user point of
view, and I think we should discount it.
2) Allow the user to provide CLI commands to customise the server
This is by far my favorite approach. The provisioning file would just
contain a list of CLI commands, and would execute them in order. I think
this is by far the most intuitive, and the CLI is well documented.
3) Allow the user to provide DMR operations to customize the server
Similar to 2, but allow the user to provide DMR or JSON operations to
customize the server. I think this is not nearly as nice as 2, as users
are much more likely to be familiar with the CLI rather than DMR.
I think 2 is by far the best approach, however it does open up the
question of how and when to execute the operations. I think the easiest
way to do this would be to just start the server in admin only mode on a
custom port (so it will not interfere with any existing running Wildfly
instances), and just execute the CLI commands in admin only mode.
Does this all sound reasonable?
Stuart
9 years, 10 months
Embedding a WF instance in the CLI
by Brian Stansberry
Moving a thread to the dev list.
This is about some prototyping I've been doing on weekends 'cause I'm
bored with my regular tasks. I've been playing with direct local
administration of a WF installation via the CLI without requiring a
socket-based connection. The general use case is initial setup type
activities where the user doesn't want to have to launch a WF server or
HC process and potentially have it be visible on the network.
https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
desire some folks have expressed in being able to do configuration
without first having to edit any xml to avoid port conflicts on 9990 or
9999.
This isn't a major initiative or big priority or anything at this point.
Just something I find interesting and perhaps you will too.
On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
> Neat :) Yes, figuring out the module path is biting everywhere.
> For file system path command line arguments there is a specialized
> FileSystemPathArgument.
>
Thanks; I'll switch to that.
>
> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>> Copying Heiko Braun as he expressed some interest in the topic.
>>
>> BTW, I played with this a bit more last weekend and was able to start an
>> embedded server inside the CLI easily enough. See [1] for very raw
>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>
>> [disconnected/] embed-server
>>
>> There are a couple issues I see, besides the HC stuff I mentioned in my
>> last message.
>>
>> 1) If the CLI is started in a non-modular environment via java -jar
>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>> the jar. And then the embed-server command would need params specifying
>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>> a server installed in any accessible filesystem location.
>>
>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>> running from a WF dist in a modular environment and the embedded server
>> modules are coming from the CLI's own module path. It would be more
>> effort to support embedding a server based on some other module path.
>> Maybe it's no big deal; maybe it's really hard. :)
>>
>> 2) The console logging from the embedded server goes to stdout mixed in
>> with the CLI output. Maybe that's good, maybe it's bad.
>>
>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>
>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>> I was poking around at this for an hour or so over the weekend.
>>>
>>> The standalone case seems pretty straightforward. Seems the existing
>>> embedded server API could work readily enough. The
>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>> ModelControllerClient.
>>>
>>> The domain case is much harder, as the CLI wants a HostController, not a
>>> ProcessController. I'd really like this to use an in-VM client, not a
>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>> an external process. My thoughts of the morning are to allow inverting
>>> the HC/PC relationship for this kind of usage. That is, remove
>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>> a separate process) to manage the server lifecycles. There could be all
>>> sorts of problems with that; it's just the thought for the morning.
>>>
>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>> Embedding the AS is the best starting point to achieve that! And more
>>>> fun, I agree :)
>>>>
>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>> And to think my reason for opening the Jira was just for a common
>>>>> way to
>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>
>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>> Wow! Indeed :)
>>>>>>>
>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>> only
>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>
>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>> implementation of all of them would be based in the server; the
>>>>>> "client"
>>>>>> aspect of the CLI would just use the management interface. The
>>>>>> difference between an embedded mode and what we have now would
>>>>>> just be
>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>> have
>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>> client.
>>>>>>
>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>
>>>>>> Yep.
>>>>>>
>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>> remote
>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>
>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>> probably
>>>>>>> easier to implement at this point.
>>>>>>>
>>>>>>
>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>> thread
>>>>>> where I briefly get into this general area too.
>>>>>>
>>>>>>> Alexey
>>>>>>>
>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>> into
>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>> interesting.
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>> move it
>>>>>>>> into the CLI
>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>> From: Darran Lofthouse (JIRA) <issues(a)jboss.org>
>>>>>>>> To: brian.stansberry(a)redhat.com
>>>>>>>>
>>>>>>>>
>>>>>>>> [
>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin....
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ]
>>>>>>>>
>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>> ----------------------------------------
>>>>>>>>
>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>> this
>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>> SSL
>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>> could
>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>
>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>> other stuff ;-)
>>>>>>>>
>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>> ---------------------------------------------------
>>>>>>>>>
>>>>>>>>> Key: WFLY-3288
>>>>>>>>> URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>> Project: WildFly
>>>>>>>>> Issue Type: Feature Request
>>>>>>>>> Security Level: Public(Everyone can see)
>>>>>>>>> Components: Domain Management, Scripts
>>>>>>>>> Reporter: Darran Lofthouse
>>>>>>>>> Fix For: Awaiting Volunteers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>> where
>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>> way to
>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>> there to
>>>>>>>>> handle this.
>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>> special
>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>> could be
>>>>>>>>> the first step to make this possible.
>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>> comments
>>>>>>>>> here are just a starting point.
>>>>>>>>
>>>>>>>> --
>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>> administrators
>>>>>>>> For more information on JIRA, see:
>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9 years, 10 months
Management model attribute groups
by Brian Stansberry
Off and on we've had discussions around the idea of "attribute groups".
We've got some use cases that are crying out for such a thing[1], so I'd
like to propose doing something concrete but simple for these for WF 9,
ideally in the next month.
A big part of my goal here is to ensure that whatever we do doesn't
preclude something more advanced in any next generation management
stuff, e.g. David's stuff.
PART I Concepts
1) What is an attribute group?
The "attribute group" concept I propose is simply a collection of
attributes associated with the same resource type that are independently
configurable but are statically declared to be conceptually related. The
group has a name, and members. The name provides a brief indication of
the nature of the relationship.
The goal is to provide information to the user to help them better
understand the relationship between attributes. In particular,
management tools could use this information to visually present related
attributes together, e.g. in a tab or other grouping widget in the web
console.
2) What isn't an attribute group?
Something relevant to writes.
3) Why would I use a child resource instead of an attribute group?
Because the attributes control a discrete piece of functionality and you
need to be able to turn that on or off as a unit. So you add/remove the
resource.
4) Why would I use a complex attribute with a bunch of fields instead of
n>1 simple attributes in a group.
a) Because the attributes control a discrete piece of functionality and
you need to be able to turn that off as a unit. So users can undefine
the complex attribute.
b) Because it's a common use case that modifications to n>1 of the
fields should be done atomically and you don't want to force users to
use a CLI batch. So you let them use write-attribute and specify the
value of all the fields.
5) Why would I use an attribute group instead of a child resource?
Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.
6) Why would I use an attribute group instead a complex attribute?
Because the various attributes should be independently configurable. In
particular, wiping out the config for all of them by simply undefining
the complex attribute isn't appropriate.
PART II Proposed Work
1) The basics
We add a piece of metadata to the read-resource-description output for
an attribute. Name is 'attribute-group', value type is ModelType.STRING,
value is the name of the group, with 'undefined' allowed.
The group is simply the set of attributes that share the same string.
To implement this, we add public String
AttributeDefinition.getAttributeGroup() and add support for setting it
to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
2) XML parsing/marshalling
Modify PersistentResourceXMLDescription such that attributes in an
attribute group get persisted in their own child element, whose name is
the name of the group.
PersistentResourceXMLBuilder exposes a setter to allow users to turn
this on/off for that resource. Turning it off will allow the addition of
attribute group settings for a resource without requiring an immediate
corresponding xsd change.
3) Web console
HAL can make use of the additional metadata at its leisure, and as it
becomes available.
4) Low level management API
The output of read-resource and read-resource-description is modified
such that attributes are sorted by group name and then by attribute name.
5) CLI
I'm not clear on exactly what to do here, but my instinct is the output
of the 'ls -l' command should be modified. Probably add a GROUP column
to the right and sort the order of attributes by group and then by
attribute name.
PART III Other possible things to do
A :read-attribute-group(name=<groupname>) operation or an
"attribute-groups=[<groupname>*]" param to :read-resource, to make it
convenient to read a set of attributes without needing to read the
entire resource.
We could also consider adding an "attribute-groups" section to the
read-resource-description output, where a fuller i18n text description
of the meaning of the group could be written. If we do this we should
probably do it in WF 9 as it will likely add some sort of requirement to
subsystem authors that we expose right from the start.
If you're still awake, comments as always are appreciated.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
[1] For example, the JDKORB pull request at
https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
number of places where it seems like attribute groups are a better fit.
9 years, 10 months
Re: [wildfly-dev] WildFly domain on OpenShift Origin
by Thomas Diesler
Lets start with requirements and a design that everybody who has a stake in this can be agreed on - I’ll get a doc started.
> On 18 Dec 2014, at 09:18, James Strachan <jstracha(a)redhat.com> wrote:
>
> If the EAP console is available as a Kubernetes Service we can easily add it to the hawtio nav bar like we do with Kibana, Grafana et al.
>
>> On 17 Dec 2014, at 16:17, Thomas Diesler <tdiesler(a)redhat.com <mailto:tdiesler@redhat.com>> wrote:
>>
>> Thanks James,
>>
>> I’ll look at the fabric8 hawtio console next I see if I can get it to work alongside with the wildfly console. Then I think I should meet with Heiko/Harald (for a long walk) and we talk about this some more.
>>
>> —thomas
>>
>> <PastedGraphic-1.tiff>
>>
>>> On 17 Dec 2014, at 15:59, James Strachan <jstracha(a)redhat.com <mailto:jstracha@redhat.com>> wrote:
>>>
>>> A persistent volume could be used for the pod running the DC; if the pod is restarted or if it fails over to another host the persistent volume will be preserved (using one of the shared volume mechanisms in kubernetes/openshift like Ceph/Gluster/Cinder/S3/EBS etc)
>>>
>>>> On 17 Dec 2014, at 14:42, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote:
>>>>
>>>> On 12/17/14, 3:28 AM, Thomas Diesler wrote:
>>>>> Folks,
>>>>>
>>>>> following up on this topic, I worked a little more on WildFly-Camel in
>>>>> Kubernetes/OpenShift.
>>>>>
>>>>> These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015)
>>>>>
>>>>> * WildFly-Camel on Docker
>>>>> <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/docke... <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/docke...>>
>>>>> * WildFly-Camel on OpenShift
>>>>> <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/opens... <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/opens...>>
>>>>>
>>>>
>>>> Great. :)
>>>>
>>>>>
>>>>> The setup looks like this
>>>>>
>>>>>
>>>>> We can now manage these individual wildfly nodes. The domain controller
>>>>> (DC) is replicated once, the host definition is replicated three times.
>>>>> Theoretically, this means that there is no single point of failure with
>>>>> the domain controller any more - kube would respawn the DC on failure
>>>>>
>>>>
>>>> I'm heading on PTO tomorrow so likely won't be able to follow up on this question for a while, but one concern I had with the Kubernetes respawn approach was retaining any changes that had been made to the domain configuration. Unless the domain.xml comes from / is written to some shared storage available to the respawned DC, any changes made will be lost.
>>>>
>>>> Of course, if the DC is only being used for reads, this isn't an issue.
>>>>
>>>>> Here some ideas for improvement …
>>>>>
>>>>> In a kube env we should be able to swap out containers based on some
>>>>> criteria. It should be possible to define these criteria, emit events
>>>>> based on them create/remove/replace containers automatically.
>>>>> Additionally a human should be able to make qualified decisions through
>>>>> a console and create/remove/replace containers easily.
>>>>> Much of the needed information is in jmx. Heiko told me that there is a
>>>>> project that can push events to influx db - something to look at.
>>>>>
>>>>> If information display contained in jmx in a console has value (e.g in
>>>>> hawtio) that information must be aggregated and visible for each node.
>>>>> Currently, we have a round robin service on 8080 which would show a
>>>>> different hawtio instance on every request - this is nonsense.
>>>>>
>>>>> I can see a number of high level items:
>>>>>
>>>>> #1 a thing that aggregates jmx content - possibly multiple MBeanServers
>>>>> in the DC VM that delegate to respective MBeanServers on other hosts, so
>>>>> that a management client can pickup the info from one service
>>>>> #2 look at the existing inluxdb thing and research into how to automate
>>>>> the replacement of containers
>>>>> #3 from the usability perspective, there may need to be an openshift
>>>>> profile in the console(s) because some operations may not make sense in
>>>>> that env
>>>>>
>>>>> cheers
>>>>> —thomas
>>>>>
>>>>> PS: looking forward to an exiting ride in 2015
>>>>>
>>>>>
>>>>>> On 5 Dec 2014, at 14:36, Thomas Diesler <tdiesler(a)redhat.com <mailto:tdiesler@redhat.com>
>>>>>> <mailto:tdiesler@redhat.com <mailto:tdiesler@redhat.com>>> wrote:
>>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> I’ve recently been looking at WildFly container deployments on
>>>>>> OpenShift V3. The following setup is documented here
>>>>>> <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/fabri... <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/fabri...>>
>>>>>>
>>>>>> <example-rest-design.png>
>>>>>>
>>>>>> The example architecture consists of a set of three high available
>>>>>> (HA) servers running REST endpoints.
>>>>>> For server replication and failover we use Kubernetes. Each server
>>>>>> runs in a dedicated Pod that we access via Services.
>>>>>>
>>>>>> This approach comes with a number of benefits, which are sufficiently
>>>>>> explained in various OpenShift
>>>>>> <https://blog.openshift.com/openshift-v3-platform-combines-docker-kubernet... <https://blog.openshift.com/openshift-v3-platform-combines-docker-kubernet...>>,
>>>>>> Kubernetes
>>>>>> <https://github.com/GoogleCloudPlatform/kubernetes/blob/master/README.md <https://github.com/GoogleCloudPlatform/kubernetes/blob/master/README.md>> and
>>>>>> Docker <https://docs.docker.com/ <https://docs.docker.com/>> materials, but also with a number of
>>>>>> challenges. Lets look at those in more detail …
>>>>>>
>>>>>> In the example above Kubernetes replicates a number of standalone
>>>>>> containers and isolates them in a Pod each with limited access from
>>>>>> the outside world.
>>>>>>
>>>>>> * The management interfaces are not accessible
>>>>>> * The management consoles are not visible
>>>>>>
>>>>>> With WildFly-Camel we have a Hawt.io
>>>>>> <http://wildflyext.gitbooks.io/wildfly-camel/content/features/hawtio.html <http://wildflyext.gitbooks.io/wildfly-camel/content/features/hawtio.html>> console
>>>>>> that allows us to manage Camel Routes configured or deployed to the
>>>>>> WildFly runtime.
>>>>>> The WildFly console manages aspects of the appserver.
>>>>>>
>>>>>> In a more general sense, I was wondering how the WildFly domain model
>>>>>> maps to the Kubernetes runtime environment and how these server
>>>>>> instances are managed and information about them relayed back to the
>>>>>> sysadmin
>>>>>>
>>>>>> a) Should these individual wildfly instances somehow be connected to
>>>>>> each other (i.e. notion of domain)?
>>>>>> b) How would an HA singleton service work?
>>>>>> c) What level of management should be exposed to the outside?
>>>>>> d) Should it be possible to modify runtime behaviour of these servers
>>>>>> (i.e. write access to config)?
>>>>>> e) Should deployment be supported at all?
>>>>>> f) How can a server be detected that has gone bad?
>>>>>> g) Should logs be aggregated?
>>>>>> h) Should there be a common management view (i.e. console) for these
>>>>>> servers?
>>>>>> i) etc …
>>>>>>
>>>>>> Are these concerns already being addressed for WildFly?
>>>>>>
>>>>>> Is there perhaps even an already existing design that I could look at?
>>>>>>
>>>>>> Can such an effort be connected to the work that is going on in Fabric8?
>>>>>>
>>>>>> cheers
>>>>>> —thomas
>>>>>>
>>>>>> PS: it would be area that we @ wildfly-camel were interested to work on
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>
>>>
>>> James
>>> -------
>>> Red Hat
>>>
>>> Twitter: @jstrachan
>>> Email: jstracha(a)redhat.com <mailto:jstracha@redhat.com>
>>> Blog: http://macstrac.blogspot.com/ <http://macstrac.blogspot.com/>
>>>
>>> hawtio: http://hawt.io/ <http://hawt.io/>
>>> fabric8: http://fabric8.io/ <http://fabric8.io/>
>>>
>>> Open Source Integration
>>>
>>
>
>
> James
> -------
> Red Hat
>
> Twitter: @jstrachan
> Email: jstracha(a)redhat.com <mailto:jstracha@redhat.com>
> Blog: http://macstrac.blogspot.com/ <http://macstrac.blogspot.com/>
>
> hawtio: http:/ <http://fusesource.com/>/hawt.io/ <http://hawt.io/>
> fabric8: http:/ <http://fusesource.com/>/fabric8.io/ <http://fabric8.io/>
>
> Open Source Integration
>
9 years, 11 months
Wildfly binary snapshot
by Jim Ma
Hi,
When our community user wants to try the latest wildfly9 snapshot, does
he or she have to git clone our code and build locally ? Can we set up a
job to deploy snapshot binary/artifacts every day or every other day ?
Cheers,
Jim
10 years
bind the server against all interfaces "-b 0.0.0.0" or configuration <any-address/>
by Wolf-Dieter Fink
To use EJB invocations from localhost and remote with IP
I try to bind the server instances against all interfaces with -b
0.0.0.0 or changing the public-interface configuration to <any-address/>.
The client connect the real IP.
I use the ejb-remote quickstart to reproduce.
If I use the standalone.xml profile it works fine.
But change to -ha.xml will fail.
Do I need to use a different configuration to being able to use all
interfaces?
From my point of view this is a bug as I can't configure the server for
all interfaces!
The ejb-remote server side is changed, the jboss-ejb3.xml mark the beans
as Clustered!
If the server starts - with 0.0.0.0 or any-address - JGroups will not
start correct:
17:14:19,522 ERROR [org.jboss.msc.service.fail] (MSC service thread
1-13) MSC000001: Failed to start service jboss.jgroups.channel.ee:
org.jboss.msc.service.StartException in service
jboss.jgroups.channel.ee: java.security.PrivilegedActionException:
java.net.BindException: [UDP] /0.0.0.0 is not a valid address on any
local network interface
at
org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:93)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.PrivilegedActionException:
java.net.BindException: [UDP] /0.0.0.0 is not a valid address on any
local network interface
at
org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:638)
at
org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87)
at
org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:90)
... 5 more
Caused by: java.net.BindException: [UDP] /0.0.0.0 is not a valid address
on any local network interface
at org.jgroups.util.Util.checkIfValidAddress(Util.java:3458)
at
org.jgroups.stack.Configurator.ensureValidBindAddresses(Configurator.java:902)
at
org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:118)
at
org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
at org.jgroups.JChannel.init(JChannel.java:848)
at org.jgroups.JChannel.<init>(JChannel.java:159)
at
org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:84)
at
org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:81)
at
org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:634)
... 7 more
================================
If the server start with "-b MY-IP" and the default standalone-ha.xml,
it works with the following message
and the cluster-connections seems not correct established
INFO: Could not create a connection for cluster node
ClusterNode{clusterName='ejb', nodeName='redhat',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='${jboss.node.name}',
destinationPort=8080}], resolvedDestination=[Destination
address=${jboss.node.name}, destination port=8080]} in cluster ejb
java.lang.RuntimeException: java.io.IOException:
java.net.URISyntaxException: Illegal character in authority at index 7:
http://@${jboss.node.name}:8080/?#
at
org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
at
org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77)
at
org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: java.net.URISyntaxException: Illegal
character in authority at index 7: http://@${jboss.node.name}:8080/?#
at
org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:102)
at
org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
at
org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
at
org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
at
org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
at
org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
at
org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
at
org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
at
org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
... 8 more
Caused by: java.net.URISyntaxException: Illegal character in authority
at index 7: http://@${jboss.node.name}:8080/?#
at java.net.URI$Parser.fail(URI.java:2829)
at java.net.URI$Parser.parseAuthority(URI.java:3167)
at java.net.URI$Parser.parseHierarchical(URI.java:3078)
at java.net.URI$Parser.parse(URI.java:3034)
at java.net.URI.<init>(URI.java:680)
at
org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:100)
at
org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
... 12 more
10 years
WildFly (domain) management in OpenShift V3
by Thomas Diesler
Folks,
I’ve recently been looking at WildFly container deployments on OpenShift V3. The following setup is documented here <https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/fabri...>
The example architecture consists of a set of three high available (HA) servers running REST endpoints.
For server replication and failover we use Kubernetes. Each server runs in a dedicated Pod that we access via Services.
This approach comes with a number of benefits, which are sufficiently explained in various OpenShift <https://blog.openshift.com/openshift-v3-platform-combines-docker-kubernet...>, Kubernetes <https://github.com/GoogleCloudPlatform/kubernetes/blob/master/README.md> and Docker <https://docs.docker.com/> materials, but also with a number of challenges. Lets look at those in more detail …
In the example above Kubernetes replicates a number of standalone containers and isolates them in a Pod each with limited access from the outside world.
* The management interfaces are not accessible
* The management consoles are not visible
With WildFly-Camel we have a Hawt.io <http://wildflyext.gitbooks.io/wildfly-camel/content/features/hawtio.html> console that allows us to manage Camel Routes configured or deployed to the WildFly runtime.
The WildFly console manages aspects of the appserver.
In a more general sense, I was wondering how the WildFly domain model maps to the Kubernetes runtime environment and how these server instances are managed and information about them relayed back to the sysadmin
a) Should these individual wildfly instances somehow be connected to each other (i.e. notion of domain)?
b) How would an HA singleton service work?
c) What level of management should be exposed to the outside?
d) Should it be possible to modify runtime behaviour of these servers (i.e. write access to config)?
e) Should deployment be supported at all?
f) How can a server be detected that has gone bad?
g) Should logs be aggregated?
h) Should there be a common management view (i.e. console) for these servers?
i) etc …
Are these concerns already being addressed for WildFly?
Is there perhaps even an already existing design that I could look at?
Can such an effort be connected to the work that is going on in Fabric8?
cheers
—thomas
PS: it would be area that we @ wildfly-camel were interested to work on
10 years
