Another option to look into for configuration management:
http://mricon.livejournal.com/360529.html
Jeff
On Mon, Dec 18, 2006 at 10:23:31PM -0600, Jeffrey C. Ollie wrote:
Another option to look into for configuration management:
Looks interesting, I'd go ahead and put it into extras so we can play with it, unless you want to do so? In the latter case I can do the review.
On Tue, 2006-12-19 at 14:14 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 10:23:31PM -0600, Jeffrey C. Ollie wrote:
Another option to look into for configuration management:
Looks interesting, I'd go ahead and put it into extras so we can play with it, unless you want to do so? In the latter case I can do the review.
I've begun to package it up, since it looks useful in for my work as well. There's at least one dependency that isn't in FE yet so I'm working on packaging that as well. I'll try and get the review requests up later today.
Jeff
Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 14:14 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 10:23:31PM -0600, Jeffrey C. Ollie wrote:
Another option to look into for configuration management:
Has anyone looked at puppet? http://reductivelabs.com/projects/puppet/
It's in Extras.
Or cfengine for that matter, though I'm getting dissatisfied with it myself.
On Tue, 2006-12-19 at 08:58 -0700, Orion Poplawski wrote:
Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 14:14 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 10:23:31PM -0600, Jeffrey C. Ollie wrote:
Another option to look into for configuration management:
Has anyone looked at puppet? http://reductivelabs.com/projects/puppet/
I haven't looked at Puppet in depth, but one con is that it's written in Ruby (not that there's anything wrong with that). But there may be license issues with bcfg2 so that may be an option as well.
Or cfengine for that matter, though I'm getting dissatisfied with it myself.
I haven't looked at cfengine yet either, but from what I've seen it's cryptic configuration is a major con.
Jeff
On Tue, 2006-12-19 at 10:15 -0600, Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 08:58 -0700, Orion Poplawski wrote:
Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 14:14 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 10:23:31PM -0600, Jeffrey C. Ollie wrote:
Another option to look into for configuration management:
Has anyone looked at puppet? http://reductivelabs.com/projects/puppet/
I haven't looked at Puppet in depth, but one con is that it's written in Ruby (not that there's anything wrong with that). But there may be license issues with bcfg2 so that may be an option as well.
skvidal was able to articulate a good reason to not use ruby for the config stack: Anytime we add an interpreted language to the dependencies we need to get a system up and running we're adding another language stack we need to confirm works with our setup before performing an upgrade.
That aside, I think the stateless people have been using puppet and generally like it.
-Toshio
On Tue, 2006-12-19 at 10:15 -0600, Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 08:58 -0700, Orion Poplawski wrote:
Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 14:14 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 10:23:31PM -0600, Jeffrey C. Ollie wrote:
Another option to look into for configuration management:
Has anyone looked at puppet? http://reductivelabs.com/projects/puppet/
I haven't looked at Puppet in depth, but one con is that it's written in Ruby (not that there's anything wrong with that). But there may be license issues with bcfg2 so that may be an option as well.
Or cfengine for that matter, though I'm getting dissatisfied with it myself.
I haven't looked at cfengine yet either, but from what I've seen it's cryptic configuration is a major con.
What was wrong with glump and friends?
It's simple, no cryptic formatting of files or craziness. The scripting language that runs on the hosts is whatever you want it to be.
-sv
On Tue, Dec 19, 2006 at 12:14:28PM -0500, seth vidal wrote:
On Tue, 2006-12-19 at 10:15 -0600, Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 08:58 -0700, Orion Poplawski wrote:
Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 14:14 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 10:23:31PM -0600, Jeffrey C. Ollie wrote:
Another option to look into for configuration management:
Has anyone looked at puppet? http://reductivelabs.com/projects/puppet/
I haven't looked at Puppet in depth, but one con is that it's written in Ruby (not that there's anything wrong with that). But there may be license issues with bcfg2 so that may be an option as well.
Or cfengine for that matter, though I'm getting dissatisfied with it myself.
I haven't looked at cfengine yet either, but from what I've seen it's cryptic configuration is a major con.
What was wrong with glump and friends?
It's simple, no cryptic formatting of files or craziness. The scripting language that runs on the hosts is whatever you want it to be.
Do you have a URL for glump?
On Tue, 2006-12-19 at 18:15 +0100, Axel Thimm wrote:
Do you have a URL for glump?
http://linux.duke.edu/projects/mini/glump/ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218577
Jeff
On Tue, 2006-12-19 at 18:15 +0100, Axel Thimm wrote:
On Tue, Dec 19, 2006 at 12:14:28PM -0500, seth vidal wrote:
On Tue, 2006-12-19 at 10:15 -0600, Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 08:58 -0700, Orion Poplawski wrote:
Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 14:14 +0100, Axel Thimm wrote:
On Mon, Dec 18, 2006 at 10:23:31PM -0600, Jeffrey C. Ollie wrote: > Another option to look into for configuration management:
Has anyone looked at puppet? http://reductivelabs.com/projects/puppet/
I haven't looked at Puppet in depth, but one con is that it's written in Ruby (not that there's anything wrong with that). But there may be license issues with bcfg2 so that may be an option as well.
Or cfengine for that matter, though I'm getting dissatisfied with it myself.
I haven't looked at cfengine yet either, but from what I've seen it's cryptic configuration is a major con.
What was wrong with glump and friends?
It's simple, no cryptic formatting of files or craziness. The scripting language that runs on the hosts is whatever you want it to be.
Do you have a URL for glump?
http://linux.duke.edu/projects/mini/glump/
and mike posted a note about it in some detail a few weeks, maybe a month, back.
-sv
On Tue, 2006-12-19 at 12:14 -0500, seth vidal wrote:
What was wrong with glump and friends?
It's simple, no cryptic formatting of files or craziness. The scripting language that runs on the hosts is whatever you want it to be.
There's nothing "wrong" with glump. It does an excellent job at what it was designed to do. I think that the issue here is that {cfengine, bcfg2, puppet} were designed to do more that serve out customized versions of config files, like checking ownership/permissions of files, the status of servcies, and whether packages are installed.
We just need to look at the alternatives, figure out which one does what we want it to do, and move on from there. I'm not even sure that we've agreed on what we want a configuration management system to do for us yet.
Personally, I'm going to be using glump to manage the configuration files for my umpteen bazillion wireless access points.
Jeff
On Tue, 2006-12-19 at 11:30 -0600, Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 12:14 -0500, seth vidal wrote:
What was wrong with glump and friends?
It's simple, no cryptic formatting of files or craziness. The scripting language that runs on the hosts is whatever you want it to be.
There's nothing "wrong" with glump. It does an excellent job at what it was designed to do. I think that the issue here is that {cfengine, bcfg2, puppet} were designed to do more that serve out customized versions of config files, like checking ownership/permissions of files, the status of servcies, and whether packages are installed.
So what we do at duke with glump is have it serve out custom versions of cron jobs.
we have a cron job that runs hourly and nightly that requests its jobs via glump.
glump puts together the shell script for that host and hands it back.
so if we want to check ownerships or update packages it would be:
chown user.group /path/to/file yum -d0 -e0 -y install your_pkg_set
That's why we don't need the other features, we implement them within what glump can do.
-sv
On Tue, 2006-12-19 at 12:43 -0500, seth vidal wrote:
On Tue, 2006-12-19 at 11:30 -0600, Jeffrey C. Ollie wrote:
On Tue, 2006-12-19 at 12:14 -0500, seth vidal wrote:
What was wrong with glump and friends?
It's simple, no cryptic formatting of files or craziness. The scripting language that runs on the hosts is whatever you want it to be.
There's nothing "wrong" with glump. It does an excellent job at what it was designed to do. I think that the issue here is that {cfengine, bcfg2, puppet} were designed to do more that serve out customized versions of config files, like checking ownership/permissions of files, the status of servcies, and whether packages are installed.
So what we do at duke with glump is have it serve out custom versions of cron jobs.
Correct me if I am wrong, but my impression is that glump is mostly a template-expansion tool with a custom language expressed in XML. The two most important features that full-blown config mgmt tools add to that are * direct control over individual entries in database-like config files (like /etc/hosts, /etc/passwd etc.) * flexible grouping of config settings that is flexible enough to express variations with little effort
we have a cron job that runs hourly and nightly that requests its jobs via glump.
glump puts together the shell script for that host and hands it back.
How do you handle security ? E.g., how do you keep host A getting its hands on the config for host B ? That is important when you manage security-sensitive parts of a machine's config with the tool.
so if we want to check ownerships or update packages it would be:
chown user.group /path/to/file yum -d0 -e0 -y install your_pkg_set
How do you deal with failures ? Logging ? Do you know whether the chown actually changed anything ? (Which might be cause for concern) ?
That's why we don't need the other features, we implement them within what glump can do.
Don't get me wrong - glump might be the right tool for the Fedora infrastructure, but you should be conscious about the issues it does _not_ address compared to a full-fledged config mgmt tool.
David
On Tue, 2006-12-19 at 14:45 -0800, David Lutterkort wrote:
Correct me if I am wrong, but my impression is that glump is mostly a template-expansion tool with a custom language expressed in XML. The two most important features that full-blown config mgmt tools add to that are * direct control over individual entries in database-like config files (like /etc/hosts, /etc/passwd etc.) * flexible grouping of config settings that is flexible enough to express variations with little effort
Which we cover in the set of scripts (just shell scripts) that I sent along with our glump configs to mike mcgrath when he was looking at it.
we have a cron job that runs hourly and nightly that requests its jobs via glump.
glump puts together the shell script for that host and hands it back.
How do you handle security ? E.g., how do you keep host A getting its hands on the config for host B ? That is important when you manage security-sensitive parts of a machine's config with the tool.
Not terribly important when all the machines are managed by the same people.
so if we want to check ownerships or update packages it would be:
chown user.group /path/to/file yum -d0 -e0 -y install your_pkg_set
How do you deal with failures ? Logging ? Do you know whether the chown actually changed anything ? (Which might be cause for concern) ?
That's up to how you want to write the shell script. If you need that level of caution, do so. If you don't, don't. You can report via logging or alerts, pretty much whatever function you want to run in your shell script.
The point is you're not learning a new set of skills and a new layout of things to get the job done. You're just extending the skills you already have. Glump just lets you deploy them in a logical sets to lots of various systems.
Don't get me wrong - glump might be the right tool for the Fedora infrastructure, but you should be conscious about the issues it does _not_ address compared to a full-fledged config mgmt tool.
glump isn't trying to be everything for everyone. It's just a very straightforward mechanism for keeping track of systems. copyfile and other such tools are just an easy way of deploying file updates for them.
my concerns about puppet are the new language for things:
class passwordsync { # remotefile is syntactic sugar - see the defintion in the docs remotefile { "/etc/passwd": server => 'server', source => 'passwd', } }
and of course the concern I issued before is that it ties us into yet another scripting language for systems-maintenance tasks.
-sv
On Wed, 2006-12-20 at 02:07 -0500, seth vidal wrote:
On Tue, 2006-12-19 at 14:45 -0800, David Lutterkort wrote:
Correct me if I am wrong, but my impression is that glump is mostly a template-expansion tool with a custom language expressed in XML. The two most important features that full-blown config mgmt tools add to that are * direct control over individual entries in database-like config files (like /etc/hosts, /etc/passwd etc.) * flexible grouping of config settings that is flexible enough to express variations with little effort
Which we cover in the set of scripts (just shell scripts) that I sent along with our glump configs to mike mcgrath when he was looking at it.
So it's not just glump, but also a whole bunch of custom shell scripts that effectively implement (part of) the functionality of a config mgmt tool without calling it that ? How are bugs getting addressed in this model ? Are the Duke and the Fedora Infrastructure deployments effectively forks of the same thing ?
How do you handle security ? E.g., how do you keep host A getting its hands on the config for host B ? That is important when you manage security-sensitive parts of a machine's config with the tool.
Not terribly important when all the machines are managed by the same people.
What happens when one of the machines gets compromised ? How much easy access does the config mgmt tool give you when you break into one machine ? For example, can you use that to get your hands on ssh keys for another machine ?
The point is you're not learning a new set of skills and a new layout of things to get the job done. You're just extending the skills you already have. Glump just lets you deploy them in a logical sets to lots of various systems.
It sounds to me that instead of reading a few webpages about your config mgmt tool of choice, you have to read and understand a bunch of shell scripts and/or shell libraries (assuming common concerns like logging are addressed by those scripts); you're just trading one kind of learning with another.
glump isn't trying to be everything for everyone.
It's more an issue that if you try to centrally manage configs for machines you quickly run into most of the issues a tool like puppet addresses; from what you've been saying, glump definitely had to address a lot of them.
It's just a very straightforward mechanism for keeping track of systems.
I can't really judge that without having seen the shell scripts that are necessary to make glump more than a template-expansion mechanism. What bothers me about the whole config mgmt space is that even though lots of people encounter those problems, and even though config mgmt is an important problem in practice, there's no tools that are commonly used for it. That's partially because the incumbent (cfengine) falls short on many fronts, and partially because it's so easy to get started with sth really simple and site-specific like glump w/o supporting shell scripts. By the time you realize that your own tool has to address a lot of the harder problems that tools like puppet wrestle with it's too late since migrating to another tool has become a major task.
I've spent quite some time looking for a good config mgmt system, and IMHO, puppet is by far the most promising of the lot (including bcfg2).
I'd much rather Fedora settled on a relatively widespread and mature tool and worked with its community to address whatever shortcomigns it has than go off and do another custom config tool; and in my experience, puppet is pretty easy to learn and work with (and I am willing to put money where my mouth is if somebody could point me to what kind of prototype setup would help them understand better what puppet is and isn't)
my concerns about puppet are the new language for things:
class passwordsync { # remotefile is syntactic sugar - see the defintion in the docs remotefile { "/etc/passwd": server => 'server', source => 'passwd', } }
True, it has its own language, though the language is straightforard and simple: http://reductivelabs.com/projects/puppet/documentation/languagetutorial.html As to why it has its own language: check question four on the FAQ (http://reductivelabs.com/projects/puppet/faq.html)
and of course the concern I issued before is that it ties us into yet another scripting language for systems-maintenance tasks.
What exactly is that saying to people who use the ruby that we ship in Fedora ? I understand that there is some concern that another language might cause upgrade problems, but that's true for _any_ additonal software that is used; upgrade problems aren't restricted to language interpreters. And ruby _is_ a mature language that has been around for a pretty long time, i.e. the ruby interpreter poses as much risk for random breakage as any other package you might want to use to maintain your system.
David
On Wed, Dec 20, 2006 at 11:53:09AM -0800, David Lutterkort wrote:
and of course the concern I issued before is that it ties us into yet another scripting language for systems-maintenance tasks.
What exactly is that saying to people who use the ruby that we ship in Fedora ? I understand that there is some concern that another language might cause upgrade problems
No, that's not the issue Seth addresses (I think), and also no attribute against the quality of ruby as language and implementation.
The question is more like what language are the current and future maintainers of the fedora infrastructure comfortable with and would be able to do some bug hunting, fixing, changes if required. And of course any python solution will have a small bonus here.
On Wed, 2006-12-20 at 21:42 +0100, Axel Thimm wrote:
On Wed, Dec 20, 2006 at 11:53:09AM -0800, David Lutterkort wrote:
and of course the concern I issued before is that it ties us into yet another scripting language for systems-maintenance tasks.
What exactly is that saying to people who use the ruby that we ship in Fedora ? I understand that there is some concern that another language might cause upgrade problems
No, that's not the issue Seth addresses (I think), and also no attribute against the quality of ruby as language and implementation.
The question is more like what language are the current and future maintainers of the fedora infrastructure comfortable with and would be able to do some bug hunting, fixing, changes if required. And of course any python solution will have a small bonus here.
That is understandable (though a little different from the reasons given a few days ago here) - I hope that phear of ruby won't keep people from having a look at puppet and comparing its features to bcfg2.
David
On Wed, 2006-12-20 at 16:44 -0800, David Lutterkort wrote:
On Wed, 2006-12-20 at 21:42 +0100, Axel Thimm wrote:
On Wed, Dec 20, 2006 at 11:53:09AM -0800, David Lutterkort wrote:
and of course the concern I issued before is that it ties us into yet another scripting language for systems-maintenance tasks.
What exactly is that saying to people who use the ruby that we ship in Fedora ? I understand that there is some concern that another language might cause upgrade problems
No, that's not the issue Seth addresses (I think), and also no attribute against the quality of ruby as language and implementation.
The question is more like what language are the current and future maintainers of the fedora infrastructure comfortable with and would be able to do some bug hunting, fixing, changes if required. And of course any python solution will have a small bonus here.
That is understandable (though a little different from the reasons given a few days ago here) - I hope that phear of ruby won't keep people from having a look at puppet and comparing its features to bcfg2.
it's not a fear of ruby at all. it's a fear of eventually having admin tools that require specific versions of:
python bash ruby java php perl etc etc etc
and not being able to more flexibly deploy applications that need to run on those systems.
-sv
On 12/20/06, seth vidal skvidal@linux.duke.edu wrote:
On Wed, 2006-12-20 at 16:44 -0800, David Lutterkort wrote:
On Wed, 2006-12-20 at 21:42 +0100, Axel Thimm wrote:
On Wed, Dec 20, 2006 at 11:53:09AM -0800, David Lutterkort wrote:
it's not a fear of ruby at all. it's a fear of eventually having admin tools that require specific versions of:
python bash ruby java php perl
That has been my biggest fear of deploying puppet myself. I wish I had the skill to make a 'portage' of it to python as its meta language is what I want in a system.
On Wed, 2006-12-20 at 11:53 -0800, David Lutterkort wrote:
So it's not just glump, but also a whole bunch of custom shell scripts that effectively implement (part of) the functionality of a config mgmt tool without calling it that ?
It's a bunch of shell scripts. Learning a new language that you will never use somewhere else is the problem I'm citing with items like puppet and cfengine.
Furthering the already existent shell scripting skills that most sysadmins already have is what I was talking about.
How are bugs getting addressed in this model ? Are the Duke and the Fedora Infrastructure deployments effectively forks of the same thing ?
That really depends on what we want to do.
What happens when one of the machines gets compromised ? How much easy access does the config mgmt tool give you when you break into one machine ? For example, can you use that to get your hands on ssh keys for another machine ?
I don't deploy ssh keys that way. It's a chicken-and-egg problem. You have to have a special key in order to get a special key, so how do you get the first special key?
It sounds to me that instead of reading a few webpages about your config mgmt tool of choice, you have to read and understand a bunch of shell scripts and/or shell libraries (assuming common concerns like logging are addressed by those scripts); you're just trading one kind of learning with another.
not really. You're extending your knowledge that already exists (every sysadmin is implicitly capable of moderate to advanced shell scripting) rather than capturing a specialized knowledge set for a single use.
glump isn't trying to be everything for everyone.
It's more an issue that if you try to centrally manage configs for machines you quickly run into most of the issues a tool like puppet addresses; from what you've been saying, glump definitely had to address a lot of them.
and we've addressed a lot of them.
True, it has its own language, though the language is straightforard and simple: http://reductivelabs.com/projects/puppet/documentation/languagetutorial.html As to why it has its own language: check question four on the FAQ (http://reductivelabs.com/projects/puppet/faq.html)
This is just it. I don't care to learn another one-off language. There are enough of those as it is.
What exactly is that saying to people who use the ruby that we ship in Fedora ? I understand that there is some concern that another language might cause upgrade problems, but that's true for _any_ additonal software that is used; upgrade problems aren't restricted to language interpreters. And ruby _is_ a mature language that has been around for a pretty long time, i.e. the ruby interpreter poses as much risk for random breakage as any other package you might want to use to maintain your system.
I'm not bad-mouthing ruby. This doesn't have to do with it being ruby. Right now in order to maintain a system running for admin tasks we require:
python - stay consistent and reliable for yum and friends bash - stay consistent and reliable for all the init scripts, etc
If we start tying down ruby or any other language as we move along we end up having more and more pieces of the OS that we cannot deploy new versions of w/o fear of breaking our administrative infrastructure.
So if puppet needs a version of ruby or some number of gems in order to run, but we want to have a ruby install for rails that needs a different version then we have to screw around with multiple version installs of ruby and keep up with those installs for security patching.
That's what I mean. I'd like to keep our administrative language requirements to a minimum. Since anaconda, yum and most of the system-config-* tools are in python, it makes since to tie down python for administrative uses, but if we keep adding components in more languages we end up with progressively more problems.
it has nothing to do with the language itself, just the proliferation of ones we rely on for admin tools.
-sv
This has gone way longer than I wanted to; just to make sure: the main points I was trying to make was (1) for Fedora infrastructure there should be a very good understanding how complex things need to be and (2) that the choice of tool should be based on matching those needs to the features of the tools available.
A couple comments to Seth's post:
On Thu, 2006-12-21 at 01:37 -0500, seth vidal wrote:
On Wed, 2006-12-20 at 11:53 -0800, David Lutterkort wrote:
So it's not just glump, but also a whole bunch of custom shell scripts that effectively implement (part of) the functionality of a config mgmt tool without calling it that ?
It's a bunch of shell scripts. Learning a new language that you will never use somewhere else is the problem I'm citing with items like puppet and cfengine.
Like everythign else, it's a tradeoff; there are problems for which domain-specific languages are appropriate and others for which they aren't. It's a matter of degrees, and what you have to invest in learning a new language you hopefully gain in clarity, abstraction, security etc. At the same time, puppet's (and even more so cfengine's) language are very simple and by design very restricted in what you can and can't do.
What happens when one of the machines gets compromised ? How much easy access does the config mgmt tool give you when you break into one machine ? For example, can you use that to get your hands on ssh keys for another machine ?
I don't deploy ssh keys that way. It's a chicken-and-egg problem. You have to have a special key in order to get a special key, so how do you get the first special key?
You didn't really answer how you deal with security breeches.
As for ssh keys: they are (by design) not very useful for establishing trust in a setting with a central authority. SSL (X509, really) certs are much better for that, and the way you do that is by giving each client it's own cert; you still have the issue of how to get that cert onto the client initially, and the answer depends on your level of paranoia - a very paranoid solution would be to generate the signed cert and private key on a USB stick, carry it to the client and clean out the USB stick after copying the keypair onto the client.
Basing trust on SSL certs buys you at least two things over ssh keys: (1) trust is ultimately derived from the fact that the certs are signed by the central authority, (2) certs can be revoked individually and centrally if they should be compromised.
With certs in place, you can send ssh keys securely from your central server to each client, and _know_ that you are really talking to the right guy.
The reason ssh keys even come up is that if you have to rebuild a machine you would usually want it to keep its host keys so that you don't have
I'm not bad-mouthing ruby. This doesn't have to do with it being ruby. Right now in order to maintain a system running for admin tasks we require:
python - stay consistent and reliable for yum and friends bash - stay consistent and reliable for all the init scripts, etc
And, in reality also perl; at least on my system, 'yum erase perl' wants to uninstall stuff like bind, php(!), postfix, psutils, a number of system-config- things, samba, squid, subversion, and, worst of all, gaim.
If we start tying down ruby or any other language as we move along we end up having more and more pieces of the OS that we cannot deploy new versions of w/o fear of breaking our administrative infrastructure.
There are many ways to break a system on upgrade or otherwise, and the tools around a specific language are pretty low on that list. From your experience with yum, how much breakage is caused by python bugs, how much by bugs in components that yum relies on, how much by bugs in yum itself and how much by user error ? I would assume the lion's share of these problems, as with any tool, is bugs in the tool itself. Actually, I assume user error is the biggest cuase here; and some user errors definitely fall into teh category of user interface bugs of the tool.
So if puppet needs a version of ruby or some number of gems in order to run, but we want to have a ruby install for rails that needs a different version then we have to screw around with multiple version installs of ruby and keep up with those installs for security patching.
How does that have anything to do with implementation language ? This exact same argument works for any sizeable component, and it's a danger everytime more than one important tool relies on that component. You could rewrite the above paragraph and turn it into an argument why yum shouldn't use sqlite or expat.
BTW, puppet's requirements are by design very simple, especially for the client: ruby and facter, a ruby library developed in concert with puppet (which could really be bundled with puppet) And I would not even look at a config management tool that wants rails on the client ;)
That's what I mean. I'd like to keep our administrative language requirements to a minimum. Since anaconda, yum and most of the system-config-* tools are in python, it makes since to tie down python for administrative uses, but if we keep adding components in more languages we end up with progressively more problems.
Again, that argument is only valid if there's some evidence that language-related problems are a significant part of the overall problems a sysadmin encounters. And you need to contrast that with the problems that are caused by choosing an inadequate tool - or worse, no tool - for the wrong reasons. I hope we can all agree that for config management there is a lot of room for improvement in any which way.
Clearly, adding another language is of some concern, but I think it's far from the most important issue to look at; things like functionality, match of the features to what's needed, viability of the tool's community, development method (are bugs fixed responsively? patches accepted? are there automated tests?) etc. deserve serious attention.
David
On Thu, Dec 21, 2006 at 03:22:01PM -0800, David Lutterkort wrote:
From your experience with yum, how much breakage is caused by python bugs, how much by bugs in components that yum relies on, how much by bugs in yum itself and how much by user error ? I would assume the lion's share of these problems, as with any tool, is bugs in the tool itself.
That's an argument in favour of a tool written in a language everyone around here is comfortable with, or not?
Anyway I think we should start looking at the tools themselves and consider more parameters than the mere language they are written in. A healthy developer and user community is probably more important, as well as usability and scalability to more complex setups.
On Dec 21, 2006, at 7:37, seth vidal wrote:
If we start tying down ruby or any other language as we move along we end up having more and more pieces of the OS that we cannot deploy new versions of w/o fear of breaking our administrative infrastructure.
I'm sorry, that's just FUD.
Generally: There are lots of components that, if you were truly paranoid, you couldn't upgrade without fear of breaking any sort of mildly complex infrastructure anyway. Yet most of us go along alright with frequent-ish "yum upgrade" or (of course) "up2date -u".
More specifically: I don't know the change history of python well, but with for instance perl then any sort of breakage is extremely rare. Maybe I have selective memory, but I don't recall any actually. You should see the lengths they go to to preserve obscure side-effects of bugs and undocumented "features" as they still rapidly are developing and enhancing perl 5.
I've only been using Ruby casually for a few years, but I haven't gotten the impression that it's much different in the Ruby community.
As someone else pointed out: It's really not reasonable to say "oh, we don't trust we won't break our own packages so let's not use them". Dog food and all. In particular not if the worst case scenario is to login to each box manually to downgrade a bad RPM to get the administration infrastructure going again.
Your other argument: "Few here programs in Ruby and critically depending on something we can't fix sucks" is much much better. :-)
As a, future, counter argument then the stateless guys are planning to use puppet as a part of that system. If so then there's a good chance it'll be very well integrated with Fedora and RHEL.
- ask
On Fri, 2006-12-22 at 01:13 +0100, Ask Bjørn Hansen wrote:
On Dec 21, 2006, at 7:37, seth vidal wrote:
If we start tying down ruby or any other language as we move along we end up having more and more pieces of the OS that we cannot deploy new versions of w/o fear of breaking our administrative infrastructure.
I'm sorry, that's just FUD.
You're using FUD like it is its own thing. Fear Uncertainty and Doubt are things that a sysadmin must weigh when evaluating tools.
As someone else pointed out: It's really not reasonable to say "oh, we don't trust we won't break our own packages so let's not use them". Dog food and all. In particular not if the worst case scenario is to login to each box manually to downgrade a bad RPM to get the administration infrastructure going again.
If you can login.
But let's be clear, I don't really care enough about this argument to continue it. If y'all want to use puppet, do so or something.
-sv
On Tue, 2006-12-19 at 12:14 -0500, seth vidal wrote:
What was wrong with glump and friends?
It's simple, no cryptic formatting of files or craziness. The scripting language that runs on the hosts is whatever you want it to be.
To my untrained eye, the glue.xml looks very much like its own language (sure, a simple one, but just because it's XML doesn't mean that it's not its own language.
David
On Tue, 2006-12-19 at 14:52 -0800, David Lutterkort wrote:
On Tue, 2006-12-19 at 12:14 -0500, seth vidal wrote:
What was wrong with glump and friends?
It's simple, no cryptic formatting of files or craziness. The scripting language that runs on the hosts is whatever you want it to be.
To my untrained eye, the glue.xml looks very much like its own language (sure, a simple one, but just because it's XML doesn't mean that it's not its own language.
In comparison to cfengine it is not it's own language.
it's a file format, sure, but I wouldn't call it a language.
That's all the comparison I was making.
-sv
infrastructure@lists.fedoraproject.org
-
Ask Bjørn Hansen -
Axel Thimm -
David Lutterkort -
Jeffrey Ollie -
Orion Poplawski -
seth vidal -
Stephen John Smoogen -
Toshio Kuratomi