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

Introduce a regional-service module #328

Merged
merged 1 commit into from
May 10, 2024

Conversation

mattmoor
Copy link
Member

@mattmoor mattmoor commented May 5, 2024

No description provided.

@mattmoor mattmoor marked this pull request as draft May 5, 2024 22:48
@mattmoor mattmoor changed the title Introduce a regional-service module Introduce a regional-service module May 5, 2024
Copy link
Member

@imjasonh imjasonh left a comment

Choose a reason for hiding this comment

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

Could we rename regional-go-service and have it accept image||source?

I really don't want to keep more things in sync with the containers type (we already need to for cron and bots, and it sucks)

@mattmoor mattmoor force-pushed the regional-service branch 2 times, most recently from d6c0d2e to 66dea10 Compare May 6, 2024 03:54
@mattmoor mattmoor marked this pull request as ready for review May 6, 2024 03:56
@mattmoor
Copy link
Member Author

mattmoor commented May 6, 2024

@imjasonh we can discuss it, but I worry that optionality will add a bunch of validation complexity (for the oneof aspect, conditional builds, etc) and become a breeding ground for subtle bugs.

I also suspect that the containers types will naturally vary module to module, e.g. something we didn't consider before, but could be useful when passing a literal container image would be command. In the [Cron]Job case, we have differences like not needing regional-env and regional-mounts.

The complexity and inability to share are annoying, but I also think that the types are intentionally divergent across these use cases.

@imjasonh
Copy link
Member

imjasonh commented May 6, 2024

When we have this, what's the benefit of regional-go-service beyond being a wrapper for a single ko_build and this?

I really don't want to have to think of two things every time we add support for something to one or the other.

@mattmoor
Copy link
Member Author

mattmoor commented May 6, 2024

I would say that generally you don’t have to think of both because one calls the other. You reviewed this before I could push that commit from the crap airplane WiFi (I ultimately had to wait until I got to my hotel).

In terms of the value, today it’s N ko builds, N cosign signs, and eliminating the need to declare those “required providers” in virtually every downstream module we have, which adds up fast. However, this is also a place where we haven’t gone as deep as I’d like either. We still can’t attest SBOMs with ko, or do any sort of SLSA provenance attestation. We should also add in a signature verification check on the base image.

@mattmoor
Copy link
Member Author

mattmoor commented May 6, 2024

@imjasonh I opened #331 to track this, but I don't want to block on this because we need something like this to decompose Octo STS's provisioning, so folks can slot in an image from us.

@mattmoor mattmoor requested a review from imjasonh May 10, 2024 02:42
@imjasonh imjasonh merged commit fbee3b1 into chainguard-dev:main May 10, 2024
79 checks passed
@mattmoor mattmoor deleted the regional-service branch May 10, 2024 18:47
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