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

Implement the Convertible interface on non-hub resources #1628

Merged
merged 14 commits into from
Jul 21, 2021

Conversation

theunrepentantgeek
Copy link
Member

@theunrepentantgeek theunrepentantgeek commented Jul 7, 2021

What this PR does / why we need it:

Implements the required ConvertTo() and ConvertFrom() methods needed by the conversions.Convertible interface used by the controller

Note that the stage is disabled for two reasons. First is that we don't want to activate this functionality until post codegen-alpha-0. Second is that we need to turn on a bunch of features together, otherwise the internal validation of the controller will reject our webhooks.

Prerequisites

How does this PR make you feel:
gif

If applicable:

  • this PR contains tests

@theunrepentantgeek theunrepentantgeek self-assigned this Jul 7, 2021
@theunrepentantgeek theunrepentantgeek added this to the codegen-alpha-1 milestone Jul 7, 2021
@theunrepentantgeek theunrepentantgeek force-pushed the feature/convertible-resources branch from cf37d2b to 813f382 Compare July 7, 2021 05:41
@theunrepentantgeek theunrepentantgeek changed the base branch from master to feature/create-conversion-graph July 11, 2021 23:44
@theunrepentantgeek theunrepentantgeek force-pushed the feature/create-conversion-graph branch from b2b1ec5 to 60d27fd Compare July 11, 2021 23:48
@theunrepentantgeek theunrepentantgeek force-pushed the feature/convertible-resources branch from 92f2e98 to 7a5ba94 Compare July 11, 2021 23:49
@theunrepentantgeek theunrepentantgeek force-pushed the feature/create-conversion-graph branch from df32912 to e9e04cf Compare July 14, 2021 02:50
@theunrepentantgeek theunrepentantgeek force-pushed the feature/convertible-resources branch from 7a5ba94 to 8890b7e Compare July 14, 2021 03:30
@theunrepentantgeek theunrepentantgeek force-pushed the feature/convertible-resources branch from 8890b7e to 994c3b5 Compare July 17, 2021 23:37
@theunrepentantgeek theunrepentantgeek force-pushed the feature/create-conversion-graph branch from 3520a61 to 9a876ce Compare July 17, 2021 23:51
@theunrepentantgeek theunrepentantgeek force-pushed the feature/convertible-resources branch from 994c3b5 to 55dd583 Compare July 17, 2021 23:53
Copy link
Member

@matthchr matthchr left a comment

Choose a reason for hiding this comment

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

Some minor comments but looks good overall

hack/generator/pkg/astmodel/interface_injector.go Outdated Show resolved Hide resolved
injector := astmodel.NewInterfaceInjector()

modifiedTypes := make(astmodel.Types)
resources := storage.FindResourceTypes(state.Types())
Copy link
Member

Choose a reason for hiding this comment

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

I feel like this method (and the others in types_tools that are generic) should be moved to astmodel along with your interface/function injectors?

Reading this made me think it was finding the storage resource types or something, I had to go look at the impl to understand it was just any old resource type.

Your FindStatusTypes could probably replace my findAllResourceStatusTypes in remover.go as well, although we could leave that for another PR because it'll require changing some types around I think.

Copy link
Member Author

Choose a reason for hiding this comment

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

Agreed. I'm sure moved these into astmodel in a later PR, not sure which one off the top of my head.

Copy link
Member

Choose a reason for hiding this comment

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

Would you consider pulling it forward? I've got at least one upcoming PR where I'd like to use the Status one.

"github.com/Azure/azure-service-operator/hack/generator/pkg/test"
)

