-
-
Notifications
You must be signed in to change notification settings - Fork 0
Parse the pipeline deployment descriptor and generate k8s resources manifests #87
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
base: main
Are you sure you want to change the base?
Conversation
|
|
| parser.add_argument( | ||
| "--deployment-template", | ||
| type=argparse.FileType("r"), | ||
| help="Path to a deployment template file.", | ||
| default=open( | ||
| importlib.resources.files("sentry_streams") / "k8s/templates/deployment.yaml", | ||
| "r", | ||
| ), | ||
| ) |
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.
like
|
One high level question we will have to have at least a high level idea on. I see two options considering many pipelines will be running getsentry and, as of now, it seems SRE is pushing to keep the monolith intact in terms of k8s resources deployment.:
Doing it with an operator changes a bit the problem but not entirely. A resource still has to be deployed that references the getsentry pod template. Did you already put any thought on this ? |
|
I was thinking about it and imo the best would be to go with an operator from the start. This way we can deploy the operator with
This can be a stopgap solution as it sounds quite easy to implement but on the other hand the same effort might be to get minimal operator into production. |
fpacifici
left a comment
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.
I think this goes in the right direction.
Please see some comments inline. I think the key aspects to work on at this stage are:
- The CRD rather than using the configmap as we discussed off line
- move the code of the operator in its own package so
sentry_streamsdoes not have to depend on kops and kubernetes.
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.
I think we should move the whole operator code, examples and Dockerfile outside of the sentry_streams directyory. Let's move everything into k8s.
This is because the content of sentry_streams is the package that contains the streaming platform runtime. That is imported as a library in every code base that runs streaming applications so it should be relatively lite. Importing kopf and kubernetes are not needed tu run sentry thus we should not import them transitively.
| labels: | ||
| service: streams-operator | ||
| data: | ||
| events.yaml: | |
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.
Adding the yaml content inside the configmap is not ideal as it is plain text.
I think the CRD will be important for that as well.
| ) + [ | ||
| generate_configmap( | ||
| config=config, | ||
| configmap_template=configmap_template, | ||
| ) | ||
| ] |
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.
I think you may have to generate and apply the configmaps before the deployments.
| ) -> K8sConfigMapManifest: | ||
| configmap = copy.deepcopy(configmap_template) | ||
| pipeline_name = config["pipeline"]["name"] | ||
| configmap["metadata"]["name"] = pipeline_name |
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.
I think we may want to call the configmap pipeline_<PIPELINE_NAME> rather than PIPELINE_NAME as it has to be a unique name in the namespace.
| streams_operator = StreamsOperator() | ||
| streams_operator.register_handlers() |
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.
Does kopf require the operator to be defined at module level ?
If not can we have it instantiated in the main function or in a function called by main passing the config parameters into the constructor rather than transparently taking them from envvars in the constructor itself? It makes the modularization a bit better and unit tests easier.
| else: | ||
| raise | ||
| # config-map already exists patch it | ||
| self.core_v1_client.patch_namespaced_config_map(name=name, namespace=namespace, body=body) |
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.
I'd add logs before the operator does any write operation.
| self.apps_v1_client.create_namespaced_deployment(namespace=namespace, body=body) | ||
| else: | ||
| raise | ||
| # do not patch the image |
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.
Is this because of GoCD ?
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.
Yes, correct, so that the current way we deploy new images keeps working even for deployments managed by the operator.
https://github.com/getsentry/streaming-planning/issues/100
Using
deployment_configfrom #77 this PR adds command that will generate k8s resources:To generate k8s resources using default templates:
cli support or custom templates: