Skip to content

Add external control bridge related infra#851

Draft
kostyanf14 wants to merge 4 commits intoHCK-CI:masterfrom
kostyanf14:prep-q-p
Draft

Add external control bridge related infra#851
kostyanf14 wants to merge 4 commits intoHCK-CI:masterfrom
kostyanf14:prep-q-p

Conversation

@kostyanf14
Copy link
Contributor

No description provided.

Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
These logs make NS creation process more visible and
allow to easyly debug problems in it.
Log to STDERR only for now to simplify code.

Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
@gemini-code-assist
Copy link

Summary of Changes

Hello @kostyanf14, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request lays the groundwork for a new feature that facilitates external control of virtual machines, likely for specialized testing environments. It involves significant changes to how network resources are provisioned and managed within isolated namespaces, moving towards a more flexible and configurable network setup for client VMs. The updates also include necessary dependency bumps and improved debugging capabilities for network-related operations.

Highlights

  • External Control Bridge Infrastructure: Introduced new infrastructure to support an 'external control bridge' feature, enabling virtual machines to connect to external Controller/Studio PC networks. This includes a new script for veth pair management and updates to network namespace handling.
  • Dependency Updates: Updated the rtoolsHCK gem to a specific development branch and bumped versions for rdoc and stringio gems.
  • WinRM Configuration Change: Modified platform configuration files to use winrm_addr instead of winrm_port for client WinRM connections, indicating a shift towards direct IP address configuration for client communication.
  • CLI and Namespace Management Enhancements: Added a new command-line option --control-bridge-external and refactored namespace entry logic to pass configuration options, allowing for dynamic setup of network interfaces based on these new parameters.
  • Debug Logging: Added extensive debug logging to bin/ns_unshared and bin/nsd scripts to provide better visibility into network setup operations and process execution.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request introduces infrastructure for an external control bridge, which is a significant networking enhancement. The changes are mostly well-implemented, including a new command-line option, a script for network setup, and updates to platform configurations. However, I've identified a few issues that need attention. There's a critical bug in the error handling of the new ns_veth script that could lead to a NameError. Additionally, there's an unsafe command execution pattern in ns.rb that could pose a security risk. I've also made a suggestion to improve dependency management for better build reproducibility. Please review the detailed comments for suggestions on how to address these points.

Comment on lines +38 to +44
command.each do |cmd|
$stderr.write "[ns_veth #{side}] Running (wait spawn): #{cmd.join(' ')}\n"
Process.wait spawn(*cmd, out: :err)
raise $CHILD_STATUS.to_s unless $CHILD_STATUS.success?
rescue StandardError
raise "#{cmd}: command failed"
end

Choose a reason for hiding this comment

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

critical

There are a couple of issues with this error handling block:

  1. The rescue is placed after the command.each loop. In this position, the cmd variable from the loop is not in scope, which will lead to a NameError if an exception occurs within the loop.
  2. The error message raise "#{cmd}: command failed" is not very informative. It converts an array to a string (e.g., ["ip", "link", ...]), which is not readable, and it swallows the original exception details.

To fix this, the rescue should be inside the loop, and the error message should be improved to be more descriptive and include the original error.

    command.each do |cmd|
      begin
        $stderr.write "[ns_veth #{side}] Running (wait spawn): #{cmd.join(' ')}\n"
        Process.wait spawn(*cmd, out: :err)
        raise "command failed with status #{$CHILD_STATUS.exitstatus}" unless $CHILD_STATUS.success?
      rescue StandardError => e
        raise "Command '#{cmd.join(' ')}' failed: #{e.message}"
      end
    end

Comment on lines +44 to +46
sudo = Process.euid.zero? ? [] : ['sudo']
cmd = %W[#{sudo} #{chdir}/bin/ns_veth host #{pid} #{run_id} #{ext_bridge}]
system(cmd.join(' '))

Choose a reason for hiding this comment

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

high

The command is constructed using cmd.join(' ') and executed with system(). This is unsafe and can lead to shell injection vulnerabilities if any of the command arguments (like chdir) contain spaces or other shell metacharacters. It's also inconsistent with other parts of the code (lines 64, 71) that use the safer system(*command) form.

Please construct the command as an array of arguments and use system(*cmd) to execute it safely.

          cmd = Process.euid.zero? ? [] : ['sudo']
          cmd.concat(["#{chdir}/bin/ns_veth", 'host', pid.to_s, run_id.to_s, ext_bridge])
          system(*cmd)

gem 'octokit'
gem 'openssl', require: false
gem 'rtoolsHCK', git: 'https://github.com/HCK-CI/rtoolsHCK.git', ref: 'v0.6.1'
gem 'rtoolsHCK', git: 'https://github.com/HCK-CI/rtoolsHCK.git', ref: 'VIRTWINKVM-1865'

Choose a reason for hiding this comment

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

medium

For reproducible builds, it's better to pin a dependency to a specific commit hash rather than a branch name. Branch refs can be updated, leading to different versions of the gem being installed over time. Please use the full commit hash from Gemfile.lock to ensure that builds are consistent.

gem 'rtoolsHCK', git: 'https://github.com/HCK-CI/rtoolsHCK.git', ref: 'f59ae987141d8d7192ede862802dbf3d9d0d9105'

"cpus": 4,
"memory_gb": 4,
"winrm_port": 4002,
"winrm_addr": "192.168.100.2",
Copy link
Contributor

Choose a reason for hiding this comment

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

The json update doesn't match the commit message. Maybe should be separate commit

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