-
Notifications
You must be signed in to change notification settings - Fork 136
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
Support multiple commands #290
Conversation
Supporting more than one "main" application and their various preStart behaviors implies they can depend on each other. Rather than making us responsible for creating a graph of these dependencies, all components will publish and subscribe to events on a top-level EventBus.
(Still working on getting |
Well perhaps a single day was ambitious... 😀 I've got the skeleton of work for how I'm splitting out the various |
bcc5932
to
d5d633f
Compare
I've got a majority of the big TODOs hit at this point. The signal handling needs to be reworked and I need to hit where I've stubbed out the |
…ec ends includes a lot of integration test cleanup around logging
4414e6c
to
e5fe99b
Compare
0aa956b
to
d9fd963
Compare
d9fd963
to
fd05aad
Compare
Ok as of fd05aad I have all the tests passing again in Travis build 214283103. There's a tiny bit of cleanup to do to make sure I haven't left in any dumb debugging messages, clear out a couple commented-out bits, etc. and then I'll merge this. This PR honestly isn't the cleanest thing in the world and merging in 3 weeks of work instead of a bunch of smaller commits sucks, but this will enable us to complete the rest of the v3 work as a series of smaller commits. Note that I'm intentionally not updating documentation for the breaking config changes here, as I don't want the docs on Joyent.com to be updated yet (they're compiled automatically from master) until we complete the config language changes. |
This PR is a work in progress for supporting multiple "main" applications on a first-class basis. It involves a fairly major refactoring of the internals.
Supporting more than one "main" application and their various preStart behaviors implies they can depend on each other. Rather than making us responsible for creating a graph of these dependencies, all components will publish and subscribe to events on a top-level EventBus. Services are split into Services and HealthChecks, Coprocesses are treated as non-advertised Services, and Tasks are treated as repeating non-advertised Services. To do this in a way that doesn't require updating all our configuration syntax at the same time, I'm having to refactor the configuration parsing code as well to more strongly separate it from the app state.
Major TODOs:
coprocess
config to createService
for each tasktasks
config to create aService
for each tasksensors
to use the sameEventBus
(i.e. implement theRunner
interface)EventBus
preStart
,postStop
, andpreStop
in terms of eventscore
package and push it intoconfig
where it belongsContext
so they can be cancelled by the events we hit in the centralRun
loop for each service/task/etc.cc @misterbisson @geek @jasonpincin