Hacker News new | past | comments | ask | show | jobs | submit login

I'd guess the OP means restoring configs and the fact that Jenkins setups tend to turn into snowflake servers. Here are some issues:

- State is stored on the filesystem across a bunch of XML files, rather than in a DB.

- Configuration of Jenkins itself happens primarily from the UI rather than in config files. This makes it very difficult to provision automatically.

- No HA story. Or there is a workaround and it relies on NFS. Which is basically the same as no HA story. For a piece of critical infrastructure this is very bad.

- Startup time is horrendous. If you build an AMI and put it in an autoscaling group to attempt to get some vague approximation of HA, boot times often tend to be so long that you need to increase your warmup health check a ton so the autoscaling group doesn't kill the server in an infinite loop.

Sure, you can ssh into your server and apt-get install it, but really you should be writing automation and not doing setups by hand.

So while it's nice to see some effort focused on the UI, since Jenkins relies on it almost exclusively, there are a lot of other fundamental problems.

I always try to use anything other than Jenkins unless forced to.




I agree Jenkins isn't the easiest to automate but surely the fact that it's all XML files makes it easier than a database -- using config management you can install Jenkins and template out the necessary configuration file(s). I much prefer systems that use files instead of the db for configuration...


Configs should be in config files, state in a database. They are coupled in Jenkins and both are on the filesystem, mainly in XML files that are undocumented. Sorry if I wasn't clear about that.


Ah, I see. Yeah, agreed on that one too then.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: