Dtgov Admin Targets

[virchete]

The related issue is:

https://issues.jboss.org/browse/DTGOV-4

I started this morning analyzing this new page to be added in dtgov.

There are 2 pages involved: the Target List View and the Edit Target View:

Target List View (attached image)

• I do not include a filter on the left. I did not include to make it simpler, because I do not think it would be a big number of targets. In case we want to include a search filter, it would contain the Name and the Type inputs.
• Do we want to include pagination?

Target Edit ViewThere are 4 kind of targets: Copy, RHQ, Jboss AS Cli and Maven. The general attributes for all of them are: Name, Description, Type and classifier.

• Type --> Create new type in s-ramp that would be the TargetType. The select input data will be populated by this data.
• Classifier --> Here I have my doubts. As I have seen the classifier used should be something like http://www.jboss.org/overlord/deployment-status.owl#InDev. We would let the user introduce whatever he wants, or the user introduces the subclassifier "InDev" and then we construct add at the beginning the ontology String  http://www.jboss.org/overlord/deployment-status.owl. 

                             Is the deployment ontology an static value? Or it can be selected by the user from a choices of ontologies that would be stored in s-ramp?

Then depending the type selected it would appear different inputs:

• Copy --> DeployDir
• RHQ --> user, password, baseUrl, rhqPlugin. About the "rhqPlugin", is this a free text, or the user should select a value from a SELECT input? By default if no value is introduced, now, we are writing JBossAS7.
• Cli --> user, password,asHost, asPort.
• Maven --> MavenRepositoryURL, isReleaseEnabled, IsSnapshotEnabled

[eric.wittmann]

Target List View

I agree that we do not need a Filter on the left hand side.  You are right that we are not expecting a large number of items in the list.  There should only be a handful of these things.  At most there may be 10s of them.  So I think leaving out the filter is good and leaving out pagination is good.

Target Edit View

Don't forget about "Custom" as the type.  One of the ways that DTGov can be customized is for users to provide their own custom deployment targets.  The UI should allow managing those types as well.  It's not clear to me what the configuration form will look like for custom types - that's to be determined I suppose.

The Classifier should be chosen from the installed ontology options.  The user must first create at least one ontology and have it installed in S-RAMP (e.g. via the UI or CLI).  Once that is done, the user can choose one (or more?) classifier from any of the installed classifiers.  It should *probably* re-use the classifier editing widgets found in the Artifact Details page.

I don't know the answer to your RHQ question.  Perhaps someone with more RHQ experience can shed some light on that.

[virchete]

Targets View is clear.

About Target View:

• About creating custom type, we could include in the select type another item call "custom" and then later we can think about it. For this development I think we can focus in the existing 4 types.
• About the Target type in S-ramp, do you think we could store as a new type in s-ramp: /s-ramp/ext/Target. For instance:

         The Copy Target would be stored in /s-ramp/ext/TargetType with the name Copy. It will contain as customProperty the attributes that define it: Description and DeployDir.    (maybe description not necessary)

       Having this type in s-ramp will allow us in the future to create a custom target easily.

• About the classifiers, as Eric commented it should be a list of classifiers. Then they would be stored in s-ramp as one custom property, classifier, where all the classifiers would be separated by "|".
• In terms of UI, the clasifiers need to be selected from the ontology tree.

[jorgemoralespou_2]

Hi,

Sorry to jump in, and don't troll me if you don't like my comments :-D

Regarding the custom type, it is very important if you want to integrate DTGov with any CI tool to be able to deploy the artifact /trigger an action in a remote system. Let's say you want to deploy to QA environment, but the real action is "trigger a QA pipeline in jenkins through REST api". This should be possible. It should be possible to register different deployers (sorry for this term, I haven't  looked at implementation) in a dynamic way, so anybody can create this "deployers". This deployers/target_invokers, should execute the deployment action based on the metadata configured for the deployers/target in S-RAMP, so there would be a need for:

a) Define and register these targets (SPI is an option)

b) Define and register views for this metadata definition (I do not know how ui is built and if it is possible) Maybe a page rendered based on a tamplate defined with the target/deployer.

And another comment would be to try to avoid properties files for defining dtgov behaviour nad instead move everything to server xml configuration as this is more manageable in a clustered environment.

Hope it helps,

[kconner]

And another comment would be to try to avoid properties files for defining dtgov behaviour nad instead move everything to server xml configuration as this is more manageable in a clustered environment.

This is something that we will be looking into shortly as part of a task to support distribution of the artifacts using domain mode.

[eric.wittmann]

David virgil naranjo wrote:

• About the Target type in S-ramp, do you think we could store as a new type in s-ramp: /s-ramp/ext/Target. For instance:

         The Copy Target would be stored in /s-ramp/ext/TargetType with the name Copy. It will contain as customProperty the attributes that define it: Description and DeployDir.    (maybe description not necessary)

       Having this type in s-ramp will allow us in the future to create a custom target easily.

Each item in the targets view should be an artifact in s-ramp of type:

  /s-ramp/ext/DeploymentTarget

Each artifact should have the following properties at a minimum:

• name (standard property)
• description (standard property)
• deployment.type (custom property)
• deployment.classifiers (custom property)

Additionally, each artifact will have a set of properties that is different depending on the value of deployment.type.

Copy

• deployment.deployDir

AS_CLI

• deployment.host
• deployment.port
• deployment.user
• deployment.password

RHQ

• deployment.baseUrl
• deployment.pluginName
• deployment.user
• deployment.password

Maven

• deployment.repositoryUrl
• deployment.releaseEnabled
• deployment.snapshotEnabled
• deployment.user
• deployment.password

[eric.wittmann]

Jorge Morales wrote:

Sorry to jump in, and don't troll me if you don't like my comments :-D

Always happy to have additional comments!

Jorge Morales wrote:

Regarding the custom type, it is very important if you want to integrate DTGov with any CI tool to be able to deploy the artifact /trigger an action in a remote system. Let's say you want to deploy to QA environment, but the real action is "trigger a QA pipeline in jenkins through REST api". This should be possible. It should be possible to register different deployers (sorry for this term, I haven't  looked at implementation) in a dynamic way, so anybody can create this "deployers". This deployers/target_invokers, should execute the deployment action based on the metadata configured for the deployers/target in S-RAMP, so there would be a need for:

a) Define and register these targets (SPI is an option)

b) Define and register views for this metadata definition (I do not know how ui is built and if it is possible) Maybe a page rendered based on a tamplate defined with the target/deployer.

We already support (a).  We need to figure out how best to support (b).

-Eric