[AZINTS-3739] Move LFO templates to integrations-management

[gpalmz]

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.

[mattsp1290]

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]

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

[gpalmz]

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]

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]

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]

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]

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]

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]

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?

[mattsp1290]

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?

A ticket would be fine. The compilation and publishing probably isn't a requirement til closer to open sourcing

This guide was essential for vault
https://datadoghq.atlassian.net/wiki/spaces/SECENG/pages/3826647944/Secure+Storage+and+Handling+of+Secrets

CI recommendations
https://datadoghq.atlassian.net/wiki/spaces/SECENG/pages/3034155880/Guide+How+to+Secure+Your+GitHub+Repositories#Secure-GitHub-Actions/Workflows