Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Terraforming Fleet Teams #18750

Merged
merged 3 commits into from
Jun 20, 2024

Conversation

yoderme
Copy link
Contributor

@yoderme yoderme commented May 3, 2024

This project adds support for terraforming teams in Fleet. If you have 100+ teams, managing them is is prone to error, mistakes, lost configuration, and general pain. An industry standard tool like terraform can unify this configuration as code.

In order to do this, I wrote a terraform provider that on one end talks to the Fleet api, and on the other end implements an interface for terraform. More information is in the README.

A small sample main.tf file is supplied.

This project adds support for terraforming teams in FleetDM. If you
have 100+ teams, managing them is is prone to error, mistakes, lost
configuration, and general pain. An industry standard tool like
terraform can unify this configuration as code.

In order to do this, I wrote a terraform provider that on one end
talks to the FleetDM api, and on the other end implements an interface
for terraform. More information is in the README.

A small sample `main.tf` file is supplied.
@yoderme yoderme requested a review from a team as a code owner May 3, 2024 21:57
@@ -0,0 +1,66 @@
module terraform-provider-fleetdm

Check warning

Code scanning / Trivy

golang: net/http, x/net/http2: unlimited number of CONTINUATION frames causes DoS Medium

Package: golang.org/x/net
Installed Version: 0.21.0
Vulnerability CVE-2023-45288
Severity: MEDIUM
Fixed Version: 0.23.0
Link: CVE-2023-45288
@lukeheath lukeheath requested a review from a team May 6, 2024 16:05
@ghernandez345
Copy link
Contributor

@yoderme thanks for the PR! I'll reach out to some of the devs to get some feedback for you.

@edwardsb
Copy link
Contributor

edwardsb commented May 8, 2024

@yoderme thanks for the the contribution, this is really awesome. I had some initial thoughts that I'd like to just lay out here for open discussion.

At first I was wonder why you might opt to redefine a client implementation(rather than pull in a dependency via go.mod) of teams because I think our client already has support for the required APIs (create, read, update, delete), but then I remembered a couple of issues I ran into doing something similar on another project which I will detail below.

Here is the project I was working on https://github.com/edwardsb/fleet-lambda-packager/blob/main/main.go#L60 and the client usage. There were a few hurdles getting to this point.

  1. we don't consistently tag the repository with go mod compliant version strings. Last compliant tag is v4.43.4 where the latest release is v4.49.3. This is fairly easy to remedy, but I thought I'd call it out.
    https://github.com/fleetdm/fleet/releases/tag/v4.43.4
    https://github.com/fleetdm/fleet/releases/tag/fleet-v4.49.3
  2. go get github.com/fleetdm/fleet/[email protected] doesn't even work (I think this is because the repository is too big and the module proxy refuses to cache it). The last version I could get working is the one in the project above, even after running go mod list -m github.com/fleetdm/fleet/[email protected]:
go get github.com/fleetdm/fleet/[email protected]
go: downloading github.com/fleetdm/fleet/v4 v4.43.4
go: github.com/fleetdm/fleet/[email protected]: verifying module: github.com/fleetdm/fleet/[email protected]: reading https://sum.golang.org/lookup/github.com/fleetdm/fleet/[email protected]: 404 Not Found
        server response: not found: 

So after painfully remembering all of this I now better understand why it might have been easier just to re-implement the small API required for teams, but it does give us something to think about. We might want to consider properly pulling the service/client into its own module so it can be properly published and depended on (for cases just like this). However I don't think that should be a blocker for this PR.

The other thing I'd like to bring up was that we were considering pulling the terraform modules into its own repository for a variety of reasons #18191. Which makes me wonder if we should also consider having custom providers live there too? This sounds like another solid +1 for proper go.mod support.

Anyways, this was a long-winded way of saying LGTM!

@yoderme
Copy link
Contributor Author

yoderme commented May 9, 2024

why you might opt to redefine a client implementation

@edwardsb - The embarrassing answer is that I didn't realize it existed. I saw the API and went from there.

I guess I accidentally avoided the issue you ran into.

I'm actually a big fan of monorepos, IMHO having multiple repositories wandering around leads to fragmentation, chaos, and means that you may have to re-implement repo-wide policies/tooling. But anyway, I would note that there is "terraform for creating a fleetdm server", and there is "terraform of config in that server" and they are entirely different things.

Lastly - what's up with all the failing PR checks, and is there anything I can do to address them?

@edwardsb
Copy link
Contributor

edwardsb commented May 9, 2024

@yoderme

I guess I accidentally avoided the issue you ran into.

Ha! Well that works too! I'd like to use the existing client but we aren't in a position to do so, which is why I think the small re-implementation shouldn't be a blocker.

I'm actually a big fan of monorepos, IMHO having multiple repositories wandering around leads to fragmentation, chaos, and means that you may have to re-implement repo-wide policies/tooling. But anyway, I would note that there is "terraform for creating a fleetdm server", and there is "terraform of config in that server" and they are entirely different things.

