-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OCM-2643: Allow default ingress configurations #242
OCM-2643: Allow default ingress configurations #242
Conversation
27b97fd
to
f56cf70
Compare
e027d9c
to
a6077e8
Compare
/retest |
8d2ce7d
to
eb605fe
Compare
@tsorya: This pull request references OCM-2643 which is a valid jira issue. In response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
d41b685
to
de3e67d
Compare
@tsorya: This pull request references OCM-2643 which is a valid jira issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
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.
Great work, just few comments
@sagidayan can you please also take a look?
/hold |
de3e67d
to
181ad9e
Compare
181ad9e
to
6cf3e31
Compare
provider/defaultingress/ingress.go
Outdated
"github.com/terraform-redhat/terraform-provider-rhcs/provider/common/attrvalidators" | ||
) | ||
|
||
const lowestDefaultIngressVer = "4.14.0-0" |
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 its shouldn't be hard coded here, at least move it to be defined in the sdk library
If you agree, I'm ok with just opening ticket for changing it and merging without this
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.
Not sure what you mean by "at least move it to be defined in the sdk library" ?
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.
Is this value can be changed in the future?
If yes, it need to be managed from one place, for both cli and tf provider, no?
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.
Can you point me to the right place? In anycase lets do it with another PR but need link to the place as i have no idea about the repo
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.
This is managed by the api, if the user supplies an older version he'll face an error. So it should be ok to not have this in TF. It's there in the CLI mostly for the interactive mode and alerting the user, for TF he'll be alerted through the api error
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.
@gdbranco When I ran it with an unsupported OCP version I got an error but it wasn't clear that this was the problem.... :
rhcs_default_ingress.default_ingress: Creating...
╷
│ Error: Failed building cluster default ingress
│
│ with rhcs_default_ingress.default_ingress,
│ on main.tf line 153, in resource "rhcs_default_ingress" "default_ingress":
│ 153: resource "rhcs_default_ingress" "default_ingress" {
│
│ Failed building autoscaler for cluster '27t5d6t120t5obdmf5948tc5nn6p40m3': status is 400, identifier is '400', code is 'CLUSTERS-MGMT-400' and operation identifier is
│ 'e7959ab9-0ea5-42a1-a768-d1b9dd9d6daa': Can't update load balancer type on legacy supported ingress 'j2b3' in cluster '27t5d6t120t5obdmf5948tc5nn6p40m3'. For more
│ information on how to be supported please check: https://access.redhat.com/node/7028653
╵
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.
Can we agree this is OCM issue or should we add cluster version param?
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.
This is the expected error on OCM side though. It links back to a KCS on how to get supported if the user is trying to add changes he can't.
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.
Maybe we could add to TF docs which are the attributes that can be modified in older versions. If the user tries to use those that are not available he'll face that error
2a3e344
to
1a4030e
Compare
6c55df0
to
4708605
Compare
} | ||
|
||
if !reflect.DeepEqual(state, plan) { | ||
err := validateDefaultIngress(ctx, plan) |
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.
Is there any reason why not adding this validation in the plan stage?
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.
not sure i understand, i assume it can be optimization but currently not sure what to do
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.
All validations that can be done in the plan mode (before calling the backend) need to be done than
I don't think this critical for now, lets open ticket to change it later
@@ -0,0 +1,453 @@ | |||
package defaultingress |
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.
Would you mind if we call it default application ingress?
Today we don't expose, but there's also an API ingress. So if we ever end up opening that it will be more complicated to adjust the terms 🤔
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 maybe we'll end up exposing through some attribute. Not sure 🤔 . Maybe we should just call it ingress then
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 agree that ingress
might be better package name here
The defaultingress
might confuse
@tsorya any thoughts here?
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.
As we are working only with default one I think we should stick with default in name. When we will have an option to work with not only default one we can change the package and add default to variables that can be set
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'm fine with pushing like this
Anyway, the package name is internal detail and can be changed without any issue
/retest |
@tsorya thank you for the great work here |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nirarg The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
/lgtm |
8dbe6c7
into
terraform-redhat:main
Tested with 4.14.0-ec.2 in candidate channel