turbulence-release
turbulence-release copied to clipboard
cppforlife
Windows compatibility
This PR will enable the following features for turbulence on windows:
- fill-disk
- stress (CPU, RAM & IO)
The following blobs are needed for this PR to work:
- stress/stress-windows-1.0.4.zip blob was compiled using cygwin (https://www.pivotaltracker.com/file_attachments/72576699/download?inline=true) https://www.pivotaltracker.com/story/show/133341955
- golang-windows/go1.7.4.windows-amd64.zip can be downloaded from (https://storage.googleapis.com/golang/go1.7.4.windows-amd64.zi)
nice, will try to pull this in later today.
Sent from my iPhone
On Jan 26, 2017, at 11:29 AM, Amin Jamali [email protected] wrote:
This PR will enable the following features for turbulence on windows:
fill-disk stress (CPU, RAM & IO) The following blobs are needed for this PR to work:
stress/stress-windows-1.0.4.zip blob was compiled using cygwin (https://www.pivotaltracker.com/file_attachments/72576699/download?inline=true) https://www.pivotaltracker.com/story/show/133341955 golang-windows/go1.7.4.windows-amd64.zip can be downloaded from (https://storage.googleapis.com/golang/go1.7.4.windows-amd64.zi) You can view, comment on, or merge this pull request online at:
https://github.com/cppforlife/turbulence-release/pull/12
Commit Summary
Fix pre-start script for windows jobs Add turbulence_agent_windows job File Changes
M config/blobs.yml (6) A jobs/turbulence_agent_windows/monit (9) A jobs/turbulence_agent_windows/spec (20) A jobs/turbulence_agent_windows/templates/ca_cert.erb (1) A jobs/turbulence_agent_windows/templates/config.json.erb (17) A jobs/turbulence_agent_windows/templates/pre-start.ps1.erb (26) A packages/golang-windows/packaging (17) A packages/golang-windows/spec (7) A packages/stress-windows/packaging (16) A packages/stress-windows/spec (5) A packages/turbulence-windows/packaging (32) A packages/turbulence-windows/spec (10) M src/github.com/cppforlife/turbulence/agentreqs/control_net_task.go (2) A src/github.com/cppforlife/turbulence/agentreqs/control_net_task_windows.go (39) M src/github.com/cppforlife/turbulence/agentreqs/fill_disk_task.go (26) A src/github.com/cppforlife/turbulence/agentreqs/fill_disk_task_unix.go (30) A src/github.com/cppforlife/turbulence/agentreqs/fill_disk_task_windows.go (41) M src/github.com/cppforlife/turbulence/agentreqs/firewall_task.go (2) A src/github.com/cppforlife/turbulence/agentreqs/firewall_task_windows.go (42) M src/github.com/cppforlife/turbulence/agentreqs/kill_process_task.go (78) M src/github.com/cppforlife/turbulence/agentreqs/monit/client.go (83) A src/github.com/cppforlife/turbulence/agentreqs/monit/client_unix.go (89) A src/github.com/cppforlife/turbulence/agentreqs/monit/client_windows.go (41)
M src/github.com/cppforlife/turbulence/agentreqs/monit/provider.go (5) M src/github.com/cppforlife/turbulence/agentreqs/shutdown_task.go (59) Patch Links:https://github.com/cppforlife/turbulence-release/pull/12.patch https://github.com/cppforlife/turbulence-release/pull/12.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
@aminjam im planning to do a little clean up before merging. i want to move compiled time windows separation to be a runtime check just like in shutdown_task.go for example. is there a particular reason that some agent tasks were picked to be split off at compile time?
@cppforlife runtime.GOOS could probably work. Some of the code paths were drastically different so it made sense to have a separate implementation. @sunjayBhatia @charlievieth Thoughts?
I'm ok with either, whatever leads to cleaner code.
If I remember correctly, we tried to get turbulence working on Windows in a hurry so some type definitions are duplicated in both *Nix and Windows code, which isn't great. There are also Windows specific functions, which places a burden on future devs to call the correct function based on the current OS.
Personally, I prefer to separate OS functionality by file as this leads to compile time errors when interfaces aren't satisfied or functionality is missing.
Both approaches are decided at compile time, (if runtime.GOOS == "OSNAME' {...} is a constant expression). The only difference is that the former (+build tags and os-specific filenames) results in a compile time error (i.e. function foo is missing on Windows), whereas lack of support in the latter won't be realized until runtime.
