Szymon Konefal
Szymon Konefal
We have this also in #92. Anyway, I think it's not a good idea to add parallelism to sequential computing. Can we close this?
To fully achieve desired state, we need to implement changes in: 1) Pipeline: We need to remove PR-task-pass-filter from RE pipeline, because estimator needs to know cpu usage of BE...
It's rather not a good idea to add parallelism to sequential computing. Can we close this?
Maybe, this could also be solved @ Mesos level. Vinod has raised this issue on Community sync on Sept 3rd, 2015 https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit
Can we consider it done? We have OverloadDetector in Serenity and load-based QoS Controller in Mesos. If we would like to introduce cpu-pinning, we should do that in separate issue.
How about making SerenityConfig immutable? It should be used to support config from external locations like configuration file or HTTP endpoint. Make all _set_ methods protected and make getSection method...
No, for test purposes we would just need to inherit a FakeSerenityConfig class (and test trough this) or be-friend the testing class (might be even better).
Nice work with putting docstrings in your APIs. One day we could enable #80 ;)
Code available in #149