4 ms·

How does this compare to something like Buildbot (https://buildbot.net/ https://buildbot.net/) - I share a lot of your frustrations with Jenkins and this is whe

by tfinch 8y ago

How does this compare to something like Buildbot (https://buildbot.net/ https://buildbot.net/) - I share a lot of your frustrations with Jenkins and this is where we landed. (BTW thanks for ansible, it's awesome :) )

morenoh149 8y ago
What's frustrating about jenkins?
- SteveNuts 8y ago
  It almost always turns into a snowflake the second you start using it, at least in my experience.
  - mpdehaan2 8y ago
    I think we owe Jenkins a TON of credit for being a free solution that has a lot of great traction. I'm used to seeing pages of checkboxes and can't stand how obscure some of the configuration is, but mostly I wanted to write something that could handle configuration differences between hundreds of projects, so that is why there are things like Snippets in Vespene. Plus, I wanted to make something that was a little better for ops use cases (so people don't also have to go pick up something like Rundeck), so that's why there are things like the SSH integration and http://docs.vespene.io/launch_questions.html http://docs.vespene.io/launch_questions.html It's more about capabilities and future capabilities than the frustrations IMHO. Though I do have a bunch of friends who are frustrated with plugin compatibility, plugin hunting (we're doing more of a "batteries included" approach like I ran with ansible - just with much less modules), and stuff like that. I was also able to add in some stuff like container build isolation really easily, and that's all included stock.
mpdehaan2 8y ago
I don't know, I'm really not trying to make one of those cliched checkbox X vs Y type grids, but when I started building Vespene I was most concerned about being able to make builds more consistent when you had hundreds of microservices developed by a lot of different teams. This is why I did http://docs.vespene.io/variables.html#snippets http://docs.vespene.io/variables.html#snippets I also saw a lot of people trying to do ops style stuff from tools like Jenkins, which is why Ansible has built-in SSH automation so it can hold on to SSH keys and use them in your behalf, and has some really cool built in RBAC so you can decide who can run what and it can be different than who can edit what. Mostly I just want to build an architecture that can go interesting places - what is here today I think is usuable, but it's just a starting point. My thinking is if you make an architecture that is really pluggable, and the code is easy to read and add to, it can go to some really neat places. I'd just recommend taking a look at the various chapters of http://docs.vespene.io/ http://docs.vespene.io/ to get a feel for features, and if you like it, spin up a copy using the setup instructions and see what you think.
- Annatar 8y ago
  Configuration management is best with operating system packages, so in creating "Ansible", not only did you completely miss the ball, you created a monster. People now hack ad hoc YAML files instead of designing clean OS packages to manipulate the configuration.
  - mpdehaan2 8y ago
    It's fine if you don't like it - there are things I don't like about it, but ultimately single packages can't express multi-node configurations very easily. We need something. While I "grew up" as it were, believing in RPM, we live in a very post-distro, multi-language kind of world, and there's a need for things to glue that together. How many times have I tried to campaign against "wget tarball" as a deployment mechanism, I don't know. It's rough and yes, there's a lack of discipline in ops that needs to improve. Immutable systems is a VERY interesting way to solve that, but it doesn't work for certain stateful things and you always need something to deploy the undercloud. I'd encourage you to try to build your own experimental project to try to find different ways to do it, as this is the only real way that technology ever gets ahead.
    - Annatar 8y ago
      Funny you should mention RPM's, since that's one of the packaging formats we perform configuration management in. I have my own configuration management framework which can add and remove configuration from files that each package brings on. It's written in AWK. No knowledge is required to use it - configuration packages deliver just their configuration files' excerpts. In addition to being able to template them with regular shell variables, self-assembly is supported as well.
  - deleted 8y ago
    [deleted]
  - throwaway5752 8y ago
    How is that different than what Puppet, Chef, CFEngine, or any number of other configuration management tools do [and did long before Ansible]? How do you propose to have a package that requires dynamic configuration supplied by the system (something from dhcp, for example). Are you conflating package management and configuration management? I'm genuinely curious.

by tfinch 8y ago

morenoh149 8y ago

What's frustrating about jenkins?

SteveNuts 8y ago
It almost always turns into a snowflake the second you start using it, at least in my experience.
- mpdehaan2 8y ago
  I think we owe Jenkins a TON of credit for being a free solution that has a lot of great traction. I'm used to seeing pages of checkboxes and can't stand how obscure some of the configuration is, but mostly I wanted to write something that could handle configuration differences between hundreds of projects, so that is why there are things like Snippets in Vespene. Plus, I wanted to make something that was a little better for ops use cases (so people don't also have to go pick up something like Rundeck), so that's why there are things like the SSH integration and http://docs.vespene.io/launch_questions.html http://docs.vespene.io/launch_questions.html It's more about capabilities and future capabilities than the frustrations IMHO. Though I do have a bunch of friends who are frustrated with plugin compatibility, plugin hunting (we're doing more of a "batteries included" approach like I ran with ansible - just with much less modules), and stuff like that. I was also able to add in some stuff like container build isolation really easily, and that's all included stock.

mpdehaan2 8y ago

I don't know, I'm really not trying to make one of those cliched checkbox X vs Y type grids, but when I started building Vespene I was most concerned about being able to make builds more consistent when you had hundreds of microservices developed by a lot of different teams. This is why I did http://docs.vespene.io/variables.html#snippets http://docs.vespene.io/variables.html#snippets I also saw a lot of people trying to do ops style stuff from tools like Jenkins, which is why Ansible has built-in SSH automation so it can hold on to SSH keys and use them in your behalf, and has some really cool built in RBAC so you can decide who can run what and it can be different than who can edit what. Mostly I just want to build an architecture that can go interesting places - what is here today I think is usuable, but it's just a starting point. My thinking is if you make an architecture that is really pluggable, and the code is easy to read and add to, it can go to some really neat places. I'd just recommend taking a look at the various chapters of http://docs.vespene.io/ http://docs.vespene.io/ to get a feel for features, and if you like it, spin up a copy using the setup instructions and see what you think.

Annatar 8y ago
Configuration management is best with operating system packages, so in creating "Ansible", not only did you completely miss the ball, you created a monster. People now hack ad hoc YAML files instead of designing clean OS packages to manipulate the configuration.
- mpdehaan2 8y ago
  It's fine if you don't like it - there are things I don't like about it, but ultimately single packages can't express multi-node configurations very easily. We need something. While I "grew up" as it were, believing in RPM, we live in a very post-distro, multi-language kind of world, and there's a need for things to glue that together. How many times have I tried to campaign against "wget tarball" as a deployment mechanism, I don't know. It's rough and yes, there's a lack of discipline in ops that needs to improve. Immutable systems is a VERY interesting way to solve that, but it doesn't work for certain stateful things and you always need something to deploy the undercloud. I'd encourage you to try to build your own experimental project to try to find different ways to do it, as this is the only real way that technology ever gets ahead.
  - Annatar 8y ago
    Funny you should mention RPM's, since that's one of the packaging formats we perform configuration management in. I have my own configuration management framework which can add and remove configuration from files that each package brings on. It's written in AWK. No knowledge is required to use it - configuration packages deliver just their configuration files' excerpts. In addition to being able to template them with regular shell variables, self-assembly is supported as well.
- deleted 8y ago
  [deleted]
- throwaway5752 8y ago
  How is that different than what Puppet, Chef, CFEngine, or any number of other configuration management tools do [and did long before Ansible]? How do you propose to have a package that requires dynamic configuration supplied by the system (something from dhcp, for example). Are you conflating package management and configuration management? I'm genuinely curious.