devrel icon indicating copy to clipboard operation
devrel copied to clipboard

Update developer Keys error when they already exists

Open gabrieldiasabreu opened this issue 1 year ago • 2 comments

I noticed that in sackmesser deploy when we do incremental deploy of the configs folder. ApiProducts, developers, and developerApps that already exists gets updated, but, if the key already exists it throws an error and stop the whole deployment.

Is this an expected behavior or should it be similar to the other resources? if it's expected, Is there a feature to bypass these error and keep the deployment? Do you think it makes sense to add this feature?

My goal is to be able to do incremental migrations with the sackmesser deploy command from apigee edge to apigee X.

Example

 **************************
POST  https://url/v1/organizations/apigee-org/developers/developerEmail/apps/appname/keys/create
accept-encoding: [gzip]
authorization: [Bearer [Not shown in log]
x-goog-api-format-version: 2
content-type: application/json
 [Request body]
{"consumerKey":"Key","consumerSecret":"secret"}
Apigee call failed 409 Conflict
{
  "error": {
    "code": 409,
    "message": "ConsumerKey already exists",
    "status": "ABORTED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.PreconditionFailure",
        "violations": [
          {
            "type": "keymanagement.service.ConsumerKeyAlreadyExists",
            "subject": "[2002:a05:6148:86a1:b0:578:9331:5126]:4001:uycjd5-20020a0574147d0500b0004b11ec048b:9801:943860:291277",
            "description": "ConsumerKey already exists"
          }
        ]
      },
      {
        "@type": "type.googleapis.com/google.rpc.RequestInfo",
        "requestId": "7850316936529017734"
      }
    ]
  }
}

gabrieldiasabreu avatar Dec 05 '24 12:12 gabrieldiasabreu

I believe this is the default behaviour of the Apigee API, likely favouring a more graceful and protective approach as to not lose active keys.

Some sort of option on the command could work, but will required a rework of how the API(s) are invoked.

What would be your preferred behaviour? Always blindly replace the key with your new value or silently discard/ignore the key if it's the same value?

OmidTahouri avatar Dec 05 '24 13:12 OmidTahouri

In my opinion, and for my migration goals, it would be great if it could blindly replace with the new one. So, at the end we would have all the resources deployed.

gabrieldiasabreu avatar Dec 05 '24 14:12 gabrieldiasabreu