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

fix uploading vm images using virtctl #422

Merged
merged 5 commits into from
Oct 16, 2024
Merged

fix uploading vm images using virtctl #422

merged 5 commits into from
Oct 16, 2024

Conversation

kvaps
Copy link
Member

@kvaps kvaps commented Oct 14, 2024

Upstream fix:
kubevirt/containerized-data-importer#3461

Signed-off-by: Andrei Kvapil kvapss@gmail.com

Summary by CodeRabbit

  • New Features

    • Introduced a new version (v1beta1) for the CDI operator alongside the existing version, enhancing configuration options.
    • Expanded spec section with detailed descriptions for various configurations including data volume management and TLS security profiles.
    • Added a new Ingress resource for the cdi-uploadproxy service, improving traffic routing capabilities.
    • Introduced new configuration parameters for dynamic upload proxy URL management.
  • Improvements

    • Updated permissions for the CDI operator to manage additional resources, improving its data handling capabilities.
    • Refined deployment configuration with updated container image references and environment variables for better operational control.
    • Enhanced network policy definitions by adding specific rules for new services while maintaining existing policies.

Copy link
Contributor

coderabbitai bot commented Oct 14, 2024

Caution

Review failed

The head commit changed during the review from f8df224 to 8bf00af.

Walkthrough

The changes involve significant updates to the cdi-operator.yaml file for the CDI operator within the KubeVirt project. This includes the introduction of a new Custom Resource Definition (CRD) version (v1beta1) alongside the existing v1alpha1, enhancements to the schema definitions, and an expansion of the spec section. Additionally, updates to the ClusterRole, ClusterRoleBinding, ServiceAccount, and Deployment sections have been made to improve permissions, roles, and container image references. Other files have seen updates related to configuration parameters, Ingress resources, network policies, and version mappings.

Changes

File Path Change Summary
packages/system/kubevirt-cdi-operator/templates/cdi-operator.yaml Added v1beta1 version to CRD, updated schema definitions, expanded spec, added ClusterRole, ClusterRoleBinding, ServiceAccount, and Role, modified Deployment with new image references and environment variables.
packages/system/kubevirt-cdi/templates/cdi-cr.yaml Added uploadProxyURLOverride field in spec.config for dynamic configuration based on Helm values.
packages/system/kubevirt-cdi/templates/ingress.yaml Introduced a new Ingress resource for cdi-uploadproxy, conditionally created based on uploadProxyHost and ingressClass.
packages/system/kubevirt-cdi/values.yaml Added new parameters: uploadProxyHost and ingressClass for enhanced configuration options.
packages/apps/tenant/Chart.yaml Updated version from 1.4.0 to 1.5.0.
packages/apps/tenant/templates/networkpolicy.yaml Added new Cilium network policy allow-to-cdi-upload-proxy and organized existing policies.
packages/apps/versions_map Updated version mappings for the tenant package, including specific commit hashes for versions.

Possibly related PRs

  • Update KubeVirt v1.3.1 #311: Updates to the versions_map file may indirectly relate to the main PR's changes in the cdi-operator.yaml file, as both involve versioning and resource management within the KubeVirt ecosystem.
  • Prepare release v0.13.0 #321: The changes in the values.yaml file for the KubeVirt CDI package may connect to the main PR's updates in cdi-operator.yaml, as both involve configuration management for Kubernetes resources.
  • Update RabbitMQ and add configuration for Users and VHosts #327: The RabbitMQ configuration updates may relate to the main PR's changes in resource definitions, as both involve enhancing Kubernetes resource management.
  • Prepare release v0.14.1 #338: Similar to Prepare release v0.13.0 #321, this PR's updates to the versions_map could relate to the main PR's versioning changes in the cdi-operator.yaml.
  • Prepare release v0.16.1 #390: The changes in the cozystack application, including updates to the image version, may connect to the main PR's focus on enhancing Kubernetes resource definitions and configurations.

Poem

In the garden of code, we hop and we play,
With versions anew, we brighten the day.
Roles and bindings, all set in a line,
The CDI operator, now truly divine!
So let’s raise our ears, and give a cheer,
For updates that bring us all near! 🐇✨


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (3)
packages/system/kubevirt-cdi/values.yaml (1)

1-2: Consider expanding the configuration file.

The current configuration file only contains two parameters. Depending on the requirements of your KubeVirt CDI setup, you might need to include additional configuration options.

Consider adding other common CDI configuration parameters, such as:

  • Resource limits and requests
  • Storage class configurations
  • Networking policies
  • Security settings

If these are defined elsewhere or use default values, it might be helpful to add comments explaining this.

