Skip to content
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

Merged
merged 5 commits into from
Dec 6, 2023

Conversation

tsorya
Copy link
Contributor

@tsorya tsorya commented Aug 16, 2023

Tested with 4.14.0-ec.2 in candidate channel

@openshift-ci openshift-ci bot requested review from nirarg and osherdp August 16, 2023 14:03
@tsorya tsorya force-pushed the igal/ingress branch 2 times, most recently from 27b97fd to f56cf70 Compare August 22, 2023 09:21
@tsorya tsorya force-pushed the igal/ingress branch 4 times, most recently from e027d9c to a6077e8 Compare August 28, 2023 17:20
@tsorya
Copy link
Contributor Author

tsorya commented Aug 28, 2023

/retest

@tsorya tsorya force-pushed the igal/ingress branch 2 times, most recently from 8d2ce7d to eb605fe Compare September 3, 2023 08:57
@tsorya tsorya changed the title DRAFT: ingress OCM-2643: Allow default ingress configurations Sep 3, 2023
@openshift-ci-robot
Copy link

openshift-ci-robot commented Sep 3, 2023

@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.

@tsorya tsorya force-pushed the igal/ingress branch 5 times, most recently from d41b685 to de3e67d Compare September 4, 2023 08:46
@openshift-ci-robot
Copy link

openshift-ci-robot commented Sep 4, 2023

@tsorya: This pull request references OCM-2643 which is a valid jira issue.

In response to this:

Tested with 4.14.0-ec.2 in candidate channel

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.

Copy link
Member

@nirarg nirarg left a 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?

provider/cluster_rosa_classic_resource.go Outdated Show resolved Hide resolved
provider/cluster_rosa_classic_resource.go Outdated Show resolved Hide resolved
provider/cluster_rosa_classic_resource.go Outdated Show resolved Hide resolved
@bardielle
Copy link
Member

/hold
would be merged after framework changes

"github.com/terraform-redhat/terraform-provider-rhcs/provider/common/attrvalidators"
)

const lowestDefaultIngressVer = "4.14.0-0"
Copy link
Member

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

Copy link
Contributor Author

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" ?

Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Contributor

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

Copy link
Member

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
╵

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

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

provider/defaultingress/ingress.go Outdated Show resolved Hide resolved
provider/defaultingress/ingress.go Outdated Show resolved Hide resolved
@tsorya tsorya force-pushed the igal/ingress branch 2 times, most recently from 2a3e344 to 1a4030e Compare December 3, 2023 15:20
@tsorya tsorya force-pushed the igal/ingress branch 2 times, most recently from 6c55df0 to 4708605 Compare December 4, 2023 09:35
}

if !reflect.DeepEqual(state, plan) {
err := validateDefaultIngress(ctx, plan)
Copy link
Member

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?

Copy link
Contributor Author

@tsorya tsorya Dec 4, 2023

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

Copy link
Member

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

provider/defaultingress/ingress.go Show resolved Hide resolved
provider/defaultingress/ingress.go Outdated Show resolved Hide resolved
provider/defaultingress/notemptymap_validator.go Outdated Show resolved Hide resolved
@@ -0,0 +1,453 @@
package defaultingress
Copy link
Contributor

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 🤔

Copy link
Contributor

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

Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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

@tsorya
Copy link
Contributor Author

tsorya commented Dec 4, 2023

/retest

@nirarg
Copy link
Member

nirarg commented Dec 5, 2023

@tsorya thank you for the great work here
/approve
/lgtm

Copy link

openshift-ci bot commented Dec 5, 2023

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved label Dec 5, 2023
@tsorya
Copy link
Contributor Author

tsorya commented Dec 5, 2023

/retest

@nirarg
Copy link
Member

nirarg commented Dec 6, 2023

/lgtm

@openshift-ci openshift-ci bot added the lgtm label Dec 6, 2023
@openshift-merge-bot openshift-merge-bot bot merged commit 8dbe6c7 into terraform-redhat:main Dec 6, 2023
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants