marema31
commented
7 years ago 👍
Closed Joseph-R closed 5 years ago
marema31
commented
7 years ago 👍
mwhooker
commented
7 years ago see also #1475
I haven't investigated too thoroughly, but someone in that thread mentioned that it might be difficult. It seems like there's a convenient entry point for us packer/provisioner.go:60 that might be useful.
Going to leave this open for now, with the caveat that I probably won't be able to work on this for a while. Would love to look at any PRs that come in for it
rickard-von-essen
commented
7 years ago For everyone who's debugging provisioners I can recommend the newish -on-error=ask argument to build which will pause if an error occurs and allow you to check out what happened and then continue with the clean up.
Joseph-R
commented
7 years ago For everyone who's debugging provisioners I can recommend the newish -on-error=ask argument to build which will pause if an error occurs and allow you to check out what happened and then continue with the clean up.
@rickard-von-essen - Useful! Thanks for posting that.
-on-error=ask is helpful, but not a 1:1 drop-in for this feature request.
Example use:
$ packer build -on-error=ask stig1_SUSE11_SP4.json
amazon-ebs output will be in this color.
==> amazon-ebs: Force Deregister flag found, skipping prevalidating AMI Name
amazon-ebs: Found Image ID: ami-3aef6a5b
==> amazon-ebs: Creating temporary keypair: packer_58c82222-629c-9c9b-8ecf-1f3f205c8285
==> amazon-ebs: Creating temporary security group for this instance...
==> amazon-ebs: Authorizing access to port 22 the temporary security group...
==> amazon-ebs: Launching a source AWS instance...
amazon-ebs: Instance ID: i-0a10c5a9639138de7
==> amazon-ebs: Waiting for instance (i-0a10c5a9639138de7) to become ready...
==> amazon-ebs: Adding tags to source instance
==> amazon-ebs: Waiting for SSH to become available...
==> amazon-ebs: Timeout waiting for SSH.
==> amazon-ebs: Step "StepConnect" failed
==> amazon-ebs: [c] Clean up and exit, [a] abort without cleanup, or [r] retry step (build may fail even if retry succeeds)?So the above is good if you want to make changes and iterate through a piece of code, for example, and make changes/retry quickly. But it doesn't generate the temporary SSH key locally, or give output re: internal/external IPs, etc. So you're still "hands off" the temporary box, which can be sub-optimal for certain kinds of troubleshooting.
marema31
commented
7 years ago I was also waiting for this -on-error option that accelerated my debug process (when I don't forget to use it :) ). But it is valid only if a provisionner send back an error, in some occasion, the provisionner is OK, but some actions does not have the expected results, and the ability to stop just before the provisionner and run its action by hand is precious.
The PR I have proposed could be extended to do just what you described in your request. It will need only to add the cli option recognition, an other boolean and a new if in the provisionner hook loop. I have not done it in this PR for the moment only because I wanted review by devs with more knowledge of the codebase because since it concern the core, it could have impact I do not imagine.
If the reviewer are OK with it, I would do the proposal (in a separate PR or the same as they prefer) for the option you ask for.
marema31
commented
7 years ago About this, an other possibility using this PS is to add one more block here like this
if rawP.PauseBefore == 0 {
provisioner = &DebuggedProvisioner{
Provisioner: provisioner,
}
}And add the "pause_before" = "0" in the provisionner will ask for a key press at this specific step.
Lets the maintainers provides their thoughts on these proposals.
SwampDragons
commented
5 years ago This has been released via the breakpoint provisioner in v1.3.3
ghost
commented
4 years ago I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Add a debug mode for the provisioners section of a build file.
Use case: If I want to debug code using a provisioner or chain of provisioners atm, I run
packer build -debug $buildfile, and step through a number of phases related to builder functions that may or may not be broken and that I may (or may not) care about at the time.Example: If a developer wants to debug why Chef is throwing an error over a package install, they have to step through the following line-by-line:
...most of which is irrelevant to "why Chef isn't installing this package?".
For me, debugging these kinds of issues is like 70-80% of the time I spend debugging Packer. And I just want to pop open a temporary instance and debug something (typically by shelling in and poking around) between the StepConnect and the end of the StepProvision steps:
Adding a
-debug-provisionersmode that let's a developer skip to that phase would save a lot of time in iterating through these kinds of debug cycles.