Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: httpd-script
data:
httpd.sh: |
#!/bin/sh
echo true > /var/www/started
echo true > /var/www/ready
echo true > /var/www/live
exec httpd -f -h /var/www -p 80
Copy link
Contributor

@camilamacedo86 camilamacedo86 Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TL;DR (just to share):

If there’s a strong reason to add probe implementations here (which doesn’t seem to be the case right now), I’d prefer to rely on the existing setup — meaning we can create a bundle using test-operator.

Otherwise, adding probes here feels unnecessary. I’d suggest using the existing test-operator instead.

Copy link
Contributor

@perdasilva perdasilva Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we ever reached a steady state on the test-operator or use it within our e2es. I'm actually wondering if we should nuke it for now.

The nice thing about having the health and readiness probes defined in this way is that we can very easily change their state at runtime by creating/deleting the files in /var/www, which is great for e2e testing. This is the real value added here by this PR.

Copy link
Contributor

@camilamacedo86 camilamacedo86 Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That might be a true point. However, unless we add tests that actually take advantage of it, I don’t see a strong reason to include it.

Could we add some unit tests or use case scenarios that demonstrate where this feature would be helpful? If so, I’d be completely on board with it — that would show not only that this change is useful, but also that it works as expected.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These will come when we start to lay down more boxcutter tests. This was added to help with manual testing of the conditions changes we've been introducing. I think it's ok to add this now, to reduce the size of PRs later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to move forward, I’m okay with that.
But I think we should properly validate that:

  • a) the configuration here is correct,
  • b) it provides the flexibility we want, and
  • c) it’s actually useful in practice (and not just theoretical).

I’d prefer to have at least one test using it, but I won’t block this one! 👍

Original file line number Diff line number Diff line change
Expand Up @@ -56,16 +56,40 @@ spec:
app: olme2etest
spec:
terminationGracePeriodSeconds: 0
volumes:
- name: scripts
configMap:
name: httpd-script
defaultMode: 0755
containers:
- name: busybox
- name: busybox-httpd-container
image: busybox:1.36
command:
- 'sleep'
- '1000'
securityContext:
runAsUser: 1000
runAsNonRoot: true
serviceAccountName: simple-bundle-manager
command: ["/scripts/httpd.sh"]
ports:
- containerPort: 80
volumeMounts:
- name: scripts
mountPath: /scripts
readOnly: true
startupProbe:
httpGet:
path: /started
port: 80
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /live
port: 80
failureThreshold: 1
periodSeconds: 2
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 1
periodSeconds: 1
serviceAccountName: simple-bundle-manager
clusterPermissions:
- rules:
- apiGroups:
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
apiVersion: v1
kind: ConfigMap
metadata:
name: httpd-script
data:
httpd.sh: |
#!/bin/sh
echo "Version 1.2.0"
echo true > /var/www/started
echo true > /var/www/ready
echo true > /var/www/live
exec httpd -f -h /var/www -p 80
Original file line number Diff line number Diff line change
Expand Up @@ -56,15 +56,39 @@ spec:
app: olme2etest
spec:
terminationGracePeriodSeconds: 0
volumes:
- name: scripts
configMap:
name: httpd-script
defaultMode: 0755
containers:
- name: busybox
- name: busybox-httpd-container
image: busybox:1.37
command:
- 'sleep'
- '1000'
securityContext:
runAsUser: 1000
runAsNonRoot: true
command: ["/scripts/httpd.sh"]
ports:
- containerPort: 80
volumeMounts:
- name: scripts
mountPath: /scripts
readOnly: true
startupProbe:
httpGet:
path: /started
port: 80
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /live
port: 80
failureThreshold: 1
periodSeconds: 2
readinessProbe:
httpGet:
path: /ready
port: 80
initialDelaySeconds: 1
periodSeconds: 1
serviceAccountName: simple-bundle-manager
Copy link

Copilot AI Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The serviceAccountName field is incorrectly placed inside the container spec. It should be at the pod spec level (after the containers array, not inside it). This will cause the deployment to fail.

Copilot uses AI. Check for mistakes.
clusterPermissions:
- rules:
Expand Down Expand Up @@ -125,7 +149,7 @@ spec:
verbs:
- create
- patch
serviceAccountName: simple-bundle-manager
serviceAccountName: simple-bundle-manager
strategy: deployment
installModes:
- supported: false
Expand Down
Loading