Is smith ready for public consumption?

nickatsegment commented 5 years ago

It looks cool and I'd like to use it, but came across some problems:

Not really any docs on how to install it
I found docs/deployment/*.yaml. Some are missing the smith namespace.
deployment.yaml has some XXX where the image tag is supposed to be. Which tag should I use? Looking at Docker Hub, they all have git commit suffixes on them for some reason.

Also, the few I tried don't boot, and have an exec error. I think it's because the entrypoint is actually a darwin binary?

# ls /app/cmd/smith/smith -l
lrwxrwxrwx 1 root root 99 Jan  1  1970 /app/cmd/smith/smith -> /app/cmd/smith/smith.runfiles/com_github_atlassian_smith/cmd/smith/darwin_amd64_pure_stripped/smith

nickatsegment commented 5 years ago

Oh, looks like I found one that works: v1.0.0-2cb13f4. Seems like it was just f5abf88 and f5abf88-race that are darwin bins

ash2k commented 5 years ago

Hey, yes, Smith is ready for public consumption and we use it in production at Atlassian. Sorry, we haven't published an image for... a year? We always run ~latest commit. We have internal builds and publish to internal docker registry. I'll publish a public image. Yes, deployment documentation is sparse and the directory you have found is all what we have. If you ask more concrete questions or suggest improvements to those YAMLs we can make it better. I'll also go through it and compare to our production YAMLs to make sure nothing is missing (probably some minor bits do).

ash2k commented 5 years ago

published v2.0.0

nickatsegment commented 5 years ago

Cool, thanks for the update. I like the tight focus of smith, and that it isn't a total solution like Helm or KubeCI or Skaffold; that allows us to integrate it into our existing pipelines.

What are the plans for support of statefulset? Is it especially difficult? I don't need it at the moment, but would eventually. I'd consider contributing the code myself if it's not a huge design problem.

ash2k commented 5 years ago

I like the tight focus of smith, and that it isn't a total solution like Helm or KubeCI or Skaffold; that allows us to integrate it into our existing pipelines.

Exactly. And it is built that way because it is not designed to be used by a human. It can be used, but from our experience users need something higher level. We have open sourced our internal PaaS (second version) here https://github.com/atlassian/voyager/. As you can see there is no public documentation atm there, but you can have a look and find how we construct Bundle objects from higher-level objects. Smith is the execution engine for our PaaS.

What are the plans for support of statefulset? Is it especially difficult?

No plans until we need it but it shouldn't be a big deal to add support for any object kind. PRs are welcome too.

nickatsegment commented 5 years ago

How should I expect Smith to handle field defaults? For instance, I'm creating a Service, and the spec has no spec.sessionAffinity set. Smith creates the Service, then sees it now has spec.sessionAffinity=None and complains.

Objects are different after specification re-check (`a` is what we've sent and `b` is what Kubernetes persisted and returned):

object[spec][sessionAffinity]:
  a: <nil>
  b: "None"
object[spec][type]:
  a: <nil>
  b: "ClusterIP"
object[status]:
  a: <nil>
  b: map[string]interface {}{"loadBalancer":map[string]interface {}{}}

ash2k commented 5 years ago

Smith cannot tell the difference between:

object with an out of date spec that needs to be updated
object with an up to date spec but with defaulted fields

So when Smith performs an update and gets an object back, it compares it with what it sent. If things do not match, smith logs this message that you are seeing and stops trying to make existing object in the cluster match the desired state in the Bundle. It does not make sense in trying because it will never reach the desired state and will be spinning indefinitely.

This is because defaulting happens at the server and there is no generic way to solve the issue above. I hope (server-side apply)[https://github.com/kubernetes/enhancements/issues/555] will give us a way to send an "apply" and detect that nothing needs to be updated somehow (dry-run of some sort?).

The workaround is to set all the fields explicitly and then there is no problem.

atlassian / smith

Is smith ready for public consumption? #425