Fork for maintenance

[MaartendeKruijf]

@mleone87 @Tinyblargon

I hereby want to invite you to join the fork of the Telmate repo for both the provider and api. When we decide to move over I would propose to point this repo to the new fork.

What do you think?

Maarten

[JamborJan]

Hi @MaartendeKruijf , which fork are you referring to? I see a lot of activity from users here in the repo bot few answers or solutions from maintainers. I know that maintaining open source projects is a lot of work. So having more people being able to bring the provider forward. This would also involve a better policy in accepting and adding changes and fixes. I would be happy to support that too, no matter which repo.

[MaartendeKruijf]

@JamborJan as I understood from @mleone87 Telmate is no longer exists which makes that there are no (active) users with GitHub Maintainer level. I've prepared a fork but only want to go that way if the community agrees.

[JamborJan]

Thanks @MaartendeKruijf . If I can be of any help, please let me know. I'm relying on the proxmox provider and would be happy to invest time and resources to stabilize the situation end ensure reliable maintenance.

[MaartendeKruijf]

@JamborJan That also goes for me so far the effort to get things working is great but not very reliable. I created this https://github.com/Terraform-for-Proxmox organisation but better would be that some one at Telmate would give more access to now active users. Also a communication channel (slack/ discord/ matrix) would be nice for maintainers.

[hestiahacker]

I made comments about this on another ticket, as did TheGameProfi and Tinyblargon.

I'm trying to get the conversation about a new fork moved over here, and make sure people looking at this issue can see the relevant info. I'll continue my thoughts here.

• Comments from others have convinced me that forking is the best path forward. I'm on board.
• I agree the new repo should be owned by an organization instead of an individual
• I agree we should preserve the commit history
• +1 to contacting contributors to the proxmox-api-go repo as well. We'll need to fork that along with the provider repo
• I believe most people find this project from a search engine (DuckDuckGo, Bing, etc.) and so they'd find the fork on GitLab without any problem. Also, many users probably have no idea this repo is on GitHub, as they just update their terraform file from some blog post they say and it magically gets them the executable (via terraform's registry). Everyone who looks at the docs will be pointed to the issue tracker whether it lives on GitLab or GitHub. The only people who wouldn't be able to find it would be if someone went to GitHub and searched there. If anyone were to do that, they'd find 481 repos with the exact same name and likely get confused about which one is "the right one", so I maintain that people finding the project is independent of which site hosts it. This is why I consider discoverability to be the same for either platform.
• I'm extremely familiar with GitLab's CI/CD and not at all familiar with GitHub's CI/CD. Thus I'd be able to help with maintenance and adding features on GitLab (in addition to personally porting everything over), but not on GitHub. If someone in the opposite situation is willing to take on all the GitHub CI/CD maintenance, then it's neutral. If not, then it's a point in favor of GitLab.

[hestiahacker]

More comments from the other thread.

