i should note that the repositories aren't actually private but the README wasn't updated to say so at release time. check the README again now and you'll see that you can skip this bit about needing a quay.io account.
hi dlandis. yes i must admit that the documentation is currently very poor. doing what you suggest is going to be my weekend :)
it has been released despite not having these things in place because it's forcing me to sort it out. the project sat untouched for a few months late last year and i didn't want that to continue.
paz documentation, presentations and (now out of date) website mention CD and environments a lot because it has always been a design goal of Paz to enable a CD workflow and give you quick and easy developer environments.
as it currently stands it's far from having achieved that. i ripped out the environments stuff before open-sourcing it because it was half-baked and hacky. expect these things to start coming back into paz in the coming months. what remains that's related to CD is really just that it can receive webhooks from the docker hub / quay.io so you can have a pipeline like git push -> webhook to CI server -> run tests -> docker build -> docker push -> webhook to paz for deployment.
as for orchestration and traditional PaaS functionality, i tend to agree with you and it's arguable whether or not Paz is actually a PaaS in the sense most people use that term. Paz is a platform that can run your services with a PaaS-like workflow. that's probably a more accurate way of putting it.
re "no special code", there is a little magic. paz creates a sidekick unit for your services that will announce them in Etcd. it uses Confd to watch for changes to announcements and reconfigures HAProxy under the hood. i need to document this :)
quay.io offered a free 6 month trial for private repos once upon a time. that's why it's there :) now that it's public it could go anywhere really, and it would simplify installation for people to not have to set up quay.io credentials when they're not actually using it for anything private. i plan to fix this soon.
the main difference from dokku is that paz is multi-host and has has a web user interface. i think the most succinct way to describe paz is kinda like a UI on top of CoreOS's Fleet.
i hadn't come across dokku-alt before, looks great!
> weaveDNS uses weave’s UDP multicast to solicit answers from other servers when it doesn’t know a name. This probably won’t scale up very far, so we’re looking at other ways of doing that;
Does weaveDNS's use of UDP multicast go beyond simply finding other Weave nodes? i.e. Weave can discover other nodes via UDP multicast but you can also tell it addresses of other nodes if for instance, you are running in an environment that doesn't have UDP multicast available. I'm wondering if this same workaround can be used for weaveDNS.
Anyone know if an API is planned? If I want to manage infrastructure from code I would love Terraform to be an option.
As a (predominantly) Node.js developer, I'd probably use pkgcloud for this sort of thing. Terraform supports a great range of providers and has some more advanced features, so I'd love to play with it as an alternative to pkgcloud.