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

Copy chef-client run output to host #135

Open
tyler-ball opened this issue Jun 23, 2020 · 0 comments
Open

Copy chef-client run output to host #135

tyler-ball opened this issue Jun 23, 2020 · 0 comments
Labels
Aspect: Integration Works correctly with other projects or systems. Aspect: UX How users feel interacting with the project, focusing on function, ease-of-use and accessibility. Triage: Feature Request Indicates an issue requesting new functionality. Type: Design Proposal Community survey of a proposal.

Comments

@tyler-ball
Copy link
Contributor

Describe the Enhancement:

Currently, we capture the chef-client output on the target node. However, if the run is successful we throw away that output. There are also failure scenarios where we do not display the output to the user but it would be helpful to do so.

Describe the Need:

We want to capture and store the chef-client output for both successful and unsuccessful runs. Users should be able to configure how they receive this information - if many of their runs are successful, displaying it on STDOUT every time is just noise.

We also need to ensure that the chef-client output can be viewed in all scenarios (EG, #133).

Current Alternative

None - we manually configure chef-client to output to stdout via the workstation.rb

Questions

  1. How will users configure this feature?
  2. Where will output be stored?
  3. Do we want to save chef-client output on the target node in addition to piping it back to the workstation?
  4. In the current failure scenario we output STDOUT to the ChefApply::Log - do we want to change that as part of this implementation? Or maybe we always store output into the ChefApply::Log?
@tyler-ball tyler-ball added Status: Untriaged An issue that has yet to be triaged. Aspect: Integration Works correctly with other projects or systems. Aspect: UX How users feel interacting with the project, focusing on function, ease-of-use and accessibility. Triage: Feature Request Indicates an issue requesting new functionality. Type: Design Proposal Community survey of a proposal. and removed Status: Untriaged An issue that has yet to be triaged. labels Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Aspect: Integration Works correctly with other projects or systems. Aspect: UX How users feel interacting with the project, focusing on function, ease-of-use and accessibility. Triage: Feature Request Indicates an issue requesting new functionality. Type: Design Proposal Community survey of a proposal.
Projects
None yet
Development

No branches or pull requests

1 participant