Thoughts on Administration/Use cases

[acoliver]

For 1.0 we have to have some places where we cut features. The adminstrative system needs to be graphical (thinking of same tech that we use for the webmail). And the following use cases (below). We will specifically NOT include anything regarding changing the datasource or the datasource configuration via the GUI post installation.

1. Install SSL domain
2. Edit SSL domain (keystore, pass)
3. Remove SSL domain
4. Install Queue
5. Remove Queue
6. Edit Queue (name)
7. Edit Virtual Host Configuration (add hosts, remove)
8. Create Domain Group (non-local)
9. Edit Domain Group (non-loca) (add hosts, remove)
10. Add DNS Server
11. Remove DNS Server
12. Edit Service Configuration:
a. SMTP
Auth Required
Auth Allowed
RelayByDomain
Verify Identity
Max MessageSize
Block Size
SSL
TLS Enabled
Require TLS
Require TLS for Auth
Require Client Cert
Postmaster address
MaxReceivedHdrs
ReceivedHeadersThreshold
MaxOwnReceived Headers
Thread Pool Assignment
Bind Address
Port
Timeout
Life
b. POP
Allow APOP
Servername
TLS Enabled
TLS Required
Require Client Cert
SSL
Thread Pool Assignment
Bind Address
Port
Timeout
Life
ThreadPool Assignment
c. IMAP
(fuzzy right now)
13. Create Service Configuration
a. SMTP (see above)
b. POP (above)
c. IMAP (above)
14. Create/Edit Thread Pool
a. Initial
b. Min
c. Max
d. Idle Keep Alive

this is essentially a graphical editor for the jboss-service.xml file. I have the back end support for this written (change, remove, create and persist) minus the actual templates and scenarios (above) and will commit it tomorrow after I goof around with it some more.

In addition I'd like to add what will essentially be an MBean hashtable of mbean names to "pretty names" for use in admin tools.

[lhoriman]

this is essentially a graphical editor for the jboss-service.xml file

How does that work in a cluster?

Jeff

[acoliver]

you geets to got to each node and manage it seperately for 1.0. Have a plan for later releases to implement a heuristic for this. The approach will work for a cluster just the implementation is more complicated then we will be able to accomplish in the remaining time alloted.

[gozilla]

Wouldn't it better than to store all this dynamic config inside the database ? It will then be automatically cluster ready.

The jboss-service.xml would only be used for a blank DB.
Or removed completelly, if the installer can have a part ran against a live instance.

Francois

[acoliver]

And where per say does the DB config go? And what if there IS no database but only LDAP? And how about dependency declaration? And what about unix sysadmins who HATE GUI tools and prefer to push files?

[sappenin]

Would it make sense to NOT use a DB with JBMS? I suppose you could use the filesystem, but it seems like that would be not the best solution. Also, I suppose you could somehow store JBMS message data in an LDAP repository (along with the user credential stuff), but it seems that would be dreadfully slow (LDAP is very efficient for reads, not so much for large amounts of writes).

I'm reminded of the JBoss ON admin tool - it seems to be able to effect changes across multiple Jboss AS's that are managed by the tool -- AND each JBAS uses an XML file and an installed agent. Would it be possible to use that mechanism (there might be licensing issues there)?

David

[gozilla]

And where per say does the DB config go? And what if there IS no database but only LDAP? And how about dependency declaration? And what about unix sysadmins who HATE GUI tools and prefer to push files?

* DB: obviously can't go to the DB. Well, maybe in another DB ;-)

* No DB ? Are you serious ? LDAP anyway can be accessed as a DB, certainly for configs which are a read-mostly pattern.

* dependencies: I didn't though about them. Maybe a database backed virtual file system then ?.

* I hate guis too, but some times, I've to admit they are usefull.

Cheers,

Francois

[acoliver]

But if I have a flat text file and the tools to manage it then what is the problem? I don't have to worry about LDAP vs DB or X or Y or Z....I can leverage the existing JBoss microkernel without writing my won dependency management stuff. And stuff just kinda works... And best of all, I have like 0 more work to do. Now everything is really GUI stuff. All the hard stuff was stuff I'd of had to do anyhow.