Conversation
cf-foundation-community-automation
bot
moved this to Inbox
in Foundational Infrastructure Working Group
mariash
force-pushed
the
use-agent-enable-access
branch
from
3b7e7c1 to
6e3a80e
Compare
| # New firewall with jobs chain exists - use bosh-monit-access helper | ||
| /var/vcap/packages/bosh-monit-access/bin/bosh-monit-access 1>&2 | ||
| else | ||
| if ! /var/vcap/bosh/bin/bosh-agent enable-monit-access; then |
There was a problem hiding this comment.
Isn't it cleaner to check if the monit access helper shell script exists?
Don't like that there is not way to distinguish between the access helper failing and the command not being available. Also wondering what an older agent without the command does when invoked this way.
There was a problem hiding this comment.
Also wondering what an older agent without the command does when invoked this way.
So when I first saw this PR my thought was "eh, it will just fail and fallback on old stemcells".
But revisiting today, I realize the issue is a little more serious than that.
This galera-agent service script runs under bpm, so it needs access to the command to run or else it will fail with an error. In this case with /var/vcap/bosh/bin/bosh-agent we would see something like this:
.../bin/service: ... /var/vcap/bosh/bin/bosh-agent: No such file or directory
This error occurs becuase the bpm managed mount namespaces do not include /var/vcap/bosh/bin. This is a problem whether it is run directly (in this PR) or if pxc-release consumes this setup via monit-access-helper.sh.
To handle this in pxc-release, we would have to update the bpm.yml config file and add access to the bosh/bin directory. But that is not a backwards compatible change which is the whole point of the bosh-agent enable-monit-access change.
If galera-agent did have access to /var/vcap/bosh/bin today, then on old stemcells without this subcommand, the service script would try to start the bosh-agent (and likely fail - hopefully without a larger blast radius than confusing galera-agent logs).
Perhaps the approach could be rescued if the enable-monit-access binary were located in a "safe" place, like /usr/local or something.
github-project-automation
bot
moved this from Inbox
to Waiting for Changes | Open for Contribution
in Foundational Infrastructure Working Group
Signed-off-by: Maria Shaldybin <maria.shaldybin@broadcom.com> Co-authored-by: Maria Shaldybin <maria.shaldybin@broadcom.com>
mariash
force-pushed
the
use-agent-enable-access
branch
from
6e3a80e to
89db70f
Compare
| /var/vcap/packages/bosh-monit-access/bin/bosh-monit-access 1>&2 | ||
| else | ||
| set +e | ||
| /var/vcap/bosh/etc/bosh-enable-monit-access |
There was a problem hiding this comment.
Isn't this essentially the same as:
if ! /var/vcap/bosh/etc/bosh-enable-monit-access; then
...Can we rewrite it like something like this to avoid getting "command not found" errors in the logs when running on older stemcells?
if ! [[ -x /var/vcap/bosh/etc/bosh-enable-monit-access ]] || ! /var/vcap/bosh/etc/bosh-enable-monit-access; then
...
4 participants
Feature or Bug Description
This PR uses bosh-agent enable-monit-access command that performs the same behavior as bosh-monit-access package
cloudfoundry/bosh-linux-stemcell-builder#474
Motivation
Move bosh-monit-access as a bosh-agent command so that more releases can consumed it. The helper script /var/vcap/bosh/etc/monit-access-helper.sh now will call it as well.