[jboss-jira] [JBoss JIRA] (WFCORE-81) Expose address of DC as runtime attributes on the HC

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998002#comment-12998002 ] 

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 at 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)