[
https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin....
]
Brian Stansberry commented on WFCORE-81:
----------------------------------------
It belongs somewhere in /host=hc-1 itself. Not in the core-service=host-environment child
as that resource is about the environmental info the HC picked up at initial boot, i.e.
stuff that comes in from the command line.
The most relevant place is the domain-controller attribute on the /host=hc-1 resource:
{code}
[domain@localhost:9999 host=slave-a] :read-resource
{
"outcome" => "success",
"result" => {
"directory-grouping" => "by-server",
"domain-controller" => {"remote" => {
"port" => expression
"${jboss.domain.master.port:9999}",
"host" => expression "${jboss.domain.master.address}",
"username" => undefined,
"admin-only-policy" => undefined,
"security-realm" => "ManagementRealm"
}},
{code}
That would need something like "resolved-scheme", "resolved-host" and
"resolved-port" fields added. The "resolved-scheme" comes in because
of WFCORE-75 which is currently being worked on. We can no longer assume the protocol
scheme is "remote".
My thinking is we only expose this for the slave HC's; i.e. it's part of that
domain-controller => remote structure that only exists on a slave. We don't add
something to the domain-controller => local structure that exists on the master,
because it would be redundant, and once WFCORE-75 is done, vague. The way to learn about
how to communicate with any HC that you're already connected to is via the existing
/host=*/core-service=management/management-interface=* resources.
As for what class to use to expose this... that's a tough question. Looking at this,
it's quite complex. Possible places are
org.jboss.as.host.controller.MasterDomainControllerClient or
org.jboss.as.domain.controllerLocalHostControllerInfo.
The way that domain-controller attribute is handled would need to change though. Currently
its contents are set once via RemoteDomainControllerAddHandler (for the slave aka remote
case) and LocalDomainControllerAddHandler (for the master aka local case) and thereafter
reading that attribute is a simple, using the default read handler. But now
HostResourceDefinition L250 would need to register a custom read handler instead of null,
one that can read the add in the dynamically determined "resolved-scheme",
"resolved-host" and "resolved-port" fields.
So, not a simple task.
Expose address of DC as runtime attributes on the HC
----------------------------------------------------
Key: WFCORE-81
URL:
https://issues.jboss.org/browse/WFCORE-81
Project: WildFly Core
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Domain Management
Reporter: Heiko Rupp
Labels: rhq
Currently there is no way to learn about the http management port of the DC from a
slave's host.xml or runtime.
17:02:31] <pilhuhn> I am reading host.xml to find the DC, so that I can contact its
http port for e.g. querying the /socket-binding-group if the one on the host is undefined
[17:02:41] <+bstansberry> I don't want it in the config, but I'm ok with
adding it as a runtime attribute
[17:04:13] <pilhuhn> bstansberry fine with me when I can query the HC for the http
port of the DC
[17:04:46] <+bstansberry> pilhuhn: the native API port should be a runtime
attribute as well
[17:04:51] <+bstansberry> yes please
[17:05:04] <+bstansberry> what i mean by that is we should expose it as a runtime
attribute
17:05:49] <+bstansberry> the config bit is an instruction to the HC, but we are
going to add alternatives, e.g. a multicast address
[17:06:55] <+bstansberry> so using the config will not be a reliable source;
runtime can be
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)