tabdump/gettab replacements planned?

[sventor]

Considering the possible switch from xCAT to confluent, we especially miss "gettab" - are there plans for a replacement?

Following the principle of a "single source of truth", we have quite a lot of attributes defined, which then are fetched by external scripts via "gettab key=<key> <table>.<column>", eg. usernames/pw for logins to BMC or the like.

This saves a lot of hassle (eg. changes in several places): if an attribute is changed in xCAT, our scripts don't bat an eye, but continue to work...

Thx - and kudos for some really helpful improvements, like the -blame function (explaining where a setting really comes from)!

[Obihoernchen]

@sventor you mean something like this?
gettab node=node01 vpd.serial

In Confluent the equivalent would be:
nodeattrib node01 id.serial | awk '{print $3}'

In Confluent you can also define arbitrary custom attributes with a custom. prefix. Example:
nodeattrib node01 custom.myown.serial=abc123

[jjohnson42]

The biggest thing I think is a gap here is the password settings being overly protected, is that the issue?

gettab came in handy for the non-node oriented attributes, however the goal in confluent is to have everything possible as node-centric, as we kept having issues in xCAT where something was assumed to be 'global' (site, passwd, etc) and encountering a user where it shouldn't be global, and having to double it up with a node-specific attribute that could supersede the site.

So the replacement in theory is, hopefully 'everything' group for globals...

So would like to know the sorts of data and we can decide if it needs something new, can be mapped to a new concept, can fit in custom, or we need to offer a reasonable access to password type data (though 'rootpassword' and 'grubpassword' are irrecoverably lost on store)