Bug 1862532 - BuildConfigs that uses points in the name are producing wrong labels on builds
Summary: BuildConfigs that uses points in the name are producing wrong labels on builds
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Build
Version: 4.4
Hardware: Unspecified
OS: Linux
Target Milestone: ---
: 4.6.0
Assignee: Corey Daley
QA Contact: wewang
Depends On:
Blocks: 1883994
TreeView+ depends on / blocked
Reported: 2020-07-31 16:07 UTC by Sahil thakare
Modified: 2020-10-27 16:22 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-10-27 16:21:54 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift openshift-apiserver pull 143 0 None closed Bug 1862532: Fix label value validation for BuildConfigs 2020-10-21 02:32:26 UTC
Github openshift openshift-controller-manager pull 137 0 None closed Bug 1862532: Fix label value validation for Builds 2020-10-21 02:32:26 UTC
Red Hat Product Errata RHBA-2020:4196 0 None None None 2020-10-27 16:22:21 UTC

Description Sahil thakare 2020-07-31 16:07:18 UTC
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.

How reproducible:
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

Actual results:

Label is truncated.

Expected results:

label should not be truncated.

Comment 2 Adam Kaplan 2020-08-04 17:12:26 UTC
All Kubernetes object labels must conform to the DNS label standard. Unlike names, periods are not allowed in label values [1]. 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.

[1] https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names

Comment 3 Sahil thakare 2020-08-06 13:56:36 UTC
Hello Team,

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!

Sahil Thakare

Comment 5 Adam Kaplan 2020-09-10 02:17:15 UTC
Customer is correct - dots, underscores, and dashes are acceptable as values as long as there are alphanumerics in betweeen [1].

[1] https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

Comment 7 Corey Daley 2020-09-30 03:07:40 UTC
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.

Comment 9 Adam Kaplan 2020-09-30 14:11:10 UTC
On further investigation, it appears we broke this behavior with the change for Bug #1777337 [1], which was applied to 4.5 and backported to 4.4 [2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1777337
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1804934

Comment 12 wewang 2020-10-09 06:49:31 UTC
Verified in version as follow, build already show complete label.

[wewang@wangwen work]$ oc describe build/dice-v1.69.0-snapshot-1
Name:		dice-v1.69.0-snapshot-1
Namespace:	wewang
Created:	37 seconds ago
Labels:		buildconfig=dice-v1.69.0-snapshot
Annotations:	openshift.io/build-config.name=dice-v1.69.0-snapshot

Status:		Running
Started:	Fri, 09 Oct 2020 14:45:49 CST
Duration:	running for 36s
  FetchInputs:	  1s

Build Config:	dice-v1.69.0-snapshot
Build Pod:	dice-v1.69.0-snapshot-1-build

Comment 15 errata-xmlrpc 2020-10-27 16:21:54 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.