| GlassFish 3.2 Administration Console 1.2. Name(s) and e-mail address of Document Author(s)/Supplier: Anissa Lam: anissa.lam@oracle.com 1.3. Date of This Document: April 21, 2011 2. Project Summary 2.1. Project Description: Administration Console (GUI) is one of the tools for application server administrators to configure and monitor the application server. PaaS Administration Console is a simplified console that allows user to deploy application to the cloud and configure Elastic Load Balancing. See below for a longer, more detailed technical description. 2.2. Risks and Assumptions: Many of the new features in the console depends on Admin Infrastructure and other backend teams, the biggest risk is to have the support and API needed by the GUI team in time and according to schedule. Admin Console 3.2 is using REST API for communicating to the server. It is assumed that any features that any sub-project requests to be exposed through the admin console will provide a way for GUI to invoke that through the REST API. The Admin Console will be using the Woodstock components, a JSF component set. Since this is an unsupported product, the GUI team has created a branch for our own use and maintains it. It is assumed that this version will not have major fault that prevents the Admin Console from utilizing it or spend significant time in maintaining it. Although we would prefer to use ADF Faces components, they are unavailable to us due to licensing restrictions. The Admin Console is written on top of the JSFTemplating framework, which is a java.net open source project. It is assumed that JSFTemplating will continue and provide bug fixes if necessary. No major features have been identified for this release. Detecting the available modules for installation or update depends on the API provided by Update Center 2.0. It is assumed that the update center team will continue to support this and fix any issues encountered. PaaS Console will be implemented on another UI framework or using another component set instead of WoodStock. As we are building this from scratch, there may be other unknown risk involved during the project. 3. Problem Summary 3.1. Problem Area: The GlassFish Admin Console needs to provide support for Virtualization, Load Balancer Configuration so that user is not limited to the command line interface. This is especially needed as IaaS and PaaS is the main delivery driver for 3.2 and the Admin Console can greatly enhance the GlassFish user experience. User who is accustomed to the simple steps when using Amazon Beanstalk to deploy new application to the cloud environment may feel overwhelmed with the current admin console, as they may not need all the capabilities and features provided by this advanced console. We need to provide a simplified console with just a few steps to help user in this category. 3.2. Justification: The Admin Console was well received by the community and often viewed as a differentiator from other similar products in the market. For GlassFish 3.2, we need to continue to provide to the user this user friendly administration tool. Besides being a simplified tool for promoting user experience in the cloud, PaaS console will also be served as a prototype for immigrating the advanced console to be build on a new UI framework in 4.0. 4. Technical Description: 4.1. Details: Admin Console will provide support for the following functionality in 3.2 4.1.1 IaaS Management Service (IMS) Configure IMS with a virtualization provider. A top level tree node will be created for Virtualization Providers. Support for this includes listing, creation and deletion of provider. During creation, user will be able to select the particular provider, such as OVM, VirtualBox, Libvert etc. Depending on the selection, meta-data that IMS will need to know about this provider will be required. Virtualization group. After a provider is configured, user can edit this provider to create a virtualization group. In the provider information page, there will be a 'Group' tab. This allows user to define a group of machines for this provider. The information requested from the user will be different depending on the provider. eg, For OVM, virtualization group would map directly to an OVM server pool. For other providers such as VirtualBox, user may need to explicitly add virtualization servers to the group. VM Template. Allows user to make a template known to IMS and associates it with a virtualization provider group. User will be requested to fill in the information such as the path to the VM template, Credentials for logging into template or any othermata-data as required. This is expected to be a long running process and status of the progress should be displayed to user. Cluster Creation. The current cluster pages will need to be modified to support virtual cluster. When creating a cluster, user will decide (by a checkbox) whether this cluster is a virtual cluster. For a virtual cluster, instead of the current instance table where user creates the instances for the cluster providing the node name, other information specific to virtual cluster will be required. This may include the provider name, group name, template, prefix to be used for any instance under this cluster etc. If user indicates this is for elasticity, additional info such as initial, min and max number of instances to be created will be asked. 4.1.2 Load Balancer Configuration Admin console will provide UI to support load balancer configuration similar to v2. This includes adding a top level tree node for Load Balancer, allowing user to list/create/edit/delete load balancers. User can manage the targets for any load balancer. Additional commands including 'Export HTTP lb config', 'Apply HTTP lb changes' or create health checker will be in 3.2. 4.1.3 Progress Status Some of the IMS features will trigger long running process, admin console needs to provide a way to inform user of the progress. Progress information and/or status will be displayed to the user. 4.1.4 Application Scoped Resources Application scoped resource is a feature implemented in 3.1, but not supported in the admin console. For 3.2, this feature will be added. The following will be added:
- Add resources related info while deploying an application
- Add resources tab for each aplication
- Facilitate monitoring of application scoped resources.
4.1.5 Resources Enhancement A couple of resources enhancement that is not provided in 3.1 will be considered for 3.2 release. This includes:
- In JDBC pool, add support for statement-leak-timeout and statement-leak-reclaim fields.
- Add support for List built in validation class names.
- Add support for Introspect field and display the driver class names for installed JDBC drivers.
4.1.6 Monitoring More monitoring support will be in 3.2. GUI team will consider displaying statistics in chart, but this is a nice-to-have feature. The new statistics will include:
- Application based pool monitoring.
- JMS connection factories monitoring.
- Application based monitoring for JMS connection factories. (issue: not available through CLI in 3.1)
4.1.7 JVM specific JVM options JVM options table probably will need to add an optional column for user to specify jvm-specific information. This is described in GLASSFISH-16247 and GLASSFISH-16348 4.1.8. Secure Admin configuration New screen for secure administration will be added for 3.2, allowing user to turn on or turn off secure admin. User can provide additional information such as adminalias and instancealias when they execute the command. Additional information is captured in GLASSFISH-16126. 4.1.9 Service Orchestration Support for Service Orchestration will be provided in the PaaS Console. Application Deployment. There will not be any change in the advance admin console regarding application deployment. User who wants to deploy the application to the cloud will need to use the PaaS console. Since this can be potentially a long running process, status of the progress should be displayed to user. A nice-to-have feature is for console to provide UI to allow user to setup resources or other services needed for this application. GUI team will work with the backend team to see how this feature can be provided. Provisioned Service. After the application is deployed, PaaS console will display all the provisioned service. This includes the Application Scoped Services and Global / Shared Services Global / Shared Services. Admin Console will fully support Global or Shared Services. User will be able to create / delete / list global services in the domain. The general information page for these global or shared services should also list out the applications that is using the service. 4.2. Bug/RFE Number(s): GUI team is committed to addressing all P1 - P3 bugs.
Any Feature or Enhancement request filed will be evaluated on a case-by-case basis. 4.3. In Scope: 4.4. Out of Scope: 4.5. Interfaces: Interfaces may be commands, files, directory structure, ports,
DTD/Schema, tools, APIs, CLIs, etc.
Note: In lieu of listing the interfaces in the one pager, providing
a link to another specification which defines the interfaces
is acceptable. 4.5.1 Exported Interfaces
| Interface |
Stability |
Package Name |
Comments |
| ConsolePluginService |
Evolving |
org.glassfish.api.admingui.ConsoleProvider |
Java API |
| Integration Point |
Evolving |
|
XML-based Admin Console Integration File, OSGi, and through JSFT syntax |
4.5.2 Imported Interfaces
4.5.3 Deprecated/Removed Interfaces: 4.6. Doc Impact: The Online Help doc set needs to be updated accordingly. Additional content will be needed for pages thats added or changed due to PaaS and IaaS support. No new plugin package anticipated at this point, so no new doc set is expected. Other docs that refers to administration using the GlassFish Admin Console may need to include information for the new features in GlassFish Admin Console. 4.7. Admin/Config Impact: Each sub-projects must expose their configuration or commands via the REST API in order for the GlassFish Admin Console to provide administrative support.
There may be changes needed in CLI to support GUI. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: Localization of Admin Console is needed. This includes all the Strings.properties files as well as the context sensitive on line help set. If the REST API is going to participate in localization of content, then the REST API must be capable of accepting the user's preferred locale and returning meta-data that includes the translated strings with the data itself (or some similar solution). If this is done, all REST clients could benefit from centralizing the I18N Strings, although this changes the location in which much of the I18N content is specified for the Admin Console. 4.10. Packaging, Delivery & Upgrade: 4.10.1. Packaging Same as in 3.1. 4.10.2. Delivery Same as in 3.1. Installation will include Admin Console in both the .zip and installer distributions. 4.10.3. Upgrade and Migration: We don't anticipate any impact on upgrade or migration. 4.11. Security Impact: Same as in 3.1. Admin Console will continue to use form authentication as in previous release. We will also need to authenticate the user with the REST API (see REST API spec).
4.12. Compatibility Impact None. 4.13. Dependencies: 4.13.1 Internal Dependencies Admin Console 3.2 heavily dependent on the Admin Infrastructure backend and the REST API. It is important to work with the admin infrastructure and REST API team very closely to resolve any backend issues effecting our implementation. 4.13.2 External Dependencies Refer to the table above regarding Imported Interface. That lists out all our dependencies. 4.14. Testing Impact: There are currently over 100 dev tests that test out the functionality of Admin Console for 3.1
Additional dev test will be written as we finish implementation of each feature. 5. Reference Documents: List of related documents, if any (BugID's, RFP's, papers). 6. Schedule: 6.1. Projected Availability: Refer to Project Page for committed delivery for each Milestone. |
