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

Rework replica logic #427

Merged
merged 2 commits into from
Dec 7, 2023
Merged

Conversation

kim-tsao
Copy link
Contributor

@kim-tsao kim-tsao commented Dec 5, 2023

What does this PR do?:

  • Updates the logic so deployment replicas are set to 1 by default if implied (i.e. unset in the component spec, devfile and inline deployment). Order of precedence is comp.spec.replicas > devfile replicas > deployment replicas
  • The component attribute deployment/replicas: 1 will be written for the default case and will trigger an update to the component model.
  • If the replicas are only specified in the deployment, no component attribute will be generated (it'll be removed if previously set). We will rely on the value that's already specified (by parsing) rather than the one set in the attribute
  • Fixed some bugs
  • Updated test cases so there's a greater coverage. Mixed up some numbers so we're not always testing with replica 1

Which issue(s)/story(ies) does this PR fixes:

https://issues.redhat.com/browse/RHTAPBUGS-12

PR acceptance criteria:

  • Unit/Functional tests

  • Documentation

  • Client Impact

How to test changes / Special notes to the reviewer:

  1. Built the HAS image and deployed on a local cluster. Created a token with read and write permissions to write into a test org
  2. Deployed the sample Application and Component. Verified the replica was set to 1 in the generated deployment
  3. Updated the Component CR to set replicas to 0. Verified the replica was set to 0 in the generated deployment
  4. Updated the Component CR to remove the replica field. Verified the replica was set to 1 (value from the deployment)
  5. Created a new Component CR with the QE test and verified the replica was 1 (and not 0 as it was set in the failing runs)

Signed-off-by: Kim Tsao <ktsao@redhat.com>
Copy link

codecov bot commented Dec 6, 2023

Codecov Report

Attention: 16 lines in your changes are missing coverage. Please review.

Comparison is base (5c90c13) 81.26% compared to head (cbad2a2) 81.22%.

Files Patch % Lines
controllers/update.go 75.00% 10 Missing and 4 partials ⚠️
pkg/devfile/devfile.go 88.23% 0 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #427      +/-   ##
==========================================
- Coverage   81.26%   81.22%   -0.04%     
==========================================
  Files          32       32              
  Lines        4788     4848      +60     
==========================================
+ Hits         3891     3938      +47     
- Misses        705      713       +8     
- Partials      192      197       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

controllers/update.go Outdated Show resolved Hide resolved
controllers/update.go Show resolved Hide resolved
controllers/update.go Show resolved Hide resolved
controllers/update.go Outdated Show resolved Hide resolved
Comment on lines +135 to +142
replica := resources.Deployments[0].Spec.Replicas
if replica != nil {
// if there is no component attribute, we will use the value in the deployment spec
currentReplica = *replica
} else {
// default value is 1. We shouldn't hit this code path since this check is done in the update logic and will write the attribute deployment/replicas:1
currentReplica = 1
}
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 these lines can be simplified?

  1. we are checking if replica is set in deploy
  2. if it is, we are reading it and setting it back 🤔

Even when we are checking if its empty and setting it to 1, do we even need to? Its 1 by default in Kubernetes i.e. if you were to create a pod without this property there is only one repllca, 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.

It looks redundant but it's because we are searching for the component attribute key first in line 129

currentReplica := int32(component.Attributes.GetNumber(ReplicaKey, &replicaErr))

We are relying on the presence of the attribute to override anything that's set in deployment but if it doesn't exist, it'll return a KeyNotFoundError and assign a 0 value. Similar to the previous comment it's there to "reset" the value

Signed-off-by: Kim Tsao <ktsao@redhat.com>
Copy link

sonarqubecloud bot commented Dec 6, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

Copy link

openshift-ci bot commented Dec 6, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kim-tsao, maysunfaisal

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:
  • OWNERS [kim-tsao,maysunfaisal]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kim-tsao kim-tsao merged commit 599e4d3 into redhat-appstudio:main Dec 7, 2023
14 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.

2 participants