Implement resources and data sources for GitLab Agent for Kubernetes API

[timofurrer]

This change set adds the following new resources / data sources:

• resource gitlab_project_cluster_agent
• data gitlab_project_cluster_agent
• data gitlab_project_cluster_agents

Corresponding to the new API here: https://docs.gitlab.com/ee/api/cluster_agents.html

This PR is currently blocked by:

• Implementation of Agents for Kubernetes APIs xanzy/go-gitlab#1461

@nagyv I had quite some discussions about the naming of that API over at GitLab. In the provider we usually name resources / data sources similar to the API path, thus /projects/:id/cluster_agents becomes gitlab_project_cluster_agent ... Is that okay with you, too? Or do you have any other preference for that particular resource name?

[RicePatrick]

Hey @timofurrer - I saw you requested a review after flagging this as blocked. Are you looking for a first round review?

[timofurrer]

@PatrickRice-KSC Yes, please. The code shouldn't be affected by the draft state ;)

[nagyv]

@timofurrer Good question. I don't have a very strong opinion, but a would prefer to call it gitlab_cluster_agent.

The project relationship is there really only to store the agent configurations and management views. The idea is to have agents that maintain a connection with a cluster, and this is independent of the concept of a project.

At the same time, to keep consistency, I don't mind the gitlab_project_cluster_agent resource name.

[RicePatrick]

I didn't make it though all the files yet, but I have a couple comments/questions so far 🙂

[RicePatrick]

One one (more general) comment, otherwise it's a bit difficult to confirm with all the compile issues, but it overall looks solid to me :)

[timofurrer]

@timofurrer Good question. I don't have a very strong opinion, but a would prefer to call it gitlab_cluster_agent.

The project relationship is there really only to store the agent configurations and management views. The idea is to have agents that maintain a connection with a cluster, and this is independent of the concept of a project.

At the same time, to keep consistency, I don't mind the gitlab_project_cluster_agent resource name.

@armsnyder you've put a 👍 there ... What was your preference, gitlab_cluster_agent or gitlab_project_cluster_agent ? Or both would be okay?

[armsnyder]

@timofurrer Good question. I don't have a very strong opinion, but a would prefer to call it gitlab_cluster_agent.
The project relationship is there really only to store the agent configurations and management views. The idea is to have agents that maintain a connection with a cluster, and this is independent of the concept of a project.
At the same time, to keep consistency, I don't mind the gitlab_project_cluster_agent resource name.

@armsnyder you've put a 👍 there ... What was your preference, gitlab_cluster_agent or gitlab_project_cluster_agent ? Or both would be okay?

Both are okay. 👍 If I had to choose I would go with gitlab_cluster_agent.

[timofurrer]

I've renamed the resources to gitlab_cluster_agent 👍

[timofurrer]

blocked by: #1095

[armsnyder]

lgtm!

[RicePatrick]

We're green across the board, I assume you're still waiting for 1095 though before you merge, is that the plan?

[github-actions]

This functionality has been released in v3.15.0 of the Terraform GitLab Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue. Thank you!