-
Notifications
You must be signed in to change notification settings - Fork 178
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
[ARO-13400] Old E2E pipeline uses MiWi clusters #4056
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 noticed several new libraries being imported some of which are not in fully supported states. Do we already use these libraries elsewhere? Do we know the history behind these selections?
@@ -601,6 +605,8 @@ github.com/rogpeppe/go-internal v1.12.0/go.mod h1:E+RYuTGaKKdloAfM02xzb0FW3Paa99 | |||
github.com/russross/blackfriday v1.6.0 h1:KqfZb0pUVN2lYqZUYRddxF4OR8ZMURnJIG5Y3VRLtww= | |||
github.com/russross/blackfriday v1.6.0/go.mod h1:ti0ldHuxg49ri4ksnFxlkCfN+hvslNlmVHqNRXXJNAY= | |||
github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM= | |||
github.com/sagikazarmark/locafero v0.6.0 h1:ON7AQg37yzcRPU69mt7gwhFEBwxI6P9T4Qu3N51bwOk= |
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 a library we're already using?
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 added viper as a dependency to help managing the different envioronment variables as a config struct ( see ClusterConfig definition and viper usage in NewClusterConfigFromEnv)
All the addiitonal dependencies are pulled in as dependencies of viper itself.
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 left some comments on the pipeline / bash components here. Thanks for your efforts!
Just to confirm, this PR merge won't be impacting the Prod release pipeline, or in other words will the MIWI e2e cluster creation will run as part of Prod release pipeline? We don't want it to be running in the Prod until the preview API endpoints are available there. |
Please rebase pull request. |
This PR shouldn't have an impact on the prod pipeline. Using a miwi cluster for the E2E tests needs to be explicitly enabled in the pipeline. |
db9f224
to
62e78f3
Compare
e8180be
to
bbe0738
Compare
Co-authored-by: Kipp Morris <[email protected]>
Please rebase pull request. |
Co-authored-by: Kipp Morris <[email protected]>
/azp run e2e |
Azure Pipelines successfully started running 1 pipeline(s). |
Please rebase pull request. |
@hlipsig I'm importing a pre-release version of viper to simplify the handling of env vars in the hack script. This version supports directly parsing the env vars into a config struct (like in ARO-RP/pkg/util/cluster/cluster.go Line 123 in 84f0863
Do you think it's an issue to have a pre-release dependency? If so, i could also rewrite that part. |
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 LGTM, I posed a few questions, but am otherwise good to approve this on next rebase.
] | ||
}, | ||
{ | ||
"openShiftVersion": "4.14", |
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.
Note for a future PR - the ARO team should find a way to consolidate PWIRS between OCP versions between 4.14 and 4.18 so we don't duplicate this JSON for each version.
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.
Since these are JSON manifests representing static data, I think duplicating the JSON for each version is probably the correct approach here. As a developer trying to read and understand the role sets for a given version, I wouldn't want to have to, for example, read the role set for 4.14 and then additionally parse through the incremental changes added in each version between 4.14 and the version I care about.
@@ -209,6 +209,12 @@ func (m *manager) deployBaseResourceTemplate(ctx context.Context) error { | |||
} | |||
|
|||
resources = append(resources, r...) | |||
|
|||
storageBlobContributorRBAC, err := m.fpspStorageBlobContributorRBAC(clusterStorageAccountName, m.fpServicePrincipalID) |
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 extra role assignment is needed because of a missing permission in our built-in role, correct?
@@ -231,24 +237,16 @@ func (m *manager) deployBaseResourceTemplate(ctx context.Context) error { | |||
) | |||
} | |||
|
|||
if !m.env.FeatureIsSet(env.FeatureDisableDenyAssignments) { |
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 a reason we're moving the deny assignment append from its original location?
@@ -58,6 +58,20 @@ jobs: | |||
displayName: Enable regression tests in CI | |||
condition: in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI') | |||
|
|||
- script: | |
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 it easy for us to rename this pipeline/azp run target to something like /azp run e2e-wimi or something similar rather than /azp run e2e
? We can handle it in a future PR as well, if that's easier.
This was raised as something that could cause confusion for contributors who want to re-run CI e2e as normal but end up kicking off a MIWI e2e instead.
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 looking into that. currently i'm unsure how to rename a pipeline.
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.
LGTM pending a rebase and responses to Caden's feedback.
] | ||
}, | ||
{ | ||
"openShiftVersion": "4.14", |
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.
Since these are JSON manifests representing static data, I think duplicating the JSON for each version is probably the correct approach here. As a developer trying to read and understand the role sets for a given version, I wouldn't want to have to, for example, read the role set for 4.14 and then additionally parse through the incremental changes added in each version between 4.14 and the version I care about.
/azp list |
CI/CD Pipelines for this repository: |
Please rebase pull request. |
Which issue this PR addresses:
Fixes ARO-6153
Fixes ARO-13400
Fixes ARO-6196
What this PR does / why we need it:
This PR is the amalgamation of most miwi e2e efforts from @bitoku and Me. Roughly speaking, it implements the following:
After this PR is merged, it is possible to run e2e tests against a miwi cluster on a PR by triggering the old pipeline with this comment: