Bug 790322 - RFE: Replacement of tokens with tag values during content bundle provisioning
Summary: RFE: Replacement of tokens with tag values during content bundle provisioning
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Provisioning
Version: 4.3
Hardware: All
OS: All
unspecified
low
Target Milestone: ---
: RHQ 4.3.0
Assignee: John Mazzitelli
QA Contact: Mike Foley
URL: https://github.com/jicken/rhq/commit/...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-14 09:08 UTC by Torben Jaeger
Modified: 2013-09-01 10:08 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-09-01 10:08:43 UTC
Embargoed:


Attachments (Terms of Use)
Patch to 4.3-SNAPSHOT (12.89 KB, patch)
2012-02-14 09:08 UTC, Torben Jaeger
no flags Details | Diff

Description Torben Jaeger 2012-02-14 09:08:56 UTC
Created attachment 561826 [details]
Patch to 4.3-SNAPSHOT

Description of problem:
The information provided by tags cannot be used to deploy system specific content.

Version-Release number of selected component (if applicable):
4.3-SNAPSHOT

How reproducible:
Deploy a content bundle like

<?xml version="1.0"?>
<project name="test-bundle" default="main" xmlns:rhq="antlib:org.rhq.bundle">

    <rhq:bundle name="example" version="1.0.3" description="an example bundle">
        <rhq:deployment-unit name="testproperty">

            <rhq:url-file url="http://192.168.56.4:8081/nexus/service/local/repositories/releases/content/de/jicken/jboss-system-master/1.0.2/jboss-system-master-1.0.2.properties" destinationDir="/Users/torben/tmp/props" replace="true"/>

        </rhq:deployment-unit>
    </rhq:bundle>

    <target name="main" />

</project>

with the above mentioned properties file looking like 

system.propA=foobar
system.filteredProp=@@rhq.tag.it.env@@
system.woNamespace=@@rhq.tag.mytag@@

should result in (with tags assigned to the platform it:env=dev and mytag=bar)

system.propA=foobar
system.filteredProp=dev
system.woNamespace=bar


Steps to Reproduce:
1. see above
2.
3.
  
Actual results:
No replacement is done.

Expected results:
If deploying a content bundle with a text file (e.g. properties file) using the pattern @@rhq.tag.[namespace].semantic@@ the token should be replaced by the value of the tag named "[namespace:]semantic".
If no tag value is available the token will remain unchanged in the property file.

Additional info:
Usage scenario: e. g. source files from a NFS share called /mnt/share/[dev|pre|prod]/application.properties depending on the value replaced with the above process

Comment 1 John Mazzitelli 2012-02-16 16:59:07 UTC
note: the tag format supported by RHQ is:

[namespace:][semantic=]name

notice the semantic is also optional. With the attached patch, I believe this means the literal string "null" will be used in the name of the replacement token if there is no semantic in your tag. examples:

   for tag of "foo:bar": @@rhq.tag.foo.null@@ will be replaced with "bar"
   for tag of "abc": @@rhq.tag.null@@ will be replaced with "abc"

After thinking about this, I do not think this is the proper behavior, at least in that second case where neither namespace nor semantic is specified, because if you have more than one tag that omits namespace and semantic specifiers, you won't be able to determine which  one to replace the @@ token with. So if I have "foo" and "bar" as two tags on my resource, what does @@rhq.tag.null@@ get replaced with? Its indeterminant.

So, I think, at least in the case where only name is in the tag, we don't populate that in the ant properties. We could put them perhaps in a comma-separated list on @@rhq.tags.null@@ but I would suggest we just don't do anything for this yet, ignore name-only tags and wait for a use-case to crop up before we do anything with those.

As for the first case, its probably safe to do the same thing - ignore them. For example:

foo:bar
foo:abc

What does @@rhq.tag.foo.null@@ get replaced with? Again, its indeterminate. bar and abc are in the same namespace, but have no semantic to qualify them.

Thus, in both cases, I will ignore tags if semantic is not specified.

Comment 2 John Mazzitelli 2012-02-16 18:45:49 UTC
the attached patch isn't all that is needed - the unit tests in the ant-bundle plugin are failing. nothing major, we just have to make sure we create a mock resource object to avoid NPEs in the tests. I have also tested replacing tag replacement tokens and I tested the cases where semantic is null (namespace:name or name-only tags).

All enterprise/jar, common/ant and plugins/ant-bundle unit tests pass on my box.

I'll commit this shortly.

Comment 3 John Mazzitelli 2012-02-16 19:40:38 UTC
git commit master - c2c2f68 

tweeked some things and added unit tests.

Thanks for the patch torben!

To Test:

1) Import a platform resource
2) Add a tag to it - provide a semantic in the tag. For example, tag names such as the following will work:
   it:group=qa
   organization=HR
3) Create an ant bundle that has a file with replacement tokens. To match the example above, such replacement tokens could be:
   @@rhq.tag.it.group@@
   @@rhq.tag.organization@@
4) Deploy the bundle to the platform resource that is tagged
5) After the bundle is deployed, confirm file has been realized with the appropriate tag names (to follow the examples above, @@rhq.tag.it.group@@ should have been replaced with the string "qa" and @@rhq.tag.organization@@ should have been replaced with "HR".

Comment 4 Heiko W. Rupp 2013-09-01 10:08:43 UTC
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.


Note You need to log in before you can comment on or make changes to this bug.