What is needed for Minimum Viable Product of WinKitchen
- Need a way to hint if command interpreter is bash or posh
- Finalize the transport mechanism (Fletcher Nichol is the tech champ for this)
- WinRM Transport
- SSH Transport
- Create command plugin layer (Jay Mundrawla is the tech champ for this)
- Fletcher to push a small kitchen release (Fletcher Nichol to complete)
- Regression test the new changes with existing functions (linux machines, etc) (Matt Stratton is the tech champ for this)
- Small kitchen release mixed into a ChefDK release
An RFC process for Kitchen should be created. Investigate having this facilitated/hosted by CHEF Software. Please use the comments on this gist to share your thoughts on how to accomplish this. Maybe an ever two week meeting in #kitchenci.
Mechanics People Are Using Today
- Running sshd on the Windows guest
- The Transport/WinRM fork done by Salim Afiune
- A fork of the aforementioned fork, using chef-metal (Matt Wrock)
- Other forks of the fork
Advantage of the Transport mode is you could replace using winrm/ssh with a cloud API (aws, azure, etc)
There are issues with privilege escalation/security context when using WinRM (citation needed)
Suggested to create an OSS implementation of of PS Remoting endpoints (someone confirm I wrote that down properly)
Kitchen needs to be able to reboot/re-run a converge action
- Signal codes?
- There is a reboot resource (xplat) in Chef 12. Question about being able to modify the exit codes.
- Kitchen should consume exit codes in a standard way from provisioners (e.g., chef-client can return code 1 for reboot, and would translate that to 300 if that is the code that Kitchen wants)
Push jobs in Kitchen??