A way to extend provider-alibaba

[crossplane-contrib]

A way to extend provider-alibaba

[negz]

We just had a quick call to discuss our options. I'm hopeful that it will be possible to solve this problem while also maintaining typical patterns in the provider.

I'm thinking the internal Alibaba provider, which is a superset of the OSS Alibaba provider, could do something like this:

type InternalAlibabaConnector struct {
    kube: client.Client
}

func (c *InternalAlibabaConnector) Connect(ctx context.Context, mg resource.Managed) (managed.ExternalClient, error) {
    ossConnector := alibabaoss.Connector{client: c.kube}

    // Create the regular OSS ExternalClient
    ossClient, err := ossConnector.Connect(ctx, mg)

    // Return the special internal Alibaba ExternalClient that wraps the OSS ExternalClient.
    return &InternalAlibabaClient{oss: ossClient}, err
}

// The special, internal Alibaba provider.
type InternalAlibabaClient struct {
    // This implementation wraps the regular OSS ExternalClient implementation.
    oss managed.ExternalClient
}

func (e *InternalAlibabaClient) Observe(ctx context.Context, mg resource.Managed) (managed.ExternalObservation, error) {
    // Special, internal Alibaba logic can be implemented here before the OSS Observe method is called.

    // Call the OSS Observe method.
    observation, err := e.oss.Observe(ctx, mg)

    // Special, internal Alibaba logic can be implemented here, after the OSS Observe method was called.
    // This could include modifying the returned observation.

    return observation, err
}

[negz]

Or is there a mechanism which can support something like Terraform module?

Great question. There is actually. Take a look at https://crossplane.io/docs/v1.1/concepts/composition.html - a Crossplane "Composite Resource (XR)" is very similar to a Terraform module. Maybe you could build only the functionality you need internally at Alibaba as a completely separate provider, then make composite resources that mixed OSS managed resources with your internal managed resources?

[wonderflow]

ping @negz @hasheddan

[negz]

I'm afraid I don't quite follow how @lowkeyrd would use these Base<T> functions - perhaps an example would help?

I wonder if instead it would it be possible to define a regular ExternalClient implementation in this provider, which @lowkeyrd could then wrap in a higher level ExternalClient implementation (or some other type of his choosing) to extend its functionality? I would prefer that approach because consistent, idiomatic provider implementations make it easier for contributors to help maintain the provider.

[zzxwill]

@negz I have updated examples based on the original feature description.

As for ExternalClient, ExternalConnector, yes, are needed. For example, ExternalConnector will include the base connector from OSS controller of the community provider, and need more clients.

type connector struct {
	baseConnector      crossplaneossctl.Connector
	xxxAccountClient xxx
}

Could you please take a look at again whether I have made it clear this time. Thanks.

[negz]

Hi @zzxwill, thanks for your reply. As far as I can tell from what you've proposed here, everything that @lowkeyrd needs to do should be possible without needing to add the BaseFoo layer of abstractions. It sounds like they can use the regular ExternalClient implementation but just need to plumb in a few more options (e.g. a different connection publisher).

[zzxwill]

@negz Your solution works. But there might be some drawbacks on code mergeing:

• When new releases of community provider-alibaba come out, like Bumping Crossplane Runtime to v0.13.0, upgrade has to be made in internal provider-alibaba.
• When SLS/OSS are refactored, the internal one needs to merge the code.
• When there are new managed resources supported, @lowkeyrd might hesitate whether to cheery-pick the feature into the internal one.
• As the internal one won't use Provider, ProviderConfig, these controllers won't be started up in the internal provider. So he will be careful not to merge those controller and api code.

This is why we need the BaseFoo and

Forking this community provider is not an option as it will take into so many troubles of merging future new releases.

Here is a brainstorm:
In the internal provider-alibaba, no BaseFoo is needed and when observing a managed resource, Crossplane runtime will load the Observe function in the community provider-alibaba to take the role to observe.

[zzxwill]

Or is there a mechanism which can support something like Terraform module? So others can consume managed resource from provider-alibaba directly, without needing to copy api/pkg code of the resource, and can make some customization.

    module "rds" {
      source = "terraform-alicloud-modules/rds/alicloud"
      engine = "MySQL"
      engine_version = "8.0"
      instance_type = "rds.mysql.c1.large"
      instance_storage = "20"
      instance_name = var.instance_name
      account_name = var.account_name
      password = var.password
    }

    output "DB_NAME" {
      value = module.rds.this_db_instance_name
    }
    output "DB_USER" {
      value = module.rds.this_db_database_account
    }
    output "DB_PORT" {
      value = module.rds.this_db_instance_port
    }
    output "DB_HOST" {
      value = module.rds.this_db_instance_connection_string
    }
    output "DB_PASSWORD" {
      value = var.password
    }

    variable "instance_name" {
      description = "RDS instance name"
      type = string
      default = "poc"
    }

    variable "account_name" {
      description = "RDS instance user account name"
      type = "string"
      default = "oam"
    }

    variable "password" {
      description = "RDS instance account password"
      type = "string"
      default = "xxx"
    }

[zzxwill]

Thanks, @negz @ryanzhang-oss . The solution has been applied to the project in the internal team.