What happens if I want to migrate to the Operator pattern, but not recreate all my Tyk objects in CRD as to not disrupt my current users. What if I want to re-use my organization, api_id etc ?
For example, I have a Tyk install running. I have users using my APIs in production. I don't want to recreate my existing APIs in CRs so as to not disrupt my existing keys. But I want to create a new policy via the CRD. In this case, we would need a way to specify in the CR to tell the Operator which API or Policy or Webhook or Organization we are referencing.
Perhaps an annotation or a bool flag to say, "this API already exists, here's the BSON ID". here's an example of a securitypolicy CR referencing an existing API:
apiVersion: tyk.tyk.io/v1alpha1
kind: SecurityPolicy
metadata:
name: httpbin
spec:
name: Some other Security Policy
state: active
active: true
access_rights_array:
- provide_mongo_id: true
bson_id: <api_id>
What happens if I want to migrate to the Operator pattern, but not recreate all my Tyk objects in CRD as to not disrupt my current users. What if I want to re-use my organization, api_id etc ?
For example, I have a Tyk install running. I have users using my APIs in production. I don't want to recreate my existing APIs in CRs so as to not disrupt my existing keys. But I want to create a new policy via the CRD. In this case, we would need a way to specify in the CR to tell the Operator which API or Policy or Webhook or Organization we are referencing.
Perhaps an annotation or a bool flag to say, "this API already exists, here's the BSON ID". here's an example of a securitypolicy CR referencing an existing API: