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

config: CNF installation (3.1) Limit cnf_setup to only one CNF #2162

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

svteb
Copy link
Collaborator

@svteb svteb commented Sep 30, 2024

Description

Remove the ability of users to run cnf-testsuite cnf_setup {../testsuite.yml} multiple times.

Issues:

Refs: #2095 #2120

How has this been tested:

  • Covered by existing integration testing
  • Added integration testing to cover
  • Verified all A/C passes
    • develop
    • master
    • tag/other branch
  • Test environment
    • Shared Packet K8s cluster
    • New Packet K8s cluster
    • Kind cluster
  • Have not tested

Types of changes:

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update

Checklist:

Documentation

  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • No updates required.

Code Review

  • Does the test handle fatal exceptions, ie. rescue block

Issue

  • Tasks in issue are checked off

@svteb svteb changed the title Feat: Limit cnf_setup to only one CNF config: CNF installation (3.1?) Limit cnf_setup to only one CNF Sep 30, 2024
@svteb
Copy link
Collaborator Author

svteb commented Sep 30, 2024

I have some problems with this one, the main issue is that it would be easiest to implement this change after the rest of the #2120 epic is already done. With #2120 finished we could leverage the ability of setting up multiple CNFs as one, as currently some tests (/spec/5g/ran_spec.cr) rely on setting up two CNFs. There is a hack around this, and that is to use the Helm.install function directly, followed up by KubectlClient::Get.resource_wait_for_install, which is not exactly pretty.

The issue with KubectlClient::Get.resource_wait_for_install is that there are multiple deployments for 5g which could be verified but would make for some ugly code and we would lose out on some of the output that is already in cnf_manager.cr.

This is the code from cnf_manager.cr that verifies a resource is ready, separating it into a different function and reusing it would also take some time and be somewhat unnecessary since cnf_manager.cr is being rewritten somewhere down the #2120 epic line.

        workload_resource_names.each do | resource |
          stdout_success "Waiting for resource (#{current_resource_number}/#{total_resource_count}): [#{resource[:kind]}] #{resource[:name]}", same_line: true
          ready = KubectlClient::Get.resource_wait_for_install(resource[:kind], resource[:name], wait_count: wait_count, namespace: resource[:namespace])
          if !ready
            stdout_failure "CNF setup has timed-out, [#{resource[:kind]}] #{resource[:name]} is not ready after #{wait_count} seconds.", same_line: true
            stdout_failure "Recommended course of actions would be to investigate the resource in cluster, then call cnf_cleanup and try to reinstall the CNF."
            exit 1
          end
          current_resource_number += 1
        end
        stdout_success "All CNF resources are up!", same_line: true

We should rethink how necessary this change is in the current situation. Temporary solutions are available, but we should decide how much more we want to bloat the code if it will be removed eventually.

@svteb svteb force-pushed the multiple_cnfs branch 2 times, most recently from 3e26888 to 4c774d9 Compare October 2, 2024 08:46
@kosstennbl kosstennbl changed the title config: CNF installation (3.1?) Limit cnf_setup to only one CNF config: CNF installation (3.1) Limit cnf_setup to only one CNF Oct 3, 2024
spec/5g/ran_spec.cr Outdated Show resolved Hide resolved
spec/5g/ran_spec.cr Outdated Show resolved Hide resolved
spec/5g/ran_spec.cr Outdated Show resolved Hide resolved
spec/setup_spec.cr Show resolved Hide resolved
Copy link
Collaborator

@kosstennbl kosstennbl left a comment

Choose a reason for hiding this comment

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

LGTM, checks that were canceled are from duplicate workflow

Copy link
Collaborator

@martin-mat martin-mat left a comment

Choose a reason for hiding this comment

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

lgtm

Refs: #2095
- In attempt to set up a different CNF the user gets a warning and is
blocked from proceeding.
- There were some changes necessary in the ran_spec.cr tests to forego
using two cnf_setups (auxiliary function was created to deploy 5g
through helm instead). This should be changed in the future when
cnf_manager.cr is rehauled.
- This change also removes two spec tests that were considered
unnecessary/non-conformant with the new approach to only having a
single CNF set up at any given time.
- Spec test to verify functionality was added.
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.

4 participants