Skip to content
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

feat(reports): enable optional reports generator deployment #191

Merged

Conversation

andrewazores
Copy link
Member

@andrewazores andrewazores commented Sep 6, 2024

Fixes #185

Currently in draft mode because there is some connection flakiness ("Connection refused") on report generation requests. It seems like some misconfiguration or maybe load balancer naming conflict.

@andrewazores
Copy link
Member Author

The connection flakiness actually reminds me a lot of what I observed before:

cryostatio/cryostat#607

So it seems the underlying HTTP client library was not really the problem, or the solution.

@andrewazores
Copy link
Member Author

Opened #194 to track the connection flakiness as a separate issue.

Comment on lines 61 to 62
- name: QUARKUS_REST_CLIENT_REPORTS_URL
value: {{ printf "http://%s-reports.%s.svc:%d" $fullName $.Release.Namespace (int .Values.reports.service.httpPort) }}
Copy link
Member

Choose a reason for hiding this comment

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

Maybe we can standardize the hostname for component services here by either using service-name or service-name.namespace.svc?

Copy link
Member Author

Choose a reason for hiding this comment

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

True, it should be unnecessary to specify the namespace and .svc. I think I did this out of desperation while trying to figure out what turned out to be the label selectors bug :-)

charts/cryostat/templates/reports_deployment.yaml Outdated Show resolved Hide resolved
spec:
replicas: {{ .Values.reports.replicas }}
strategy:
type: Recreate
Copy link
Member

Choose a reason for hiding this comment

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

I think the strategy can be RollingUpdate here?

Since the report sidecars do not require any PVC, there should not be any issues with pods on different nodes binding to the same PVC (as in the case of cryostat), thus requiring Recreate strategy. Or there might be other reasons?

At least on the operator side, it is RollingUpdate: https://github.com/cryostatio/cryostat-operator/blob/1bdfc3e61ab7fd4e7e7759f0007a09ad27efb057/internal/controllers/common/resource_definitions/resource_definitions.go#L236

tolerations:
{{- toYaml . | nindent 8 }}
{{- end }}
volumes:
Copy link
Member

Choose a reason for hiding this comment

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

We can remove volumes: here?

Comment on lines 105 to 107
cpu: 2000m
## @param reports.resources.requests.memory Memory resource request for each Pod in the Report Generator Deployment.
memory: 512Mi
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

@tthvo tthvo left a comment

Choose a reason for hiding this comment

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

Looks good to me! There is definitely flankiness in connection between components. But when I fixed the selector as in #197, all are good :D

@andrewazores andrewazores merged commit aab2ade into cryostatio:separate-db-storage Sep 19, 2024
2 checks passed
@andrewazores andrewazores deleted the sidecar-reports branch September 19, 2024 21:17
andrewazores added a commit to andrewazores/cryostat-helm that referenced this pull request Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request safe-to-test
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants