Bug 1713982 - TemplateInstance object not taking into account values passed in through secret
Summary: TemplateInstance object not taking into account values passed in through secret
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Templates
Version: 3.11.0
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
: 3.11.z
Assignee: Gabe Montero
QA Contact: XiuJuan Wang
URL:
Whiteboard:
Depends On:
Blocks: 1718412 1719044
TreeView+ depends on / blocked
 
Reported: 2019-05-26 11:19 UTC by Joel Rosental R.
Modified: 2020-02-20 07:38 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The templateinstance controller switch to the dynamic client in 3.9 did not properly deal with cluster level objects in its create path, as it always tried to set a namespace/project on its create request. This was especially problematic when trying to create projects themselves. Consequence: The templateinstance controller started failing to create any projects specified in templates. Fix: The templatesinstance controller now determines if each object it is creating is cluster level in scope, and if its, it does not set the namespace on its dynamic client create request. Result: The templateinstance controller can now create projects, assuming it has that capability has been added to its permission set, defined in templates.
Clone Of:
: 1718412 1719044 (view as bug list)
Environment:
Last Closed: 2019-07-23 19:56:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:1753 0 None None None 2019-07-23 19:56:35 UTC

Description Joel Rosental R. 2019-05-26 11:19:09 UTC
Description of problem:
TemplateInstance object in OCP 3.11 is not taking values defined in secret passed in spec.secret.name and therefore the objects defined in the template are not getting instantiated

Version-Release number of selected component (if applicable):
OCP 3.11

How reproducible:
Always

Steps to Reproduce:
1. oc new-project mycloudpoc
2. Create service account:

  $ oc create sa mycloudadmin
  $ oc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:openshift-infra:template-instance-controller 
  $ oc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:openshift-infra:resourcequota-controller 
  $ oc create clusterrolebinding mycloudamdin --clusterrole cluster-admin --serviceaccount=mycloudpoc:mycloudadmin

3. Create template file: 

  $ oc create -f template.json

4. Create a secret "secrettest":

  curl -k \
    -X POST \
    -d @- \
    -H "Authorization: Bearer $TOKEN" \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' \
    https://openshift.xxx.redhat.com:443/api/v1/namespaces/mycloudpoc/secrets <<EOF

{
  "kind": "Secret",
  "apiVersion": "v1",
  "metadata": {
    "name": "secrettest"
  },
  "stringData": {
      [...]
      "MEM": "4Gi",
      "PROJECT_ADMIN_USER": "foo-admin",
      "PROJECT_NAME": "openshift-proj011",
      "REQUESTER": "foo",
      "RITM": "xyz",
      [...]
  }
}
EOF

5. Instantiate previous created template directly through an API call like this:

curl -k \
    -X POST \
    -d @- \
    -H "Authorization: Bearer $TOKEN" \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' \
    https://openshift.xxx.redhat.com:443/apis/template.openshift.io/v1/namespaces/mycloudpoc/templateinstances <<EOF
{
  "kind": "TemplateInstance",
  "apiVersion": "template.openshift.io/v1",
  "metadata": {
    "name": "secrettest"
  },
  "spec": {
    "secret": {
      "name": "secrettest"
    },
    "template": $(curl -k \
                    -H "Authorization: Bearer $TOKEN" \
                    -H 'Accept: application/json' \
                     https://openshift.xxx.redhat.com:443/apis/template.openshift.io/v1/namespaces/mycloudpoc/templates/odenprojcreation)
  }
}
EOF


Actual results:

Objects defined into the template are not created.

Expected results:

Objects should be created.

Additional info:
Same procedure with OCP 3.7 works without issue.

Comment 22 Gabe Montero 2019-06-10 21:30:56 UTC
PR https://github.com/openshift/origin/pull/23107 up for 3.11 release

Comment 23 Gabe Montero 2019-06-12 18:45:59 UTC
PR has merged

Comment 28 Gabe Montero 2019-06-24 13:34:18 UTC
XiuJuan - can you provide the precise steps you took in trying to verify the bug?

Would it be possible for me to get access to the cluster you are attempting to verify against?

Comment 39 XiuJuan Wang 2019-07-02 02:36:44 UTC
Verified this in cluster:
# oc version
oc v3.11.125
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://ip-172-18-1-156.ec2.internal:8443
openshift v3.11.125
kubernetes v1.11.0+d4cacc0

# oc get ns  openshift-proj011 -o yaml 
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/description: Openshift Project delivered via Hybrid Cloud
    openshift.io/display-name: openshift-proj011
    openshift.io/node-selector: slabasic=true
    openshift.io/sa.scc.mcs: s0:c17,c14
    openshift.io/sa.scc.supplemental-groups: 1000300000/10000
    openshift.io/sa.scc.uid-range: 1000300000/10000
  creationTimestamp: 2019-07-02T02:34:10Z
  labels:
    apmid: OS
    assignmentcode: VY02RJ
    crq: SRTest013
    deliverymanager: vishwa
    requester: tin2933
    ritm: openritm013
    serviceruntimemanager: vishwa
    sla: basic
    sz: VolvoCI
    technicalcontact: tin2933
    template.openshift.io/template-instance-owner: df2a2e3e-9c71-11e9-8353-0e01018c1f1c
  name: openshift-proj011
  resourceVersion: "8469"
  selfLink: /api/v1/namespaces/openshift-proj011
  uid: df3fafcf-9c71-11e9-8353-0e01018c1f1c
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Comment 41 errata-xmlrpc 2019-07-23 19:56:23 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:1753


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