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

The tagged - e.g. v4.0.1, v4.0.2 - versions manifests install pods from shifting images #1170

Closed
maiqueb opened this issue Sep 29, 2023 · 5 comments
Labels

Comments

@maiqueb
Copy link
Collaborator

maiqueb commented Sep 29, 2023

What happend:
When we use the manifest from a tagged version - e.g. v4.0.2 - the version of multus we are installing is not pinned, since this "snapshot" tag keeps getting overwritten everytime a PR is merged.

In essence, the snapshot and latest tags are essentially the same. Same thing happens with their thick counterparts.

What you expected to happen:
A manifest present on a "tagged" commit should point to a pinned image, not to one that varies over time.

How to reproduce it (as minimally and precisely as possible):
Install a versioned manifest.

Anything else we need to know?:

Environment:

  • Multus version
    image path and image ID (from 'docker images')
  • Kubernetes version (use kubectl version):
  • Primary CNI for Kubernetes cluster:
  • OS (e.g. from /etc/os-release):
  • File of '/etc/cni/net.d/'
  • File of '/etc/cni/multus/net.d'
  • NetworkAttachment info (use kubectl get net-attach-def -o yaml)
  • Target pod yaml info (with annotation, use kubectl get pod <podname> -o yaml)
  • Other log outputs (if you use multus logging)
@maiqueb
Copy link
Collaborator Author

maiqueb commented Sep 29, 2023

/cc @oshoval

Thanks for bringing this to my attention Or.
Do you want to add anything ?

oshoval added a commit to oshoval/ovs-cni that referenced this issue Oct 1, 2023
Since multus doesnt pin image correctly,
pin it before deploying multus.

See k8snetworkplumbingwg/multus-cni#1170

Signed-off-by: Or Shoval <oshoval@redhat.com>
@oshoval
Copy link
Member

oshoval commented Oct 1, 2023

Nope
here a ref for a temp wa if desired
k8snetworkplumbingwg/ovs-cni#282

kubevirt-bot pushed a commit to k8snetworkplumbingwg/ovs-cni that referenced this issue Oct 3, 2023
Since multus doesnt pin image correctly,
pin it before deploying multus.

See k8snetworkplumbingwg/multus-cni#1170

Signed-off-by: Or Shoval <oshoval@redhat.com>
@dougbtv
Copy link
Member

dougbtv commented Oct 9, 2023

I think two parts...

  • first: change from snapshot to stable so you at least get the latest tagged image
  • secondly: Should we have a new commit in each tag that adds the specific tagged image, so you're operating from that tag and tagged image?

@sdwilsh
Copy link

sdwilsh commented Nov 4, 2023

This problem is getting more problematic with time. I was going crazy because as I restarted nodes calico would stop working because multus couldn't find calico in /opt/cni/bin, which made no sense in v4.0.2 because that directory didn't exist until 1dd4edd. All of my problems went away once I pinned the image to v4.0.2-thick

sdwilsh added a commit to sdwilsh/ansible-playbooks that referenced this issue Nov 4, 2023
Unfortunately, the image in the daemonset for v4.0.2 uses a snapshot
that is effectively latest.  This change pins to `v4.0.2-thick` to match
the deployment being used.  See
k8snetworkplumbingwg/multus-cni#1170 for more
details.
Copy link

github-actions bot commented Feb 3, 2024

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the Stale label Feb 3, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants