Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST] Add possibility to provide custom hostnames #2768

Closed
13 tasks
rafzei opened this issue Dec 1, 2021 · 5 comments
Closed
13 tasks

[FEATURE REQUEST] Add possibility to provide custom hostnames #2768

rafzei opened this issue Dec 1, 2021 · 5 comments
Assignees
Labels
priority/high Task with high priority source/jira This task origins from internal JIRA type/feature-request

Comments

@rafzei
Copy link
Contributor

rafzei commented Dec 1, 2021

Is your feature request related to a problem? Please describe.
Currently, there is no option to provide a custom VM hostname via epicli.
The hostname is set up referencing inventory hostname.

Describe the solution you'd like
Current: [prefix][clustername]-kubernetes[master/node]vm[x]
Needed: [prefix][clustername]-kubernetes[master/node]vm[x].[domain.name]
but it should allow to set up anything you can imagine 👾

Additional context
Internal team request, if possible prepare a workaround they could apply to their LTS deployment.

Please check kind: infrastructure/virtual-machine. Maybe specification.name should be the right place for that? Right now it's overwritten after manifests merge.


DoD checklist

  • Changelog updated
  • COMPONENTS.md updated / doesn't need to be updated
  • Schema updated / doesn't need to be updated
  • Feature has automated tests
  • Automated tests passed (QA pipelines)
    • apply
    • upgrade
  • Idempotency tested
  • Documentation added / updated / doesn't need to be updated
  • All conversations in PR resolved
  • Solution meets requirements and is done according to design doc
  • Usage compliant with license
  • Backport tasks created / doesn't need to be backported
@rafzei rafzei added type/feature-request status/grooming-needed source/jira This task origins from internal JIRA priority/high Task with high priority labels Dec 1, 2021
@seriva seriva assigned seriva and unassigned seriva Dec 2, 2021
@seriva
Copy link
Collaborator

seriva commented Dec 2, 2021

So this is only for Azure? Or we want this also on AWS?

@rafzei
Copy link
Contributor Author

rafzei commented Dec 2, 2021

The fr/fix was requested for Azure but afaik the team also uses AWS.

@seriva seriva self-assigned this Dec 3, 2021
@seriva
Copy link
Collaborator

seriva commented Dec 14, 2021

After some more research I found several issues with the task described above:

  • For both AWS and Azure the infrastructure/virtual-machine document type represents a template for a group of VM`s of a certain component . This template is then being used to generate the Terraform VM definitions on Azure and auto-scaling groups on AWS. Any VM specific config is generated by the providers:
    image.png
    Adding a mechanism to specify something like a hostname per VM would require some massive changes which will be hard to keep backwards compatible.
  • While the hostname Azure is generated and explicitly set on AWS the hostnames are provided automatically by the auto-scaling groups. This makes it impossible without reworking a large part of the Terraform to set the hostnames easily. Probably it requires the removal of the auto-scaling groups in favor of a similar approach we have with Azure now. I think there already is an issue to do this as the auto-scaling groups are responsible for more issues regarding scaling components anyway.
  • A work around to change hostnames on older clusters will be expensive to provide as we need to check every component that might have configuration that uses said hostname. It will be similar as some of the outdated scripts we have now for changing IPs for certain components: https://github.com/epiphany-platform/epiphany/tree/develop/tools/ip_change. It probably can be done but its for sure outside the scope of this task and we need to weigh if migrating to a new cluster install is not more cost effective.

Because of these above issues I propose an easier approach to provide the team the ability to add the domain at the end of the hostname and only for Azure in the form as an additional cloud parameter in the root cluster-config document:

kind: epiphany-cluster
name: default
provider: azure
title: Epiphany cluster Config
specification:
 ...
  cloud:
    hostname_domain_extension: **domain**
 ....

This hostname_domain_extension field, if defined will be added to each machine hostname separated by a .. The same as machine VM image definitions it will be retained across Epicli versions and re-applies as changing this will cause the re-creation of the VM as changing VM images would do before.

For our Terraform revision that needs to happen somewhere in next year these scenarios should be re-considered.

@przemyslavic
Copy link
Collaborator

Tested by @rafzei #2790 (comment).
Thanks man ❤️

@atsikham atsikham changed the title [FEATURE REQUEST] Add posibility to provide custom hostnames [FEATURE REQUEST] Add possibility to provide custom hostnames Dec 29, 2021
@przemyslavic
Copy link
Collaborator

@seriva what about adding extra validation for the hostname?

ERROR cli.engine.terraform.TerraformCommand - Error: compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="InvalidParameter" Message="Linux host name cannot exceed 64 characters in length or contain the following characters: ` ~ ! @ # $ % ^ & * ( ) = + _ [ ] { } \\ | ; : ' \" , < > / ?." Target="computerName"

@seriva seriva closed this as completed Dec 30, 2021
seriva added a commit that referenced this issue Jan 21, 2022
… (#2826)

* Backport #2784 for issue #2774
* Backport #2813 for issue #2768
* Backport #2823 for issue #2788
* Backport #2776 for issue #1221
* Backport #2442 for issue #2426
* Backport #2764 for issue #2744
* Backport issue #2831
* Backport #2912 for issue #2894
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/high Task with high priority source/jira This task origins from internal JIRA type/feature-request
Projects
None yet
Development

No branches or pull requests

3 participants