[BUG]Removal of subscription Folder from Artifacts Deletes All Subscriptions in APIM Instance

[sandhya-techie]

Release version

v6.0.1.1

Describe the bug

It has been observed that when the subscription folder is removed from the artifacts, it results in the deletion of all subscriptions present in the Azure API Management (APIM) instance. This is a critical issue because it leads to unintended loss of subscriptions and disrupts the management of API access.

Impact: Data Loss: Loss of all subscriptions in the APIM instance can lead to significant disruptions in service and access control. Configuration Management: Failure to override values from the .yaml file can result in inconsistent and unexpected behavior.

kindly provide the solution.

Expected behavior

Removing the subscription folder should not affect existing subscriptions in the APIM instance. Instead, the process should handle this folder appropriately without deleting existing data or should provide a warning about potential impacts.

Actual behavior

The removal of the subscription folder leads to the deletion of all existing subscriptions in the APIM instance. Additionally, the configuration values from the configuration..yaml file are not being overridden as expected.

Reproduction Steps

Remove the subscription folder from the artifacts directory. Deploy the artifacts to the APIM instance. Observe that all existing subscriptions in the APIM instance are deleted.

[github-actions[bot]]

  Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
  Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.

[waelkdouh]

Not sure what's the problem. If you delete the subscription folder and publish, all subscriptions in that folder should get deleted from your APIM instance. The publisher works by utilizing git commits and if it detects that the changes in the last commit include the deleting the subscriptions folder then it will go ahead and delete the subscriptions.

[sandhya-techie]

Thank you @waelkdouh for your input. You’re right that deleting the subscription folder in APIM will indeed result in the removal of those subscriptions, as the publisher depends on git commits to synchronize changes. However, this approach might not be suitable when dealing with different environments (e.g., dev, preprod, prod) where subscription values vary across environments.

Please guide me how to manage environment-specific values and prevent validation errors during deployment in publisher pipeline.

[waelkdouh]

I still don't understand your question. If you are referring to overriding values across environments you need to use namedvalues.

Not sure what you mean by preventing validation errors. Apiops utilizes the apim restful api. If there is a validation error that happens on the server side as a result of the apiops attempted put request then we surface this error through logging within your devops pipeline and fail the publisher. Just remember that the publisher doesn't execute in an atomic fashion. Meaning, if the publisher fails everything that has been applies already on the apim server side can't be rolled back. You would have to reexecute a full publish operation after you resolve the issue that cause the publisher to fail. Please make sue you read past closed issues, our wiki, as well as the repo assosicated github page.

[dagraham7]

I would also like to add that this is an issue for our environment as well. Our stage apim instance and prod apim instance have completely different subscriptions and keys.

I think it is due to the nature of subscriptions and how they are intended to be treated (at least from our perspective), it seems they are meant to be created by the potential audiences of your apis/products in a specific environment (mostly prod).

In our environment, we may have some subscriptions in stage, but for the majority of our apis/products, users would just subscribe to prod as they have no need to deal with the lower environments. This creates a gap between stage and prod that we cannot feasibly manage with overrides.

Is there a recommended way to manage subscriptions that would be API Ops friendly?

Maybe some kind of exclusion could be in the configuration where we can tell it that we don't care to see certain types be managed by api ops or at least published to prod?

[guythetechie]

@dagraham7 - I would suggest excluding subscriptions completely from ApiOps. In your configuration.extractor.yaml, set subscriptionNames: [ignore]. This will prevent subscriptions from being extracted when the extractor runs.

Note that if you already have subscriptions in your artifacts directory, you should probably delete them so they're no longer managed by ApiOps.

[dagraham7]

@guythetechie - thank you for the suggestion! Is this information in the wiki? I didn't see it when I was looking, but I could have easily overlooked as well.

And just for my understanding. When the extractor ignores it and it is no longer in the git repo, api ops will simply ignore subscriptions altogether? I don't have to worry about api ops removing them from my Dev (and of course prod) instance when the publisher runs a "full sync"?

[guythetechie]

@dagraham7 - that's correct. Another scenario where subscriptions get deleted is when ApiOps creates a brand-new product. Here is the flow:

• dev has productA, prod does not have productA.
• Operator runs extractor against dev. /artifacts/products/productA gets created in Git.
• Operator runs publisher against prod.
  • Publisher creates productA in prod.
  • APIM automatically creates a subscription and associates it with productA.
  • Publisher checks whether productA existed in prod before it ran.
    • If it existed, nothing happens
    • If it did not exist, publisher deletes the automatically created subscription. That subscription would not exist in source control, so ApiOps removes it to ensure Git and APIM are as much in sync as possible.

This scenario is a bit of an edge case, but mentioning it in case you see unexplained subscription deletions when publishing.

[dagraham7]

@guythetechie Thanks for the information! That is helpful and will give us something to lookout for when testing.