WIP THREESCALE-7135 create a CR for product promotion

[austincunningham]

What

Create a promoteProduct CRD that allows for product promotion to staging or production

apiVersion: capabilities.3scale.net/v1beta1
kind: PromoteProduct
metadata:
  name: example
  namespace: 3scale-test
spec:
  productId: '3'
  promote: false
  promoteEnvironment: production
  promoteVersion: '5'
  providerAccountRef:
    name: provideraccountref
status:
  productId: '3'
  latestPromoteEnvironment: production
  latestPromoteVersion: 5

Verification

• Deploy this branch

make
make install 
make download
make run

• Create a product and add a backend to it in the UI
• Create a providerAccountRef secret

Promote to staging

• Create a productPromote cr with following spec to promote to staging

spec:
  productId: '3'
  promote: true
  promoteEnvironment: staging
  providerAccountRef:
    name: provideraccountref

• After it has reconciled check the ui to see that the product has been promoted to staging

NOTE: the spec.promote will be removed after a successful promotion

Promote to production

• promote to production by editing the spec of the existing CR

spec:
  productId: '3'
  promote: true # this will need to be added in every time you need to promote
  promoteEnvironment: production
  promoteVersion: '1' # configuration version needs to be added for promoting to production
  providerAccountRef:
    name: provideraccountref

• After it has reconciled check the ui to see that the product has been promoted to production

NOTE: the spec.promote will be removed after a successful promotion

[openshift-ci]

Hi @austincunningham. 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.

[austincunningham]

@eguzki Can you give this a review, we would love some feed back on weather this is the right approach for product promotion

@philbrookes I understand you are also interested in reviewing this

[codeclimate]

Code Climate has analyzed commit 357aed6 and detected 5 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Complexity	3
Style	2

View more on Code Climate.

[openshift-ci]

@austincunningham: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/test codeclimate

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]

owesome! Before going into code details, one obvious question, why differentiated CRD instead of integrating in the Product CRD? Although the promotion could work without requiring a Product CR, seems more consistent if the operator only provides promotion feature if the user is working with Product CR's. That `productId' field in the spec ringed the bell.

It is important to differentiate between:

• promotion action from staging to production environment
• deploy action promotes the APIcast configuration to the Staging Environment

They are two different 3scale API endpoints, the promotion requiring a version while the deployment does not. In my mind, there would be an optional struct field in the Product CRD spec:

spec:
  promote:
     promoteVersion: '1'

If the spec.promote field exists, it mean the customer wants the apicast configuration being deployed to staging and production version would be the one specified in the spec.

From the configuration history, the 3scale API endpoint allows setting any version at the production environment. But I have not managed to set staging version to an arbitrary version from the configuration history. I will ask system team whether this is feasible or not.

I suggest we jump to a call and discuss this a agree one approach.

Anyway, the work is super and most of the logic has been implemented so far.

[austincunningham]

@eguzki it was believed before we started the work on this pr that Promotion was a one off event, and therefore a separate CRD made sense at that time. But after interacting with product promotion I can see no reason why it couldn't live in the Product CRD. An agreed way forward would be best, I will stick something in the calendar

[austincunningham]

closing this as the implementation discussed will be substantially different to this pr