In order to try to move things forward, I propose the following (based on all the comments I've seen on the topic):

1. We have @mleone87 merge in the outstanding changes here to get us by for now
2. We create forks of this repo and the proxmox-api-go over at https://github.com/Terraform-for-Proxmox organization (and we should sure to preserve the git commit history in the process)
3. @MaartendeKruijf adds @Tinyblargon @mleone87 @hestiahacker & @JamborJan to the organization
4. We make a ticket on the proxmox-api-go repo to invite other contributors to our new fork

Then we create some issues that I think we can all agree on:

• Update all the Telmate references to be Terraform-for-Proxmox
• Do whatever is necessary to get into the official terraform registry (and put a pointer to the documentation in our README)

And some more tickets that may require some discussion:

• Add a statement that our repo will support all versions of Proxmox that are still supported by Proxmox Server Solutions
• Implement the SDN api proxmox is offering right now.
• Implement the proxmox firewall API (so your firewalls live outside of the VM and can't be changed even if the machine get rooted)
• Move the design of this repo to somewhat more structured like BPG

[JamborJan]

Thanks for all your brain power guys. That looks very promising and I'm happy to be on board with you guys.

[TheGameProfi]

Sound good so far.

For the part about git-commit-history, there are two options:

1. ignore them (not prefered)
2. detach the fork from the main repo, via Github Support (I also detached my Repo, and now its working with the history, and you can see the contribouters again.)

   ---

   For @MaartendeKruijf, I would definitly be able to create a basic discord server, if you want one.

   ---

   Getting the Provider to the Terraform Registry

   Easiest to do it via the Github Workflows/Actions. For me it was kinda triky, i needed to create a new Action, to activate the Add-On and then the old-one got activated. Then you also need to add a GPK-Key and its Password to the Repo Secrets

I could also try to hand over my Repo's to the company and mayby then everything will still be there and would work still

[Tinyblargon]

@hestiahacker @MaartendeKruijf

---

• Add a statement that our repo will support all versions of Proxmox that are still supported by Proxmox Server Solutions

If we are gonna support all versions we are gonna have to improve the black box integration tests of the proxmox-api-go library.

---

• Implement the SDN api proxmox is offering right now.

Before we start with this i would like to have a good discussion about the structure/schema we are gonna create. Preferably we never have to re-implement it.

---

• Implement the proxmox firewall API (so your firewalls live outside of the VM and can't be changed even if the machine get rooted)

This is my personal roadmap for upcoming features:

1. fix the qemu disks
2. add all cpu settings (like 70% done)
3. add firewall support at cluster, node and guest level
4. minor improvements for qemu-config
5. give the lxc-config some attention.

---

Regarding slack/ discord/ matrix. A platform that has voice chat and screen sharing would be preferred. Personally i see this as an addition in the the development process, being able to discuss and debug things together in real time. But I think we shouldn't encourage people creating issues there, issues and such belong on git.

---

Do keep in mind that proxmox-api-go needs some serious internal restructuring to improve readability, maintainability and test-ability. Recently we came to a consensus on a Style Guide as at the current rate proxmox-api-go is gonna be a 250.000+ lines when we support everything proxmox has to offer, and the tests to make sure it keeps working. As for the integration tests this is probably gonna be a semi- manual process due to the resources needed.

Also in proxmox-api-go way more is public than there should be. We should make a lot of thing private before others start using it.

[mleone87]

hello @all sorry for not answering before! I'm not sure to understand the issue about the project management, what we cannot do on the project right now except for myself being the only one that we can merge(I'm working on a solution right now, if possible)? This is a genuine question, I'm astonished by the brain power that get involved in the provider lately after some time

[clincha]

hello @ALL sorry for not answering before! I'm not sure to understand the issue about the project management, what we cannot do on the project right now except for myself being the only one that we can merge(I'm working on a solution right now, if possible)? This is a genuine question, I'm astonished by the brain power that get involved in the provider lately after some time

+1 to this question. Keeping the repository is "as is" is the least effort going forward, it's already in the Terraform registry and we all managed to find and use it. @mleone87 what is Telmate? Are they an organisation that is likely to support this project long term? Either way sounds like you're getting a couple more maintainers on board which sounds really positive. Is there any chance of getting Proxmox themselves involved to see if the repository can be moved over to them and supported by there developers?

I would be keen to help out both on the technical side (qemu disks has been driving me nuts!!) and getting communication open with Telmate/Proxmox. I thought I was just one of a few using this but it looks like there are loads of us (dozens!). Let me know if I can be helpful.

It would also be great to get a Slack/Discord going if there isn't one already

[TheGameProfi]

Because multiple people had talking about Slack/Discord..., and i personally prefere writing in a chat instead of a issue, i created for now a discord server. If it's really wanted: https://discord.com/invite/wbnqAHYKAT

[MaartendeKruijf]

@ALL I spoke with @TheGameProfi on Discord today, and we are agreeing that moving over to COSSAS https://github.com/COSSAS will be a good strategy for a fork. I would like to have your opinions : @mleone87 @JamborJan @Tinyblargon

Some background: COSSAS is a organisation sponsored by TNO (https://tno.nl/en) which could provide some structural continuation for this project.

Timeline wise I would suggest to prepare to fork this repo somewhere coming week(s) and create a PR on this one to let people know we are developing over there.

Hope to see your reactions and see you join the discord!

[mleone87]

@TheGameProfi link is expired, can you make a new one?

@MaartendeKruijf my question above is still valid, what's the real benefit of messing with forks and new organization? The project is not dead, creator is still alive, just moved to other things. I managed to have admin privilege on both repos so now this is all under full control. Anyone who wants to become a maintainer, after a sufficient number of contributions, will become one! I think is time to move on and start contributing to the project with code/tests/docs

[mleone87]

p.s. @Tinyblargon I invited you to become mantainer!

[TheGameProfi]

@mleone87 Sure here is a new link, hopefully this one will last longer, the other one should also been an unlimited one. https://discord.com/invite/FXG54hWzWg

[JamborJan]

@mleone87 when I get you right, then we have full control over the repo and we can also release new updates including the providers page / docs on terraforms registry. Right? So for example a intermediate release for 2.9.15 could be done. If this is possible I don't know if it is worth moving away. From my point of view we should try to keep the repo alive. With your suggestion, that people who are contributing can get maintainers, thats given for me.

My wishes:

• fix bugs more quickly
• work on new features (e.g. managing proxmox firewall)

I don't care about the repo I'm contributing to. It should be convenient for people to use it. And this is a vote for the current one in my eyes.

[mleone87]

@JamborJan this was already possible even before. What was missing was some working code :D

[gbrackley]

It would be great from my perspective if another release could be made with the existing code. I understand it won't be perfect - it might be that it could be marked pre-release. In the mean time I am having to use a compiled binary (from the source) which is just a PITA. @mleone87 Thanks for the work on this provider.

[Tinyblargon]

@mleone87 thanks for promoting me.

P.S. Noticed i had only subscribed to mentions and PRs.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. Please update the provider to the latest version and, in the issue persist, provide full configuration and debug logs

[github-actions[bot]]

This issue was closed because it has been inactive for 5 days since being marked as stale.