GMU: deploy service including folder path

[Michael Mueller]

Hello.
I am trying to deploy a service with the help of GMU.
The service itself resides in a subfolder tree which does not exist in the target gateway.
Example: Service Name "folderA/folderB/folderC/Service"
If I migrateOut  this service to a singlefile, the bundle contains "only" the service and its dependencies, but not the folders.
hence the migrateIn fails, as all the folders do not exist.

What is the best approach to deploy such a service including the full folder path?

Sorry if this has been asked before. 

Thanks and regards
...Michael

[Francois Lascelles]

Hello Michael,

If you migrateOut with the option --folderName your_folder, The folder object will be included in your bundle but everything else in that folder is also pulled out. There might be a better way to handle this with GMU, and I will let more experienced GMU subject matter experts weigh in on this part of it.

However, I do want to point out the next-generation config management API named graphman which is designed to avoid many usability issues with restman + GMU. For example, in graphman, folder objects are just transparently handled. In graphman, folder is a property of services and policies and when you write one of those objects, the folder object will be created as needed on the receiving end. This is one of many ways graphman aims to facilitate your config management experience and please drop me a note at [e-mail] if you want to be invited to the experimental version of it which works with gateway versions 10.0 and 10.1. In there you will find the assertion as well as the client-side tooling including a rich postman collection as well as cli commands and samples.

[Michael Mueller]

Thanks Francois.
graphman sounds very interesting and might help not only in this case, well, but not now, if you know what I mean;)
migrateOut the folders itself is of course no option, as it would contain everything in that folder as well, as you already mentioned.

I was wondering that the folders of the folder-path are not part of the bundle as dependencies, as they are referenced to each other, similar to all other chained dependencies, in my understanding.

One idea I had to achieve what I am looking for is:

• As part of the exported bundle, the resource (service) is referencing the folder in its folderId property 
• loop through folders, starting with the folderId, until upmost root folder is reached
  • export folder folderId resource by GMU restman GET
  • check, if folderId exists by GMU restman GET in target gateway
  • update(PUT) or insert(POST) folder resource to target gateway
  • use folderId property of current folder as next folderId

This kind of procedure could easily be implemented in a script.
Maybe someone can let me know if this approach is suitable.
Or tell me a different, maybe even simpler one.

Thanks
...Michael

[Barry Stern]

Michael,

Unfortunately this is a common issue with using GMU with partial migrations. 

What you would do is create an export bundle that will only create folders that do not exist on your target gateway.

Export everything under /folder1 and set defaultAction to ignore to create a bundle file

 ./GatewayMigrationUtility.sh migrateOut -z argfiles/source.args --folderName /folder1 --d output/folder1.bundle --defaultAction Ignore

Then run manageMappings on the bundle to set action to NewOrExisting for all FOLDER entities in the bundle file

./GatewayMigrationUtility.sh manageMappings -b output/folder1.bundle --type FOLDER  --action NewOrExisting

you could also selectively specify folder by name to set action if you only wanted to selectively import a specific folder

./GatewayMigrationUtility.sh manageMappings -b output/folder1.bundle --type FOLDER --srcName "folder1" --action NewOrExisting 

This gives you effectively a bundle file that you cna run with migrateIn on your target gateway that will create any missing folders under the root path of /folder1 but will not import anything else. 

Now that all the folders exist under root of /folder1  you can run partial migrations of any services under that path without having the missing folder issue. 

[Michael Mueller]

Hi Barry.
Yes, of course. Thanks for this bright idea.
Have a great weekend.
...Michael

[Vince Baker]

Hi Michael,

I had exactly the same issue about 4 years ago when I worked for William Hill and TEMPORARILY/dirtily fixed it by creating 2 bundles. The first one contained just the folders which I applied first, then after migrated the services etc. However, this wasn't an enterprise solution so I started using the APIIDA API Gateway Manager which solved all our issues. I now work for APIIDA and using my hands-on customer experiences have helped with the Gateway Manager's development.

As well as faultless migrations via the UI it now brings the following features to the L7 table (among many others). It really brings the L7 suite up to the latest industry automation standards.

• Version control of APIs via GIT (Make SoT your GIT repos and edit policies as code)
• CI/CI control of the migration tool via it's REST API (in conjunction with GIT full APIOps can be easily acheived)
• Service creation directly to GWs via Templates (no L7 policy dev knowledge needed to create standardized APIs)
• Prometheus based metrics (point to your company's Prometheus for fully integrated monitoring and alerting)
• Dependency viewer (parents and children of an entity for dev and troubleshooting ease)
• Dry Run migrations to test before migration (100% confidence in any planned migration)

I'll be happy to give you (or anyone) a demo environment to "play" on.

Just book my time and/or grab a trial here. https://apiida.com/product/apiida-api-gateway-manager/

Regards

Vince Baker

------------------------------
Principal Architect
Apiida AG
https://www.apiida.com
------------------------------

[Michael Mueller]

Hi Vince.
Thanks for coming back to me on this.
As you might know, I am quite aware of "your" Gateway Manager and think it offers a very interesting approach.
Let's see ;)
Kind regards
...Michael

[Adrien French]

Hi.  I had success doing it this way. This worked for 2 folders deep: Services/xyz/xyz1:

GatewayMigrationUtility.sh migrateOut -h devnode --trustHostname --argFile commonargs.properties --dest xyz-folder.xml --folderName 'Services/xyz/xyz1'
GatewayMigrationUtility.sh manageMappings --type FOLDER --bundle xyz-folder.xml --outputFile xyz-folder.xml-mappings.xml --action NewOrExisting --targetPath
GatewayMigrationUtility.sh manageMappings --type SERVICE --bundle xyz-folder.xml --outputFile xyz-folder.xml-mappings.xml --action NewOrExisting --targetPath
GatewayMigrationUtility.sh migrateIn -h testnode --trustHostname --argFile commonargs.properties --bundle xyz-folder.xml --map xyz-folder.xml-mappings.xml --results results.xml --destFolder 'Services/xyz'

As I recall it, the key point was to run manageMappings --type FOLDER then run manageMappings --type SERVICE.
Note that when migrateIn you don't put the final destination folder for --destFolder.

Adrien.

[Michael Mueller]

Hi Adrien.
Thanks a million for letting "us" know your experience in this.
I will definitively have a look at your steps in more detail and let you know my findings.
Best regards
...Michael