Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create conversion graph #1627

Merged
merged 17 commits into from
Jul 21, 2021
Merged

Conversation

theunrepentantgeek
Copy link
Member

@theunrepentantgeek theunrepentantgeek commented Jul 7, 2021

What this PR does / why we need it:

Adds a pipeline stage that computes the conversion graph required for our storage versioning.

Prerequisites

How does this PR make you feel:
gif

If applicable:

  • this PR contains tests

@theunrepentantgeek theunrepentantgeek added this to the codegen-alpha-1 milestone Jul 7, 2021
@theunrepentantgeek theunrepentantgeek self-assigned this Jul 7, 2021
@theunrepentantgeek theunrepentantgeek added this to In progress in CRD Code Generation via automation Jul 7, 2021
@theunrepentantgeek theunrepentantgeek force-pushed the feature/move-property-assignment-function branch from 1c75733 to fa329cf Compare July 8, 2021 21:03
Base automatically changed from feature/move-property-assignment-function to master July 8, 2021 21:27
@theunrepentantgeek theunrepentantgeek force-pushed the feature/create-conversion-graph branch 2 times, most recently from b86d27f to cf5198b Compare July 8, 2021 22:34
Copy link
Member

@babbageclunk babbageclunk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great mostly but I think the graph creation stage needs to deal with types from more than one group. (Although I could be wrong!)

Comment on lines 53 to 59
for i, ref := range sortedApiReferences {
if i == 0 || !ref.IsPreview() {
continue
}

conversionGraph.AddLink(sortedStorageReferences[i], sortedStorageReferences[i-1])
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this part. Don't the references need to be split by group before you can do this? Otherwise you'll get the earliest version of one group pointing at the latest version of the previous group - something like microsoft.network/v20150101 pointing to microsoft.compute/v20210701. In my head each stage runs with the full set of loaded types. Is that right? Or is there something structural that means that the stage only runs with (all versions of) the types from one group?

Copy link
Member Author

@theunrepentantgeek theunrepentantgeek Jul 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you're perfectly correct - I transplanted this code from #1533 and put it in the wrong place. 😲

I'll relocate it into GroupConversionGraph and add some tests to ensure it behaves correctly.

@@ -3,10 +3,20 @@
// Licensed under the MIT license.
package v20211231
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the package have changed? Or is the destination package an input to the code that this test is checking?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll double check this after moving the graph creation code; when I reviewed these changes prior to creating the PR I was sure they were correct, but I'm no longer convinced.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They have no longer changed - I fixed a couple of bugs in the test. Good catch.

type Person struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
Spec Person_Spec `json:"spec,omitempty"`
Status Person_Status `json:"status,omitempty"`
}

// AssignPropertiesFromPerson populates our Person from the provided source Person
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did these go away? Aren't they still needed for conversion to storage versions?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These have no longer changed either.

@codecov-commenter
Copy link

codecov-commenter commented Jul 14, 2021

Codecov Report

Merging #1627 (9472d0b) into master (c1e1902) will increase coverage by 0.17%.
The diff coverage is 90.98%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1627      +/-   ##
==========================================
+ Coverage   67.04%   67.22%   +0.17%     
==========================================
  Files         205      208       +3     
  Lines       14898    14979      +81     
==========================================
+ Hits         9989    10069      +80     
+ Misses       4152     4151       -1     
- Partials      757      759       +2     
Impacted Files Coverage Δ
...ck/generator/pkg/codegen/storage/type_converter.go 71.66% <83.33%> (ø)
...or/pkg/codegen/storage/conversion_graph_builder.go 86.20% <86.20%> (ø)
...or/pkg/codegen/pipeline/create_conversion_graph.go 86.66% <86.66%> (ø)
.../generator/pkg/codegen/storage/conversion_graph.go 81.81% <88.88%> (-7.66%) ⬇️
.../codegen/storage/group_conversion_graph_builder.go 94.28% <94.28%> (ø)
hack/generator/pkg/astmodel/package_reference.go 90.99% <100.00%> (+3.02%) ⬆️
hack/generator/pkg/codegen/code_generator.go 89.03% <100.00%> (+0.07%) ⬆️
...rator/pkg/codegen/pipeline/create_storage_types.go 91.66% <100.00%> (-0.34%) ⬇️
...g/codegen/pipeline/inject_original_gvk_function.go 76.19% <100.00%> (ø)
...degen/pipeline/inject_original_version_function.go 88.23% <100.00%> (ø)
... and 10 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1e1902...9472d0b. Read the comment docs.

@theunrepentantgeek
Copy link
Member Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

Copy link
Member

@babbageclunk babbageclunk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great - some minor comments.

person2022 := test.CreateSpec(test.Pkg2022, "Person", test.FullNameProperty, test.KnownAsProperty, test.FamilyNameProperty)

types := make(astmodel.Types)
types.AddAll(person2020, person2021, person2022)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth having some unrelated types in here to make sure there aren't any links created between Person and OtherType?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noted for a followup PR.

Comment on lines +52 to +54
createConversionGraphStage := CreateConversionGraph()
state, err := createConversionGraphStage.Run(context.TODO(), state)
g.Expect(err).To(Succeed())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be better done as just constructing the intended conversion graph, rather than calling the stage to build it. The current way makes it an integration test for the interaction between the three stages (CreateConversionGraph, CreateStorageTypes and InjectFunctions) . That's good for making sure that they all work together, but makes it hard to pinpoint the problem if it fails. I can see that it would be hard to create the storage types manually, but I think the graph should be reasonably easy to build by hand?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a problem occurs with an earlier stage, the tests on that stage should flag it. I tried manually creating the required state but the amount of code required was prohibitive and it didn't seem to provide any value - in fact, it obscured what the test was doing. I have later changes (different PRs) to simplify the tests further.

Co-authored-by: Christian Muirhead <christian.muirhead@microsoft.com>
@theunrepentantgeek theunrepentantgeek merged commit b7ccaba into master Jul 21, 2021
CRD Code Generation automation moved this from In progress to Done Jul 21, 2021
@theunrepentantgeek theunrepentantgeek deleted the feature/create-conversion-graph branch July 21, 2021 02:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

4 participants