5:44 a.m.
Referring to:
https://community.jboss.org/wiki/DomainManagementModelDesign
"Internally, the object model representing the domain configuration for a standalone
server may be quite similar to that shown above. However, the XML configuration schema and
perhaps the management API will be simplified to remove extraneous concepts like the
ServerGroup. (Whether creating a distinct management API for this use case is appropriate
needs discussion. A separate API means clients like JON and the embedded console need to
be coded against two APIs in order to cover all use cases.)"
Creating to API's doesn't make sense at all. Instead we should try to collapse the
concepts when used standalone. I.e. by referencing a default server group
"standalone".
What domain model concepts can you think of that don't match the standalone
scenario?
Ike
10:59 a.m.
On 01/11/2011 04:44 AM, Heiko Braun wrote:
Referring to:
https://community.jboss.org/wiki/DomainManagementModelDesign
[...]
Creating two API's doesn't make sense at all. Instead we should try to
collapse the concepts when used standalone. I.e. by referencing a
default server group "standalone".
There is actually only one API. The data organization changes to an
extent in domain mode.
However in standalone mode there is no concept of a server group for
example, nor a concept of domain-level deployments. Instead, in the
standalone sense, deployments encompass some features of both of these
concepts. The view *must* be different, I'm sorry. But the good news
is, a lot of it should be reusable.
In fact my feeling is that the view should be fully dynamic, but we
shall see if that is even possible.
What domain model concepts can you think of that don't match the
standalone scenario?
Many operations simply don't make sense in a standalone situation, like
anything involving deployment plans, server control, or multiple servers
in one operation.
The data organization is fairly different too. The management model
hierarchy is more like this:
domain
+-- profiles
| +-- web
| | +-- subsystems
| | +-- web
| | | +-- connector...
| | +-- remoting
| | +-- blah blah
| +-- another
| +-- subsystems
| +-- blah
+-- host foo
| +-- server bar
| +-- a bunch of other stuff
| +-- server baz
+-- host bar
| +--- server bar
| +--- server bzt
+-- deployments
| +--- foo.war
| +--- bar.ear
+-- server group blah = profile web
| +--- deployments
| +-- foo.war
+-- server group blah = profile another
| +--- deployments
| +-- bar.ear
...
in standalone it's more like:
server
+-- profile
| +-- subsystems
| +-- web
| | +-- connector...
| +-- remoting
| +-- blah blah
+-- deployments
| +-- foo.war
| +-- bar.ear
...
So you see, the data is the same in many cases but the organization and
addressing is different. There is just one API, however you have to use
more complex addressing in the domain case to distinguish between
multiple items where in the standalone case there is just one, or none
of that item.
Hope this clarifies things.
--
- DML
11:09 a.m.
On 1/11/11 4:44 AM, Heiko Braun wrote:
Referring to:
https://community.jboss.org/wiki/DomainManagementModelDesign
"Internally, the object model representing the domain configuration for
a standalone server may be quite similar to that shown above. However,
the XML configuration schema and perhaps the management API will be
simplified to remove extraneous concepts like the ServerGroup. (/Whether
creating a distinct management API for this use case is appropriate
needs discussion. A separate API means clients like JON and the embedded
console need to be coded against two APIs in order to cover all use
cases./)"
Creating to API's doesn't make sense at all. Instead we should try to
collapse the concepts when used standalone. I.e. by referencing a
default server group "standalone".
What domain model concepts can you think of that don't match the
standalone scenario?
Maybe there aren't any. Please forgive the long journey I'm about to go
on...
There are two main difficulties:
1) A standalone mode server exposes some operations that are not
available to a domain mode server. E.g. in domain mode the alias of a
virtual host is a domain level configuration, and can't be independently
altered on an individual server.
2) In domain mode, a server's configuration is synthesized from two
inputs: domain.xml and server.xml. The model exposed by the management
API (from DomainController) reflects those inputs:
(If e-mail mangles this, see http://pastebin.com/2a2GV0iA)
{
"profile" => {
"default" => {
// domain-wide config here
}
},
"server-group" => {
"group1" => {
"profile => "default"
...
}
},
"host" => {
"host1" => {
"interface" => {
"public" => {
"ip-address" => "10.0.0.1"
}
}
"server-config" => {
"server-one" => {
// host-specific configs here
}
},
"server" => {
"server-one" => {
"profile" => {
"default" => {
// read-only view
}
}
"interface" => {
"public" => {
// read-only view
}
}
}
}
}
}
}
The "profile" and "server-group" elements above reflect what's in
domain.xml.
The "host/host1" element above represents a particular HostController's
portion of the model.
The "host/host1/interface" and "host/host1/server-config" elements
represent what's in host1's host.xml.
The "host/host1/server/server-one" element represents server-one's view
of the model. In terms of configuration, it's a read-only view of the
synthesis of relevant stuff from domain.xml and host.xml. The details of
"host/host1/server/server-one/profile/default" are not directly writable
via the management API; the update operations are in "profile/default"
at the domain level.
In standalone mode, the view is simpler:
{
"profile" => {
"default" => {
// writable view
}
}
"interface" => {
"public" => {
// writable view
}
}
}
That directly represents what's in standalone.xml, and the details are
writable.
Now, it is possible to eliminate (at least internally) that simple view
for standalone mode. Essentially, standalone mode could "desynthesize"
the standalone.xml content and pretend everything either came from a
domain.xml or a host.xml. The internal model representation would then
look like the complex one above. The operations available from the
different addresses would then be identical.
TBH, doing it that way will probably solve a lot of internal problems.
And I can certainly see how it makes life easier for sophisticated
clients, like the console code itself.
The downside to it is it's conceptually confusing for standalone mode users.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
5:52 a.m.
Am 11.01.2011 um 11:44 schrieb Heiko Braun:
Creating to API's doesn't make sense at all. Instead we
should try to collapse the concepts when used standalone. I.e. by referencing a default
server group "standalone".
+1 - I thought we had this already in Antwerp?
For the standalone case just use some "defaults" for domain and profile. Parts
of the tree that don't make sense,
will return "an empty collection" which the API user would not need to display.
And if standalone as some API methods enabled that aren't for domain mode, just expose
them
in both modes and return some "wrong mode" exception if they are called in wrong
mode.
Aside from admin console/RHQ, other users will also like to have only one api to code
against.
Especially when writing CLI scripts against the standalone mode (don't want to fire n
instances) and
then later want to port them over to a domain.
Heiko (pilhuhn)
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
9:44 a.m.
On 01/12/2011 04:52 AM, Heiko W.Rupp wrote:
Am 11.01.2011 um 11:44 schrieb Heiko Braun:
> Creating to API's doesn't make sense at all. Instead we should try
> to collapse the concepts when used standalone. I.e. by referencing
> a default server group "standalone".
+1 - I thought we had this already in Antwerp?
For the standalone case just use some "defaults" for domain and
profile. Parts of the tree that don't make sense, will return "an
empty collection" which the API user would not need to display. And
if standalone as some API methods enabled that aren't for domain
mode, just expose them in both modes and return some "wrong mode"
exception if they are called in wrong mode.
Why, when it's just a question of asking the server "what operations are
available"? Very little of the tree is actually the same between domain
and standalone - applying this kind of logic is just going to create
lots of places where things can be broken.
Aside from admin console/RHQ, other users will also like to have
only
one api to code against.
Of course there is only one API...
Especially when writing CLI scripts against the standalone mode
(don't want to fire n instances) and then later want to port them
over to a domain.
What kind of API unification do you think we can do here? If they run a
standalone script against a domain and want to modify some server
parameter directly, they have to specify which server they want to talk
to. No amount of unification will change that. And some things just
aren't going to work - if you want to add a deployment in domain mode,
the steps are just not quite the same, no matter what.
I think you should make an effort to understand the API a bit more
before you criticize how it is organized.
--
- DML
4852
days inactive
4853
days old
4 comments
4 participants
participants (4)
-
Brian Stansberry -
David M. Lloyd -
Heiko Braun -
Heiko W.Rupp