4 ms·

Well, I'm sorry for being entirely negative, but after looking over the templates... in my opinion you're doing it wrong. For example (at a glance) I don't see

by moe 16y ago

Well, I'm sorry for being entirely negative, but after looking over the templates... in my opinion you're doing it wrong. For example (at a glance) I don't see any mechanism to upgrade anything after the fact. Am I just missing that, or what's the approach there? Either way, it seems you're effectively reinventing a subset of puppet. Wouldn't it be more sensible to implement rubber in the form of puppet manifests (or chef recipes)?

nirvdrum 16y ago
You're certainly entitled to your opinion. It's just a strong stance to take for something you surveyed for 15 min. and then proceeded to compare to a few things that don't make a ton of sense. But that may very well be due to holes in the docs (hopefully the article did give a motivating example though). I'd have to check the timeline again (I wasn't involved with rubber from the outset), but I think it predates both puppet & chef. Regardless, we've discussed adding a chef adapter. However, it's unlikely that would ever work with the chef configuration server since a large tenet of rubber is your entire deployment and provisioning configuration is wholly contained in your project. Re: upgrading. If you want to upgrade to the latest OS packages, you can "cap rubber:bootstrap" or use "cap invoke" to execute whatever command you want on the remote machines. If you're referring to the rubber modules, you just re-run the generator when we issue an update, much like with other generated source projects. Or modify any of the rubber-*.yml files to specify whatever version number you want, since it's in your version-controlled source tree. Don't get me wrong. I'm highly critical of the projects I'm involved in. It's the best motivator I can think of for improving things. I'm just trying to clear up any misunderstandings to elucidate real issues. I think the rubber mailing list might be a more appropriate venue for a technical deep dive, if you want. Or feel free to email me directly (nirvdrum@gmail). Or we could keep going back and forth here, but it doesn't feel very productive.
defroost 16y ago
Oh my god, if you don't like the way rubber in implemented, either don't use it, or submit some patches to fix areas that you dislike, but give the guy a break.

by moe 16y ago

nirvdrum 16y ago

You're certainly entitled to your opinion. It's just a strong stance to take for something you surveyed for 15 min. and then proceeded to compare to a few things that don't make a ton of sense. But that may very well be due to holes in the docs (hopefully the article did give a motivating example though). I'd have to check the timeline again (I wasn't involved with rubber from the outset), but I think it predates both puppet & chef. Regardless, we've discussed adding a chef adapter. However, it's unlikely that would ever work with the chef configuration server since a large tenet of rubber is your entire deployment and provisioning configuration is wholly contained in your project. Re: upgrading. If you want to upgrade to the latest OS packages, you can "cap rubber:bootstrap" or use "cap invoke" to execute whatever command you want on the remote machines. If you're referring to the rubber modules, you just re-run the generator when we issue an update, much like with other generated source projects. Or modify any of the rubber-*.yml files to specify whatever version number you want, since it's in your version-controlled source tree. Don't get me wrong. I'm highly critical of the projects I'm involved in. It's the best motivator I can think of for improving things. I'm just trying to clear up any misunderstandings to elucidate real issues. I think the rubber mailing list might be a more appropriate venue for a technical deep dive, if you want. Or feel free to email me directly (nirvdrum@gmail). Or we could keep going back and forth here, but it doesn't feel very productive.

defroost 16y ago

Oh my god, if you don't like the way rubber in implemented, either don't use it, or submit some patches to fix areas that you dislike, but give the guy a break.