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

Release: Update payloads for v0.10.0 #448

Merged
merged 3 commits into from
Sep 25, 2024

Conversation

niteeshkd
Copy link

No description provided.

Update the enclave-cc runtime payloads to point to the v0.10.0
release of enclave-cc and update the pre-reqs payload.

Signed-off-by: Niteesh Dubey <[email protected]>
@niteeshkd niteeshkd requested a review from a team as a code owner September 20, 2024 16:03
@niteeshkd
Copy link
Author

Copy link
Member

@stevenhorsman stevenhorsman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @niteeshkd!

Copy link
Member

@portersrc portersrc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK to me. I sanity checked it by comparing against the same step for v0.9.0 here.

Copy link
Member

@fitzthum fitzthum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There still seems to be an issue with the kata version

Copy link
Contributor

@ldoktor ldoktor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It generally looks good, there is the v3.9.0 vs. 3.9.0 issue introduced in the 2nd commit and fixed in the 3rd one which needs to be corrected (so changes work separately).

One more thing I noticed is that there are still a couple of 3.9.0 entries here and there, shouldn't these be tackled together? {Makefile,config/manager/kustomization.yaml,config/manifests/bases/cc-operator.clusterserviceversion.yaml,bundle/manifests/cc-operator.clusterserviceversion.yaml}

@portersrc
Copy link
Member

portersrc commented Sep 23, 2024

One more thing I noticed is that there are still a couple of 3.9.0 entries here and there, shouldn't these be tackled together?

I looked at the files you pointed to, and I guess you mean the 0.9.0 entries (i.e. some lingering, hard-coded coco version numbers)? This is a good catch. I see @wainersm was modifying these in the past -- looks related to operator hub. Is now the time to fold those manual steps into this release process, or are things still too much in flux and requiring extra effort each release?

Edit: This is Step 8 for us currently.

Niteesh Dubey added 2 commits September 23, 2024 18:10
Update Kata payloads to 3.9.0 and bump the pre-reqs
payload for default, peer-pods and s390x ccruntimes

Signed-off-by: Niteesh Dubey <[email protected]>
Update operator version from v0.9.0 to v0.10.0.

Signed-off-by: Niteesh Dubey <[email protected]>
Copy link
Member

@fitzthum fitzthum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@fitzthum
Copy link
Member

Is now the time to fold those manual steps into this release process, or are things still too much in flux and requiring extra effort each release?

We have treated these as a later step in the past.

Copy link
Contributor

@mythi mythi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we did some manual testing too and seems working

@wainersm
Copy link
Member

One more thing I noticed is that there are still a couple of 3.9.0 entries here and there, shouldn't these be tackled together?

I looked at the files you pointed to, and I guess you mean the 0.9.0 entries (i.e. some lingering, hard-coded coco version numbers)? This is a good catch. I see @wainersm was modifying these in the past -- looks related to operator hub. Is now the time to fold those manual steps into this release process, or are things still too much in flux and requiring extra effort each release?

Yes, those are the changes required for publishing the released operator in operator hub. The instructions are in here but I think it's a good idea to merge the steps into this doc, all in all, it's part of the release.

I don't know if step 8 could also be done simultaneously with step 5 (this). The bundle generated bundle files will point to the built operator image (quay.io/confidential-containers/operator:v${TARGET_RELEASE}). I don't know if the tool that build the bundle will check the existence of the image, if yes then step 8 should be done after the release.

For 0.10.0 release, maybe let's not change the flow.

Edit: This is Step 8 for us currently.

@fitzthum fitzthum merged commit cb92e0f into confidential-containers:main Sep 25, 2024
18 checks passed
@fitzthum
Copy link
Member

I guess there is a nonzero chance of v0.10.1 so I will wait to tag the repo.

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.

7 participants