Tidy up JGF match writer support #520

Change the use of ggv_t to vtx_t. ggv_t is the data type of a vertex of a graph generation recipe graph whereas vxt_t is the data type of a vertex of the actual resource graph. Found a few sites where ggv_t type is used when vtx_t should have been used during a code review and fix them.

Problem: It is becoming difficult to maintain two difference versions (pretty vs. unpretty) of writers of the same type. Further the value of the pretty versions is marginal as the output from a unpretty writer can easily be made human readable by piping to the jq command. Drop the pretty writer support for JSON-based writers. Adjust testing coverage accordingly. Will consider to add back this support when we convert our JSON writers to use either the Jansson library or its C++ equivalent. If and when this is revived, the implementation should be added such that pretty writers will be supported without having to introduce their own classses that contain duplicate codes with unpretty versions.

Correctly detect the unmatch case to write nothing. Wasn't taking into account a new-line character in detecting unmatch cases, and as a result these writers were writing header information (e.g., version key and execution key) with no match data!

Problem: the old scheme uses the resource graph's vertex index to denote the unique id for each JGF vertex. As the resource graph's vertex index is the same as uniq_id at the top level Flux instance, this has not been a problem. It is "generated" from the graph's vertex index. However, this will become a problem to support general cases. For example, at a nested Flux instance, uniq_id will be "given" by the JGF object from its parent, the resource graph's vertex index and uniq_id will differ. Similarly, if an JGF object is constructed either manually or by Kubernetes, the same problem will occur. Use uniq_id as the JGF node id to generalize our JGF writer support.

Problem: The paths field was previously omited with a hope that the paths can be reconstructed by the future JGF reader. But it appears that this would require lots of code at the reader side and would be inefficient regardless. Modify the JGF writer code to emit the paths of each graph vertex within each subsystem. (Doing this in the writer side is simpler at the expense of using more memory/storage). Will consider JGF schema compression as part of future optimization phase.

Problem: The old scheme is to concatenate the edge's relationship information with respect to each subsystem using some delimiters. While this is condense, this can lead to unnecessary complexity in the future JGF reader code. Emit the relationship information for each subsystem that the edge represents as a unique sub-key within the name key.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tidy up JGF match writer support #520

Tidy up JGF match writer support #520

Commits on Oct 2, 2019