Feature Request: API Management support #1177
Comments
|
I am looking for the same thing, is this in any plan? |
|
I've created a pull request for the API Management service #1516. Once this is working correctly we can add other API Management resources. |
|
I've started to look at the other relevant Edit: After using and learning API Management in Azure, it looks like all resources mentioned below are relevant for TF, and that deployment really don't come into play
I've listed possible
Note: The ones with
|
|
@torresdal this is something I'd be interested in picking up as well if you're looking for a partner in crime. |
|
I love this so much. I cannot wait to migrate my brittle |
|
For my use case I would require the base resources needed to manage products and APIs (rate limits, backends, rewrites, auth, ..). I assume that maps to the following resources from your list. Mandatory to implement functionality:
Lower Priority (ordered):
Edit: Imho there is currently no tooling available to handle any of those resources in another way; so for me it is hard to draw a objective line saying some things should be TF and others should not. One question that popped into my head is how TF should handle self-service subscriptions that will not be generated via TF if you have a |
|
Hi all! Quick status. Picking this up again after a rather long summer vacation :-) Currently the pull request (#1516) for the api management service is awaiting approval (expect this to go out very soon after great reviews and help by @tombuildsstuff @jeffreyCline), and I've started the work on api-management-api. @lfshr You mentioned you might be interested in contributing - that would be great! It will probably be easier to do so when both |
|
With regards to feature prioritization I totally agree with your assessment @anoff, and I think this is what we should aim for. Btw if anyone wants to contribute to any of these features, that would be very welcome. I've just started with the basic stuff, but too much work for me to do all these features on my own 😄 |
|
While working on the Allowing users to explicitly define all operations of an API is by all means doable, but will require some work. A very important factor will be to get the abstraction level right, to make it usable. Any input you have on this would be great. Thanks. |
|
Import from swagger would be lovely - so that I could just check in a swagger file with some .tf files and apply those rather than a giant pile of ARM template JSON |
|
@alastairtree Import is what I've implemented so far and will probably be what we support in the first release. The more I think about it, the more I think being able to add individual operations is not a good idea. If someone have good arguments for the opposite, please let me know. |
|
Yeah until terraform import can actually generates the HCL in .tf files for you you are probably right. But the ability to define your api mangagement config in HCL with references to swagger files for the api definition would be an nice feature I think. Any idea on an ETA on API management support in the azurerm terraform provider? |
|
@alastairtree as I see it was merged 7 days ago: MR #1516 Hopefully updates will follow :) |
|
I've implemented the CRUD for product on the side (separate provider), have decided to merge it back into the main provider and am looking to complete that and raise a pull request hopefully this week, if I can get enough time. For the project on which I'm currently working, the things that're candidates for TF provisioning are the APIMS, products, product policies, name value pairs and API version sets. These are the things we don't consider to be very volatile. We're often redeploying Swagger specs and versions during development so from this perspective I haven't considered API as a TF candidate. |
|
Just letting you know that I wont be contributing any more to this repository and the API Management resources, until I see major improvements in lead times. After months of coding resources for Azure API Management, only the first resource is merged (api_management). My second (api_management_api) has been in review for 2 months and nothing is happening and nobody is answering my questions - so I’ve now closed it (#2073). Hope other contributors gets a better experience contributing here, because I’m done wasting my time. |
|
Can someone from Hashicorp address why this PR couldn't be merged? And most importantly when those features might land in terraform? |
|
Also interested In that. @mcwienczek I guess that question should go to Hashicorp and not Microsoft, since this is a Hashicorp open source project. |
|
I would like to see api-management-settings-virtual-network. I'm using the apim in combination with AKS and I need to put the APIM into an existing vnet->subnet. Is this a different issue or does this belong to this feature request. |
|
so in the absence of this, we're looking at either embedding arm into terraform configuration, or just moving to aws? |
|
hey @torresdal So firstly I apologies that it's taken so long to reply to this. Spending some time thinking about this issue, based on the comments above I think this ultimately comes down to 3 questions:
So:
This is mostly unintentional, from our side we were busy with other things (personally that's some holiday, HashiConf and then the Requiring Imports changes) - and due to taking a quick skim over this PR I believed this was still waiting on changes to be made at your end. In either case unfortunately this is my fault for missing that you'd pushed changes here - so apologies about that. Whilst I appreciate that probably isn't helpful at this point - we're aware there are pain points in the current flow (and I'll cover more about and our plan to improve that below).
So I have good news on this front, we're going to be working on adding support for the following API Management Resources in the next few releases:
Whilst I don't have an exact timeline for each Resource, after spending some time trying to work out the dependencies between these resources - this is the (more or less) ordered list we're planning on supporting over the next few releases. In addition we also plan to enhance the
Whilst I appreciate this experience has been frustrating - we're aware there's issues that require fixing here and we're working to improve this going forward. One of the benefits of investing heavily in the Azure Provider over the last couple of years has been the marked increase in adoption, both in terms of folks using the provider but also in terms of issues and PR's. Whilst on the one hand we've done a fairly good job in terms of adding support for new resources - on the other hand we've not done so well in terms of bug fixes or community PR's - and we're intending on fixing that. Unfortunately for historical reasons our roadmaps pretty fixed until the end of April - but from that point we're intending on switching the ratios such that we can spend more time on Community PR's, Bug Fixes and Issues (as well as new resource development) - rather than being solely focused on new resource development. Taking a look at where we are today, we're trying to review PR's and get them merged within a day or two of them coming in, which tends to work for the smaller PR's. On the flip side some of the larger PR's can take longer and sometimes fall through the cracks - in particular where they require more thought (such as #1805) or have an upstream dependency blocking them (such as #2582). From our side @katbyte has spent some time adding linters to try and ensure the low-hanging comments are covered - and ensuring the codebase is a little more consistent insofar as when users look to existing resources, they're not using a pattern we're deprecating. In addition, we've been trying to ensure the PR reviews that we do are comprehensive - which whilst this may introduce a larger number of comments does reduce the amount of back and forth so that we can get things merged faster. Finally when reviewing PR's that are otherwise good to merge (for example we've not heard back from a user) we've been pushing the odd commit to the branch so that we can get these merged. Over the past few months we've been working to try and make what's being worked on more visible through the project's GitHub Milestones, both in terms of the work we're planning on doing and in terms of PR's we plan to review. This includes the use of the 'blocked' milestone where appropriate (e.g. where a PR is blocked on a broken API such as #2582) - where we've recently switched tact to temporarily closing PR's which are blocked on an upstream issue but leaving them assigned to the Thinking ahead slightly further, we're also looking to onboard additional maintainers for the Azure Provider - but I don't have a timeframe for this unfortunately. In the case of this particular Pull Request - apologies that this has slipped through the cracks, this was an error on my part. If you're still interested in contributing support for API Management API's we'd love to take another look and get this over the line - in either case I'd like to thank you for this contribution even though I appreciate it's been a frustrating experience. Thanks! |
|
Hi @tombuildsstuff, Great to hear that this part is getting some well deserved love. I'm still curious if the vnet part will be picked up as well. I've currently deployed the APIM with an ARM template to circumvent this problem but would love to see this back into this resource. Kind regards, |
|
@michaelmeelis support for API Management Virtual Networks is being implemented in #2582 - however it's blocked on an upstream issue, which is why that PR is temporarily closed |
|
@tombuildsstuff thanks for the quick response! I will look at that issue. |
|
Hey @tombuildsstuff, While testing the Azure API Management Service Provider I noticed a few things.
|
|
@NathanielRose would you mind opening a separate issue for those? Thanks! |
|
For the record, thanks for coming back with an explanation @tombuildsstuff! Looks like the activity on APIM has really picked up and things are moving. Good to see! |
|
This has been released in version 1.24.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example: provider "azurerm" {
version = "~> 1.24.0"
}
# ... other configuration ... |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks! |
ghost
locked and limited conversation to collaborators
I couldn't find anything on the documentation about API Gateways, policies, etc. for Azure API Management[0][1].
[0] https://docs.microsoft.com/en-us/azure/api-management/
[1] https://docs.microsoft.com/en-us/rest/api/apimanagement/
The text was updated successfully, but these errors were encountered: