amazon-archives / aws-service-operator

AWS Service Operator allows you to create AWS resources using kubectl.
Apache License 2.0
732 stars 97 forks source link

Create RDS Resource Type #39

Open christopherhein opened 6 years ago

christopherhein commented 6 years ago

This should create any engine of the AWS::RDS:DBInstance class meaning it should support creating mysql, postgres, mariadb, etc all via the same spec.

apiVersion: operator.aws/v1alpha1
kind: RDS
metadata:
  name: my-rds
spec:
  engine: postgres
  backupRetentionPeriod: 30
  instanceClass: db.m1.small
  version: 9.6.3
  storage:
    capacity: 100GB
    type: io1
    encrypted: true
    iops: 1000
  versioning:
    allowMajorUpgrade: true
    allowMinorUpgrade: true
  user: # optional
    username: chris # optional
    password: foobar # optional
pierreozoux commented 5 years ago

@christopherhein I'd love that you take a look at https://github.com/kubernetes/enhancements/issues/706 I think we would all benefit from more standardisation :)

christopherhein commented 5 years ago

@pierreozoux I think standardization is a really interesting idea, I know at one point service catalog was considering implementing something like this, and Upbound with CrossPlane is working on something in this space as well.

As we go down this path my hopes would be that we build out an abstraction layer to help support but not force anything specific. Al la it's critical that we have the ability to implement our own levers for the service definitions since not all providers expose the same controls for all resources and types.

Liorba commented 5 years ago

Any progress on the RDS implementation ?

srueg commented 5 years ago

Any news on this? We would also very much like to provision RDS instances with this operator.

lukipro commented 5 years ago

Any news on this one? Maybe some pre-alpha version is available?

icereed commented 5 years ago

Hi there, I played around with creating the RDS implementation. In my implementation, I would like to output the credentials to a secret. For this, I would need #44 to be implemented first. Would be happy to contribute here.

mattlord commented 5 years ago

@icereed, let me know if you'd like any help. I've been thinking about working on this at some point too. :-)

icereed commented 5 years ago

One other general challenge I see is the following: a consumer would need to specify the VPC ID, Subnets and maybe other RDS specific stuff. I generally would like aws-service-operator to be aware of which VPC it runs in and I would like some logic to resolve the rest of the parameters. I know this rds-operator is resolving those parameters so you don't have to specify them: https://github.com/sorenmat/k8s-rds

Any ideas on how to approach this? This resource should be usable by a user who is not aware of the networking internals of the cluster.

joshes commented 5 years ago

@icereed perhaps the aws-servicebroker project could give some pointers in this regard? The centralized initial setup w/the ability to override seems like a good approach IMO (e.g. a centrally configured vpcId, but the ability to override for example). I'm new to that project so maybe there are some downfalls, but perhaps a good spot to look for inspiration.

acidnag commented 5 years ago

we will be able to get its vpcid from an ec2 instance, so I think user should not have to provide vpc details. But user will probably have to provide a subnet and security group so there is control over where rds can be provisioned in. I would add Multi_az, dbname & snapshot_retention_policy to what @christopherhein called out.