Skip to content

Conversation

gpalmz
Copy link
Collaborator

@gpalmz gpalmz commented Oct 8, 2025

Azure will allowlist this repository such that we will be able to use our ARM/BICEP templates and CreateUIDefinition assets. See incident-40771. Copied from here.

Subsequently we should update references to point to this new location, and finally remove the dead assets from the old location.

@gpalmz gpalmz requested a review from mattsp1290 October 8, 2025 14:35
@gpalmz gpalmz marked this pull request as ready for review October 8, 2025 14:36
@gpalmz gpalmz requested a review from a team as a code owner October 8, 2025 14:36
@gpalmz gpalmz requested a review from agulen October 8, 2025 14:36
@mattsp1290
Copy link
Member

This repo doesn't match the requirements of Terraform. The standalone forwarder will eventually be removed from the LFO repository. Unfortunately it will need to live somewhere else than here to be able to be a terraform module. TF has requirements on the repo name for modules so it doesn't work in the LFO one either.

@mattsp1290
Copy link
Member

Also what about the code that compiles bicep to ARM and publishes? Should that be moved?

@gpalmz
Copy link
Collaborator Author

gpalmz commented Oct 8, 2025

This repo doesn't match the requirements of Terraform. The standalone forwarder will eventually be removed from the LFO repository. Unfortunately it will need to live somewhere else than here to be able to be a terraform module. TF has requirements on the repo name for modules so it doesn't work in the LFO one either.

Hmmm okay... my plan was to put TF assets here so that they can be served to the frontend and templated based on user selections (see the "Terraform" tab here.) Any thoughts on how we could support both this and the creation of a module?

@gpalmz
Copy link
Collaborator Author

gpalmz commented Oct 8, 2025

Also what about the code that compiles bicep to ARM and publishes? Should that be moved?

Was unaware of this but probably. Do you have a link handy?

@mattsp1290
Copy link
Member

mattsp1290 commented Oct 8, 2025

This repo doesn't match the requirements of Terraform. The standalone forwarder will eventually be removed from the LFO repository. Unfortunately it will need to live somewhere else than here to be able to be a terraform module. TF has requirements on the repo name for modules so it doesn't work in the LFO one either.

Hmmm okay... my plan was to put TF assets here so that they can be served to the frontend and templated based on user selections (see the "Terraform" tab here.) Any thoughts on how we could support both this and the creation of a module?

We cannot. The repo needs named "terraform-TF PROVIDER-NAME". It would not be possible to share this repo among all integrations AND have terraform modules in here.

@mattsp1290
Copy link
Member

Also what about the code that compiles bicep to ARM and publishes? Should that be moved?

Was unaware of this but probably. Do you have a link handy?

Here's one of the jobs https://github.com/DataDog/azure-log-forwarding-orchestration/blob/main/.gitlab-ci.yml#L265-L276

@gpalmz
Copy link
Collaborator Author

gpalmz commented Oct 8, 2025

This repo doesn't match the requirements of Terraform. The standalone forwarder will eventually be removed from the LFO repository. Unfortunately it will need to live somewhere else than here to be able to be a terraform module. TF has requirements on the repo name for modules so it doesn't work in the LFO one either.

Hmmm okay... my plan was to put TF assets here so that they can be served to the frontend and templated based on user selections (see the "Terraform" tab here.) Any thoughts on how we could support both this and the creation of a module?

We cannot. The repo needs named "terraform-TF PROVIDER-NAME". It would not be possible to share this repo among all integrations AND have terraform modules in here.

I mean in general, not necessarily by sticking them in this repo. The solution may be to have the frontend point to separate terraform repos (as long as they're open sourced). Any issues you'd see with that?

@mattsp1290
Copy link
Member

This repo doesn't match the requirements of Terraform. The standalone forwarder will eventually be removed from the LFO repository. Unfortunately it will need to live somewhere else than here to be able to be a terraform module. TF has requirements on the repo name for modules so it doesn't work in the LFO one either.

Hmmm okay... my plan was to put TF assets here so that they can be served to the frontend and templated based on user selections (see the "Terraform" tab here.) Any thoughts on how we could support both this and the creation of a module?

We cannot. The repo needs named "terraform-TF PROVIDER-NAME". It would not be possible to share this repo among all integrations AND have terraform modules in here.

I mean in general, not necessarily by sticking them in this repo. The solution may be to have the frontend point to separate terraform repos (as long as they're open sourced). Any issues you'd see with that?

That should work. Part of requirements for publishing a TF module is open source.

@gpalmz gpalmz changed the title [AZINTS-3739] Move LFO templates (and TF) to integrations-management [AZINTS-3739] Move LFO templates to integrations-management Oct 8, 2025
@gpalmz
Copy link
Collaborator Author

gpalmz commented Oct 8, 2025

Also what about the code that compiles bicep to ARM and publishes? Should that be moved?

Was unaware of this but probably. Do you have a link handy?

Here's one of the jobs https://github.com/DataDog/azure-log-forwarding-orchestration/blob/main/.gitlab-ci.yml#L265-L276

Thanks. We haven't set up CI for this repo yet but it's ticketed. I could either add this note to said ticket or we could block on it. Any strong preference?

Also, do you have any pointers/links/info on how you set up CI in the LFO repo or in general?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants