Cool effort here

[wzrdtales]

First of all cool effort here, while I don't see this as something in my toolchain yet, it might become such in the future though.

The part of packing together everything and pushing it to the registry is both, nice and a little concerning at the same time, but that is probably just b/c of a lack of knowledge since this process is not yet thoroughly explained. I guess you do not really combine secondary containers like the redis and db container of your examples, but reference them? If really everything is just merged and squished together that would go against the separation of duties and the often uncomfortable truth, that packaging can be a means to customer decision. Especially for components like the db at some point, there must be control to not deploy it all together, but separate. But I guess there will be options for that, I am just expressing my thoughts here (very loosely, just reviewed your whole docs...). On the other side not having to host the helm chart (which I guess you aim to compete with just like operators?) separately, is a nice way to solve it, that part I do like.

I also noted you clearly want to get rid of those operators out there :p , which I completely support, they suck, looking forward to seeing how this will integrate.

I will definitely keep an eye on this and wait for production readiness (which in my terms just means certain features are there which are currently missing like all the scheduling stuff for example).

For now I would just have one question, did you already solve the problem of self-deleting one-off init jobs (db migrations and compatibility checks are classic examples of those which often just can't run as an init container). I saw the depend key, not sure though how powerful it is yet, and depending wouldn't be enough, but of course, a condition on the job's result.

All in all though, cool project.

[cjellick]

Thanks for the feedback @wzrdtales.

I didn't write the image packaging, but have a little familiarity. At the end of the day, it uses image manifests, like you would use for multi-arch images. So, they are all packaged in there together, but at the same time they're still distinct internally. The image that is actually running for a pod is just the "sub image".

We do have jobs as well and we intend to use them to do exactly what you descibe: "operations" for apps. @cloudnautique might be able to chime in with a bit more detail on them.

[cloudnautique]

As @cjellick mentioned the images for the individual containers are packaged in the Acorn manifest.

At runtime though, you can override any of the defined containers with another Acorn. So if you had an Acorn with a redis container, at runtime you could link in a separate redis Acorn that is deployed and optimized for production. You could also not deploy it, and use a SaaS service if you wanted.

A couple of benefits though If you do use all of the container images packaged in the Acorn, you will be guaranteed to always get the same image, even if it's based on a moving tag(latest), because Acorn references the SHA digest. It also makes an app easier to move into an Airgapped environment because you will have all of the dependent images available.

[wzrdtales]

yah I got that of course, that is a benefit: without additional effort. that point I give, I struggle because we usually never deal with the easy early stage scenarios, but am curious to see how you gonna solve some of the common issues and challenges around, since helm and operators obviously failed to fulfill them. Helm did a decent job though, just incomplete. About the Airgap part: not really, especially those environments tend to use either a central db or a very carefully overlooked setup for a rock solid production setup. Plus packaging everything together vs. having multiple containers, well to speak it direct: The nexus, artifactory, or whatever does not care at all about that.

Last questions for today:

• if you override the packaged up container, does it skip to download the unnecessary parts?
• is the redis (or any other) container really uploaded? Or is it just a referenced layer of the existent one like the rest in the container universe?

[cloudnautique]

if you override the packaged up container, does it skip to download the unnecessary parts?

At runtime yes, it will not pull the image onto the cluster. As part of the acorn pull && acorn push process the image would be present in the OCI artifact.

is the redis (or any other) container really uploaded? Or is it just a referenced layer of the existent one like the rest in the container universe?

Yes, it is packaged into the Acorn image and moved around as a single artifact. The Acorn Image contains all of the containers defined at build time. Which in the future we plan to be able to sign/verify the artifact and nested images as a single unit.

[wzrdtales]

Yes, it is packaged into the Acorn image and moved around as a single artifact.

So it is duplicated and not just referenced? If yes, then my next question would be, could you opt-out from that if you already know that this connection is only for dev and not for anything else?

[cloudnautique]

The image layers are stored in the Acorn in the registry, but not put into the cluster as a part of a deployment. The other Acorn with Redis would contain a redis version as well. Each Acorn is self contained. You could build the artifact in such a way that didn't contain the redis image for the prod artifact, but they you couldn't just do acorn run app. These are good things to bring up, would be interested to hear more about the concerns for your use case. Our target is production apps.

[cloudnautique]

Oh, the other thing I wanted to follow up on was operations. The mariadb Acorn README has some examples of how to interact with an Acorn.

https://github.com/acorn-io/library/tree/main/mariadb