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

chore: add uds package CR #15

Merged
merged 5 commits into from
Jan 19, 2024
Merged

chore: add uds package CR #15

merged 5 commits into from
Jan 19, 2024

Conversation

TristanHoladay
Copy link
Contributor

update the sonarqube package to utilize the new operator pattern provided by uds-core

…ing virtual service; updated create task with flavor var.
@TristanHoladay TristanHoladay changed the title chore: added chart for uds-package CR with initial config for generat… chore: add uds package CR Jan 18, 2024
@TristanHoladay TristanHoladay marked this pull request as ready for review January 18, 2024 19:08
@TristanHoladay
Copy link
Contributor Author

should we go ahead and implement these netpols since goal is to deploy soon on uds-prod with gitlab and runner?

#  enabled: true
#networkPolicy:
#  enabled: true
#  additionalNetworkPolicys:
#    ingress:
#    - from:
#      - namespaceSelector:
#          matchLabels:
#            kubernetes.io/metadata.name: gitlab-runner-sandbox
#        podSelector: {}
#      ports:
#      - port: 9000
#        protocol: TCP
#    egress:
#    - to:
#      - namespaceSelector:
#          matchLabels:
#            kubernetes.io/metadata.name: gitlab
#        podSelector:
#          matchLabels:
#            app: webservice
#    - to:
#      - namespaceSelector:
#          matchLabels:
#            kubernetes.io/metadata.name: gitlab-runner-sandbox
#        podSelector: {}
#    podSelector:
#      matchLabels: {}
#    policyTypes:
#    - Egress
#    - Ingress

@mjnagel
Copy link
Contributor

mjnagel commented Jan 18, 2024

@TristanHoladay might be worth a discussion on how we anticipate comms for pipelines working. One option is just to have all ingress go through the Istio VS, but that does mean egress on the other end is allowed to effectively anywhere. It feels "smarter" to handle traffic "directly" internal to the cluster, but we don't always know if/how runners and gitlab are deployed. It might make more sense to leave those stitching pieces to the environment specific bundle?

@TristanHoladay
Copy link
Contributor Author

That makes sense. So each bundle would deploy a separate package, which is a chart with another CR or traditional netpols to handle making whatever pieces exist in that environment talk to each other?

@mjnagel
Copy link
Contributor

mjnagel commented Jan 18, 2024

@TristanHoladay that's my leaning yeah. We have something similar to handle auth pieces for AWS currently in our environment, and I think every environment will probably have a small zarf package that does similar things. Might be good to talk through that a bit and determine if we want to publish examples/a full example package or bundle for those missing bits....

Copy link
Contributor

@mjnagel mjnagel left a comment

Choose a reason for hiding this comment

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

LGTM overall - 2 small comments.

tasks/deploy.yaml Outdated Show resolved Hide resolved
values/sonarqube-values.yaml Outdated Show resolved Hide resolved
@TristanHoladay TristanHoladay merged commit 3102036 into main Jan 19, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants