-
Notifications
You must be signed in to change notification settings - Fork 247
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
Change nfd container image registry #177
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Still relevant /remove-lifecycle rotten |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Need to get back to this in the near future |
@marquiz Do we have any update on this? |
Not really 😬 But, thanks for poking this. I think we could ask for a gcr.io image repository (https://github.com/kubernetes/k8s.io/tree/master/k8s.gcr.io). In the first stage we would use the gcr.io repos but still do image builds in travis-ci (plus the k8s.io image promoter for releases). In the second stage we could enable automatic gcr builds. I'll create PRs for the first stage |
I created kubernetes/k8s.io#524 |
kubernetes/k8s.io#524 has been merged, we can move one here :) |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Now, waiting for kubernetes/k8s.io#880 to be merged in order to get the rights to promote images |
/remove-lifecycle stale |
From the perspective of our project everything is basically now in place. I was able to push and promote the previous release: you can try out {asia,eu,us}.gcr.io/k8s-artifacts-prod/nfd/node-feature-discovery:v0.5.0 However, I'd still wait until the k8s.gcr.io domain flip has been completed so that we can use |
The domain flip has been rolled out and I now have a PR to publish the latest release (v0.6.0) in After that we should be able to change our references of |
This is now complete. Staging images are found at: Release images at: |
Version 0.4.0 Node-feature-discovery was migrated into a new repository under the kubernetes-sigs organization in Github (kubernetes-sigs#175). Related to the migration, the final container image registry/repo hasn't been dediced yet (kubernetes-sigs#177) – for this release we still use the old repo. Major changes - Split NFD into client and server (kubernetes-sigs#209) - Changes in labels: - NFD label namespace was changed to 'feature.node.kubernetes.io/' (kubernetes-sigs#176) - 'nfd-' prefix was dropped from all feature labels - NFD version label (feature.node.kubernetes.io/node-feature-discovery.version) was replaced by an annotation (nfd.node.kubernetes.io/version) - network SRIOV labels were changed (kubernetes-sigs#173): - 'network-sriov' -> 'network-sriov.capable' - 'network-sriov-configured' -> 'network-sriov.configured' - selinux detection was moved to kernel feature source - 'selinux' -> 'kernel-selinux.enabled' - cpuid, pstate and RDT labels moved under cpu feature source (kubernetes-sigs#217) - 'cpuid-<cpuid flag>' -> 'cpu-cpuid.<cpuid flag>' - 'pstate-turbo' -> 'cpu-pstate.turbo' - 'rdt-<rdt feature>' -> 'cpu-rdt.<rdt feature>' - Support for config file (kubernetes-sigs#169). Currently with three configurable feature sources i.e. cpu (kubernetes-sigs#224), kernel (kubernetes-sigs#157) and pci (kubernetes-sigs#168) - Support for non-binary labels, with arbitrary values other than plain 'true' - PCI device detection (kubernetes-sigs#168) - Kernel version detection (kubernetes-sigs#157) - Kernel config option detection (kubernetes-sigs#146) - Support for custom feature-detector hooks (kubernetes-sigs#144) - Support OS version detection (kubernetes-sigs#149, kubernetes-sigs#211) - Detection of hardware multithreading, such as Intel Hyper-Threading Technology (kubernetes-sigs#147) - Arm64 support for CPUID detection (kubernetes-sigs#194) - Validation of feature label names and values (kubernetes-sigs#199, kubernetes-sigs#219) - Detection of NVDIMM devices (kubernetes-sigs#214) - Get labels by reading from file in 'local' source (kubernetes-sigs#228) - Detection of Intel SST-BF (Speed Select Technology - Base Frequency) (kubernetes-sigs#235) - Make it possible to create feature labels in non-default namespace (kubernetes-sigs#231). Currently possible for using the local source (hooks and files). Miscellaneous - Template specs converted from json to yaml - Documentation updates and fixes
Moving from kubernetest-incubator org to kubernetes-sigs org (#175), it would probably be logical to also move the nfd images to a new registry, in order to reflect the new host organization.
We currently use https://quay.io/repository/kubernetes_incubator/node-feature-discovery. Does the registry host matter (e.g. gcr.io vs quay.io)? Is there some kubernetes(-sigs) project under quay.io that we could possibly use?
The text was updated successfully, but these errors were encountered: