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

Update label to identify number of pods #648

Conversation

ChristianZaccaria
Copy link
Contributor

@ChristianZaccaria ChristianZaccaria commented Sep 22, 2023

Issue link

What changes have been made

Updated label selector.

Verification steps

  1. With MCAD running
  2. Create an AppWrapper
  3. Search in the MCAD logs for There are.
  4. See 3 pods of your AppWrapper and their status.

image

Checks

  • I've made sure the tests are passing.
  • Testing Strategy
    • Unit tests
    • Manual tests

@openshift-ci openshift-ci bot requested review from dmatch01 and sutaakar September 22, 2023 16:41
@openshift-ci
Copy link

openshift-ci bot commented Sep 22, 2023

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign sutaakar for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found 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

@@ -144,7 +144,7 @@ func GetQueueJobKey(obj interface{}) (string, error) {
// UpdateQueueJobStatus was part of pod informer, this is now a method of queuejob_controller file.
// This change is done in an effort to simplify the controller and enable to move to controller runtime.
func (qjm *XController) UpdateQueueJobStatus(queuejob *arbv1.AppWrapper) error {
labelSelector := fmt.Sprintf("%s=%s", "appwrapper.mcad.ibm.com", queuejob.Name)
labelSelector := fmt.Sprintf("%s=%s", "ray.io/cluster", queuejob.Name)
Copy link
Contributor

@sutaakar sutaakar Sep 25, 2023

Choose a reason for hiding this comment

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

This looks suspicious.
Why would MCAD label pod using Ray label?

Copy link
Contributor

Choose a reason for hiding this comment

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

Right. @ChristianZaccaria this probably works for your particular use case, but that mechanism must be generic, for whatever resources managed by the AppWrapper. So the root cause is likely a missing update of these managed resources, so they are labeled with appwrapper.mcad.ibm.com.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that makes sense now. The managed resources are not updating their labels to use appwrapper.mcad.ibm.com. So, are we speaking about a bug issue, or is this something just happening on my end? (I suppose in any case, we could probably close this issue). Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

It's very possible it's a bug. One possibility is that controller owning the resource / generic item overwrites the label applied by MCAD.

@ChristianZaccaria
Copy link
Contributor Author

Closing PR. Issue #646 has been updated to reflect what has been discussed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants