Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Tidy up JGF match writer support #520
This PR cleans up match writer support in preparation for the upcoming JGF reader support. It contains:
@@ Coverage Diff @@ ## master #520 +/- ## ========================================== - Coverage 76.55% 76.23% -0.32% ========================================== Files 58 58 Lines 6291 6165 -126 ========================================== - Hits 4816 4700 -116 + Misses 1475 1465 -10
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.
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments.