GithubHelp home page GithubHelp logo

crossplane / crossplane-tools Goto Github PK

View Code? Open in Web Editor NEW
32.0 11.0 27.0 4.82 MB

Experimental code generators for Crossplane controllers.

Home Page: https://crossplane.io

License: Apache License 2.0

Go 97.23% Makefile 2.77%

crossplane-tools's Introduction

crossplane-tools Godoc

Code generators for Crossplane controllers.

angryjet

angryjet will detect Go structs that appear to be capable of satisfying crossplane-runtime's interfaces (such as resource.Managed) and automatically generate the method set required to satisfy that interface. A struct is considered capable of satisfying crossplane-runtime's interfaces based on the heuristics described in the Provider Development Guide, for example a managed resource must:

  • Embed a ResourceStatus struct in their Status struct.
  • Embed a ResourceSpec struct in their Spec struct.
  • Embed a Parameters struct in their Spec struct.

Methods are not written if they are already defined outside of the file that would be generated. Use the //+crossplane:generate:methods=false comment marker to explicitly disable generation of any methods for a type. Use go generate to generate your Crossplane API types by adding a generate marker to the top level of your api/ directory, for example:

// Generate crossplane-runtime methodsets (resource.Claim, etc)
//go:generate go run ../vendor/github.com/crossplane/crossplane-tools/cmd/angryjet/main.go generate-methodsets ./...

Reference Resolvers

In addition to functions that satisfy resource.Managed, you can use angryjet to generate a ResolveReferences method as well. In order to generate a resolution call for given field, you need to add the following comment marker:

// +crossplane:generate:reference:type=<target type>

<target type> could either be just the type name of the CRD if it is in the same package or <package path>.<target type> if it is in a different package, such as github.com/crossplane/provider-aws/apis/ec2/v1beta1.VPC.

The generated resolver will use the external name annotation of the target resource to fetch the value and it assumes that reference field is named as FieldNameRef/FieldNameRefs if array and selector field is named as FieldNameSelector. You can override these defaults by adding the optional comment markers, see the following example:

type SomeParameters struct {
    // +crossplane:generate:reference:type=github.com/crossplane/provider-aws/apis/ec2/v1beta1.Subnet
    // +crossplane:generate:reference:extractor=github.com/crossplane/provider-aws/apis/ec2/v1beta1.SubnetARN()
    // +crossplane:generate:reference:refFieldName=SubnetIDRefs
    // +crossplane:generate:reference:selectorFieldName=SubnetIDSelector
    SubnetIDs []string `json:"subnetIds,omitempty"`
    
    SubnetIDRefs []xpv1.Reference `json:"subnetIdRefs,omitempty"`
    
    SubnetIDSelector *xpv1.Selector `json:"subnetIdSelector,omitempty"`
}

Note that it doesn't make any change to the CRD struct; authors still need to add FieldNameRef and FieldNameSelector fields on their own for the generated code to compile.

Usage

$ angryjet generate-methodsets --help
usage: angryjet generate-methodsets [<flags>] [<packages>]

Generate a Crossplane method sets.

Flags:
  --help                     Show context-sensitive help (also try --help-long and --help-man).
  --header-file=HEADER-FILE  The contents of this file will be added to the top of all generated files.
  --filename-managed="zz_generated.managed.go"
                             The filename of generated managed resource files.
  --filename-resolvers="zz_generated.resolvers.go"
                             The filename of generated reference resolver files.
  --filename-managed-list="zz_generated.managedlist.go"
                             The filename of generated managed list resource files.
  --filename-pc="zz_generated.pc.go"
                             The filename of generated provider config files.
  --filename-pcu="zz_generated.pcu.go"
                             The filename of generated provider config usage files.
  --filename-pcu-list="zz_generated.pculist.go"
                             The filename of generated provider config usage files.

Args:
  [<packages>]  Package(s) for which to generate methods, for example github.com/crossplane/crossplane/apis/...

crossplane-tools's People

Contributors

dependabot[bot] avatar eljohnson92 avatar gravufo avatar hasheddan avatar janwillies avatar jbw976 avatar lsviben avatar muvaf avatar negz avatar renovate[bot] avatar ruhika1417 avatar sergenyalcin avatar turkenf avatar turkenh avatar ulucinar avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

crossplane-tools's Issues

Consumers are "forced" to use gopkg.in/alecthomas/kingpin.v2

What happened?

Go projects that reference this project are (almost) forced to use gopkg.in/alecthomas/kingpin.v2 instead of github.com/alecthomas/kingpin/v2.

How can we reproduce it?

Take any project that references this one in its go.mod and try to use github.com/alecthomas/kingpin/v2 in the sub project with a replace such as this:
replace gopkg.in/alecthomas/kingpin.v2 v2.2.6 => github.com/alecthomas/kingpin/v2 v2.4.0

then:

โฏ go mod why -m all          
go: github.com/alecthomas/kingpin/[email protected] used for two different module paths (github.com/alecthomas/kingpin/v2 and gopkg.in/alecthomas/kingpin.v2)

This returns an exit code of 1, which makes scanning tools (such as Black Duck) fail their scan. This is why it makes it "impossible" for consumers to use the newer module version of kingpin.

What environment did it happen in?

Go version: 1.22

Lack of tagged versions causes trouble for provider development

What happened?

Naive provider from scratch development flow breaks when using @latest version of both crossplane-runtime and crossplane-tools, due to managed interface no longer being satisfied.
#57 is the the breaking point, using older revsion 2684f4b works fine.

I expected there to be a (tagged) version of crossplane-tools to be compatible with the "current" version of crossplane-runtime

How can we reproduce it?

Clone https://github.com/crossplane/provider-template
Update dependencies to @latest
Ensure you have a resource API to be managed (in apis/)
make generate
Error manifests in zz_generated.managedlist.go for not satisfying the managed interface

What environment did it happen in?

Crossplane version:
crossplane-runtime 1.13 (current @latest)
crossplane-tools 628280f (current @latest)
Go 1.21

Suggested fix

Tag crossplane-tools 2684f4b with 0.1.0 or similar

Test that generated method sets satisfy crossplane-runtime interfaces

What problem are you facing?

angryjet intends to generate method sets for types such that they satisfy various crossplane-runtime interfaces. Per https://github.com/crossplaneio/crossplane/pull/856/files#r330327715 previously we would add interface satisfaction tests, e.g.:

It's less likely that generated code will accidentally not satisfy these interfaces, but still worth testing. It's possible for example that angryjet is targeting a newer or older version of crossplane-runtime than the project using generation is targeting.

How could Crossplane help solve your problem?

Teach angryjet to generate interface satisfaction tests, e.g.:

var _ resource.Claim = &RedisCluster{}

After bump to v0.0.0-20240522174801-1ad3d4c87f21 asks for github.com/crossplane/upjet/cmd/[email protected]

Greetings,

