Earlier quoted context omitted.
Flynn isn't a service discovery library by itself. It's more of a self hosted Heroku. Though, it does use etcd for service discovery.
Are you sure flynn uses etcd for service discovery instead of its own[1]? Looks like it uses Google Omega instead of RAFT which etcd uses. https://github.com/flynn/discoverd
Flynn: first preview release
31–40 of 80 posts
Re: Flynn: first preview release
#32Earlier quoted context omitted.
Are you sure flynn uses etcd for service discovery instead of its own[1]? Looks like it uses Google Omega instead of RAFT which etcd uses. https://github.com/flynn/discoverd
Very first line of discoverd's README: It's currently backed by etcd[...]
Re: Flynn: first preview release
#33Are these sorts of services good enough? I want somewhere to deploy my Django apps, ideally I should be able to get a beefy server and deploy every app as a single thing on that server, completely compartmentalized. The problem I keep hitting is that these things have a tradeoff between ease of use and power. I want to use Docker, but it has no easy way to say "take this file that contains instructions and make every…
Re: Flynn: first preview release
#34Re: Flynn: first preview release
#35Re: Flynn: first preview release
#36Earlier quoted context omitted.
We actually did a crowdfunding campaign[1] last summer to pay for the development time. [1] https://news.ycombinator.com/item?id=6058662
Actually after Jeff Lindsay latest blog post[0] I thought that the project was put on the back burner. What is the relationship between cupcake and the initial author(s) ? [0]: http://progrium.com/blog/2014/02/06/the-start-of-the-age-of-...
Most of the development on Flynn (nearly all of the 2014 work) was done by Jonathan Rudenberg (@titanous), one of the founders of Cupcake. We brought in Jeff as a contractor and paid him out of the crowdfunding campaign. He contributed to the initial architecture and prototypes but stepped back in December.
I don't want to speak for Jeff (@progrium) but my understanding is that he'll keep evangelizing the project at conferences and may be working on a proprietary version/components at Digital Ocean.
The Cupcake team (especially Jonathan) will keep developing Flynn (of course with open source contributions) full time in the future.
Re: Flynn: first preview release
#37Earlier quoted context omitted.
There are currently no tutorial-style instructions for using anything but Vagrant, but you should be able to just to run these commands in whatever environment you are using: https://github.com/flynn/flynn-demo/blob/26fcd98cd7646199513...
PSA to anyone trying this on Ubuntu 14: the docker command seems to be "docker.io" now.
In the meantime, you should either a) install the latest docker from the official docker APT repos http://docs.docker.io/installation/ or b) do something like ln /usr/bin/docker{.io,}
In any case, don't leave your Docker install without a docker binary in your path. That will universally break all tutorials and scripts ever written for Docker, and is unsupported by us (Docker maintainers).
Re: Flynn: first preview release
#38Can anybody discuss how Flynn compares to Mesos? Superficially, it seems to be solving the same sort of problems.
I feel like the projects have very different prospective user bases and communities (Mesos is an Apache project, hundreds of thousands of lines of C++; Flynn Layer 0 is run by a startup and only a few thousand lines of Go) and will likely develop in very different directions to service those communities.
That being said, we've explored creating a version of Flynn layer 1 components that run on Mesos instead of Flynn Layer 0 for users who are already deeply invested in the Mesos ecosystem.
Re: Flynn: first preview release
#39Does anyone know if Flynn components can be run on CoreOS? Also, does Fylnn offer the ability to use sub-domains for accessing apps, with either a random string or custom, eg. //dev.example.com? Thx
You can add any route to any app in Flynn, so different subdomains, domains, and TCP ports are pretty easy.
Re: Flynn: first preview release
#40Can anybody discuss how Flynn compares to Mesos? Superficially, it seems to be solving the same sort of problems.
The Omega authors claim that Mesos' system of application specific schedulers accepting resource offers from the Mesos master is well suited toward short-lived jobs (think ephemeral Map/Reduce or MPI type workloads) but is not well suited for long lived 'service' jobs (like a Rails app or DB server). As this seems to be an important use-case for Flynn, it would seem like a valid architecture decision to not use Mesos.
[0] - https://github.com/flynn/flynn-host/tree/master/sampi
[1] - http://eurosys2013.tudos.org/wp-content/uploads/2013/paper/S...