Another issue for token replacement is what to do about Structured validation.  If I read it right, the validation code for the ConfigRendere has been disabled in the ConfigRenderer as of this commit:

b50c2e34 (Ian Springer    2009-02-11 18:02:21 +0000 457)

But I haven't tested to see if it is actually implemented somewhere else.  Assuming that we want to turn that back on, the validation will happen prior to the call to the agent that does the token replacement.

So two choices here:

1.Move the token replacement to the serve side and call prior to the call to validate:
or
2. Have validate be aware of token replacement.  For failed validations, see if they contain  <%   %>  and if so, pass them through unmolested. 


I'm assuming that token replacement can be any portion of the field, and not just the whole field.




On 01/28/10 11:21, Adam Young wrote:
On 01/28/10 08:08, Bryan Kearney wrote:
On 01/27/2010 09:15 PM, Adam Young wrote:
Here are the current set of values for token replacement.  I'm willing
to modify them based on feedback.

All of the following tokens start with "rhq.system."

hostname
os.name
os.version
os.type
cpu.count
architecture

For network adapters the key will start with "rhq.system.interfaces."
followed by the network adapter name; i.e. eth0

.mac
.type
.flags

The way that system info is set up right now, there is a list of IP
addresses associated with the network adapter. For now, I will pull out
the first one and assume it is the only one, but this is probably not
the right solution. The same goes for multicast.
.address
.multicast.address


Looking at the satellite macros, I see the following missing. Some may be satellite specific tho..

• rhn.system.sid
• rhn.system.profile_name
• rhn.system.description
• rhn.system.net_interface.netmask(eth_device)
• rhn.system.net_interface.driver_module(eth_device)


Did we bail on doing traits? Or, are all the traits on the platform from here?

So far I have not attempted to use traits, as they are not currently available from the agent.  However, I don't think traits solves these problems anyway.  If they do, I'll attack them again.


These are the values on the overiview page for the platform: (Sorry about the html)
Type: Linux (Platform) Description: Linux Operating System
Version: Linux 2.6.30.9-96.fc11.x86_64 Parent: none
Hostname: ayoung.boston.devel.redhat.com Architecture: x86_64
OS Name: Linux Distribution Name: Fedora
OS Version: 2.6.30.9-96.fc11.x86_64 Distribution Version: release 11 (Leonidas)

These all come from the systeminfo object.  Description is, I think, reusing one of the other fields, like OsType or OsName.


at the sysinfo level, the netmask and driver_module are not avaialable.  The same information is available on the website, so I don't think we have that information yet.  Inet4Address is, I think, an enumeration of the values stored under the network adapters unicast address list.  For Linux systems, there is only one IPv4 Address, although there can be many IPv6 ones, which may be an issue in the future.








In order to use the templating engine, call:
org.rhq.core.system.SystemInfoFactory.fetchTemplateEngine. I partnered
this with the SystemInfoFacotry since that was bascially the major
dependecy for getting this to work. Again, I am not wedded to that, but
it seems the cleanest place to put it.

And example of using it is checked in to the ConfigurationManager:

TemplateEngine templateEngine = SystemInfoFactory.fetchTemplateEngine();

...
for (RawConfiguration rawConfig : configuration.getRawConfigurations()) {
String contents = templateEngine.replaceTokens(new
String(rawConfig.getContents()));
....




Can I add to the list above with new tokesn?


Are you asking for dynamic tokens?  I have not implemented that yet.  There was some question as to whether we needed it or not.  Do we?


-- bk

_______________________________________________ rhq-users mailing list rhq-users@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/rhq-users