There are two references in r/stx.2.0 that configure the image tag to be used for the k8s-plugins-sriov-network-device image: https://opendev.org/starlingx/ansible-playbooks/src/branch/r/stx.2.0/playboo... https://opendev.org/starlingx/config/src/branch/r/stx.2.0/puppet-manifests/s... It may only be the ansible-playbooks reference that has any effect, as the puppet-manifests reference may be stale code. The k8s-cni-sriov and k8s-plugins-sriov-network-device images are built as part of the regular build, and tagged with a versioned tag and a latest tag, as with the other stx images. However, these are loaded as part of the built-in platform-integ-app and therefore uses the static image tag that’s in the repo. What this means is that every load is referencing the master-stable-centos-latest tag when you initially bring up the system, which would be the latest weekly build at that time. This may not always work, if there is something incompatible in the new image. This is presumably what’s happened here with 2.0. My suggestion would be to treat these images, built from upstream sources, specially and manually tag them with versions as needed, updating the static references to those tags. In r/stx.2.0, we could update these static tags to the appropriate tag for that build - presumably the one referenced below by Ting. Going forward, we can manually tag the image in docker hub with whatever format we choose - such as 1.0.0, or maybe whatever version corresponds to the upstream repo at that time (ie. v3.0.0). Once we’ve manually tagged the image, we push an update into the repo to update the static reference to use the new tag. So for example: k8s-cni-sriov: Currently building from https://github.com/intel/sriov-cni/commit/365c8f8cc1204df84f3e976ea30f113e73..., which looks like it’s tagged as v2.2. We could retag the current build as starlingx/k8s-cni-sriov:v2.2, then update ansible-playbooks with the new tag. k8s-plugins-sriov-network-device: Building from: https://github.com/intel/sriov-network-device-plugin/commit/000db15405f3ce3b..., tagged as v3.1. We could retag the current build as starlingx/k8s-plugins-sriov-network-device:v3.1, then update ansible-playbooks with the new tag. Whenever there’s new content in these images we want to pick up, we retag the new build, and push updates to the static references. From: Chiing-Ting Huang [mailto:chiinting@gmail.com] Sent: Monday, November 04, 2019 10:17 PM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] sriov-network-device container issue Dear StarlingX Team I have installed StarlingX R2.0 in September, and kube-sriov-device-plugin can get VF at that time. I think the team updated starlingx/k8s-plugins-sriov-network-device docker image in October, so I cannot get VF now. So I roll back to starlingx/k8s-plugins-sriov-network-device:rc-2.0-centos-stable-20190826T233000Z.0 Best regards Ting