(Updated Proposal with an eye on Bundle Deployment)

Purpose

Design proposals improve usability and robustness of the RHQ content subsystem.

Goals

• Intuitive Deployment and Lifecycle Management
• Ease of common operations
• Robust Deployment options
• Group Deployment

Constraints

• Backward compatibility

Relevant Jiras

Known Issues

• 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.

RHQ GUI/Server:

Responsible for representing, manipulating and presenting to the user deployed resources, their version history, and deployable content. Coordination of group work.

RHQ Agent/PC:

Responsible for interacting with the plugin to report on deployed content and carry out deployment work on behalf of the server/user.

Plugin:

Responsible for actually discovering deployed content, deploying new content, redeploying or patching existing content. Also, for deleting (partially) deployed content.

Product(container):

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.

Approach

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.

Content Sources and Repos

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)

Ideas

Create implicit repos for each content source

The idea here is to remove the need for Repo definition in the typical scenario of a 1-1 association between CS and Repo.

Maintain an "Inventory" 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 ?

Remove Resource-Repo association

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.

Remove the "Install Packages" feature on Repos

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.

Rename "noarch" to "Any" or "All"

Perhaps combine "Create Children" and Content perms into a single "Deploy" perm

Perhaps prevent child creation if the child will not be visible (ensure parent resource in recursive group, if necessary).

GUI Deploy Workflow

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

Child Subtab

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 Subtab

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.

Bundle Subtab

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.

History Subtab

The history subtab would basically mimic the current Content->History subtab although would probably require some filters to narrow the list in various ways.

Group Deploy

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.

Child Subtab

Basically the same as the analogous resource subtab but will create the child across the group members.

Update Subtab.

Basically the same as the analogous resource subtab but will update all group members.

Bundle Subtab.

Basically the same as the analogous resource subtab but will bundle deploy to all group members.

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.

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.

AutoGroup deploy

Not Supported.

Robustness

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.

Questions

What Content Sources do we really need?

Does the new UrlContentSource with XML backing replace the need for DiskCS, HttpCS or even PatchCS?

Answer (mazz)UrlContentSource wit XML backing does not replace the need for HttpCS because HttpCS provides the additional features of having authentication and supporting HTTP proxies. DiskCS could be replaced/removed by UrlContentSource, however, the plugin configuration in DiskCS currently works while the Url/HttpCS does not (I can explain, but its complicated, I can do it over skype). But, once this config rendering problem is fixed, diskCS can probably go away since UrlCS can be used with a file: URL.

What is the status of YumCS?

Answer (mazz)Working fine.

Result

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.

How can we leverage features in the container product that may assist with things like side-by-side or rolling deployment?

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.

Do we need to handle package delete as well as resource delete?

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.

(LEGACY - Original proposal)

Purpose

Design proposals improve usability and robustness of the RHQ content subsystem.

Goals

• Intuitive Deployment and Lifecycle Management
• Ease of common operations
• Robust Deployment options
• Group Deployment

Constraints

• Backward compatibility

Relevant Jiras

Known Issues

• 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.

RHQ GUI/Server:

Responsible for representing, manipulating and presenting to the user deployed resources, their version history, and deployable content. Coordination of group work.

RHQ Agent/PC:

Responsible for interacting with the plugin to report on deployed content and carry out deployment work on behalf of the server/user.

Plugin:

Responsible for actually discovering deployed content, deploying new content, redeploying or patching existing content. Also, for deleting (partially) deployed content.

Product(container):

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.

Approach

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.

Content Sources and Channels

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)

Ideas

Create implicit channels for each content source

The idea here is to remove the need for channel definition in the typical scenario of a 1-1 association between CS and Channel.

Maintain an "Inventory" 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 ?

Remove Resource-Channel association

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.

Remove the "Install Packages" feature Channels

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.

Rename "noarch" to "Any" or "All"

Perhaps combine "Create Children" and Content perms into a single "Deploy" perm

Perhaps prevent child creation if the child will not be visible (ensure parent resource in recursive group, if necessary).

GUI Deploy Workflow

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

New Subtab

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.

Patch Subtab

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.

Deploy Subtab

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.

History Subtab

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.

Resource Content Subtab

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.

Group Deploy

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.

New Subtab

Basically the same as the analogous resource subtab but will deploy a new package across the group.

Patch Subtab.

"Deploy" would be "Deploy to Group". The selected package would be deployed to all group members.

Deploy Subtab.

"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.

AutoGroup deploy

Not Supported.

Robustness

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.

Questions

What Content Sources do we really need?

Does the new UrlContentSource with XML backing replace the need for DiskCS, HttpCS or even PatchCS?

Answer (mazz)UrlContentSource wit XML backing does not replace the need for HttpCS because HttpCS provides the additional features of having authentication and supporting HTTP proxies. DiskCS could be replaced/removed by UrlContentSource, however, the plugin configuration in DiskCS currently works while the Url/HttpCS does not (I can explain, but its complicated, I can do it over skype). But, once this config rendering problem is fixed, diskCS can probably go away since UrlCS can be used with a file: URL.

What is the status of YumCS?

Answer (mazz)Working fine.

Result

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.

How can we leverage features in the container product that may assist with things like side-by-side or rolling deployment?

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.

Do we need to handle package delete as well as resource delete?

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.