Design proposals improve usability and robustness of the RHQ content subsystem.
Intuitive Deployment and Lifecycle Management
Ease of common operations
Robust Deployment options
Group Deployment
Backward compatibility
|
Jira |
Title |
|
Content Security System |
|
|
Upload new package UI needs to be customized per type |
|
|
Packages > New > Upload New Package silent accepts jar files as CPs. |
|
|
Cannot deploy WAR file to JBoss server with WebKit browsers (Safari, Google Chrome) |
|
|
Clicking on "create" button without first selecting the type of the new child resource results in a |
|
|
Add ability to schedule a deployment for the future |
|
|
Unable to install packages from the channel view |
|
|
Be able to schedule a WAR/EAR create operation |
|
|
Link ear/war backup creation into content subsystem |
|
|
Application deployment via JOPR |
|
|
Patching process is too eager when acquiring write lock on JBAS resource |
|
|
Patch process timeout too short |
|
|
add support for deploying EARs, WARs, EJB-JARs to all members of a JBossAS Server compatible group |
Confusion due initial deployment via "Create New" (Inventory tab of parent) and subsequent deployment via Content Tab of the Resource
Cumbersome and confusing steps surrounding Content Source/Channel/Resource definition and association
Lack of clarity around what package types are deployable from where in the UI
JBoss AS does not support Jar file update
AS EAR file representation issues
resource hierarchy does not reflect EAR relationships (e.g. SLSB resources child of AS, not EAR)
Can leave "dead" resources on EAR delete
There are several things at play and it is important to keep in mind the various responsibilities of the components involved in deployment. Weaknesses perceived in RHQ deployment can result from different parts of the puzzle, or interactions between them.
Responsible for representing, manipulating and presenting to the user deployed resources, their version history, and deployable content. Coordination of group work.
Responsible for interacting with the plugin to report on deployed content and carry out deployment work on behalf of the server/user.
Responsible for actually discovering deployed content, deploying new content, redeploying or patching existing content. Also, for deleting (partially) deployed content.
Responsible for hosting deployed content and exposing it as needed for management by the plugin.
Overall dissatisfaction with RHQ deployment can be blamed on each of these areas for different shortcomings. It is important to distinguish between RHQ infrastructure/feature issues and issues in the specific plugin (typically JBoss AS plugin). And also, deficiencies in the underlying product (typically, JBoss AS) that may make offering certain features difficult, unreliable, or impossible.
For schedule and compatibility reasons we want to leverage the work already done, and be backward compatible. We can deprecate the use of certain constructs, and add new ones as needed but the more that can be carried forward the better. The goal is first to improve end user experience, second to allow for group deployment, and third, to ease plugin development.
The existing mechanism has strengths but in practice can be cumbersome for several reasons:
New deployments (via "Create New") ignore Content Sources and Repos and are restricted to File Upload.
Content Sources can be tricky to set up.
Can require a lot of tricky options be defined (architecture, download options, package type names, resource type names, plugin names, etc).
Repo relationships can be cumbersome. Updating deployed resources from a repo requires:
Defining content sources
Associating a repo with content sources
Synchronizing repos
Associating the (existing) resource with repo(s)
The idea here is to remove the need for Repo definition in the typical scenario of a 1-1 association between CS and Repo.
The Inventory Repo offers all package-versions previously deployed and accessible to the server (via database or file system). This set of package versions needs to be indexed in some way to allow users to distinguish between packages of the same name. A natural indexing scheme exists in the resource hierarchy itself. By being able to display the resource hierarchies of selected package versions it should allow sufficient distinction for selection.
To be available to the Inventory Repo the package-version would had to be deployed to a resource in inventory as well as having accessible bits. Accessible bits would be in the database or file system, typically from a content source download. Or possibly stored at file upload time (the latter being a new option we may need to add).
Available Package-versions in the Inventory Repo would be restricted to those deployed to an accessible resource for the user.
An alternate, or complimentary scheme, would allow a user to select a deployed package from an existing resource for deployment to other resources. How this would work in the GUI is not exactly clear as only a (small) subset of packages would be eligible.
Other possible names: Default Repo, Deployed Repo, Global Repo ?
I believe that this simplifies our workflow and enhances usability. It may still be required in certain cases (like platform yum install) but for GUI based deployment I'm in favor of removing this relationship altogether. The idea here is to not require predefining repos available to a resource. Instead the user chooses the package-version in an ad-hoc fashion at deploy time. It could be thought of as ad-hoc, temporary association but basically it's just a deploy time package-version selection from:
An existing content source (implicit repo)
An existing repo
The "Inventory" repo
File upload
I think a user with the permissions necessary to perform a deployment should have access to all the defined repos for selection. If we really had to I suppose we could restrict repo access based on (optional) Role-Repo association, but my initial feeling is that this is not necessary.
We already have some semblance of group deploy. More than that, we can deploy multiple packages to multiple resources in one fell swoop. Here's the kicker, it's done via the Admin Repos Repo Detail page. You can install selected packages from the repo to all of the subscribed resources for the repo.
This is another example of content handling well outside of any standard workflow. I recommend this button be removed and that we employ standard resource groups for deploying to multiple resources. I would probably recommend that we also limit deploy requests to a single packageversion per request.
This mechanism is unmoderated, we kick off the deploy requests but all status/history is maintained at the resource level. There is no aggregrated view into the status of the multiple deploy requests. We could do the same in a first version of group deploy although I think a better option would be to provide group request status, similar to group config update or operation requests.
Removal of this mechanism also plays well with the removal of resource-repo associations.
The overriding proposal here is to consolidate what users consider deployment in a single place, the "Deploy Tab (D)".
The Deploy Tab will appear on resource types that have non-creatable <content> defined or creatable <content> defined on a child resource type. It will have the following Subtab structure:
Deploy
Child Update Bundle History
Resource types that are logically "containers" will have "Create New" functionality moved from the Inventory to the Deploy->Child Subtab. It will be grayed out if there is no creatable child resource type. Otherwise, the Child subtab will allow all the same options for selecting the backing package to use for creation as exists for Update. This is different than before, where the option was only file upload. These options are those proposed above:
A defined Content Source (implicit repo)
A defined Repo (explicit repo)
The Inventory Repo (implicit repo)
File upload
Note that the first three choices could probably be consolidated into one list.
After package selection the workflow is as before.
Update the current resource, i.e. a patch. It will be grayed out if the content facet is not implemented for the resource type.
The Update Subtab is active if the resource type has non-creatable <content> defined. It would allow deploy of a package type associated with the current resource type (e.g. for AS, a patch or a jar).
It would display the currently deployed package-versions (like today's Content->deployed subtab). To update a deployed package-version the user would select it (radio button, maybe checkbox) and click something like "Deploy Update". It would then kick off the package-version selection and deploy workflow.
Deploy a Bundle to this resource. This should probably just kick off the bundle deployment wizard and preset the resource id. Or, possibly is should list the previously deployed bundles and present a button to kick off a new deployment.
The history subtab would basically mimic the current Content->History subtab although would probably require some filters to narrow the list in various ways.
The basic idea here is to be able to request a package deployment across a cluster/compatible group. Each deployment would be performed with the same content configuration.
A Compatible group would offer a Deploy Tab by the same criteria as would one of its members (non-creatable <content> defined or creatable <content> defined on a child resource type). It would offer the same subtabs: New, Patch, Deploy, History.
Basically the same as the analogous resource subtab but will create the child across the group members.
Basically the same as the analogous resource subtab but will update all group members.
Basically the same as the analogous resource subtab but will bundle deploy to all group members.
There are various levels of robustness we could put in place for group deployment.
No group status: Just mke the deployment requests and that's it.
Like group config update: Something analogous, with potentially the same complexity and fragility.
Workflow: Introduce a more generic workflow mechanism that can handle state transition, dependencies, asynchronous steps, and recovery in a clear and dependable way.
We may also want to provide a "Delete" button for group delete of a deployed resource, assuming it allows Delete.
Group deploy is not all or nothing, some can succeed and some can fail.
We may want an option for not redeploying the same version. (so you can retry a group deploy w/o redeploying previous successes.)
6. History Subtab
This should be analogous to the resource level but the requests would be group deployment requests. Details of what this should look like are not clear yet but perhaps can leverage the look and feel of group config update.
Not Supported.
I think most of this falls into the category of plugin and product. We need to ensure that customers can deploy and undeploy what they want (EAR, WAR, JAR, other?), on each supported version of the product, on each supported platform, with a variety of options. Support for different package types is the responsibility of the plugin. The rest is, I think, mainly a increased testing effort. At least to test scenarios that have failed for customers. It means using real-world ear/wars with a variety of configurations.
Does the new UrlContentSource with XML backing replace the need for DiskCS, HttpCS or even PatchCS?
What is the status of YumCS?
We will continue to ship DiskCS even if UrlCS is fully functioning. If for no other reason then for backward compatibility. The docs should indicate that it is deprecated and the UrlCS should be used in its place. All other ContentSource types will continue to ship (in all packaging flavors) as each has distinct advantages. We'll continue to look at any simpifications we can introduce into the CS configs.
At the moment we have no hooks for anything like this. It's not clear to me what it is we would offer above the current ability for the plugin to provide a relevant operation or something like that. I don't know what kind of extension to the ContentFacet would be helpful.
I'm not sure this is a very typical case.
It may be the case that we deploy a new package successfully but the package can not be hosted, started, etc. In this case we will not discover the resource. If it can not be manually added then there is no way via JON to clean up the situation. The package will need to be removed outside of JON.
Design proposals improve usability and robustness of the RHQ content subsystem.
Intuitive Deployment and Lifecycle Management
Ease of common operations
Robust Deployment options
Group Deployment
Backward compatibility
|
Jira |
Title |
|
Content Security System |
|
|
Upload new package UI needs to be customized per type |
|
|
Packages > New > Upload New Package silent accepts jar files as CPs. |
|
|
Cannot deploy WAR file to JBoss server with WebKit browsers (Safari, Google Chrome) |
|
|
Clicking on "create" button without first selecting the type of the new child resource results in a |
|
|
Add ability to schedule a deployment for the future |
|
|
Unable to install packages from the channel view |
|
|
Be able to schedule a WAR/EAR create operation |
|
|
Link ear/war backup creation into content subsystem |
|
|
Application deployment via JOPR |
|
|
Patching process is too eager when acquiring write lock on JBAS resource |
|
|
Patch process timeout too short |
|
|
add support for deploying EARs, WARs, EJB-JARs to all members of a JBossAS Server compatible group |
Confusion due initial deployment via "Create New" (Inventory tab of parent) and subsequent deployment via Content Tab of the Resource
Cumbersome and confusing steps surrounding Content Source/Channel/Resource definition and association
Lack of clarity around what package types are deployable from where in the UI
JBoss AS does not support Jar file update
AS EAR file representation issues
resource hierarchy does not reflect EAR relationships (e.g. SLSB resources child of AS, not EAR)
Can leave "dead" resources on EAR delete
There are several things at play and it is important to keep in mind the various responsibilities of the components involved in deployment. Weaknesses perceived in RHQ deployment can result from different parts of the puzzle, or interactions between them.
Responsible for representing, manipulating and presenting to the user deployed resources, their version history, and deployable content. Coordination of group work.
Responsible for interacting with the plugin to report on deployed content and carry out deployment work on behalf of the server/user.
Responsible for actually discovering deployed content, deploying new content, redeploying or patching existing content. Also, for deleting (partially) deployed content.
Responsible for hosting deployed content and exposing it as needed for management by the plugin.
Overall dissatisfaction with RHQ deployment can be blamed on each of these areas for different shortcomings. It is important to distinguish between RHQ infrastructure/feature issues and issues in the specific plugin (typically JBoss AS plugin). And also, deficiencies in the underlying product (typically, JBoss AS) that may make offering certain features difficult, unreliable, or impossible.
For schedule and compatibility reasons we want to leverage the work already done, and be backward compatible. We can deprecate the use of certain constructs, and add new ones as needed but the more that can be carried forward the better. The goal is first to improve end user experience, second to allow for group deployment, and third, to ease plugin development.
The existing mechanism has strengths but in practice can be cumbersome for several reasons:
New deployments (via "Create New") ignore Content Sources and Channels and rely on File Upload.
Content Sources can be tricky to set up.
Can require a lot of tricky options be defined (architecture, download options, package type names, resource type names, plugin names, etc).
Channel relationships can be cumbersome. Updating deployed resources from a channel requires:
Defining content sources
Associating a channel with content sources
Synchronizing Content sources
Associating the (existing) resource with channel(s)
The idea here is to remove the need for channel definition in the typical scenario of a 1-1 association between CS and Channel.
The Inventory Channel offers all package-versions previously deployed and accessible to the server (via database or file system). This set of package versions needs to be indexed in some way to allow users to distinguish between packages of the same name. A natural indexing scheme exists in the resource hierarchy itself. By being able to display the resource hierarchies of selected package versions it should allow sufficient distinction for selection.
To be available to the Inventory Channel the package-version would had to be deployed to a resource in inventory as well as having accessible bits. Accessible bits would be in the database or file system, typically from a content source download. Or possibly stored at file upload time (the latter being a new option we may need to add).
Available Package-versions in the Inventory Channel would be restricted to those deployed to an accessible resource for the user.
An alternate, or complimentary scheme, would allow a user to select a deployed package from an existing resource for deployment to other resources. How this would work in the GUI is not exactly clear as only a (small) subset of packages would be eligible.
Other possible names: Default Channel, Deployed Channel, Global Channel, Download Channel, Global Repository ?
I believe that this simplifies our workflow and enhances usability. So much so that I'm in favor of removing this relationshiop altogether (I don't see this as a backward compatibility issue). Minimally, it could be made optional. The idea here is to not require predefining channels available to a resource. Instead the user chooses the package-version in an ad-hoc fashion at deploy time. It could be thought of as ad-hoc, temporary association but basically it's just a deploy time package-version selection from:
An existing content source (implicit channel)
An existing channel
The "Deployed" channel (see below)
File upload
I think a user with the permissions necessary to perform a deployment should have access to all the defined channels for selection. If we really had to I suppose we could restrict channel access based on (optional) Role-Channel association, but my initial feeling is that this is not necessary.
We already have some semblance of group deploy. More than that, we can deploy multiple packages to multiple resources in one fell swoop. Here's the kicker, it's done via the Admin Channels Channel Detail page. You can install selected packages from the channel to all of the subscribed resources for the channel.
This is another example of content handling well outside of any standard workflow. I recommend this button be removed and that we employ standard resource groups for deploying to multiple resources. I would probably recommend that we also limit deploy requests to a single packageversion per request.
This mechanism is unmoderated, we kick off the deploy requests but all status/history is maintained at the resource level. There is no aggregrated view into the status of the multiple deploy requests. We could do the same in a first version of group deploy although I think a better option would be to provide group request status, similar to group config update or operation requests.
Removal of this mechanism also plays well with the removal of resource-channel associations.
The overriding proposal here is to consolidate what users consider deployment in a single place, the "Deployment Tab (D)".
The Deployment Tab will appear on resource types that have non-creatable <content> defined or creatable <content> defined on a child resource type. It will have the following Subtab structure:
Deployment
New Patch Deploy History
Resource types that are logically "containers" will have "Create New" functionality moved from the Inventory to the Deploy->New Subtab. It will be grayed out if there is no creatable child resource type. Otherwise, the New subtab will allow all the same options for selecting the backing package to use for creation as exists for patch or update. This is different than before, where the option was only file update. These options are those proposed above:
A defined Content Source (implicit channel)
A defined Channel (explicit channel)
The Inventory Channel (implicit channel)
File upload
Note that the first three choices could probably be consolidated into one list.
After package selection the workflow is as before.
There are logically two types of update deployments, an update to the current resource, i.e. a patch, or an update to a child resource, i.e. a container deployment. This addresses the former.
The Patch Subtab is active if the resource type has non-creatable <content> defined. It would allow deploy of a package type associated with the current resource type (e.g. for AS, a patch or a jar).
It would display the currently deployed package-versions (like today's Content->deployed subtab). To update a deployed package-version the user would select it (radio button, maybe checkbox) and click something like "Deploy". It would then kick off the package-version selection and deploy workflow.
There are logically two types of update deployments, an update to the current resource, i.e. a patch, or an update to a child resource, i.e. a container deployment. This addresses the latter.
The deployed child resources would be a list looking similar to that under the current Content Deployed subtab. But it would include the resource itself (as a link). To update the package-version on the resource the user would select it (radio button, maybe checkbox) and click something like an "Deploy". It would then kick off the package-version selection and deploy workflow.
This page may also incorporate an "Undeploy" button for deleting a deployed resource, assuming it allows Delete.
The history subtab would basically mimic the current Content->History subtab although would probably require some filters to narrow the list in various ways since it would include the history for the deployments of the current resource and deployed children.
It may still be useful when looking at a resource to be able to look at its individual package history. But, this proposal removes the Content Tab on most creatable, deployable resources. Perhaps we could move Content->History to Inventory->Package. The other Content subtabs, I think, are obsoleted.
The basic idea here is to be able to request a package deployment across a cluster/compatible group. Each deployment would be performed with the same content configuration.
A Compatible group would offer a Deploy Tab by the same criteria as would one of its members (non-creatable <content> defined or creatable <content> defined on a child resource type). It would offer the same subtabs: New, Patch, Deploy, History.
Basically the same as the analogous resource subtab but will deploy a new package across the group.
"Deploy" would be "Deploy to Group". The selected package would be deployed to all group members.
"Deploy" would be "Deploy to Group". This is semantically a little tricky. We could go a couple of ways here, we could display the intersection of deployable child resources for the group members. Or we could display the union. In the former case the update should be able to succeed. In the latter the update would fail for members that did not have the resource deployed already.
I propose the intersection approach as the way to go since it is semantically more clear and better matches the resource-level update.
.h5 Group Deploy Coordination
There are various levels of robustness we could put in place for group deployment.
No group status: Just mke the deployment requests and that's it.
Like group config update: Something analogous, with potentially the same complexity and fragility.
Workflow: Introduce a more generic workflow mechanism that can handle state transition, dependencies, asynchronous steps, and recovery in a clear and dependable way.
.h5 Notes
We may also want to provide a "Delete" button for group delete of a deployed resource, assuming it allows Delete.
Group deploy is not all or nothing, some can succeed and some can fail.
We may want an option for not redeploying the same version. (so you can retry a group deploy w/o redeploying previous successes.)
6. History Subtab
This should be analogous to the resource level but the requests would be group deployment requests. Details of what this should look like are not clear yet but perhaps can leverage the look and feel of group config update.
Not Supported.
I think most of this falls into the category of plugin and product. We need to ensure that customers can deploy and undeploy what they want (EAR, WAR, JAR, other?), on each supported version of the product, on each supported platform, with a variety of options. Support for different package types is the responsibility of the plugin. The rest is, I think, mainly a increased testing effort. At least to test scenarios that have failed for customers. It means using real-world ear/wars with a variety of configurations.
Does the new UrlContentSource with XML backing replace the need for DiskCS, HttpCS or even PatchCS?
What is the status of YumCS?
We will continue to ship DiskCS even if UrlCS is fully functioning. If for no other reason then for backward compatibility. The docs should indicate that it is deprecated and the UrlCS should be used in its place. All other ContentSource types will continue to ship (in all packaging flavors) as each has distinct advantages. We'll continue to look at any simpifications we can introduce into the CS configs.
At the moment we have no hooks for anything like this. It's not clear to me what it is we would offer above the current ability for the plugin to provide a relevant operation or something like that. I don't know what kind of extension to the ContentFacet would be helpful.
I'm not sure this is a very typical case.
It may be the case that we deploy a new package successfully but the package can not be hosted, started, etc. In this case we will not discover the resource. If it can not be manually added then there is no way via JON to clean up the situation. The package will need to be removed outside of JON.