WIP: Initial import and azure hostname module

[yuqi-zhang]

Create an azure-hostname.service to fetch the hostname and write to /etc/hostname.

Questions:

1. I feel that this should run before ignition, in case ignition wants to overwrite the file with a static config? I assume this is for DHCP only.

2. This should be firstboot only right?

3. From what little rust I know I think /usr/bin/afterburn --cmdline --hostname /etc/hostname is the right call for this

4. I think this needs systemd network and that should be it?

[yuqi-zhang]

cc @lucab

[lucab]

Paging @ajeddeloh as well as this could be tricky.

1. I would place in-between ignition-disks and ignition-files
2. technically the hostname could change at anytime, so I don't think this is first-boot only
3. I think it needs a /sysroot/ prefix as well (and proper ordering so that sysroot is mounted already)
4. assuming that means network-online.target, yes

[yuqi-zhang]

Sorry for the delay, I fixed it up to a working state and tested on metal for now.

One question is, since Afterburn is so closely coupled with ignition, should we make this a separate repo like coreos/afterburn-dracut or should be add this under ignition-dracut/overlay it in? I have been modifying the afterburn specfile to build this so its not hard to do either way.

cc @jlebon @ajeddeloh

[jlebon]

Let's make this part of the Afterburn repo itself? I'm hoping this is something we can do for Ignition as well eventually. That one started out as separate because it did more things than just Ignition. But for this, since it's purely about enabling Afterburn, I'd prefer we keep it all together from the start.

[jlebon]

Maybe just afterburn-hostname.service ? Theoretically, other clouds could need this too in the future.

[yuqi-zhang]

Good point

[jlebon]

Did you mean to commit this, or was it just a test?

[yuqi-zhang]

I committed a test service in case people wanted to verify since its WIP and I don't have Azure access atm

[jlebon]

Super minor: let's do descriptions in Title Case?

[yuqi-zhang]

Will do

[yuqi-zhang]

I don't have strong feelings either way. It will probably easier to do as part of the main Afterburn repo then. Will open a similar PR against it for discussion

[jlebon]

1. I would place in-between ignition-disks and ignition-files
2. technically the hostname could change at anytime, so I don't think this is first-boot only

These two conflict, no? If Ignition runs only on first boot, but Afterburn runs on every boot, then:

1. running before ignition-files means that Ignition will be able to set the hostname on the first boot, but then the machine will revert back to another hostname on reboot
2. more generally, it's impossible to persistently set the hostname different from the Azure hostname since it'll be reset on the next boot; not sure if that's the behaviour we want

IOW, ISTM if we do want the hostname to be overridable by Ignition, then we should also be first boot only. If we don't, then we should run after Ignition so that the machine consistently has the same hostname.

(I guess one hybrid approach is to conditionally track Azure's hostname iif no Ignition hostname is specified, though that's more complex to implement.)

[yuqi-zhang]

These two conflict, no?

That is true.

IOW, ISTM if we do want the hostname to be overridable by Ignition, then we should also be first boot only.

I think its safe to implement this for now as I believe Azure leases are in the order of many years, so its not SUPER likely we will see a switch in behaviour that often.

I guess one hybrid approach is to conditionally track Azure's hostname iif no Ignition hostname is specified

The other thing is I haven't really used Azure much, will there be a lot of situations that we foresee people doing static IP/hostname setup with ignition?

[ashcrow]

Is this still relevant post coreos/afterburn#224 being merged?

[yuqi-zhang]

Yes, closing.