Description of problem:
cu is using semantic version number for the names of the BuildConfigs. If a build is started via OpenShifts WebUI this build config should generate a build with the label openshift.io/build-config.name: dice-v1.69.0-snapshot.
This works in OpenShift 3.11 but not in 4.4. This produces the following label: openshift.io/build-config.name: dice-v1
All the information after the first dot is missing.
Deploy BuildConfigs on OpenShift 4.4 with specific label and it truncates the label unlike OpenShift 3.11 which shows complete label.
Steps to Reproduce:
1. Deploy the attached BuildConfigs on both OpenShift 4.4 and OpenShift 3.11.
2. Describe the build on OpenShift 4.4
3. Describe the build on OpenShift 3.11
4. Notice that the build on OpenShift 4.4 has truncated label
Label is truncated.
label should not be truncated.
All Kubernetes object labels must conform to the DNS label standard. Unlike names, periods are not allowed in label values . This validation was probably added after k8s 1.11 was released.
Truncating the label value after the period is probably not the best behavior - IMO we should try to replace the periods with dashes, then truncate if the label value exceeds the length maximum.
Downgrading severity of this bug to "low", as this issue should not block a release. The label truncation may be happening in openshift-apiserver via the instantiate build workflow.
Below is the latest response from cu,
It is possible to use for BuildConfig names "dots" since version 3.0 of OpenShift. This is still working until OpenShift 4.4 and I hope you don't plan to change this.
It is definitely possible to use "dots" in label values, and we are talking about the values, not the name of the labels!
As you can see there are also examples in the Kubernetes documentation about version numbers as labels in the best practices of using labels:
app.kubernetes.io/version : 5.7.21
From this point of view it is not needed to change the label value by replacing the "dots" with a different character!
Customer is correct - dots, underscores, and dashes are acceptable as values as long as there are alphanumerics in betweeen .
It looks like the kubernetes documentation page is incorrect, and that RFC 1123 does not allow for decimals in domains names except as section delimiters.
The long version:
According to RFC 952 (https://tools.ietf.org/html/rfc952) on which RFC 1123 builds upon:
"1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names"."
Reading section 2.1 (https://tools.ietf.org/html/rfc1123#page-13), I do not interpret any of the given information as saying that you can have a decimal anywhere else in the domain name other than as a separator. What RFC 1123 does add is additional length (up to 63 characters) and segments of the dns name may now begin with a digit (possibly added earlier, hard to tell from the wording).
I believe that the kubernetes documentation writers for https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ misunderstood what RFC 1123 was saying and adding to RFC 952.
Forgot to include a link to the code: https://github.com/kubernetes/kubernetes/blame/e077b0ffa48b1c0300a2cb25dd5d45d6fc358ade/staging/src/k8s.io/apimachinery/pkg/util/validation/validation.go#L177-L178
On further investigation, it appears we broke this behavior with the change for Bug #1777337 , which was applied to 4.5 and backported to 4.4 .
Verified in version as follow, build already show complete label.
[wewang@wangwen work]$ oc describe build/dice-v1.69.0-snapshot-1
Created: 37 seconds ago
Started: Fri, 09 Oct 2020 14:45:49 CST
Duration: running for 36s
Build Config: dice-v1.69.0-snapshot
Build Pod: dice-v1.69.0-snapshot-1-build
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.