Red Hat Bugzilla – Bug 790322
RFE: Replacement of tokens with tag values during content bundle provisioning
Last modified: 2013-09-01 06:08:43 EDT
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):
Deploy a content bundle like
<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: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"/>
<target name="main" />
with the above mentioned properties file looking like
should result in (with tags assigned to the platform it:env=dev and mytag=bar)
Steps to Reproduce:
1. see above
No replacement is done.
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.
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
note: the tag format supported by RHQ is:
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:
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.
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.
git commit master - c2c2f68
tweeked some things and added unit tests.
Thanks for the patch torben!
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:
3) Create an ant bundle that has a file with replacement tokens. To match the example above, such replacement tokens could be:
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".
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.