Should clearing old revisions be part of your regular maintenance tasks?

Not applicable

We run a multi tenant Edge installation that services a large number of development environments. New proxy revisions are pushed from the build pipeline straight into Edge, and over time there are a lot of revisions.

I have seen plenty of posts with people asking how to do mass deletions of old revisions, but nothing that says whether you should be doing this or not. I've checked the recurring maintenance tasks page at https://docs.apigee.com/private-cloud/latest/recurring-edge-services-maintenance-tasks and nothing is suggested here.

Will 50 odd proxies all with 30 odd revisions cause some issues eventually for an Edge installation? It takes us a number of hours (yes, really!) to restart an MP in our development environments and we believe this to be down to the sheer number of revisions on there - we have 50+ proxies, with 30 odd revisions each, duplicated over 50 organisations. Maybe this is the problem rather than the revisions.

Much appreciated!

Michael

Solved Solved
2 1 376
1 ACCEPTED SOLUTION

Yes, it's a good idea. Especially if you're restarting MPs regularly. You observed that it takes a long time to restart an MP, and the number of environments and proxies and revisions has an effect on that.

I don't know why the standard guidance does not suggest removing old revisions.

My view is that the system of record ought to be your source code control system. So you don't need 45 revisions of a proxy in Apigee Edge. Maybe 3 in case you want to revert a change with the UI or API. But not 45. You're never gonna use those old revisions.

As for how to remove old revisions of proxies, I haven't seen a ton of questions on that topic.

But there is this tool built on nodejs that accomplishes just that via the Administrative API. cleanOldRevisions.js

Usage:
  node cleanOldRevisions.js [OPTION]
Options:
  -M, --mgmtserver=ARG the base path, including optional port, of the Edge mgmt server. Defaults to https://api.enterprise.apigee.com .
  -u, --username=ARG   org user with permissions to read Edge configuration.
  -p, --password=ARG   password for the org user.
  -n, --netrc          retrieve the username + password from the .netrc file. In lieu of -u/-p
  -o, --org=ARG        the Edge organization.
  -v, --verbose
  -h, --help
  -R, --regexp=ARG     Optional. Limit the culling to proxies with names matching this regexp.
  -K, --numToKeep=ARG  Required. Max number of revisions of each proxy to retain.

I suppose it would not be difficult to write something similar for Powershell or Go, or whatever automation language you prefer.

View solution in original post

1 REPLY 1

Yes, it's a good idea. Especially if you're restarting MPs regularly. You observed that it takes a long time to restart an MP, and the number of environments and proxies and revisions has an effect on that.

I don't know why the standard guidance does not suggest removing old revisions.

My view is that the system of record ought to be your source code control system. So you don't need 45 revisions of a proxy in Apigee Edge. Maybe 3 in case you want to revert a change with the UI or API. But not 45. You're never gonna use those old revisions.

As for how to remove old revisions of proxies, I haven't seen a ton of questions on that topic.

But there is this tool built on nodejs that accomplishes just that via the Administrative API. cleanOldRevisions.js

Usage:
  node cleanOldRevisions.js [OPTION]
Options:
  -M, --mgmtserver=ARG the base path, including optional port, of the Edge mgmt server. Defaults to https://api.enterprise.apigee.com .
  -u, --username=ARG   org user with permissions to read Edge configuration.
  -p, --password=ARG   password for the org user.
  -n, --netrc          retrieve the username + password from the .netrc file. In lieu of -u/-p
  -o, --org=ARG        the Edge organization.
  -v, --verbose
  -h, --help
  -R, --regexp=ARG     Optional. Limit the culling to proxies with names matching this regexp.
  -K, --numToKeep=ARG  Required. Max number of revisions of each proxy to retain.

I suppose it would not be difficult to write something similar for Powershell or Go, or whatever automation language you prefer.