This shouldn’t be created any more - the only files written in here are 2 bubble and 2 nodemanager logs. Removing it here would be another confirmation to me that I fully removed the usage of this folder.
This shouldn't be created any more - the only files written in here are 2 bubble and 2 nodemanager logs. Removing it here would be another confirmation to me that I fully removed the usage of this folder.
I’d prefer the endpoint to simple by called /logs (and the constant named EP_LOGS) -- because in the long run, we may offer more fine-grained configuration than just on/off. We may also offer GET endpoints to read log data.
I'd prefer the endpoint to simple by called `/logs` (and the constant named `EP_LOGS`) -- because in the long run, we may offer more fine-grained configuration than just on/off. We may also offer GET endpoints to read log data.
Added, but also moved to a most proper place - NodesResource - as these calls doesn’t actually require network UUID. Then don’t require node UUID either, so the final URL doesn’t contain any UUID. But that seems like more proper place as this log flag is node’s property.
Added, but also moved to a most proper place - NodesResource - as these calls doesn't actually require network UUID. Then don't require node UUID either, so the final URL doesn't contain any UUID. But that seems like more proper place as this log flag is node's property.
Do we need to supervisorctl reload to make sure the new log locations are used by the various processes that supervisord starts? Where is that happening?
Do we need to `supervisorctl reload` to make sure the new log locations are used by the various processes that `supervisord` starts? Where is that happening?
Overall looks very good. Just a few suggestions and one big question -- how do the supervisord changes take effect?
why remove this from .gitignore?
This shouldn’t be created any more - the only files written in here are 2 bubble and 2 nodemanager logs. Removing it here would be another confirmation to me that I fully removed the usage of this folder.
I’d prefer the endpoint to simple by called
/logs
(and the constant namedEP_LOGS
) -- because in the long run, we may offer more fine-grained configuration than just on/off. We may also offer GET endpoints to read log data.I’d prefer to add a LogsResource class, and reference it here via
@Path(EP_LOGS)
to delegate everything under/logs
to LogsResource.Added, but also moved to a most proper place - NodesResource - as these calls doesn’t actually require network UUID. Then don’t require node UUID either, so the final URL doesn’t contain any UUID. But that seems like more proper place as this log flag is node’s property.
Do we need to
supervisorctl reload
to make sure the new log locations are used by the various processes thatsupervisord
starts? Where is that happening?👍 Forgot to add that, sorry. And that is the answer to the question above `how do the supervisord changes take effect?
WIP: (testing) Log flag and logs refactoringto Log flag and logs refactoring 4 years agoLog flag and logs refactoringto WIP: (re-implementing) Log flag and logs refactoring 4 years agoWIP: (re-implementing) Log flag and logs refactoringto Log flag and logs refactoring 4 years agoReviewers
d5d2bb508a
.