MVP

[mhausenblas]

In order to validate the design and gain understanding of the shortcomings, we will put together an MVP. This SHOULD cover an end-to-end implementation of the business logic based on #15 for three services (S3, IAM, DynamoDB) incl. install procedure and testing.

The MVP will depend on #3 #4 #5 #6 and #14.

[mhausenblas]

The issue #20 MAY be considered, however I believe, for the time being it SHOULD be out of scope for the MVP.

[daviddyball]

Regarding PR #15... I'm not sure the statement about kubebuilder not supporting multiple API groups is correct at all.... in our aws-controller code we have s3.amazonaws.com and rds.amazonaws.com apiGroups in the same codebase.

Correction... it looks like v2 of the controller doesn't yet support multiple API groups 🤦‍♂️

[srijitm]

We would like to see RDS and Redis(Elasticache) added to this MVP if possible. We have customers who are interested in these two services right now.

[rohithcj]

We would like to see RDS and Redis(Elasticache) added to this MVP if possible. We have customers who are interested in these two services right now.

plus SQS

[daviddyball]

@mhausenblas it looks like the latest master branch of kubebuilder supports multi-group resources, so it's completely possible to have s3.amazonaws.com and dynamodb.amazonaws.com groups now. The original discovery document from PR 15 probably needs updating and, if this change has any impact on DIY code-generator vs. kubebuilder it should be re-assessed before things get too far down the line.

[mhausenblas]

Cool, thanks a lot @daviddyball! CC: @jaypipes

[jaypipes]

@daviddyball ack, thx for the heads up. feel free to push a PR that updates the code-generation.md doc if you'd like!

[daviddyball]

@jaypipes #26 👍

[andrewmichaelsmith]

Services we would likely use this for:

• CloudWatch Alarms
• S3
• PostgreSQL RDS
• IAM Roles
• Redis Elasticache
• Kinesis
• DynamoDB

[juv]

Here's a list of services that we would love to see:

• S3
• Aurora/RDS
• DynamoDB
• Redis Elasticache
• DocumentDB

Not sure if ACM is also a viable candidate for a first service here. An operator for fetching ACM certificates and storing them into a secret would be great though. Cert-manager.io isn't supporting ACM and isn't likely to support it anytime soon (judging by cert-manager/cert-manager#333)

[sfzylad]

It raises the question in my head if IAM support is not essential for other services? Whenever any other service is created, IAM will come into play.

[jaypipes]

@sfzylad The topic of IAM in the context of this particular issue is really just about whether we will have the controller support creation/management of IAM Roles and PermissionSets via a Kubernetes CRD. If we do not support this, we would require that IAM roles and permission sets be pre-created/managed by an administrator.

Clearly, having the AWS Service Operator controller have the ability to create new IAM roles or modify IAM role permission sets is a giant security consideration, which is why we are hesitant to include it into ASO's initial set of managed services...

[harm-smits]

Here's a list of services that we use on a daily basis, that would fit these requirements (these are now endpoints in our Kubernetes cluster, but we'd rather have them available as services as it would ease our development life-cycle):

• S3
• Aurora/RDS
• DynamoDB (+ DAX)
• Redis ElastiCache
• Elasticsearch Service
• Simple Email Service
• Simple Notification Service
• Simple Queue Service
• Amazon Rekognition
• Amazon Textract

[mhausenblas]

The targeted AWS services in scope for the MVP will be:

• Amazon S3
• Amazon SNS
• Amazon SQS
• Amazon ECR
• Amazon DynamoDB
• Amazon API Gateway V2

[adamrbennett]

Consider my use-case, which I believe is reasonably ubiquitous:

Manage infrastructure assets via Terraform (or CloudFormation)
Manage application assets via k8s manifests/helm charts

Under this approach I already have support for creating things like queues, topics, databases, etc. These assets are then available for integration by applications. What I lack support for is cloud assets that fall under the scope of applications -- essentially application assets that I want to declare in manifests that belong to the application helm chart. For example: Route53 records and CloudFront distros. These are the most desired services for me to be supported in this operator.

I guess my perspective is different, but I was hoping this operator would provide the ability to declare typical application assets in my application's helm chart. Considering I don't anticipate creating queues, topics and databases as part of an application release (they are usually shared infra services, IMO), I don't expect to gain much value from the MVP as defined. Adding Route53 and CloudFront would provide much more value. I'd love to contribute toward these implementations once the groundwork is laid.

[unthought]

@adamrbennett Not sure you're aware of this, but generic Route53 entries can be managed using external-dns. Which works well also with Ingress & Service resources (Nginx Ingress controller, NLB in tree on services, ALB Ingress controller). Cert manager has it's own integration into Route53 for ACME dns0 validation. However, I don't have an answer for managing CloudFront from inside kubernetes, I manage that through Pulumi upfront. Those resources are also far less dynamic, so it hasn't proven to be a huge drawback to not have it as a kubernetes resource. It does however require that you provision ephemeral environments the same way, they don't just get automatically provisioned when deploying the resources but are an additional step upfront (I guess it would also be possible to wrap Pulumi to run in a controller similar to https://github.com/rancher/terraform-controller).

[mhausenblas]

For those reading this issue now or if you're subscribed and waiting for an update: please help us testing the MVP, see details in https://aws.github.io/aws-controllers-k8s/dev-docs/testing/

[albertollamaso]

I am surprised I do not see Route 53

[jescarri]

Any plans to support ACM Certificates?

[mhausenblas]

PSA: see the service controller release roadmap for the canonical status. Once we have all six services (Amazon S3, Amazon SNS, Amazon SQS, Amazon ECR, Amazon DynamoDB, and Amazon API Gateway V2) as per my previous comment in dev preview we consider the MVP to be 100% completed.

[RedbackThomson]

Closing as this information has become largely out of date, and superseded by other issues.