Need to solidify how layer naming is managed

[seansund]

We have a number of identifiers for each BOM/layer

• code
• platform (e.g. ibmcloud, aws, azure
• name

We need to determine how we uniquely identify each BOM. The infrastructure layer are a good place to finalize this.

Provider	QuickStart	Standard	Advanced
IBM Cloud	single infra layer	multiple infra layers	multiple infra layers (some overlap with Standard - e.g. 000, 100 will be same)
AWS	"	"	"
Azure	"	"	"

I propose that the layer numbers should be the same for a particular flavor across the providers (e.g. IBM Cloud, AWS, and Azure Quick Start all define a 110 layer). The layer would be distinguished by the platform value

[seansund]

From @mjperrins

I am happy with 110 top level number, but if we can add in 110-vnet-azure-q-etc
and 110-vpc-ibmc-q-etc
as the unique ID in the BOM
so we add the platform and the arcitecture pattern

[seansund]

I don't think the flavor name should be included in the name because the layer could be reused across flavors. I'd rather use something that describes what makes it different. E.g. 110-core-shared-services has LogDNA, Sysdig, and COS by default. 110-secure-shared-services has LogDNA, Sysdig, COS, and KMS (either HPCS or Key Protect)

QuickStart	Standard	Advanced
	000-{provider}-account-setup	000-{provider}-account-setup
100-{provider}-core-shared-services	100-{provider}-secure-shared-services	100-{provider}-secure-shared-services
105-{provider}-vpc-openshift	110-{provider}-vpc-internal-dmz	110-multi-vpc-internal-dmz
	115-{provider}-vpc-external-dmz	115-multi-vpc-external-dmz
	130-{provider}-vpc-openshift	130-vpc-management
		150-vpc-workload-integration
		160-vpc-workload-backend
200-{provider}-openshift-gitops	201-{provider}-openshift-gitops-bastion	201-{provider}-openshift-gitops-bastion
205-{provider}-odf-storage	205-{provider}-odf-storage	205-{provider}-odf-storage
205-{provider}-portworx-storage	205-{provider}-portworx-storage	205-{provider}-portworx-storage
220-dev-tools	200-dev-tools	200-dev-tools