if i bump to version v0.0.0-20240522174801-1ad3d4c87f21 ( https://github.com/crossplane-contrib/provider-keycloak/pull/81/files) i'll get the following message:

$ make generate
18:01:55 [ .. ] verify go modules dependencies have expected content
all modules verified
18:01:56 [ OK ] go modules dependencies verified
18:01:56 [ .. ] generating provider schema for mrparkers/keycloak 4.4.0
18:01:56 [ OK ] generating provider schema for mrparkers/keycloak 4.4.0
18:01:56 [ .. ] go generate linux_amd64
/home/bree/go/pkg/mod/github.com/crossplane/[email protected]/cmd/scraper/main.go:11:2: missing go.sum entry for module providing package gopkg.in/alecthomas/kingpin.v2 (imported by github.com/crossplane/upjet/cmd/scraper); to add:
        go get github.com/crossplane/upjet/cmd/[email protected]
apis/generate.go:22: running "go": exit status 1
18:01:56 [FAIL]
make[1]: *** [build/makelib/golang.mk:246: go.generate] Error 1
make: *** [build/makelib/common.mk:434: generate] Error 2

which makes no sense to me because we require github.com/crossplane/upjet v1.4.0

No versionlist for this dependency / module - Renovate Dependency Bot fails on this dependency

What happened?

This package has no version list on goproxy.io so the renovate dependency bot fails on this dependency. For crossplane-runtime it's working.
It looks like there only is a latest version.

How can we reproduce it?

https://goproxy.io/github.com/crossplane/crossplane-tools/@v/list => empty answer
https://goproxy.io/github.com/crossplane/crossplane-tools/@latest => {"Version":"v0.0.0-20230714144037-2684f4bc7638","Time":"2023-07-14T14:40:37Z","Origin":{"VCS":"git","URL":"https://github.com/crossplane/crossplane-tools","Hash":"2684f4bc76380172bdc3813baa38031a2ecf3749"}}

What environment did it happen in?

has nothing to do with crossplane version

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

  • Update fkirc/skip-duplicate-actions action to v5
  • Update golangci/golangci-lint-action action to v6
  • ๐Ÿ” Create all rate-limited PRs at once ๐Ÿ”

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

github-actions
.github/workflows/ci.yml
  • fkirc/skip-duplicate-actions v2.2.0
  • actions/checkout v2
  • actions/setup-go v2
  • actions/cache v2
  • actions/cache v2
  • golangci/golangci-lint-action v2
  • actions/checkout v2
  • actions/setup-go v2
  • actions/cache v2
  • actions/cache v2
  • actions/checkout v2
  • actions/setup-go v2
  • actions/cache v2
  • actions/cache v2
  • codecov/codecov-action v1
  • docker/setup-qemu-action v1
  • docker/setup-buildx-action v1
  • actions/checkout v2
  • actions/setup-go v2
  • actions/cache v2
  • actions/cache v2
  • docker/setup-qemu-action v1
  • docker/setup-buildx-action v1
  • actions/checkout v2
  • actions/setup-go v2
  • actions/cache v2
  • actions/cache v2
  • actions/upload-artifact v2
  • docker/login-action v1
  • ubuntu 22.04
  • ubuntu 22.04
  • ubuntu 22.04
  • ubuntu 22.04
  • ubuntu 22.04
  • ubuntu 22.04
.github/workflows/promote.yml
  • actions/checkout v2
  • docker/login-action v1
  • ubuntu 22.04
.github/workflows/tag.yml
  • actions/checkout v2
  • negz/create-tag v1
  • ubuntu 22.04
gomod
go.mod
  • go 1.18
  • github.com/alecthomas/kingpin/v2 v2.4.0
  • github.com/dave/jennifer v1.7.0
  • github.com/google/go-cmp v0.6.0
  • github.com/pkg/errors v0.9.1
  • golang.org/x/tools v0.6.0
  • k8s.io/apiextensions-apiserver v0.25.0
  • k8s.io/apimachinery v0.25.0

  • Check this box to trigger a request for Renovate to run again on this repository

angryjet fails starting with go 1.22

What happened?

Following the official guidelines to create a custom provider, all the steps can be run until go generate.

then, go generate panics with a backtrace

panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x5f1f4f]
goroutine 182 [running]:
go/types.(*Checker).handleBailout(0xc00033d600, 0xc0006d[9](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:10)c60)
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/check.go:367 +0x88
panic({0x7a47a0?, 0xac2140?})
	/opt/hostedtoolcache/go/1.22.1/x64/src/runtime/panic.go:770 +0x132
