The future path for the Unifi provider

[evenh]

Hi all 👋🏻

I've tested this provider through the last few years and got it 80% working every time. As a irregular contributor to various open source projects myself I know that maintenance of and interest in these projects can vary when jobs, roles or life itself changes. With that in mind I reached out to @paultyng via email this summer and got a reply that drowned in my mailbox until I found it today (I'm really sorry). The reply was this:

I started the provider when I worked on providers at HashiCorp, I no longer do that, I'm not even in the DevOps space anymore and haven't been for the past 3 years or so. […]. I do use the provider occasionally on my home network, but I haven't had to change anything in some while, so its grown pretty stale as you see.

I'd be happy to have some one take it over, the issue for me is mostly that its under my name, and without a lot of vetting, its hard to bring folks in I don't really know, so I think a fork is possibly the best option, for the SDK as well. I'm happy to archive it and provide a pointer to a new fork assuming it has forward momentum but I don't really have the time to interview new maintainers on my repo.

I thought I'd share it with the community in case somebody wants to step up and maintain a fork. At least this is a starting point for a discussion. I found a few recent forks which may or may not be candidates going forward:

• https://github.com/ubiquiti-community/terraform-provider-unifi (@appkins)
• https://github.com/sayedh/terraform-provider-unifi (@sayedh)

Related issues:

• https://github.com/paultyng/go-unifi/issues/213
• https://github.com/paultyng/terraform-provider-unifi/pull/454

cc @joshuaspence

[joshuaspence]

Thanks for the write up. I have been meaning to get better at maintaining this project but have young kids at home, which has made it difficult.

I am happy to bring in additional maintainers to the project. With some additional maintainers I thought no it would help to renew my interest in the project

The last time I worked on this project I was trying to think about how to handle a change in the underlying API in which Unifi removed / significantly changed functionality in a minor version and I wasn't sure how to deal with that. I can't remember if that is still an issue

[elacy]

Only registered provider other than this one is https://registry.terraform.io/providers/akerl/unifi/latest not sure if @akerl is still maintaining theirs

[akerl]

I'm not not maintaining it 😄

When I forked, my original goal was to apply my patch for https://github.com/paultyng/terraform-provider-unifi/issues/389 , so that I could have a public statefile w/o leaking passphrases.

From there, I've been pulling in updates and patches (some of mine, some from other folks opening PRs on this repo) to keep it working as Unifi changes their services.

I maybe run the provider once every couple of months, when I add some new DHCP reservations to my network or decom some old services, so I'm not actively using it on a daily basis, but I do have interest in keeping it working.

[sayedh]

Hi everyone,

Thank you @evenh for sharing Paul's message and opening the discussion.

I've forked the original terraform-provider-unifi and created an updated version:

• Terraform Provider: sayedh/unifi
• GitHub Repository

This fork supports UniFi Controller v8.4.59. Currently, the following resources are fully tested and confirmed working:

• Resource: Network
• Resource: Port Profile

I'm actively working to expand the feature set and improve stability. For more information, please refer to the README and the Terraform documentation.

I should note that this provider is under active development and should be considered experimental at this stage. While some features are thoroughly tested, others are still a work in progress. Testing and feedback are highly appreciated.

I’d also like to acknowledge the efforts of those who have been working on forks of this provider, such as @appkins, @akerl and others. It would be fantastic if we could coordinate our efforts to create a unified, actively maintained version.

I've also forked and updated the go-unifi SDK to support UniFi Controller v8.4.59.

If Paul agrees, it would be great if the original repository could point to this fork as the actively maintained version for those looking for continued development and compatibility with newer UniFi versions.

Thanks again for sharing this and for everyone's interest in keeping this project moving forward. I'm looking forward to any contributions, feedback, or discussions from the community.

Best,
Sayed (@sayedh)

[joshuaspence]

Thanks @sayedh for your input. I am a co-maintainer of this project although haven't been able to spend any time of it lately for personal reasons. Having said that, I am experiencing a renewed interest for this project and would like to continue development. I would rather continue working on this project than point to a fork but, of course, this is open source and the community can choose to use this repository or any of the forks.

I will work to close off the open PRs this week

[DevOpsFu]

I noticed my PR is mentioned here. I'm happy to help with any clean up needed to get the changes merged in. As it happens I've been revisiting this stuff today because I need to automate some configuration on my USG.

[joshuaspence]

I am currently working through the PR backlog. One thing that would help us making sure your PRs have acceptance test coverage. There are a few flakey acceptance tests that I need to chase down but mostly the acceptance tests are in a good place.

The acceptance tests work by spinning up a demo install of Unifi Network. The demo install has a bunch of demo devices that can be used for testing devices, everything else can be created/modified as needed within the tests.

I'll try to close some of the PRs off without tests (or add the tests myself) but I'd like to maintain a high level of test coverage for this provider as there are a lot of edge cases in using an unofficial, undocumented API