One product with multiple keys in an app

Hi,

We have 1 APP in which there is one product. When we are deploying our proxies through Jenkins using Apigee Maven plugin, it creates another set of consumer key and secret for the same product in the same app. It means number of times you deploy it will create same number of keys for same product. How we can avoid this ? We don't want multiple keys for 1 product since any key will work.

Thanks

Solved Solved
0 12 746
1 ACCEPTED SOLUTION

Hi @nikhilchawla,

Its sort of a chicken-n-egg thing. If your using mvn command line then there's a number of options.

I have one command that does everything in one go, like when I want to deploy the proxy, create config items, export keys and test to a new org/env. That uses this command:

mvn -Ptest install -Ddeployment.suffix= \
    -Dapigee.config.options=update \
    -Dapigee.config.dir=target/resources/edge \
    -Dapigee.config.exportDir=target/test/integration \
    -Dapi.testtag=@health

Once, I've got the apps created, I use a different command to update both the proxy and config items (excluding apps and new proxy revisions). That command is:

mvn -Ptest install -Ddeployment.suffix= \
    -Dapigee.options=update \
    -Dapigee.config.options=update \
    -Dskip.apps=true \
    -Dapigee.config.dir=target/resources/edge \
    -Dapigee.config.exportDir=target/test/integration \
    -Dapi.testtag=@health 

Note the use of "-Dapigee.options=update" to overwrite the last revision instead of creating new ones.

So how do I skip "updating" Apps and generating new keys all the time? I added an option to control that phase using "-Dskip-apps=true".

<execution>
    <id>create-config-app</id>
    <phase>install</phase>                        
    <configuration>
        <skip>${skip.apps}</skip>
    </configuration>
    <goals>
        <goal>apps</goal>
    </goals>
</execution>

I use this approach to iterate quickly and to avoid exceeding limits.

Hope that helps

View solution in original post

12 REPLIES 12

I too have the same query.

@Kurt Googler Kanaskie

Any input will be appreciated.

Thanks

When we are deploying our proxies through Jenkins using Apigee Maven plugin, it creates another set of consumer key and secret for the same product in the same app.

This behavior results from your configuration of the maven plugin.

@Sai Saran Vaidyanathan will have a definitive answer, but here's my guess... from this example, it is possible to configure the maven plugin to create develoepr apps. If you don't want those developer apps, don't configure the develoepr apps section in the edge.json. Have you tried that?

If you have tried this, then please post your config for the maven plugin.

In any case you can delete the extra keys that have been created, using the UI or the Admin API.

Thanks @Dino for the response.

Removing developer apps from edge.json will definitely work. But here my use case is that if someone deploy the same release twice then you don't have an option to change edge.json.

Thanks.

I guess you could separate the config for the developer apps from the config for the proxies and other assets. If someone is "deploying twice", what things do you want to NOT deploy? Remove those from the maven plugin config. Put them in a separate step. (Reading this answer, it seems to amount to "if you don't like those results, don't do that." If I am oversimplifying your situation, I apologize.)

ok. Thanks for the suggestions 🙂

So i'm assuming currently there is no out of box way to restrict duplicate products in an app.

Thanks.

I think the "out of the box" way to get the apigee maven plugin to not create developer apps, is to NOT tell the apigee maven plugin to create developer apps.

Hi @nikhilchawla - This is a known behavior of the Management API, nothing to do with the plugin. You will see the same behavior if you call the Management APIs directly. Whenever you try to update the Dev App that has a Product, it creates a new set of client credentials. What you can do in your CI/CD pipeline is -

  1. Delete the developer app by running mvn apigee-config:apps -Dapigee.config.options=delete
  2. Execute your maven command that does everything from deploying the proxy to updating product to creating a new app. And for this new app, you will have only one client id/secret

I am facing the same issue. I am using management apis to create an app via Spring Boot. During update, its creating multiple Client key and Client Secret. Whats needs to be done for this bug? @Anil Sagar @ Google and @Dino Please provide your inputs on this.

PFA screenshot for the same.apigee-bug.png

Hi @nikhilchawla,

Its sort of a chicken-n-egg thing. If your using mvn command line then there's a number of options.

I have one command that does everything in one go, like when I want to deploy the proxy, create config items, export keys and test to a new org/env. That uses this command:

mvn -Ptest install -Ddeployment.suffix= \
    -Dapigee.config.options=update \
    -Dapigee.config.dir=target/resources/edge \
    -Dapigee.config.exportDir=target/test/integration \
    -Dapi.testtag=@health

Once, I've got the apps created, I use a different command to update both the proxy and config items (excluding apps and new proxy revisions). That command is:

mvn -Ptest install -Ddeployment.suffix= \
    -Dapigee.options=update \
    -Dapigee.config.options=update \
    -Dskip.apps=true \
    -Dapigee.config.dir=target/resources/edge \
    -Dapigee.config.exportDir=target/test/integration \
    -Dapi.testtag=@health 

Note the use of "-Dapigee.options=update" to overwrite the last revision instead of creating new ones.

So how do I skip "updating" Apps and generating new keys all the time? I added an option to control that phase using "-Dskip-apps=true".

<execution>
    <id>create-config-app</id>
    <phase>install</phase>                        
    <configuration>
        <skip>${skip.apps}</skip>
    </configuration>
    <goals>
        <goal>apps</goal>
    </goals>
</execution>

I use this approach to iterate quickly and to avoid exceeding limits.

Hope that helps

Thanks @Kurt Googler Kanaskie for the suggestion. We will try this option.


Yes - this works perfectly as long as you don't want to touch the Apps configuration