| > Flynn has no BOSH equivalent, so there's nothing there to bring back VMs when they fail, perform rolling upgrades or manage the IaaS Flynn auto-heals after node restarts (and if it doesn't that is first and foremost a bug we need to fix), but also has a cluster monitor service which brings services back online automatically, and as a last gasp there is `flynn-host fix` for manual intervention. Flynn has node promotion / demotion so you can totally do rolling upgrades (users have reported they do this with a modified CloudFormation stack for example). There is also a built-in updater to update to a more recent version of Flynn. > Flynn doesn't seem to offer a metrics stream, only logs Something I think should be built-in, but there are many off the shelf solutions which can be deployed to Flynn as apps. > Flynn builds apps from source, so not sure how that works for compiled Java/Go, or anything you'd run with a binary buildpack Flynn has built-in buildpacks but also supports running custom buildpacks (see https://flynn.io/docs/apps#buildpacks). If you just want to deploy binaries, you can either: - use the inline buildpack: https://github.com/kr/heroku-buildpack-inline
- deploy a tarball: https://github.com/flynn/flynn/issues/306#issuecomment-23321...
- deploy a Docker image: https://flynn.io/docs/docker > I couldn't find anything about role-based access control in Flynn, something Cloud Foundry has (which can be backed by LDAP for enterprises) Flynn does not currently have strict access control, but work is very much on the way, see our security improvements project: https://github.com/flynn/flynn/projects/1. > Flynn only appears to route HTTP traffic, so no TCP routing for IoT workloads Flynn supports TCP routes, although it does not seem to be documented very well: https://flynn.io/docs/cli#route |
The Flynn auto-heal - does that monitor infrastructure (ie at the VM level) or is that process auto-healing?