Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The new Ubuntu Server installer starts an SSH server. The credentials are installer:<random_pw> Packer wrongfully tries to connect to this SSH, thinking the VM is ready for further provisioning steps - which it is NOT. Thanks to @JulyIghor we found a workaround. We simply change the port packer expects the ssh server to run at to something else AND during cloud-init late_commands we override the servers port accordingly. That way once the cloud-init finishes and reboots the VM the ssh server will run at the new port - now packer picks up on that and continues provisiong as we are used to. As a last step durng provision, we remove the conf file, essentially resettign the ssh server port back to default 22. @SwampDragons: hashicorp/packer#9115 Please check on the logic behind communicator setting "pause_before_connecting". That setting actually does still try to connect ONCE and then waits, instead of waiting for the specified duration and then and only then trying to connect. Thanks!
- Loading branch information
4b535fe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the ping. I'm aware of that behavior: hashicorp/packer#7430 (comment)
The idea behind doing it that way was that rather than just having an arbitrary wait that has to cover an entire preseed run, you'd be able to be a bit more specific with how long Packer has to wait around because you only have to wait between the time the server is up, and whenever you think the preseed is complete. Originally, we figured setting up SSH would be near the end of the run, which means that doing it this way would enable a shorter and more precise wait.
Is connecting, then disconnecting and waiting causing an issue that forces this workaround, or was it just unexpected?
Thanks for tagging me on this so I can see this workaround. I've been following hashicorp/packer#9115 but hadn't had a chance to research it myself yet so was waiting to comment.
4b535fe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
4b535fe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the real issue is the logs being spammy when you increase the SSH timeout, I'd rather we adjust the verbosity of the connection attempt logging.
4b535fe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.