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

Machine rename support #498

Closed
wants to merge 5 commits into from
Closed

Machine rename support #498

wants to merge 5 commits into from

Conversation

bravechamp
Copy link
Contributor

@bravechamp bravechamp commented Mar 13, 2022

  • read the CONTRIBUTING guidelines
  • raised a GitHub issue or discussed it on the projects chat beforehand
  • added unit tests
  • added integration tests
  • updated documentation if needed
  • updated CHANGELOG.md

Changes:

  • Machines can have nicknames
  • If nickname is set, it overrides Machine Name and new name will be used instead
  • Added nickname on nodes list output
  • New command nodes rename sets and clears nickname

Copy link
Contributor

@restanrm restanrm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are missing some lock mechanism to forbid update of the name from the machine like the enable autogenerate machine name from https://tailscale.com/kb/1098/machine-names/.
If you don't bring something like that, it would overwritten quickly I think.

@bravechamp
Copy link
Contributor Author

Thanks for the feedback. But, that's the point of the nickname field. It's a new field and can only be set by cli (or api). When set, it overrides machine name. When cleared, machine name is used. So, enable autogenerate machine name checkbox functionality is there.

@restanrm
Copy link
Contributor

Thanks for the feedback. But, that's the point of the nickname field. It's a new field and can only be set by cli (or api). When set, it overrides machine name. When cleared, machine name is used. So, enable autogenerate machine name checkbox functionality is there.

Sorry I missed that point. Then, I think you should add a migration script to add the column in the database. See what is done in db.go

@bravechamp
Copy link
Contributor Author

Well, db.AutoMigrate(&Machine{}) already does that, right? During my tests, column appeared as soon as I run the executable.

@restanrm
Copy link
Contributor

Neat thanks !

@@ -40,6 +40,13 @@ func init() {
}
nodeCmd.AddCommand(expireNodeCmd)

renameNodeCmd.Flags().Uint64P("identifier", "i", 0, "Node identifier (ID)")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

general thought: Is this a rename, or is it a setname or something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just reused headscale namespaces rename command to keep things familiar. I'm open for suggestions. Right now you can headscale nodes -i 1 rename newmachinename to set the Nickname field or headscale nodes -i 1 rename to clear it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ye, its mostly fine, I didnt have a really good name

@@ -207,6 +214,54 @@ var expireNodeCmd = &cobra.Command{
},
}

var renameNodeCmd = &cobra.Command{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These command will need integration tests

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do

@@ -367,6 +368,29 @@ func (h *Headscale) ExpireMachine(machine *Machine) {
h.db.Save(machine)
}

// RenameMachine takes a Machine struct and sets the expire field to now.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment seems wrong ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. Result of pure laziness. Fixing...

@@ -40,6 +40,7 @@ type Machine struct {
DiscoKey string
IPAddresses MachineAddresses
Name string
Nickname string
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit conflicted about the naming here; Nickname doesnt just sound completely right, in a way, what is now called Name should become HostName and then Nickname should be Name or maybe GivenName

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree Nickname is not a good name. I didn't want to change the name of an existing field. Shall I change the Name to Hostname and keep the db column name as name?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am slightly concerned that the migration software actually understands this tho... I would like to have that sorted. I personally am not interested in having naming things we are not happy with accumulate.

I suspect that using something like RenameColumn (https://gorm.io/docs/migration.html) would just end in an "infinite" loop, renaming it every startup

I think we can do:

Suggested change
Nickname string
GivenName string

and HostName, and add a comment above both with how they are set, and what they mean.

Comment on lines +373 to +376
newNickname, err := NormalizeToFQDNRules(
newName,
h.cfg.OIDC.StripEmaildomain,
)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a user set name, we should not modify the value, we should throw a "name is not valid error" instead of setting something the user didnt expect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, sounds good. I'll do that

Comment on lines +581 to +584
name := machine.Name
if len(machine.Nickname) > 0 {
name = machine.Nickname
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to think about this a bit differently, if we implement this feature, we will have two name fields:

  • Name
  • Nickname

Name should be the exact hostname that is passed by the Tailscale client, and should not be used in the DNS config.

Nickname should be set as the Normalized name of Name on registration (e.g. it will always have a value) and then it can be changed by the user later.

Nickname should therefore always be used for the DNS Config.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then, we have to store the state of "Auto-generate from OS hostname" checkbox in database, right? Otherwise, each client update will overwrite this field.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, so the flow should be:

  1. Machine sends a register request with hostname: TailScaleNode-123
  2. We set the HostName (currently Name) field to TailScaleNode-123
  3. We Normalize TailScaleNode-123 and set the result to GivenName (currently Nickname)

Then if a user wants to rename the host, we let them do that and use the validation part of the Normalization infra.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does look like the GivenName should be unique?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes for the DNS to work properly, normalization function should check if GivenName is already registered in DB and add something to it. This step should behave proerly automatically without the use of an admin or the user to change anything. If the user is not satisfied with the name he could change it manually on the tailscale node.

@kradalby kradalby added this to the v0.16.0 milestone Mar 20, 2022
@kradalby kradalby mentioned this pull request Apr 24, 2022
5 tasks
@kradalby
Copy link
Collaborator

kradalby commented May 1, 2022

Closing this in favour of #560

@kradalby kradalby closed this May 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants