-
Notifications
You must be signed in to change notification settings - Fork 49
examples: aks-production cluster config update #1307
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this PR is really needed.
How about adding |
Yeah, I think that make sense 👍 |
ccc7c35
to
e63a97a
Compare
@invidian in production config we are already using backend as s3, so I guess we could add external-dns and ingresses to web-ui? |
Hmm, true. I guess it's fine to add it then, though still S3 is easier to consume than Route53. |
e63a97a
to
2d7716a
Compare
2d7716a
to
21d0151
Compare
@@ -33,21 +31,6 @@ variable "location" { | |||
default = "West Europe" | |||
} | |||
|
|||
variable "state_s3_key" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we remove it? For production setups using local state is not recommended. And we do not have an alternative right now. See #361.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I did not know about it, will revert it back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @surajssd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it is practical for someone to use S3 when they are deploying cluster to AKS.
It is more practical to store the assets locally than someone creating an account on AWS just for storing assets on S3. I think we should not add S3 or any AWS related stuff for Azure. It is not how production setup for a pragmatic user will look like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either we add a way to store assets on Azure and then add that to this docs OR use local dir to store assets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you say it's not production ready? I don't think practicality plays a role in reliability/robustness required to treat something as "production-ready".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The goal of this document is to be useful not just something that works. Having two cloud accounts to run a cluster on one is not something one would do in production, unless one cloud lacks the functionality. In this case Azure has a functionality we need to implement it or suggest using local dir for assets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove production config for AKS then until we implement Azure backend support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or And leave this PR as it is for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by "leave"? To keep it open?
I think we should remove the production configuration.
Add new compatible components which we test on CI. Signed-off-by: knrt10 <kautilya@kinvolk.io>
21d0151
to
52aaf44
Compare
Add new compatible components which we test on CI. Remove AWS dependant
backend as it should not be needed on AKS cluster.
Signed-off-by: knrt10 kautilya@kinvolk.io