func TestInjectConvertibleInterface(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

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

Should this test be replaced with a standard json input file + golden file once the stages are actually enabled in the pipeline?

If so, consider leaving a TODO here to that effect?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, the purpose of this test is to test this pipeline stage in isolation (well, as much isolation as possible). I don't want to conflate the results of this test with other things happening to independent stages.

Copy link
Member Author

Choose a reason for hiding this comment

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

Added a comment.

@@ -57,6 +57,11 @@ func (iface *InterfaceImplementation) References() TypeNameSet {
return results
}

// FunctionCount returns the number of included functions
func (iface *InterfaceImplementation) FunctionCount() int {
Copy link
Member

Choose a reason for hiding this comment

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

Would it make more sense to just expose this as Functions() like exists on ResourceType? (Can we do that since this is also embedded there?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Functions returns a copy (by necessity), whereas this can return the count directly. Not that we're too performance sensitive, but that's why I added. it. 😁

//
// Direct conversion from the hub type:
//
// func (r <receiver>) ConvertFrom(hub conversion.Hub) error {
Copy link
Member

Choose a reason for hiding this comment

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

minor: use the From|To notation you used below to clarify that this can also happen in either direction?

Copy link
Member

Choose a reason for hiding this comment

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

Or maybe because you aren't using it super consistently below either (and doing so might make the examples awkward for example in the error messages, etc) instead you could just preface this with something like: "Examples show the From direction. The only difference between the two is that all instances of From are replaced with To in the To direction." or something?

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've been wavering on whether including <From|To> actually adds clarity or just makes things harder to read. Adding them in for now.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah FWIW I agree. In theory I like <From|To> but in practice it makes things a bit harder to read. I think my main thing here is just be consistent, if you don't use them that's fine you can just have a preface or something that explains roughly how the other direction might look. The comments are meant to help us understand the code rather than be an exact, faithful replica of the template that is being applied so I think either is ok.

Copy link
Member Author

@theunrepentantgeek theunrepentantgeek Jul 21, 2021

Choose a reason for hiding this comment

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

At the moment I'm leaning (just) towards keeping them in - it's still easier to parse the comment with <To|From> than the actual code, and it cues readers into the complexity that's present.

Base automatically changed from feature/create-conversion-graph to master July 21, 2021 02:49
@theunrepentantgeek theunrepentantgeek force-pushed the feature/convertible-resources branch from 64e9d88 to 131ec1b Compare July 21, 2021 03:01
@theunrepentantgeek theunrepentantgeek force-pushed the feature/convertible-resources branch from 131ec1b to 3fb22f1 Compare July 21, 2021 03:06
@codecov-commenter
Copy link

Codecov Report

Merging #1628 (fa8ac7e) into master (b7ccaba) will increase coverage by 0.39%.
The diff coverage is 87.38%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1628      +/-   ##
==========================================
+ Coverage   67.22%   67.61%   +0.39%     
==========================================
  Files         208      211       +3     
  Lines       14979    15175     +196     
==========================================
+ Hits        10069    10260     +191     
  Misses       4151     4151              
- Partials      759      764       +5     
Impacted Files Coverage Δ
hack/generator/pkg/astmodel/types.go 62.80% <ø> (ø)
hack/generator/pkg/codegen/code_generator.go 89.03% <ø> (ø)
hack/generator/pkg/astmodel/property_injector.go 80.00% <66.66%> (ø)
hack/generator/pkg/astmodel/interface_injector.go 72.22% <72.22%> (ø)
...odegen/pipeline/implement_convertible_interface.go 81.81% <81.81%> (ø)
hack/generator/pkg/astmodel/function_injector.go 90.47% <84.61%> (ø)
...ator/pkg/functions/resource_conversion_function.go 91.24% <91.24%> (ø)
...generator/pkg/astmodel/interface_implementation.go 65.71% <100.00%> (+2.07%) ⬆️
...erator/pkg/codegen/pipeline/inject_hub_function.go 80.95% <100.00%> (ø)
...g/codegen/pipeline/inject_original_gvk_function.go 76.19% <100.00%> (ø)
... and 8 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 b7ccaba...fa8ac7e. Read the comment docs.

@theunrepentantgeek theunrepentantgeek merged commit 6667d97 into master Jul 21, 2021
@theunrepentantgeek theunrepentantgeek deleted the feature/convertible-resources branch July 21, 2021 19:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants