Closed yeoldegrove closed 3 years ago
@arbulu89 I get the point about the workspace and deployment_name prefixing in the resources... The intention was not to change this behavior, will rework it.
I plan to built it in a way that the resource names stay the same as now and you can only decide if you want to have the deployment_name as a prefix to the actual hostname (within salt/OS, not terraform).
@arbulu89 I get the point about the workspace and deployment_name prefixing in the resources... The intention was not to change this behavior, will rework it.
I plan to built it in a way that the resource names stay the same as now and you can only decide if you want to have the deployment_name as a prefix to the actual hostname (within salt/OS, not terraform).
I don't know if there is a way to use resources with the same name. Maybe using tags or similar.
@arbulu89 resource names on aws, gcp, libvirt are not touched anymore. Only slight changes in this regard to streamline the naming.
There is now a default deployment_name_in_hostname
set based on the current behavior of the cloud providers. The user can overwrite this if he e.g. does not like such long hostnames or needs the deployment name in the hostname.
@arbulu89 please re-review.
This PR makes it possible to configure the hostnames of each VM type via variables in
terraform.tfvars
. It addresses #757 . Additionally there is the possibility to add thedeployment_name
as a prefix to the actual hostname (in salt and OS). Thedeployment_name
will be added to terraform resources as usual (no change in behavior).run salt default state on all hosts
default.hostname
ignore terraform lockfiles
ignore gcp credentials
azure: make hostnames configurable
aws: make hostnames configurable
gcp: make hostnames configurable
libvirt: make hostnames configurable