Bill raised the point that we still have the legacy key-value system
hanging around, despite having replaced most of that subsystem with
dedicated entries in the database. This gives opportunities for stale
data to accumulate as we change the way the inventory system works.
However, simply dropping key-value support isn't acceptable, since it
may break usage of existing Beaker instances.
One possible answer to that (and my currently preferred approach) is to
define a mapping from particular "key" settings to their more data model
For example, when we see: <key_value key="Vendor" op="!="
We would automatically replace it with: <system><vendor op="!="
If we find existing "key" settings that we can't map, well, that's a
sign that there's a missing piece in the system data model :)
Creating this mapping would also make it clear how to ensure the legacy
data is migrating correctly in an existing installation: scan the
database for systems that haven't been reinventoried since the inventory
task was last updated and the key/value query and the remapped query
give different answers.
Once we have those in place to provide a clean transition plan, then we
can move forward with simply dropping the key/value store from the
system data model.
As a related change (to avoid needing to do the key/value remapping in
two places), we should look into redesigning how the query system works,
creating an internal representation used by both the XML and web
interfaces to invoke a common query engine.
Anyone interested in writing the design proposal(s) for this? (Amit, it
may be somewhat related to the work you're already doing on the
Red Hat Infrastructure Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Development Lead (http://beaker-project.org/