Details
- Reviewers
epriestley - Group Reviewers
Blessed Reviewers - Maniphest Tasks
- T4209: Multiserver / High-Availability Configuration
- Commits
- Restricted Diffusion Commit
rPf52fbf61170d: Unify the local and global view for `./bin/phd status`.
> sudo ./bin/phd status ID Host PID Started Daemon Arguments 38 localhost 2282 Jun 18 2014, 7:52:56 AM PhabricatorRepositoryPullLocalDaemon 39 localhost 2289 Jun 18 2014, 7:52:57 AM PhabricatorGarbageCollectorDaemon 40 localhost 2294 Jun 18 2014, 7:52:57 AM PhabricatorTaskmasterDaemon 41 localhost 2314 Jun 18 2014, 7:52:58 AM PhabricatorTaskmasterDaemon 42 localhost 2319 Jun 18 2014, 7:52:59 AM PhabricatorTaskmasterDaemon 43 localhost 2328 Jun 18 2014, 7:53:00 AM PhabricatorTaskmasterDaemon 44 localhost 2354 Jun 18 2014, 7:53:08 AM PhabricatorRepositoryPullLocalDaemon X --not Y
Diff Detail
- Repository
- rP Phabricator
- Branch
- phd-global_status
- Lint
Lint Warnings Severity Location Code Message Warning resources/sql/autopatches/20140617.daemonlog.2.sql:2 TXT3 Line Too Long - Unit
No Test Coverage - Build Status
Buildable 1198 Build 1198: [Placeholder Plan] Wait for 30 Seconds
Event Timeline
src/applications/daemon/query/PhabricatorDaemonLogQuery.php | ||
---|---|---|
28–32 ↗ | (On Diff #23029) | (These changes appear elsewhere?) |
src/applications/daemon/management/PhabricatorDaemonManagementStatusWorkflow.php | ||
---|---|---|
56 | I forgot that I hadn't yet implemented this... thoughts on how to tackle this? |
src/applications/daemon/management/PhabricatorDaemonManagementStatusWorkflow.php | ||
---|---|---|
56 | The issue is that the DB version is too verbose? I think either adding a method to PhabricatorDaemonLog like getInterestingArgv() and filtering there, or adding a new column and inserting only the interesting stuff are both reasonable approaches. Although it looks like we aren't GC'ing this table, so maybe we should do that before schema mutations. So I guess I slightly favor:
|
We only have ~16K rows on secure.phabricator.com and are probably near the high end of all installs (i.e., we run the normal number of daemons but probably restart way more often than most installs do) so if you really want to mutate the table that's probably fine to do today without waiting for the GC to clean things up in the wild.
resources/sql/autopatches/20140617.daemonlog.sql | ||
---|---|---|
1–2 | Actually, renaming this is a bad idea. |
resources/sql/autopatches/20140617.daemonlog.sql | ||
---|---|---|
1–2 | yes plz no rename These patches don't need to apply in order so the new one can be called whatever. |
Seems fine, modulo one inline, depending on how you do the implementation.
src/applications/daemon/storage/PhabricatorDaemonLog.php | ||
---|---|---|
22–23 | (Should interestingArgv also have JSON serialization?) |
src/applications/daemon/storage/PhabricatorDaemonLog.php | ||
---|---|---|
22–23 | Yeah, probably. Will fix. |
@epriestley, before I land this... I don't suppose there is a better name than interestingArgv? I'm not a huge fan TBH.
Just being super cautious (paranoid?) and making sure this still all walks. I'll do a quick test on my dev box too.