Generally I am too, but in our case terraform doesn't handle monorepos very well (most of the details are outlined in the issue I linked) but each module we define ends up separately cloning the fleet repo, which turns into dozens of GBs of code in .terraform.

Lastly - what's up with all the failing PR checks, and is there anything I can do to address them?

I think most are due to the fact that the PR is coming from a fork and your fork doesn't have permissions and secrets that are required.

@yoderme
Copy link
Contributor Author

yoderme commented May 10, 2024

@edwardsb Thanks for all the comments - so what are my next steps here? Thanks a bunch.

@edwardsb
Copy link
Contributor

@edwardsb Thanks for all the comments - so what are my next steps here? Thanks a bunch.

Someone from the approved code owners needs to approve. @lukeheath @rfairburn when y'all have a chance to check this out and review the discussion so far.

rfairburn
rfairburn previously approved these changes May 11, 2024
@lukeheath
Copy link
Member

@yoderme Thank you for your contribution! We are currently in a merge freeze as we prepare for Fleet v4.50.0, but we'll finish reviewing your PR and merge after the freeze is lifted later this week.

@yoderme
Copy link
Contributor Author

yoderme commented Jun 11, 2024

@lukeheath Any news on when this might land?

@nonpunctual nonpunctual added ~csa Issue was created by or deemed important by the Customer Solutions Architect. ~feature fest Will be reviewed at next Feature Fest customer-rocher labels Jun 11, 2024
@lukeheath
Copy link
Member

@yoderme Apologies for the delay and thank you for following up. We are now out of merge freeze and I will ask for a review from the Go group.

edwardsb
edwardsb previously approved these changes Jun 11, 2024
Copy link
Member

@mna mna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Most of my comments refer to the fleet client helper as I'm not familiar with the implementation of a terraform provider (and the provider's code otherwise looked good to me).

tools/terraform/fleetdm_client/fleetdm_client.go Outdated Show resolved Hide resolved
tools/terraform/fleetdm_client/fleetdm_client.go Outdated Show resolved Hide resolved
tools/terraform/fleetdm_client/fleetdm_client.go Outdated Show resolved Hide resolved
tools/terraform/fleetdm_client/fleetdm_client.go Outdated Show resolved Hide resolved
tools/terraform/fleetdm_client/fleetdm_client.go Outdated Show resolved Hide resolved
tools/terraform/fleetdm_client/fleetdm_client_test.go Outdated Show resolved Hide resolved
@@ -0,0 +1,66 @@
module terraform-provider-fleetdm
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if we should use a more typical github.com/fleetdm/fleet/... module path here? Not totally sure what the implications are, but I found it weird when I saw the unfamiliar import syntax for that package. Might be totally ok, just raising in case others have more info on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to change it if you like

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine, we can always change it later if we see it causes issues.

tools/terraform/provider/provider.go Show resolved Hide resolved
tools/terraform/provider/provider_test.go Show resolved Hide resolved
tools/terraform/provider/teams_resource.go Outdated Show resolved Hide resolved
@yoderme
Copy link
Contributor Author

yoderme commented Jun 13, 2024

@mna - thanks for the great comments; addressed basically all your feedback.

Copy link
Member

@mna mna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! The Go code looks good to me!

@@ -0,0 +1,66 @@
module terraform-provider-fleetdm
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine, we can always change it later if we see it causes issues.

@noahtalerman noahtalerman changed the title Support for Terraforming FleetDM Teams Support for Terraforming Fleet Teams Jun 20, 2024
@noahtalerman
Copy link
Member

noahtalerman commented Jun 20, 2024

Hey @lukeheath do you think we need to bring a story for this through feature fest? Maybe not?

(pulling the ~feature fest label off of this PR)

It's not a change to the product but increases surface area we commit to maintaining (another way to manage Fleet as code along side Fleet's best practice GitOps)

I think up to you.

@noahtalerman noahtalerman removed the ~feature fest Will be reviewed at next Feature Fest label Jun 20, 2024
@noahtalerman
Copy link
Member

FYI @nonpunctual ^

@nonpunctual
Copy link
Contributor

nonpunctual commented Jun 20, 2024

I guess since it's community-sourced maybe our ongoing effort to keep it up-to-date is not as high as a product designed & built by Fleet? It's a good point @noahtalerman & it kind of means making a decision about how to maintain external contributions.

@lukeheath
Copy link
Member

Our recommended best practice for managing teams at scale is Fleet with GitOps. However, GitOps may not work for everyone, so this is a valuable alternative that allows Terraform users not using GitOps to manage teams programatically.

@yoderme Thank you for your contribution!

@lukeheath lukeheath merged commit c7ea012 into fleetdm:main Jun 20, 2024
11 of 16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
~csa Issue was created by or deemed important by the Customer Solutions Architect. customer-rocher
Development

Successfully merging this pull request may close these issues.

8 participants