Open christopherhein opened 6 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 :)
@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.
Any progress on the RDS implementation ?
Any news on this? We would also very much like to provision RDS instances with this operator.
Any news on this one? Maybe some pre-alpha version is available?
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.
@icereed, let me know if you'd like any help. I've been thinking about working on this at some point too. :-)
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.
@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.
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.
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.