packages/system/kubevirt-cdi/templates/ingress.yaml (1)

10-22: Ingress specification is properly configured.

The Ingress specification is well-structured:

  • The ingressClassName is dynamically set using the provided value.
  • The host is set using the uploadProxyHost value.
  • The backend service and port are correctly specified.
  • The path and pathType are appropriately set for routing all traffic to the service.

However, there's one potential improvement to consider:

Consider adding TLS configuration to the Ingress spec for enhanced security. This would typically involve adding a tls section under spec. For example:

spec:
  tls:
  - hosts:
    - {{ .Values.uploadProxyHost }}
    secretName: cdi-uploadproxy-tls

Note that you'd need to ensure the TLS secret is created separately.

packages/apps/tenant/templates/networkpolicy.yaml (1)

162-171: LGTM! Consider adding a comment for clarity.

The new 'allow-to-cdi-upload-proxy' policy is well-structured and aligns with the PR objective of fixing VM image uploading using virtctl. It correctly allows egress traffic to the CDI upload proxy in the 'cozy-kubevirt-cdi' namespace.

Consider adding a brief comment explaining the purpose of this policy, for example:

metadata:
  name: allow-to-cdi-upload-proxy
  namespace: {{ include "tenant.name" . }}
  # Allow communication with CDI upload proxy for VM image uploading
spec:
  # ... (rest of the policy remains unchanged)

This will help future maintainers understand the policy's purpose at a glance.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 17e9213 and cde1bca.

📒 Files selected for processing (6)
  • packages/apps/tenant/Chart.yaml (1 hunks)
  • packages/apps/tenant/templates/networkpolicy.yaml (1 hunks)
  • packages/apps/versions_map (1 hunks)
  • packages/system/kubevirt-cdi/templates/cdi-cr.yaml (1 hunks)
  • packages/system/kubevirt-cdi/templates/ingress.yaml (1 hunks)
  • packages/system/kubevirt-cdi/values.yaml (1 hunks)
✅ Files skipped from review due to trivial changes (1)
  • packages/apps/tenant/Chart.yaml
🧰 Additional context used
🪛 yamllint
packages/system/kubevirt-cdi/templates/cdi-cr.yaml

[warning] 8-8: wrong indentation: expected 2 but found 4

(indentation)


[error] 7-7: syntax error: expected the node content, but found '-'

(syntax)

packages/system/kubevirt-cdi/templates/ingress.yaml

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

🔇 Additional comments (12)
packages/system/kubevirt-cdi/values.yaml (2)

1-1: Verify the uploadProxyHost configuration.

The uploadProxyHost is set to "cdi.infra.aenix.org". This appears to be an internal infrastructure endpoint for the CDI upload proxy service.

Please confirm that:

  1. This hostname is correct and accessible within your infrastructure.
  2. The necessary DNS records and network configurations are in place to route traffic to this host.
  3. The upload proxy service is properly configured to handle requests at this hostname.
✅ Verification successful

uploadProxyHost configuration verified successfully.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify if the uploadProxyHost is referenced in other configuration files
rg --type yaml "cdi.infra.aenix.org"

Length of output: 116


2-2: Confirm the ingressClass configuration.

The ingressClass is set to "tenant-root", which is a non-standard value.

Please ensure that:

  1. This ingress class exists in your Kubernetes cluster.
  2. It's the correct class for routing CDI-related traffic.
  3. The corresponding Ingress controller is properly configured to handle this class.
packages/system/kubevirt-cdi/templates/cdi-cr.yaml (1)

7-9: LGTM! Dynamic configuration of uploadProxyURLOverride

The addition of the conditional block for uploadProxyURLOverride is a good improvement. It allows for dynamic configuration of the upload proxy URL based on the provided Helm values, which aligns with the PR objective of fixing VM image uploads using virtctl.

A few observations:

  1. The use of Helm templating here is appropriate and allows for flexible configuration.
  2. The indentation appears correct for Helm templates, despite the yamllint warning.
  3. This change enhances the adaptability of the CDI configuration across different environments.

To ensure this change is properly utilized, let's verify the uploadProxyHost value in the Helm chart:

🧰 Tools
🪛 yamllint

[warning] 8-8: wrong indentation: expected 2 but found 4

(indentation)


[error] 7-7: syntax error: expected the node content, but found '-'

(syntax)

packages/system/kubevirt-cdi/templates/ingress.yaml (6)

1-1: Conditional creation looks good.

The Ingress resource is conditionally created based on the presence of both uploadProxyHost and ingressClass values. This is a good practice to ensure the Ingress is only created when necessary.

