For a moment, I'm going to throw away my automation and configuration management hat. I'll let you know when I put it back on. Also, let's ignore that we're talking about Riak specifically for a moment. Also also, let's ignore any (for a brief moment) the proper role of a package manager.
If you're writing server software, you have two target markets. The system administrator/operations team and the developer.
The main reason you want autostart is to get people up and running quickly. To do this, you need to ship safe and sane defaults. This means something like a default configuration that listens only on localhost.
This is a great goal. People can easily install a package and BOOM, they can start using it. No additional thought required.
However, let's look at what you've just done. You've started a program running in the background (or worse - foreground) that, in the case of Riak, is now writing persistant data to the file system. You've just made some pretty arrogant assumptions about not only whether or not the user actually wants it to run full time but also about where that data should go.
So maybe you think, I'll add a post-install dialog for the user so they can tell me where they want the data. If autostarting hadn't hinted that the market you're catering to is the developer, requiring human interaction pretty much cemented it.
But wait! Debian package files support preseeding. This works for system admins too! Except for those who happen to not be using a debian based distro. So now you've narrowed your target market to developers on debian-based systems.
We're going to move firmly back into Riak territory now. An autostart configuration with localhost only listening does Riak a disservice. The ONLY valid use case for running in localhost-only mode is local testing/development. Even then it's probably not a valid use case. How many times has the Riak list seen people "benchmarking" Riak with a single node only to be told "You really should be using more than one node for this"?
The fact is that Riak is not a localhost-only single node system. It's a complex system (not in the difficulty sense). Designing a Riak cluster SHOULD require thought. Which backend do I want to use? How many nodes to I need to start? What should my ring creation size be? That last one in particular is a big one.
The reality is you can't reasonably take a single node Riak install that has had no additional configuration done and add it to a production cluster as is. You HAVE to make changes.
Mind you, Riak is wonderfully friendly to operations staff but by making your official packages autostart with what is essentially a developer config makes it LESS friendly to operations folks.
A bit of a side note. At my last company we were testing using Datastax Enterprise. The official packages behaved in exactly the way you're proposing now.
It was one of the single biggest pain points for me. When I went to automate the entire thing with Chef, I ended up having to jump through hoops cleaning up after the default behavior of the package that it would have been LESS work just having Chef install from tarball and setting up all the additional environment variables and symlinks!
I've attached two files that made up our DSE Analytics node install. Note the "cleanup-default-install". This was neccessary because when the default install started up, configuration data was actually written not only to a Cassandra keyspace itself but to the filesystem. Essentially to add the node to a cluster, I had to blow away the data dir AND clean up the local cached settings stuff. Note those recipes don't even deal with having to rebalance the ring. Let's not even get into the clusterfuck that we ran into because Datastax treated /tmp as persistent storage (which ubuntu happily blows away by default at each restart)
Mind you, Basho is not Datastax.
Basho should be encouraging customers down the proper path - that of automating node installation. Autostarting and shipping developer-only defaults does not encourage that. I would hate to manage a Riak cluster without automation tools. Technically I hate to manage ANYTHING without automation. You guys already point your customers in the right direction with being so operationally friendly. You HAVE a working developer-friendly setup in the 3-node quick start. Shit, you guys have even made EVERY erlang packagers life easy with Rebar.
Debian packages should NOT be looked to as best practices for how to install your software. Pre and Post steps in RPM packages should have never been invented.
IMHO (a very strong O), the role of the package manager should be to lay bits on the disk. Nothing more. I would even argue that creating users is not even the role of the package manager. Let's not even get into creating the user as a system user or not (useradd -r) which some packages do and some don't. I might not want /etc/skel copied over for that user.
Package manager's opinionated workflow are great for desktop systems. Debian packages are fairly decent at ensuring they never trample all over user changes. However servers are not desktops. The configuration is (or at least should be) a know state before the software is even installed. Default configuration files are useless for pretty much everyone.
Lay the bits on disk, ship well documented example configs and support storing persistent data in customizable locations. If you really want to make it easier for developers and the riak-curious to get started, ship a shell script that enables "developer-mode" - copy localhost-only configs over to real configs and start the service for the user (just don't add it to the system startup scripts!).
As someone who's going to be standing up a large multi-datacenter Riak cluster that will be automated with Chef in the near future, please don't make my job any harder ;)
My, put down the flaming pitch forks, preface!
I'm going to comment here, and @lusis, if you want to delete this, by all means do so. Let me first say this... holy crap did I hit a hot topic!
So, lets start by clarifying one thing, I never suggested that we were going to have Riak auto-start on install. What I asked in this tweet was if people want packages to auto-start for them on reboot?
The Background
In previous releases, we had a bug in our packaging where not all of the debhelper scripts were properly running. If you know debian packaging, you know that misplacing one dh_ in a rules file somewhere means that lots of things don't happen that you might expect. Moving on. For our next major release 1.1, I had a self imposed task to turn on lintian to clean up some known issues we had in our debian packages. Why was lintian off in the first place? We had it off because embedding erlang in a package auto-fails lintian because erlang includes things like Windows .bat files that are exectubable and lintian for some odd reason take offense as do I Sidenote: I've heard Erlang R15B fixes this, but alas we are shipping R14B04 with 1.1 of Riak due to 15B not making it in time for proper testing. So I turn on lintian, I get 400 errors or some ridiculous number like that, I spend a couple of days fixing issues, and bam now we have like 20 issues and they are all related to stuff in the erlang install I can't fix.
But what about auto-start
I'm getting there, sheesh (I have kids, I use "sheesh" get over it!). When I "fixed" all of our deb issues, one magically great/sucky thing happened. All of the stuff that Debian does by default now works. So the auto-dependencies of shared libraries listing that didn't work before now works... yay! The auto-start on package install now works... booooo! So if you didn't know this already, as a package maintainer you don't need to do anything extra to get the magic of auto-start on install working. If you think to yourself, "hey, I think it sucks to make people create all the rc.d links themselves, I'll just call
dh_installinit
and have debhelper create all those links for them!" well then you also just decided to have that package start on install. Yes they are linked as one, yes that sucks.TL;DR I "fixed" our packaging, it creates sane rc.d links to avoid one more annoyance, it also added auto-start when I didn't want it, crap.
Eating our own dogfood
This came up because with every release now we are going to make sure our Riak chef cookbook is up-to-date with the latest release and Sean Carey (not to be confused with our Ruby client dev Sean Cribbs) is finishing the cookbook for 1.1 and testing it thoroughly. So Sean says in our group chat, "so this is an issue, when we install riak with dpkg it start riak before the true app.config is set". WAT? Discussion ensues, I figure out why stuff is auto-starting, he explains how bad that sucks for a proper Chef cookbook, etc., etc.
The proposed solution
So we are going to fix that, but that brings us all the way back to my actual tweet do you as a user / ops guy / dev want the startup scripts linkified in rc.d for you?
Assuming it doesn't auto-start on install (I really don't like that, and get that you all HATE that) do you want something like Riak to startup on reboot, or would you rather take care of all that configuration yourself?
One solution that was proposed, so I don't have to pass the
-n
flag todh_installinit
to disable it, is to go the route of Pound, Haproxy, and Postgres (at least once-upon-a-time) to create an/etc/default/riak
file that containsENABLED=false
and our init script reads that file and doesn't startup if it isfalse
. This seems to be a common practice to get around auto-start on install, while still having everything in place for start-on-boot. So I ask, is this reasonable? It will force you to configure the app.config properly, change that flag, and everything is good to go. As you point out @lusis, it might frighten some users who are just trying things out, so it doesn't come without some downsides.So yeah, let me know here (if that's okay with @lusis?), tweet at me at _jared, message @jaredmorrow on github, ping me on Freenode in #riak (I'm Spyplane in there, it was an old throwback name I had, don't taze me bro). Thanks for all the feedback on twitter btw, I'm sure glad I didn't actually suggest auto-starting on install! Phew.