-
Notifications
You must be signed in to change notification settings - Fork 0
Add new job-agent-mode flag #269
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
Conversation
src/pkg/k8s.go
Outdated
| } | ||
|
|
||
| func isCodingAgentJob(job opslevel.RunnerJob) bool { | ||
| return strings.Contains(job.Image, "coding-agent") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think I'm going to set this to the exact image name/version before pushing up. So that our release sequence will be:
- Merge
opslevel-containersMR with new image - update this branch to have that exact image name, then merge this
a. At this stage, runner behaviour is unchanged for existing opslevel codebase - Now bump the image in OpsLevel monolith - then runner will run it with privileges
a. we can test on staging at this point - Circle back and change this opslevel-runner check back to
coding-agentmore generically
Basically want to avoid the current non-containerized version running in privileged mode. Open to other ideas!
f0c5be1 to
5f6d11a
Compare
| var containerSecurityContext *corev1.SecurityContext | ||
| if isCodingAgent { | ||
| // Coding agent jobs need privileged mode for creating containers within container | ||
| privileged := true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have an existing network policy for runner-jobs blocking egress to internal networks: https://gitlab.com/jklabsinc/opslevel-kubernetes/-/tree/main/clusters/new-prod-runners/runner-jobs?ref_type=heads
1e28d55 to
0bce102
Compare
| rootCmd.PersistentFlags().String("job-pod-workdir", "/jobs", "The job pod working directory.") | ||
| rootCmd.PersistentFlags().Int("job-pod-log-max-interval", 30, "The max amount of time between when pod logs are shipped to OpsLevel. Works in tandem with 'job-pod-log-max-size'") | ||
| rootCmd.PersistentFlags().Int("job-pod-log-max-size", 1000000, "The max amount in bytes to buffer before pod logs are shipped to OpsLevel. Works in tandem with 'job-pod-log-max-interval'") | ||
| rootCmd.PersistentFlags().Bool("job-agent-mode", false, "Enable agent mode with privileged security context for Container-in-Container support. WARNING: This grants elevated privileges and should only be enabled for trusted workloads.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now that we're using a job arg, we can be oober confident that nothing will use this mode until we explicitly add it to opslevel-kubernetes 👍
so sequencing will be:
- ship new image to ECR (done)
- ship this PR - no effect since flag isn't used
- Test on staging, then ship the OpsLevel MR
- Once changes are live, fast follow with an opslevel-kubernetes MR adding the
--job-agent-modeflag
a. since the feature isn't "on" yet we can get away with this teeny gap.
Test plan
cd src->go build -o /tmp/opslevel-runner-local.opslevel-runner.env.localto haveOPSLEVEL_RUNNER_PATH=/tmp/opslevel-runner-local./bin/dev-serverChangelog
changieentryTophatting