Adressing proxy promotion issues

[Patryk-Stefanski]

What

Addressing issues raised in this comment

Verification

1. Deploy 3scale-operator locally

2.Create dummy smtp secret

kubectl apply -f - <<EOF
---
kind: Secret
apiVersion: v1
metadata: 
  name: s3-credentials
  namespace: 3scale-test
data: 
  AWS_ACCESS_KEY_ID: UkVQTEFDRV9NRQ==
  AWS_BUCKET: UkVQTEFDRV9NRQ==
  AWS_REGION: UkVQTEFDRV9NRQ==
  AWS_SECRET_ACCESS_KEY: UkVQTEFDRV9NRQ==
type: Opaque
EOF

3.Create apimanager resource

kubectl apply -f - <<EOF
---
apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata: 
  name: apimanager-sample
  namespace: 3scale-test
spec: 
  system: 
    fileStorage: 
      simpleStorageService: 
        configurationSecretRef: 
          name: s3-credentials
  wildcardDomain: <cluster_domain>
EOF

cluster domain example : apps.pstefans.uq32.s1.devshift.org

4. Create Backend resource

kubectl apply -f - <<EOF
---
apiVersion: capabilities.3scale.net/v1beta1
kind: Backend
metadata:
  name: backend1-cr
  namespace: 3scale-test
spec:
  mappingRules:
    - httpMethod: GET
      increment: 1
      last: true
      metricMethodRef: hits
      pattern: /
  name: backend1
  privateBaseURL: 'https://api.example.com'
  systemName: backend1
EOF

5. Create product resources with the backend referenced

kubectl apply -f - <<EOF
---
apiVersion: capabilities.3scale.net/v1beta1
kind: Product
metadata:
  name: product1-cr
  namespace: 3scale-test
spec:
  name: product1
  backendUsages:
    backend1:
      path: /
EOF

6. Create proxyconfigpromote resources to promote product to staging.

kubectl apply -f - <<EOF
---
apiVersion: capabilities.3scale.net/v1beta1
kind: ProxyConfigPromote
metadata:
  name: product1-v1-staging
  namespace: 3scale-test
spec:
  productCRName: product1-cr
 production: true
EOF

7. In 3scale UI check that product1 configuration was promoted to staging and that the CR now correctly reflects the staging and production versions.

[openshift-ci]

Hi @Patryk-Stefanski. Thanks for your PR.

I'm waiting for a 3scale member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[eguzki]

/ok-to-test

[eguzki]

Can you fix indenting issues like https://github.com/3scale/3scale-operator/pull/773/files#diff-b7a85d834496ef811bc135bcf19a9cb43d407ed592225b17396bc8bcaaeff8cbR17? Not a big deal, but things like this are very weird

| **Field**                  | **json field**       | **Type** | **Info**                                                                                                                                                   | **Required** |
|----------------------------|----------------------|----------|------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------|

[eguzki]

there is no provider account reference in the spec.

To be consistent with other CRDs, there should be one. Have a look at the product, backend CRDs types.

Regarding the doc you can just "copy&paste" the documentation here.

[Patryk-Stefanski]

good spot, added it in. Thanks.

[eguzki]

this "spaghetti code" is calling for a refactor :)

[eguzki]

not to be done in this PR, though

[eguzki]

verification steps have passed

[codeclimate]

Code Climate has analyzed commit d2aaa41 and detected 0 issues on this pull request.

View more on Code Climate.