Bug 1280247

Summary: Pre-upgrade checks couldn't report invalid port name
Product: OpenShift Container Platform Reporter: Anping Li <anli>
Component: Cluster Version OperatorAssignee: Jason DeTiberus <jdetiber>
Status: CLOSED ERRATA QA Contact: Johnny Liu <jialiu>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.1.0CC: agoldste, anli, aos-bugs, bleanhar, jokerman, mmccomas, xtian
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 23:29:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Anping Li 2015-11-11 10:34:19 UTC
Description of problem:
pre-upgrade-check can't report the invalid port name. For example: "web-web-web-webs", "mysqlmysql-mysqls",  "w-e--b" , " "name": "w-e--b""


Version-Release number of selected component (if applicable):
https://github.com/openshift/openshift-ansible/blob/master/playbooks/adhoc/upgrades/files/pre-upgrade-check
openshift v3.0.2.0

How reproducible:
always

Steps to Reproduce:
1. create applications with invalid port name.

anli@openshift-120 ~]$ oc get service -o json |grep name
<--skip -->
   "name": "w-e--b",
  
<--skip -->
   "name": "m--ysql",


2. python pre-upgrade-check

Actual results:
[root@openshift-120 ~]# python pre-upgrade-check
Checking for oc ... found
[root@openshift-120 ~]#

Expected Results:

All invalid port name should be print.

Comment 1 Brenton Leanhardt 2015-11-11 14:01:33 UTC
Hi Anping!

In the case of services it's not the name that is being checked but instead the 'targetPort':

https://github.com/openshift/openshift-ansible/blob/master/playbooks/adhoc/upgrades/files/pre-upgrade-check#L170

I think this is simply a minor problem with the test case.  Would you mind testing again by setting a broken targetPort on a 3.0 install?

Comment 2 Anping Li 2015-11-11 15:01:55 UTC
Hi Brenton,  
Andy Goldstein said 'this is about port names, not pod names. 3.0 supported port names longer than 15 characters, and it also allowed consecutive hyphens. 3.1 restricts port names to a max of 15 characters and won't allow --. We need a pre-upgrade script that ensures that anyone with 3.0 deployed can identify possible DCs, RCs, pods, and services that have port names that become invalid in 3.1.'. target port only can be digits. I think it should be port name.

Comment 3 Andy Goldstein 2015-11-11 15:11:36 UTC
Hi Anping,

Brenton is correct. For services, the field that can potentially result in validation errors when upgrading from 3.0 to a newer version is targetPort. It can be either number or a string. See https://github.com/openshift/origin/blob/e0399d977ca537eb2532f0cbccf48d7c5ec8f71b/Godeps/_workspace/src/k8s.io/kubernetes/pkg/api/v1/types.go#L1616-L1623 for full details.

Could you please retest with values in service.spec.ports[i].targetPort? Thanks!

Comment 4 Anping Li 2015-11-12 14:10:59 UTC
Finally, I can create the test data. the issue finally turn out only exist in openshift v3.0.0.1. 

The scripts pre-upgrade-check works well. A short snapshot is as following. 

root@openshift-111 ~]# python pre-upgrade-check 
Checking for oc ... found
At least one port name does not validate. Valid port names:

    * must be less that 16 chars
    * have at least one letter
    * only a-z0-9-
    * do not start or end with -
    * Dashes may not be next to eachother ('--')

services/frontend -n test2 (Port="88888888888888888")
services/frontend -n test3 (Port="8")
services/database -n test4 (Port="#a")
services/frontend -n test4 (Port="a--a")
services/database -n test6 (Port="-a")
services/frontend -n test6 (Port="a1-")

Comment 6 errata-xmlrpc 2015-11-19 23:29:33 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, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2015:2492