🧰 Tools
🪛 yamllint

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)


2-3: API version and kind are correct.

The use of networking.k8s.io/v1 for the API version is appropriate for recent Kubernetes versions. The kind: Ingress is also correct.


4-9: Metadata and annotations are well-defined.

The metadata and annotations are correctly specified:

  • The name "cdi-uploadproxy" is descriptive and aligns with the service it's routing to.
  • The NGINX ingress controller annotations are appropriate for the use case, enabling HTTPS backend, SSL passthrough, and SSL redirect.

23-23: Conditional block is properly closed.

The conditional block is correctly closed with the {{- end }} directive.


1-1: Note on YAML linting:

The static analysis tool (yamllint) reported a syntax error on this line, but this is a false positive. The {{- if ... }} syntax is valid Helm template syntax used for conditional rendering and whitespace control. No changes are needed here.

🧰 Tools
🪛 yamllint

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)


1-23: Overall, the Ingress resource is well-defined and aligns with the PR objectives.

This new Ingress resource for the cdi-uploadproxy service is correctly implemented using Helm templating. It addresses the PR objective of fixing uploading VM images using virtctl by providing a proper ingress configuration. The conditional creation, correct API version, appropriate annotations, and well-structured specification all contribute to a solid implementation.

The only suggested improvement is to consider adding TLS configuration for enhanced security. Otherwise, this implementation should effectively route traffic to the cdi-uploadproxy service, facilitating the upload of VM images.

🧰 Tools
🪛 yamllint

[error] 1-1: syntax error: expected the node content, but found '-'

(syntax)

packages/apps/versions_map (1)

75-76: Version updates for the tenant package look good.

The changes to the tenant package versions are consistent with the file's structure and show a logical progression:

  1. Version 1.4.0 has been updated from HEAD to a specific commit (94c688f), indicating a stabilization of this version.
  2. A new version 1.5.0 has been added, pointing to HEAD, suggesting ongoing development.

These updates align with good versioning practices. However, it's not immediately clear how these changes relate to the PR objective of "fix uploading vm images using virtctl".

To ensure these changes are related to the PR objective, please run the following script:

This script will help verify if the specified commit or recent changes in the tenant package are related to the PR objective.

✅ Verification successful

Tenant package version updates are verified and relevant to the PR objective.

The recent changes in the tenant package versions align with the PR objective of fixing VM image uploads using virtctl:

  • The addition of tenant 1.5.0 points to ongoing development, which includes the commit cde1bca ("Allow specifying uploadproxy url") related to upload functionalities.
  • The update of tenant 1.4.0 to a specific commit ensures stability for this version.

These updates confirm that the version changes support the objectives of the PR.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if the commit 94c688f7 or recent commits in the tenant package are related to VM image uploading or virtctl.

# Test 1: Check the commit message for 94c688f7
echo "Checking commit 94c688f7:"
git show --no-patch --format=%B 94c688f7 | grep -iE "vm|image|upload|virtctl"

# Test 2: Check recent commits in the tenant package
echo "Checking recent commits in the tenant package:"
git log -n 10 --oneline -- packages/apps/tenant | grep -iE "vm|image|upload|virtctl"

Length of output: 371

packages/apps/tenant/templates/networkpolicy.yaml (2)

162-173: Overall structure and consistency look good.

The new 'allow-to-cdi-upload-proxy' policy is well-integrated into the existing file structure. It maintains consistency with other policies in terms of indentation, naming conventions, and overall format. The placement at the end of the file, just before the 'allow-to-ingress' policy, is appropriate and doesn't disrupt the existing flow of policies.

The changes align well with the existing file structure and do not interfere with the conditional logic used for other policies.


162-171: Consider conditional application of the new policy.

The new 'allow-to-cdi-upload-proxy' policy effectively supports the PR objective of fixing VM image uploading using virtctl. However, it's applied unconditionally to all pods in the namespace.

To ensure this aligns with the intended behavior:

  1. Confirm if this policy should always be applied or only under certain conditions.
  2. If conditional application is appropriate, consider wrapping it in a conditional block similar to other policies in this file.

For example:

{{- if .Values.enableCDIUpload }}
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-to-cdi-upload-proxy
  namespace: {{ include "tenant.name" . }}
spec:
  # ... (rest of the policy remains unchanged)
{{- end }}

This would allow more fine-grained control over when this policy is applied.

Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
@kvaps kvaps merged commit 4812874 into main Oct 16, 2024
2 checks passed
@kvaps kvaps deleted the cdi-upload branch October 16, 2024 16:37
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.

1 participant