add support for checking the compatibility of schema version and xcat release

[immarvin]

fix issue:
#67
#69

key modifications:

• support configurable schema version validation criteria and relevant message in object schemas
• the logic to determine the valid schema version for xCAT versions on MN
• add 3 schema versions for several latest xCAT releases
• a new schema version is expected when:
  1. the DB schema of xCAT is changed
  2. the layout of xcat-inventory output is changed

behavior changes:

• xcat-inventory import will pickup the schema file according to the "schema_version" in the inventory file, then validate whether the schema file is compatible with the xCAT version on management server.

• xcat-inventory export will pick up the most updated valid schema version for the xCAT version on management server and export the inventory data, the schema version will also be added in the inventory data/file

UT:

1. incompatible xCAT release and schema version:

[root@c910f03c05k21 inventory]# xcat-inventory import -e GITREPO=/tmp/ -e SWDIR=/tmp -f /home/yangsbj/xcat_clusters/osimage/rhels/ist.redhat-alt.perf.custom.netboot.DL.osimage.yaml
Error: invalid schema /opt/xcat/lib/python/xcclient/inventory/schema/3.0/osimage.yaml: This schema is valid for xCAT releases >=2.14.3, current xCAT version is 2.14.1

[whowutwut]

@immarvin I don't know all the details but just trying to comment on the above... right now most of our schema version is 1.0...

[vhu@c910loginx01 xcat_clusters]$ git grep schema_version
osimage/rhels/ist.redhat-alt.install.DF.osimage.yaml:schema_version: '1.0'
osimage/rhels/ist.redhat-alt.netboot.DL.osimage.yaml:schema_version: '1.0'
osimage/rhels/ist.redhat.custom.install.DF:schema_version: '1.0'
osimage/rhels/ist.redhat.netboot.DL.osimage.yaml:schema_version: '1.0'
osimage/rhels/xcat/xcat.redhat-alt.full.install.osimage.yaml:schema_version: '1.0'
osimage/rhels/xcat/xcat.redhat-alt.full.netboot.osimage.yaml:schema_version: '1.0'
osimage/rhels/xcat/xcat.redhat.full.install.osimage.yaml:schema_version: '1.0'
osimage/rhels/xcat/xcat.redhat.full.netboot.osimage.yaml:schema_version: '1.0'

In this case, are we able to import using any version of xcat-inventory? This is what I would like to solve...

What is required in schema version 2.0 and what is required in 3.0 ? Since I will never export again, i will never update my schema version in the source control.... Maybe the import should be looking for keywords that related to schema changes... for example, if GITREPO is specified, it's at a newer version ,and then we should do the checking and block if xCAT is not at a supported version that required... Otherwise do not block import.

One big problem here is that for my use case, I don't see us doing xcat-inventory export all the time. I see this flow as the following:

1. Initially create the file in source control using xcat-inventory export....
2. From this point onwards, I don't see any need to re-export the osimage definition. I'm able to create new osimage and maintain my osimages via manipulating source control files directory. Most of the xCAT osimage never changes... to bump up software versions, it's all stored in files that xCAT osiamge points to. Git will handle this.

How would we ever update the schema version of the json or yaml?

[immarvin]

hi @whowutwut , here is a summary of the scenarios that a new schema version(Ver.new) need to be added and the behavior to manipulate the inventory file exported with old schema version(Ver.old)

1. the layout of inventory file is changed, no xCAT DB change:
   the inventory files exported with Ver.old can be import with Ver.old

2. a new field is added into xCAT table, or a new table is added in xCAT DB:
   the inventory files exported with Ver.old can be import with Ver.old

3. a field of xCAT table is dropped or altered, or a xCAT table is dropped:
   rare case, the inventory files with Ver.old cannot be imported

So on your question,

From this point onwards, I don't see any need to re-export the osimage definition. I'm able to create new osimage and maintain my osimages via manipulating source control files directory. Most of the xCAT osimage never changes... to bump up software versions, it's all stored in files that xCAT osiamge points to. Git will handle this.

I think if the DB fields involved in osimage definition does not go beyond the DB schema in xCAT, the osimage definitions can always be imported.

[robin2008]

We can do an enhancement later to figure out which schema is compatible for a specified inventory file.