go/types.(*StdSizes).Sizeof(0x0, {0x888760, 0xac6320})
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/sizes.go:228 +0x30f
go/types.(*Config).sizeof(...)
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/sizes.go:333
go/types.representableConst.func1({0x888760?, 0xac6320?})
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/const.go:76 +0x9e
go/types.representableConst({0x88a520, 0xab96e0}, 0xc00033d600, 0xac6320, 0xc0006d8078)
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/const.go:92 +0x192
go/types.(*Checker).representation(0xc00033d600, 0xc0006e9[10](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:11)0, 0xac6320)
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/const.go:256 +0x65
go/types.(*Checker).implicitTypeAndValue(0xc00033d600, 0xc0006e9100, {0x888760, 0xac6320})
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/expr.go:375 +0x2d7
go/types.(*Checker).convertUntyped(0xc00033d600, 0xc0006e9100, {0x888760, 0xac6320})
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/const.go:289 +0x3f
go/types.(*Checker).matchTypes(0xc00033d600, 0xc0006e90c0, 0xc0006e9100)
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/expr.go:926 +0x79
go/types.(*Checker).binary(0xc00033d600, 0xc0006e90c0, {0x889570, 0xc0006db590}, {0x889600, 0xc0006e6ea0}, {0x889b40, 0xc0006e6ec0}, 0x28, 0x3c109)
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/expr.go:800 +0x166
go/types.(*Checker).exprInternal(0xc00033d600, 0x0, 0xc0006e90c0, {0x889570, 0xc0006db590}, {0x0, 0x0})
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/expr.go:1416 +0x206
go/types.(*Checker).rawExpr(0xc00033d600, 0x0, 0xc0006e90c0, {0x889570?, 0xc0006db590?}, {0x0?, 0x0?}, 0x0)
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/expr.go:979 +0x19e
go/types.(*Checker).expr(0xc00033d600, 0x888a58?, 0xc0006e90c0, {0x889570?, 0xc0006db590?})
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/expr.go:1513 +0x30
go/types.(*Checker).stmt(0xc00033d600, 0x0, {0x889960, 0xc0006e8380})
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/stmt.go:570 +0x[11](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:12)f2
go/types.(*Checker).stmtList(0xc00033d600, 0x0, {0xc0006e7020?, 0x0?, 0x0?})
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/stmt.go:[12](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:13)1 +0x85
go/types.(*Checker).funcBody(0xc00033d600, 0x888760?, {0xc0006dc700?, 0xac6500?}, 0xc0006e8e00, 0xc0006db620, {0x0?, 0x0?})
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/stmt.go:41 +0x331
go/types.(*Checker).funcDecl.func1()
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/decl.go:852 +0x3a
go/types.(*Checker).processDelayed(0xc00033d600, 0x0)
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/check.go:467 +0x[16](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:17)2
go/types.(*Checker).checkFiles(0xc00033d600, {0xc0000b04[20](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:21), 0x1, 0x1})
	/opt/hostedtoolcache/go/1.[22](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:23).1/x64/src/go/types/check.go:411 +0x1cc
go/types.(*Checker).Files(...)
	/opt/hostedtoolcache/go/1.22.1/x64/src/go/types/check.go:372
golang.org/x/tools/go/packages.(*loader).loadPackage(0xc0001[24](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:25)000, 0xc00044b340)
	/home/runner/go/pkg/mod/golang.org/x/[email protected]/go/packages/packages.go:1001 +0x76f
golang.org/x/tools/go/packages.(*loader).loadRecursive.func1()
	/home/runner/go/pkg/mod/golang.org/x/[email protected]/go/packages/packages.go:838 +0x1a9
sync.(*Once).doSlow(0x0?, 0x0?)
	/opt/hostedtoolcache/go/1.22.1/x64/src/sync/once.go:74 +0xc2
sync.(*Once).Do(...)
	/opt/hostedtoolcache/go/1.22.1/x64/src/sync/once.go:65
golang.org/x/tools/go/packages.(*loader).loadRecursive(0x0?, 0x0?)
	/home/runner/go/pkg/mod/golang.org/x/[email protected]/go/packages/packages.go:8[26](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:27) +0x4a
