A few questions to clarify some weird findings

[boanbagon33]

I must admit, as I am quite "green" to Terraform and new to this distro which I did not try yet to deploy. I am trying first to make sense of the code and documentation. And unfortunately so far not being able to relate the documentation with what I see in the code. Maybe missing something, but I did some reverse engineering of the code and it's quite weird what I gather

[TL;DR]

First of all there seem to be a major discrepancy between 3-networks-dual-svpc and 3-networks-hub-and spoke, in terms of design and implementation. For instance

1. In 3-networks-hub-and spoke under envs, each module's main.tf is invoking a vpc_config module, under modules/nhas_config. This vpc_config module seems to get some network-related configuration from a vpc_config.yaml file, which seems to provide the address ranges for each VPC and subnet and much more.
2. However there seem to be no such configuration being used in 3-networks-dual-svpc where everything seems hardcoded.

Weird fact 1 : why the 2 modules, being both about network topology, seem to be using different approaches to parameterize network provisioning? And there is nothing whatsoever in the documentation explaining what this vpc_config.yaml contains and how to use it.

Weird fact 2: it was mentioned in one of the threads that Azure Devops can be used as a deployment alternative, considering the sunset of Cloud Source. Looking at the pipeline and the automation_scripts, can't see how this would deploy 3-networks-dual-svpc

Weird fact 3: while looking at the code stumbled over a number of terraform modules with a "Copyleft none" header, in contrast with "Copyright 2022 Google LLC" found in other modules. So the question arises - what kind of licensing is applicable to this distribution?

As the documentation is visibly out of sync with the code, does the Apache License (2004) apply to this code?

Looked as well at the 4-Projects module and beside business_unit_1 and business_unit_2 (referenced in the doc) there are also a number of modules (some with similar names) under business_units .

Question : What is this business_units folder, not mentioned anywhere in the documentation? Is it something to be used? Or, if experimental / unusable code why it's still present in the release?

Weird fact 4: under business_units, each module's main invokes a prj_config module providing a prj_config.yaml parameter. The file seems to contain some kind of configuration but this is not documented anywhere. And conversely under business_unit_1 and business_unit_2 the approach is different more along the lines of hardcoding.

Weird fact 5: the Azure Pipeline, mentioned in one of the threads as a valid alternative for deployment does not seem to be deploying business_unit_1 and business_unit_2 but instead is using the modules under business_units. Why there is no documentation for this pipeline and underlying modules being deployed if really considered and proposed as alternative?

Thanks in advance to the maintainers and contributors for somehow sorting out the confusion and updating / cleaning-up the distribution's code and documentation. Personally I don't feel this distribution should have been released as is.

[brangouy44]

Thank you @boanbagon33 for raising these questions. Regarding the supposedly viable option of using a Azure Devops pipeline for deploying this distribution, not sure how feasible this is. There is a comment in #469 from @tackaberry mentioning this avenue but how this could work? The code being in github and not in an Azure Devops repository, is it possible to deploy on GCP using an Azure pipeline and this github repository? Seems quite a weird combination and any documentation on how to set it up, ideally for free would be more than welcome (but did not find any hint thereof in the Readme's). Not to mention that the pipeline seems to be overkill, by simply executing shell scripts in each of the stages and in a very weird way (LOL) : reinstalling Terraform in each stage and restoring then re-saving as an artifact the current working directory. Probably because a Devops pipeline runs each stage on a brand new agent not knowing anything of what other stages did. So one might wonder why go through all the trouble of getting an Microsoft "freemium" devops account and going through all the complexities of pipelines rather than invoking all those commands in a master shell script invoking the commands in each stage as a separate script, and run this in a container? Wouldn't be simpler just to provide such a script ?