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

Added support for NS autoloadbalancing #4161

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

HaruChebrolu
Copy link
Contributor

@HaruChebrolu HaruChebrolu commented Oct 14, 2024

Description

Changes to support NS autoloadbalancing
Doc: https://docs.google.com/document/d/1bpx21903Sof1JzGTg81lG7lnk4QeCcqo6uF28Au_zEc/edit#heading=h.m22j2pb1oqna
Polarion:
CEPH-83598716
CEPH-83598717

Logs link: http://magna002.ceph.redhat.com/cephci-jenkins/harika/cephci-run-YR9PMT/

click to expand checklist
  • Create a test case in Polarion reviewed and approved.
  • Create a design/automation approach doc. Optional for tests with similar tests already automated.
  • Review the automation design
  • Implement the test script and perform test runs
  • Submit PR for code review and approve
  • Update Polarion Test with Automation script details and update automation fields
  • If automation is part of Close loop, update BZ flag qe-test_coverage “+” and link Polarion test

@HaruChebrolu HaruChebrolu self-assigned this Oct 14, 2024
Copy link
Contributor

openshift-ci bot commented Oct 14, 2024

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: HaruChebrolu

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

@HaruChebrolu HaruChebrolu changed the title Ns autoloadbalancing Added support for NS autoloadbalancing Oct 14, 2024
Copy link
Contributor

@rahullepakshi rahullepakshi left a comment

Choose a reason for hiding this comment

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

Can we avoid running "gw info" command so many times? It creates confusion while analyzing logs

Also namespace list or probably any CLI output is logged twice. Any idea why? can we avoid it?

@HaruChebrolu
Copy link
Contributor Author

Can we avoid running "gw info" command so many times? It creates confusion while analyzing logs

Also namespace list or probably any CLI output is logged twice. Any idea why? can we avoid it?

Can we avoid running "gw info" command so many times? It creates confusion while analyzing logs - "gw info" was running for each GW entity operation like "subsystem add", "listener add" for 2 reasons.

  • to check the GW health after evry operation
  • to use the few properties from "gw info" output to subsequent operations instead of hardcoding things
    Also namespace list or probably any CLI output is logged twice. Any idea why? can we avoid it? - its being printed twice because of pretty_print and our own logger to check on exit_code. We need them inorder to diagnose on automation errors.

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.

2 participants