Bug 1673155 - Inconsistency when ProjectRequestTemplate specified with and without namespace identifier
Summary: Inconsistency when ProjectRequestTemplate specified with and without namespac...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Master
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.1.0
Assignee: David Eads
QA Contact: zhou ying
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-06 19:24 UTC by brad.williams
Modified: 2019-06-04 10:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 10:42:31 UTC
Target Upstream Version:


Attachments (Terms of Use)
project-request template (4.87 KB, text/plain)
2019-02-06 19:24 UTC, brad.williams
no flags Details
projects.config.openshift.io CR (182 bytes, text/plain)
2019-02-06 19:26 UTC, brad.williams
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 None None None 2019-06-04 10:43:52 UTC

Description brad.williams 2019-02-06 19:24:33 UTC
Created attachment 1527671 [details]
project-request template

Description of problem:
We are trying to setup a 4.0 cluster with similar project quotas/limits/etc as our existing starter clusters.  We have created a "project-request" template in the openshift-config namespace.  When we apply the CR that references the template, we get different resources created based on whether the namespace is specified of not.

If we specify:
   name: "project-request"
then only the rolebindings are created.

If we specify:
   name: "openshift-config/project-request"
then all the resources (rolebindings, limits, quotas, networkpolicy, etc) are created, as expected.

If the ProjectRequestTemplate field requires a namespace, then if should be checked, verified, and fail accordingly (not silently). 


Version-Release number of selected component (if applicable):
oc v4.0.0-0.159.0
kubernetes v1.12.4+610027abd7
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://rhcos-west-1-api.rhcos.sandbox.openshift.com:6443
kubernetes v1.12.4+b367d26


How reproducible:
100%

Steps to Reproduce:
1. Create a new 4.0 cluster
2. Create a template in the "openshift-config" namespace that creates any combination of limits, quotas, rolebindings, networkpolicy, etc. 
3. Apply a projects.config.openshift.io CR that references the template, *without* specifying a namespace, in step #2
4. Wait for all apiservices pods to restart
5. Switch users to a non-admin user, and create a project
5a. Observe that only rolebindings have been created
6. Switch back to kubeadmin
7. Edit/delete-apply a new CR *with* the "openshift-config" namespace specified
8. Wait for all apiservices pods to restart
9. Switch users to a non-admin user, and create a different project
9a. Observe that all the template resources have been created

Actual results:
Varies based on whether or not a namespace value is specified inside the "name" field

Expected results:
If namespace is required, then if should verify and fail accordingly, and/or not fail silently when unable to create resources defined in a template

Additional info:

Comment 1 brad.williams 2019-02-06 19:26:30 UTC
Created attachment 1527672 [details]
projects.config.openshift.io CR

Comment 2 Michal Fojtik 2019-02-20 12:04:36 UTC
// TemplateReference references a template in a specific namespace.
// The namespace must be specified at the point of use.
type TemplateReference struct {
	// name is the metadata.name of the referenced project request template
	Name string `json:"name"`
}

See: https://github.com/openshift/cluster-openshift-apiserver-operator/blob/b23dac5f69383c0f70ac86089ef4df6c484f64b0/vendor/github.com/openshift/api/config/v1/types_project.go#L22-L21

Once we have `oc explain config.openshift.io` hopefully this will be more clear.

Also we don't want to check whether the template exists or not in the operator.

Comment 3 David Eads 2019-02-20 14:19:56 UTC
I think I see it.  There's a piece of wiring missing.  Good catch.

I think I've got it here https://github.com/openshift/cluster-openshift-apiserver-operator/pull/149

Comment 4 zhou ying 2019-03-08 05:50:42 UTC
Confirmed with OCP:

[root@dhcp-140-138 yamlfile]#  oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.0.0-0.nightly-2019-03-06-074438   True        False         27h     Cluster version is 4.0.0-0.nightly-2019-03-06-074438


The result is : 

When I create the CR with projectRequestTemplate=openshift-config/project-request , then the openshift-apiserver's configmap is  "projectRequestTemplate": "openshift-config/openshift-config/project-request", then the project template not works well;

When I create the CR with projectRequestTemplate=project-request, then the openshift-apiserver's configmap is  "projectRequestTemplate": "openshift-config/project-request", the project template works.

Comment 6 Michal Fojtik 2019-03-12 10:59:57 UTC
Hmm strange, the admission validation should return error when you set this field to `openshift-config/project-request` (as it should only allow the name).
Can you paste the exact CR you created with this?

Comment 8 zhou ying 2019-03-13 08:47:26 UTC
[root@preserve-yinzhourhel-1 home]# oc get projects.config.openshift.io cluster -o yaml 
apiVersion: config.openshift.io/v1
kind: Project
metadata:
  creationTimestamp: 2019-03-13T08:42:21Z
  generation: 1
  name: cluster
  resourceVersion: "116377"
  selfLink: /apis/config.openshift.io/v1/projects/cluster
  uid: ea93f1b7-456b-11e9-a203-02c79379c738
spec:
  projectRequestMessage: ""
  projectRequestTemplate:
    name: openshift-config/project-request


[root@preserve-yinzhourhel-1 home]# oc get cm config -n openshift-apiserver -o yaml 
apiVersion: v1
data:
  config.yaml: |
    {"aggregatorConfig":{"allowedNames":["kube-apiserver-proxy","system:kube-apiserver-proxy","system:openshift-aggregator"],"clientCA":"/var/run/configmaps/aggregator-client-ca/ca-bundle.crt","extraHeaderPrefixes":["X-Remote-Extra-"],"groupHeaders":["X-Remote-Group"],"usernameHeaders":["X-Remote-User"]},"apiVersion":"openshiftcontrolplane.config.openshift.io/v1","auditConfig":{"auditFilePath":"/var/log/openshift-apiserver/audit.log","enabled":true,"logFormat":"json","maximumFileSizeMegabytes":100,"maximumRetainedFiles":10,"policyConfiguration":{"apiVersion":"audit.k8s.io/v1beta1","kind":"Policy","omitStages":["RequestReceived"],"rules":[{"level":"None","resources":[{"group":"","resources":["events"]}]},{"level":"None","nonResourceURLs":["/api*","/version","/healthz"],"userGroups":["system:authenticated","system:unauthenticated"]},{"level":"Metadata","omitStages":["RequestReceived"]}]}},"imagePolicyConfig":{"internalRegistryHostname":"image-registry.openshift-image-registry.svc:5000"},"kind":"OpenShiftAPIServerConfig","projectConfig":{"projectRequestMessage":"","projectRequestTemplate":"openshift-config/openshift-config/project-request"},"routingConfig":{"subdomain":"apps.qe-yinzhou-upgrade.qe.devcluster.openshift.com"}}

Comment 9 Michal Fojtik 2019-03-14 12:22:34 UTC
Fix: https://github.com/openshift/origin/pull/22311

Comment 10 zhou ying 2019-03-18 08:25:43 UTC
Confirmed with latest OCP, the issue has fixed:
[zhouying@dhcp-140-138 ~]$ oc version --short 
Client Version: v4.0.22
Server Version: v1.12.4+befe71b
Payload: 4.0.0-0.nightly-2019-03-15-063749

When try to create the project.config with 
projectRequestTemplate:
    name: openshift-config/project-request
will failed with error: The Project "" is invalid: spec.projectRequestTemplate.name: Invalid value: "openshift-config/project-request": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

When create the project.config with     
projectRequestTemplate:
    name: project-request

Will succeed.

Comment 12 errata-xmlrpc 2019-06-04 10:42:31 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/RHBA-2019:0758


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