Hello,
I tried to understand the structure of the XML CIB a little bit better, and I found at least two major problems:
1) the "nvpair" element is missing a "datatype": As a consequence, generic interpretation or checking of nvpair out of context is difficult. Instead the application must know what the individual types of the variables are (e.g. "cluster-recheck-interval").
2) The "id"s are not free of semantic: An ID only needs one property: "Two IDs are equal iff their objects are the same". In contrast, IDs are rich of semantics in the CIB, e.g. id="cib-bootstrap-options-cluster-infrastructure". Also, "id-like" attributes are longer than needed (e.g. "transition-key", "transition-magic", "op-digest"): I see little sense adding extra information to a universally unique ID, despite of the fact that I don't see why a "local" cluster resource needs a universally unique ID at all.A better approach would be to use just some sequence number when assigning a new id. Wherever this will break using the XML CIB, the XML structure should be fixed instead. As a contrast, the "dc-uuid" attribute just uses the local hostname (without domain), which most likely is not (as the name might suggest) universally unique.
3) Data types are used inconsistently: In "op" elements, the "interval" attribute is in "free form" time specification, like "30s", while the interval elsewhere (e.g. "lrm_rsc_op") is in milliseconds. Timestamps in "lrm_rsc_op" usually use "ctime" values, but attribute "cib-last-written" is using an ASCII string.
Regards,
Ulrich
_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ha-wg-technical
I tried to understand the structure of the XML CIB a little bit better, and I found at least two major problems:
1) the "nvpair" element is missing a "datatype": As a consequence, generic interpretation or checking of nvpair out of context is difficult. Instead the application must know what the individual types of the variables are (e.g. "cluster-recheck-interval").
2) The "id"s are not free of semantic: An ID only needs one property: "Two IDs are equal iff their objects are the same". In contrast, IDs are rich of semantics in the CIB, e.g. id="cib-bootstrap-options-cluster-infrastructure". Also, "id-like" attributes are longer than needed (e.g. "transition-key", "transition-magic", "op-digest"): I see little sense adding extra information to a universally unique ID, despite of the fact that I don't see why a "local" cluster resource needs a universally unique ID at all.A better approach would be to use just some sequence number when assigning a new id. Wherever this will break using the XML CIB, the XML structure should be fixed instead. As a contrast, the "dc-uuid" attribute just uses the local hostname (without domain), which most likely is not (as the name might suggest) universally unique.
3) Data types are used inconsistently: In "op" elements, the "interval" attribute is in "free form" time specification, like "30s", while the interval elsewhere (e.g. "lrm_rsc_op") is in milliseconds. Timestamps in "lrm_rsc_op" usually use "ctime" values, but attribute "cib-last-written" is using an ASCII string.
Regards,
Ulrich
_______________________________________________
ha-wg-technical mailing list
ha-wg-technical@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ha-wg-technical