Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.
The "TomcatGridDiscussion" page has been changed by theimpaler: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=3&rev2=4 * CPU usage * CPU load (1 min, 5, min, 15 min) * Memory usage - * File system drives/mounts space usage (maybe only specific mounts) + * File system space usage for the mount where the "webapps" dir is (can this be different per instance?). == Phase 5 - Command-Line Interface (CLI) == @@ -280, +280 @@ Included features are: - # New commands: #* '''deploy''': deploys a web application (a WAR) to a specific or all grid instances #* '''undeploy''': undeploys a web application to a specific or all grid instances + 1. New commands: + * '''deploy''': deploys a web application (a WAR) to a specific or all grid instances + * '''undeploy''': undeploys a web application to a specific or all grid instances - # Through this operations Tomcat instances will be able to run multiple web applications. + 1. Through this operations Tomcat instances will be able to run multiple web applications. - # The status command is revamped so it now lists all war applications deployed on each instance. + 1. The status command is revamped so it now lists all war applications deployed on each instance. == Phase 9 - Application Version Management == + The application versioning is like a deployment functionality on steroids. The Application Version Management may interfere with the simple Deployment as described before, since it manages web applications in a different manner. It needs to be studied if both modes are compatible and can work at the same time, or if both are mutually exclusive. If the latter, the user will need to choose which mode to use when setting up the grid. @@ -295, +298 @@ Included features are: - # A Release includes one or more deployables. Deployables are WARs, JARs, etc. that will be part of an application we want to deploy on the grid. + 1. A Release includes one or more deployables. Deployables are WARs, JARs, etc. that will be part of an application we want to deploy on the grid. - # Maybe all deployables are deployed to all instances, maybe each deployable goes to a subset of instances. This will need to be specified on the configuration file. + 1. Maybe all deployables are deployed to all instances, maybe each deployable goes to a subset of instances. This will need to be specified on the configuration file. - # Releases are first registered into the Grid (maybe even uploaded) under a client-provided unique Version ID. If no Version ID is provided, the system generates it. Behind the scenes, each release deployable is transferred to the corresponding machines automatically during registration. Since this operation may take a while the release will show the states of loading, ready, or removing. + 1. Releases are first registered into the Grid (maybe even uploaded) under a client-provided unique Version ID. If no Version ID is provided, the system generates it. Behind the scenes, each release deployable is transferred to the corresponding machines automatically during registration. Since this operation may take a while the release will show the states of loading, ready, or removing. - # Releases must be deployed to the grid using the Version ID. Since all deployables are already distributed to all machines, a deployment now corresponds to local copy (or sym link) of each deployable to the Tomcat's webapps dir. The deployment automatically registers which Version ID is now deployed on every instance. The deployment operation can be sent to the whole grid or to a single instance. + 1. Releases must be deployed to the grid using the Version ID. Since all deployables are already distributed to all machines, a deployment now corresponds to local copy (or sym link) of each deployable to the Tomcat's webapps dir. The deployment automatically registers which Version ID is now deployed on every instance. The deployment operation can be sent to the whole grid or to a single instance. - # No two versions are deployed at the same time on a Tomcat instance. When a version is deployed to an instance, the existing one is first unlinked from the instance. It's not actually removed from the grid or the file system, so a rollback operation can be performed quickly if needed. + 1. No two versions are deployed at the same time on a Tomcat instance. When a version is deployed to an instance, the existing one is first unlinked from the instance. It's not actually removed from the grid or the file system, so a rollback operation can be performed quickly if needed. - # New commands are implemented: #* '''register''': loads a new application version into the grid under a unique Version ID #* '''deregister''': removes a non-live application version from the grid #* '''versions''': list all loaded and live Version IDs and where they are deployed #* '''deploy''': deploys all version's deployables to the corresponding instances, unlinking the old ones #* '''rollback''': undeploys the current version from all Tomcat instances, and restores the previous version #* '''deploystop''': deploys all version's deployables to the corresponding instances, but keep the Tomcat instances down #* '''undeploy''': undeploys a version (or a single deployable) from the grid or a subset of the grid + 1. New commands are implemented: + * '''register''': loads a new application version into the grid under a unique Version ID + * '''deregister''': removes a non-live application version from the grid + * '''versions''': list all loaded and live Version IDs and where they are deployed + * '''deploy''': deploys all version's deployables to the corresponding instances, unlinking the old ones + * '''rollback''': undeploys the current version from all Tomcat instances, and restores the previous version + * '''deploystop''': deploys all version's deployables to the corresponding instances, but keep the Tomcat instances down + * '''undeploy''': undeploys a version (or a single deployable) from the grid or a subset of the grid - # As shown above the deploy and undeploy commands are revamped. + 1. As shown above the deploy and undeploy commands are revamped. - # The deploy, rollback, deploystop, and undeploy command may use, behind the scenes, many low-level "link" and "unlink" tasks. These tasks add/remove a deployable to/from an instance correspondingly. + 1. The deploy, rollback, deploystop, and undeploy command may use, behind the scenes, many low-level "link" and "unlink" tasks. These tasks add/remove a deployable to/from an instance correspondingly. - # Each deploy inspects the current state of the grid and saves a Rollback Plan. The rollback commands executes the Rollback Plan. Only one Rollback Plan is saved at any given time. + 1. Each deploy inspects the current state of the grid and saves a Rollback Plan. The rollback commands executes the Rollback Plan. Only one Rollback Plan is saved at any given time. - # The Rollback (if saved) is shown on the Web and CLI interfaces. + 1. The Rollback (if saved) is shown on the Web and CLI interfaces. - # The status operation now also shows for each instance: #* Deployables (the list of war applications deployed in the instance) #* Version IDs #* Deployed at (date & time) + 1. The status operation now also shows for each instance: + * Deployables (the list of war applications deployed in the instance) + * Version IDs + * Deployed at (date & time) - # New hooks are added for the new commands: #* '''pre-register-release''' #* '''post-register-release''' #* '''pre-register-deployable''' #* '''post-register-deployable''' #* '''pre-deregister-release''' #* '''post-deregister-release''' #* '''pre-deregister-deployable''' #* '''post-deregister-deployable''' #* '''pre-deploy''' #* '''post-deploy''' #* '''pre-rollback''' #* '''post-rollback''' #* '''pre-deploystop''' #* '''post-deploystop''' #* '''pre-undeploy''' #* '''post-undeploy''' #* '''unlink''' (unlink: low-level operation that removes a deployable from an instance) #* '''post-unlink''' #* '''pre-link''' (link: low-level operation that adds a deployable to an instance) #* '''post-link''' + 1. New hooks are added for the new commands: + * '''pre-register-release''' + * '''post-register-release''' + * '''pre-register-deployable''' + * '''post-register-deployable''' + * '''pre-deregister-release''' + * '''post-deregister-release''' + * '''pre-deregister-deployable''' + * '''post-deregister-deployable''' + * '''pre-deploy''' + * '''post-deploy''' + * '''pre-rollback''' + * '''post-rollback''' + * '''pre-deploystop''' + * '''post-deploystop''' + * '''pre-undeploy''' + * '''post-undeploy''' + * '''unlink''' (unlink: low-level operation that removes a deployable from an instance) + * '''post-unlink''' + * '''pre-link''' (link: low-level operation that adds a deployable to an instance) + * '''post-link''' == Phase 10 - Collections == + Collections are groups and sub-groups of services (instances and/or agents) that are managed together. Essentially, instead of issuing a command on a single service, you can now issue it onto a collection. The commands will now affect all services in the collection and will probably take longer to complete, since multiple operations are now needed to complete the whole command. Collections may group identical Tomcat instances or maybe Tomcat instances that do not serve the same purpose. For example, one subgroup of Tomcat instances may run the customer facing site (like an HTTP cluster), other group may run the back end site (maybe processing JMS queues), other group may be dedicated to serving or connecting to integration points. Included features are: - # The following commands can now be issued on collections in addition to plain services: #* status #* trigger-start #* trigger-stop #* trigger-kill #* start #* stop #* kill #* restart #* killstart #* deploy #* rollback #* deploystop #* undeploy + 1. The following commands can now be issued on collections in addition to plain services: + * status + * trigger-start + * trigger-stop + * trigger-kill + * start + * stop + * kill + * restart + * killstart + * deploy + * rollback + * deploystop + * undeploy - # Hooks are modified to provide information of the collection they are affecting. + 1. Hooks are modified to provide information of the collection they are affecting. - # When a hook runs on a collection, it runs on the machine where the manager application (web or cli) runs, not remotely on the machine of any other instance. This is because in this case the execution is not tied to a specific instance, but to a collection. + 1. When a hook runs on a collection, it runs on the machine where the manager application (web or cli) runs, not remotely on the machine of any other instance. This is because in this case the execution is not tied to a specific instance, but to a collection. - # Services defined in a collection can be managed in sequential or parallel modes. For example, a restart command on a sequential collection will restart the second service only, when the first one has fully completed. Once the second completes, it will restart the third one, and so on. A parallel collection would issue a restart on all services simultaneously. + 1. Services defined in a collection can be managed in sequential or parallel modes. For example, a restart command on a sequential collection will restart the second service only, when the first one has fully completed. Once the second completes, it will restart the third one, and so on. A parallel collection would issue a restart on all services simultaneously. - # Collections are defined in the configuration file and are of a recursive nature: a collection can include plain services, other collections, or both. For sequential mode, each "sub-collection" is treated as a single element so it's considered fully complete when all its included services and collections complete. + 1. Collections are defined in the configuration file and are of a recursive nature: a collection can include plain services, other collections, or both. For sequential mode, each "sub-collection" is treated as a single element so it's considered fully complete when all its included services and collections complete. - # [To be analyzed and defined if it's useful or not] Collections editing through the Web interface. This can be useful to graphically update collections when machines/instances are added/removed. + 1. [To be analyzed and defined if it's useful or not] Collections editing through the Web interface. This can be useful to graphically update collections when machines/instances are added/removed. == Phase 11 - Instance Configuration == + The Web interface adds functionality to specify Tomcat instances configuration from the centralized location. The CLI interface does not offer this functionality. [to be discussed] Included features are: - # Using the Web interface the user can change instance's configuration remotely. This operation allows the instances to be changed remotely, for example to: #* Add libraries (typically JDBC drivers, MQ drivers, JSF, etc.) #* Set JVM parameters (memory settings, GC behavior, JVM tweaking, etc.) #* Prepare (add/change/remove) JDBC data sources #* Set context parameters #* Set JNDI entries #* View required WAR resources, and set resources values accordingly #* Changing listeners #* Other instance configurations + 1. Using the Web interface the user can change instance's configuration remotely. This operation allows the instances to be changed remotely, for example to: + * Add libraries (typically JDBC drivers, MQ drivers, JSF, etc.) + * Set JVM parameters (memory settings, GC behavior, JVM tweaking, etc.) + * Prepare (add/change/remove) JDBC data sources + * Set context parameters + * Set JNDI entries + * View required WAR resources, and set resources values accordingly + * Changing listeners + * Other instance configurations == Phase 12 - Instance Provisioning == + This functionality removes the necessity of a manual setup of all machines and Tomcat instances of the Grid. After installing the first Tomcat instance and deploying the Web Manager, provisioning operations to local or remote machines can be performed through the web interface. Because of its nature, the implementation of the provisioning operations is heavily OS dependent. @@ -356, +413 @@ Included features are: - # The provisioning operation will automate the following tasks: #* Login into a machine #* Installing the Grid Agents #* Configuring & running the Grid Agent #* Installing the Tomcat instances #* Configuring the Tomcat instances #* Configuring the environment (shell variables, other) + 1. The provisioning operation will automate the following tasks: + * Login into a machine + * Installing the Grid Agents + * Configuring & running the Grid Agent + * Installing the Tomcat instances + * Configuring the Tomcat instances + * Configuring the environment (shell variables, other) - # Using the Web and Command-Line interfaces the user can provision the Grid. Typical operations can be: #* Adding a new machine to the Grid. #* Removing a machine from the Grid. #* Adding a new instance to a machine. #* Removing an instance from a machine. + 1. Using the Web and Command-Line interfaces the user can provision the Grid. Typical operations can be: + * Adding a new machine to the Grid. + * Removing a machine from the Grid. + * Adding a new instance to a machine. + * Removing an instance from a machine. - # Once new machine is registered, the machine's Agent is installed and executed. + 1. Once new machine is registered, the machine's Agent is installed and executed. - # To deregister a machine all instances must have been removed first. + 1. To deregister a machine all instances must have been removed first. - # If a machine is deregistered, the Agent is stopped and optionally uninstalled. Maybe we'll leave it there, so it will be easier in the future to re-provision the machine. + 1. If a machine is deregistered, the Agent is stopped and optionally uninstalled. Maybe we'll leave it there, so it will be easier in the future to re-provision the machine. - # Once a new instance is created the following operations are performed: #* Registering the machines on the grid configuration file #* Standard instance's directory tree is copied #* All the instance extra configuration (libraries, JDBC data sources, etc.) are performed #* No deployments are installed yet. + 1. Once a new instance is created the following operations are performed: + * Registering the machines on the grid configuration file + * Standard instance's directory tree is copied + * All the instance extra configuration (libraries, JDBC data sources, etc.) are performed + * No deployments are installed yet. - # To remove an instance, all deployables must have been undeployed first. + 1. To remove an instance, all deployables must have been undeployed first. - # Once an instance is removed: #* The instance is removed from the configuration file and any collection that included it #* All deployments are removed from it #* The whole directory tree for it is removed on the remote machine + 1. Once an instance is removed: + * The instance is removed from the configuration file and any collection that included it + * All deployments are removed from it + * The whole directory tree for it is removed on the remote machine - # The provisioning operations require remote access to the new machine, and therefore some kind of connections needs to be setup. For example, an SSH connection could be used if the user provides the user name/password credentials or if if an ssh key exchange had been previously setup between the machines. + 1. The provisioning operations require remote access to the new machine, and therefore some kind of connections needs to be setup. For example, an SSH connection could be used if the user provides the user name/password credentials or if if an ssh key exchange had been previously setup between the machines. == Phase 13 - Custom Commands == + [To be described] == Phase 14 - Version Repository == + [To be described] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
