Daniel Thayer commented on BIT-1194:
Hmm, is that the only thing that it needs to work? if
so, maybe makeConfig(..) just needs to be ran
automatically anytime a change in broctl.cfg is detected.
Yes. I've thought about auto-update when broctl.cfg changes, but
didn't implement it because that would mean config changes would take effect
on the manager immediately, while the remote workers/proxies would require
the user to do "install" (which users often forget to do, however broctl now
a warning in that case, so it should be less of a problem going forward).
There's also the caveat that some option value changes don't really take effect
broctl initializes (e.g. SitePluginPath).
broctl deploy command
Project: Bro Issue Tracker
Issue Type: New Feature
Affects Versions: git/master
Reporter: Justin Azoff
(mostly notes for me right now)
Currently broctl makes it too easy for an end user to do the wrong thing when changing
the bro config.
restart --clean is close, however, it does things in this order:
stop -> clean -> check -> install -> start
This is bad because in the event of a 'check' failure bro will not restart.
So, I think what needs to be done is 'restart --clean' should only do:
stop -> clean -> start
and a new command 'broctl deploy' should do
check -> install -> restart
'broctl deploy --clean' can do
check -> stop -> clean -> install -> start
Also, I think the 'install' operation should always run 'check', is
there any reason it shouldn't? Would someone every want to force install a broken
This message was sent by Atlassian JIRA