golang.org/x/tools/go/packages.(*loader).loadRecursive.func1.1(0x0?)
	/home/runner/go/pkg/mod/golang.org/x/[email protected]/go/packages/packages.go:833 +0x26
created by golang.org/x/tools/go/packages.(*loader).loadRecursive.func1 in goroutine 79
	/home/runner/go/pkg/mod/golang.org/x/[email protected]/go/packages/packages.go:8[32](https://github.com/tjamet/test-crossplane-provider-template/actions/runs/8351040741/job/22858659459#step:7:33) +0x94
Error: Process completed with exit code 2.

How can we reproduce it?

The problem can be easily reproduced on github action workers.

Here is a workflow reproducing the problem:

name: Go

on:
  push:
    branches: [ "*" ]
  pull_request:
    branches: [ "*" ]

jobs:

  build:
    continue-on-error: true
    strategy:
        fail-fast: false
        matrix:
          version: [20, 21, 22]

    runs-on: ubuntu-latest
    steps:

    - name: Set up Go
      uses: actions/setup-go@v4
      with:
        go-version: '1.${{ matrix.version }}'
    - name: Install CLI
      run: go install github.com/crossplane/crossplane-tools/cmd/angryjet@master

    - name: Build
      run: |
        git clone https://github.com/crossplane/provider-template.git
        cd provider-template
        make submodules
        export provider_name=MyProvider
        make provider.prepare provider=${provider_name}
        export group=sample
        export type=MyType
        make provider.addtype provider=${provider_name} group=${group} kind=${type}
    - name: generate
      run: |
        cd provider-template
        make generate
    - name: go run angryjet
      if: always()
      run: |
        cd provider-template
        (
          cd apis
          go run -tags generate github.com/crossplane/crossplane-tools/cmd/angryjet generate-methodsets --header-file=../hack/boilerplate.go.txt ./...
        )
    - name: call angryjet
      if: always()
      run: |
        cd provider-template
        (
          cd apis
          angryjet generate-methodsets --header-file=../hack/boilerplate.go.txt ./...
        )

As we can see in this run, the build works well for go 1.20 and 1.21.

It though fails on go 1.22 regardless the way the angryjet command is called (make generate, go run or locally build command)

What environment did it happen in?

Crossplane version: Not required

I could reproduce the error locally as well as in github actions using ubuntu-latest

Support Go modules

What problem are you facing?

The angryjet command is a wrapper around a series of libraries used to generate crossplane-runtime method sets. The libraries are (or at least should be) unaware of the Go path and thus Go modules - they require the caller supply a fully qualified file path to which to write the generated methods for each package.

The cmd/angryjet binary, however, is not compatible with Go modules. It exposes a --base flag, which defaults to $GOPATH/src, and writes generated files to ${base}/${packagepath}/${filename}.go, where ${packagepath} is the PkgPath returned by https://godoc.org/golang.org/x/tools/go/packages#Package, typically the full import path to the package.

How could Crossplane help solve your problem?

Crossplane should not assume it is operating in a pre-modules GOPATH style environment. Perhaps this could be done by deriving the output filename from the package's GoFiles paths rather than its PkgPath.

Cannot generate referencers when a function call expression involves an argument with dots

What happened?

Referencer configuration involving a function call expression with an argument with dots fails with the following message:

angryjet: error: cannot write reference resolvers for package github.com/upbound/official-providers/provider-azure/apis/cache/v1beta1: cannot write reference resolver methods: cannot render Go file: Error 15:41: invalid import path: "github.com/upbound/upjet/pkg/resource.ExtractParamPath(\"spec.forProvider" (and 10 more errors) while formatting source:
...

How can we reproduce it?

Configure a referencer as follows:

	// +crossplane:generate:reference:type=github.com/upbound/official-providers/provider-azure/apis/cache/v1beta1.RedisCache
	// +crossplane:generate:reference:extractor=github.com/upbound/upjet/pkg/resource.ExtractParamPath("spec.forProvider.alias")
	// +kubebuilder:validation:Optional
	ResourceGroupName *string `json:"resourceGroupName,omitempty" tf:"resource_group_name,omitempty"`

, and run:

go run -tags generate github.com/crossplane/crossplane-tools/cmd/angryjet generate-methodsets --header-file=../hack/boilerplate.go.txt ./...

What environment did it happen in?

crossplane-tools commit: 1f43fc12793e

Helper utility to scaffold API and controllers for new types

What problem are you facing?

We need an alternative to kubebuilder create API ... commands for Crossplane providers.

From https://crossplane.io/docs/v1.8/contributing/provider_development_guide.html#defining-resource-kinds

Note that while Crossplane was originally derived from kubebuilder scaffolds its patterns have diverged somewhat. It is possible to use kubebuilder to scaffold a resource, but the author must be careful to adapt said resource to Crossplane patterns. It may often be quicker to copy and modify a v1beta1 or above resource from the same provider repository, rather than using kubebuilder.

How could Crossplane help solve your problem?

Implement some utility to scaffold API and controllers for new types, preferably replacing the approach in crossplane/provider-template#50

Support generating reference resolvers targeting multiple types

What problem are you facing?

It is currently not possible to generate ResolveReferences methods that target multiple suitable types even though there are cases in which this would be desirable.

A good example for this are references to KMS CMKs and Aliases in AWS.

Either can be used as reference in a SQS Queue's kmsMasterKeyId and Crossplane should support both.

How could Crossplane help solve your problem?

Resolving of references to KMS Keys for Queues has been implemented in the following way:

// KMSMasterKeyID - The ID of an AWS-managed customer master key (CMK)
// ...
// +crossplane:generate:reference:type=github.com/crossplane/provider-aws/apis/kms/v1alpha1.Key
KMSMasterKeyID *string `json:"kmsMasterKeyId,omitempty"`
KMSMasterKeyIDRef *xpv1.Reference `json:"kmsMasterKeyIdRef,omitempty"`
KMSMasterKeyIDSelector *xpv1.Selector `json:"kmsMasterKeyIdSelector,omitempty"`

It would be absolutely fantastic if crossplane-tools would support listing multiple suitable types here, similar to:

// KMSMasterKeyID - The ID of an AWS-managed customer master key (CMK)
// ...
// +crossplane:generate:reference:type=github.com/crossplane/provider-aws/apis/kms/v1alpha1.Key
// +crossplane:generate:reference:type=github.com/crossplane/provider-aws/apis/kms/v1alpha1.Alias
KMSMasterKeyID *string `json:"kmsMasterKeyId,omitempty"`
KMSMasterKeyIDRef *xpv1.Reference `json:"kmsMasterKeyIdRef,omitempty"`
KMSMasterKeyIDSelector *xpv1.Selector `json:"kmsMasterKeyIdSelector,omitempty"`

If there are multiple suitable candidates users would use matchLabels and suitable matches to differentiate between these resources.

Thank you!

Target smaller interfaces

What problem are you facing?

crossplane-runtime interfaces like resource.Managed are composed of other, more tightly scoped interfaces such as resource.ClassReferencer. angryjet currently targets the broader interfaces; it will generate the resource.Managed method set for types that are support the entire functionality of resource.Managed, or it will generate nothing. This means types like Azure storage containers that look almost but not quite like a managed resource (due to missing embedded ResourceSpec) get no generated methods, despite being capable of satisfying many of the interfaces that resource.Managed is composed from.

How could Crossplane help solve your problem?

angryjet could detect the potential to satsify, and generate the methods of, smaller interfaces like resource.ClassReferencer rather than broad interfaces like resource.Managed. This may require some thought as to what files the (generally 1-2) getters and setters of these interfaces would be written to.

Generate Target interface methods

What problem are you facing?

The new Target interface was implemented as part of crossplane/crossplane-runtime#103, but the methods required to satisfy its embedded interfaces are not generated by angryjet.

How could Crossplane help solve your problem?

While there is only one implementation of the Target interface at this time (KubernetesTarget), it would be helpful and more consistent with other Crossplane interfaces if we generated the required methods automatically.

Generate webhook functions for fields with `+immutable` comment tag

What problem are you facing?

Webhooks are available in Crossplane now and immutability check on UPDATE action is implemented manually for each field.

How could Crossplane help solve your problem?

Similar to reference resolver generation, we can have a generator in crossplane-tools that will scan the fields for // +immutable tag and generate the logic automatically.

Requirement for the code to compile necessitates manual intervention during codegen

What problem are you facing?

When you use a custom resource type in a file under apis/group/version to do the following:

func (mg xpresource.Managed) {
cr, ok := mg.(*Cluster)
}

It expects that *Cluster satisfies xpresoruce.Managed interface but in order to do that angryjet needs to work to generate those functions. To get out of the chicken-egg problem, we end up commenting out the code, run agryjet, and enable it again.

How could Crossplane help solve your problem?

If it's possible, we could disable the expectation that the package should be compile-able. One option could be to give individual files, maybe?

Add type checks to generated methods

What problem are you facing?

Before generation was used for claim / class / managed resource methods, we made sure that methods were implemented such that each struct satisfied its desired interface. For example:

var _ resource.Claim = &RedisCluster{}

How could Crossplane help solve your problem?

Though these type checks are less important now that the methods are generated, they are helpful for someone who is trying to understand how these types are used in crossplane-runtime. It would be useful to generate these type checks alongside the methods.

Endless recursion when running make generate for recursive types

What happened?

I am working on an crossplane-runtime based Elasticsearch provider. One of the things I'd like to automate is the lifecycle of Ingest Pipelines. As you can see in the docs there is a recursive "on_failure" element to the API call.

An example of a real, even more nested ingest pipeline:

   "processors": [
     {
       "rename": {
         "description": "Rename 'provider' to 'my.field'",
         "field": "field",
         "target_field": "my.field",
         "on_failure": [
           {
             "set": {
               "description": "Set 'error.message'",
               "field": "error.message",
               "value": "Field 'field' does not exist. Cannot rename to 'my.field'",
               "override": false,
               "on_failure": [
                 {
                   "set": {
                     "description": "Set 'error.message.multi'",
                     "field": "error.message.multi",
                     "value": "Document encountered multiple ingest errors",
                     "override": true
                   }
                 }
               ]
             }
           }
         ]
       }
     }
   ]

How can we reproduce it?

An example with some irrelevant fields omitted:

type OpensearchIndexPipelineSpec struct {
	xpv1.ResourceSpec `json:",inline"`
	Description       string                  `json:"description"`
	Version           int64                   `json:"version"`
	Processors        []*PipelineProcessorSpec `json:"processors"`
}

type PipelineProcessorSpec struct {
	Set *SetProcessorSpec `json:"set,omitempty"`
	Rename *RenameProcessorSpec `json:"rename,omitempty"`
}

type SetProcessorSpec struct {
	Field string `json:"field,omitempty"`
	Value string `json:"value,omitempty"`
	Description string `json:"description,omitempty"`
	Override    bool   `json:"override,omitempty"`
	OnFailure []PipelineProcessorSpec `json:"on_failure,omitempty"`
}

type RenameProcessorSpec struct {
	Field       string `json:"field,omitempty"`
	TargetField string `json:"target_field,omitempty"`
	OnFailure []PipelineProcessorSpec `json:"on_failure,omitempty"`
}

run make generate

The generation will fail due to endless recursion in https://github.com/crossplane/crossplane-tools/blob/master/internal/types/types.go#L89

What environment did it happen in?

crossplane-provider template tip

I have a patch ready and will send it shortly.

Cheers

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.