Note: this is an xCAT design document, not an xCAT user document. If you are an xCAT user, you are welcome to glean information from this design, but be aware that it may not have complete or up to date procedures.
In xCAT 2, there are two configuration schemes, 'table' and 'objdef'. For confluent, converge the two models. The result is something that resembles objdef, but with dot-delimited names to help organize data and provide a way to map 'tabedit' behavior as desired. Also, rename and consolidate concepts for more understandable use. For example:
Some attributes are removed entirely for now (installnic). At least long enough to have people comfortable with the concept that it need not be defined for the common case. Boot from media may indicate a return of the need of it.
Inheritence behaves on the surface much like xCAT 2. Under the covers, performance is dramatically improved on read as inheritance is done and re-evaluated on writes and results stored in memory and on disk. Backup process will skip the result fields and only get the source material, restore will re-evaluate the information
Expressions are dramatically changed. In xCAT 2, regular expressions were used and extended by allowing 'Safe' compartment evaluation of result data with a blacklist of forbidden low level operations. This results in a syntax that is unbelievably flexible, but slow, hard to follow, and likely able to do unexpected things from a security standpoint. Confluent expressions, like inheritance improve performance by doing all evaluations on write rather than read of data. One additional capability is the ability to read in values from other attributes. Some example xCAT2 expressions and confluent equivalents (using the relatively new 'easy' xCAT expressions when possible:
| xCAT 2 | Confluent |
| /\z/-bmc | {nodename}-bmc |
| |10.1.($1/255).($1%255)| | 10.1.{n0/255}.{n0%255} |
| N/A | 10.1.{enclosure.id}.{enclosure.bay} |
| /n/bmc/ | *TBD*, possibly {nodename.replace('n', 'bmc')} |
| /(\D+)\d+\D+(\d+)/test$1$2/ | N/A (TODO if requested) |
Data is committed to disk in a DBM style backing store.
Backup data is to be in .json files. inheritedfrom entries are omitted. value attributes alongside expression attributes are omitted. cryptvalue entries are converted to base64. The master integrity and privacy keys are encrypted by a backup password which is required to restore the encrypted values. See [Confluent_security] for more on that aspect.