diff options
Diffstat (limited to 'zarb-ml/mageia-sysadm/2011-March/003220.html')
| -rw-r--r-- | zarb-ml/mageia-sysadm/2011-March/003220.html | 205 |
1 files changed, 205 insertions, 0 deletions
diff --git a/zarb-ml/mageia-sysadm/2011-March/003220.html b/zarb-ml/mageia-sysadm/2011-March/003220.html new file mode 100644 index 000000000..33202c23c --- /dev/null +++ b/zarb-ml/mageia-sysadm/2011-March/003220.html @@ -0,0 +1,205 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-sysadm] Packaging puppet modules + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20Packaging%20puppet%20modules&In-Reply-To=%3C1301497269.10310.79.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="003200.html"> + <LINK REL="Next" HREF="003221.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-sysadm] Packaging puppet modules</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-sysadm%40mageia.org?Subject=Re%3A%20%5BMageia-sysadm%5D%20Packaging%20puppet%20modules&In-Reply-To=%3C1301497269.10310.79.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-sysadm] Packaging puppet modules">misc at zarb.org + </A><BR> + <I>Wed Mar 30 17:01:09 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="003200.html">[Mageia-sysadm] Packaging puppet modules +</A></li> + <LI>Next message: <A HREF="003221.html">[Mageia-sysadm] Packaging puppet modules +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#3220">[ date ]</a> + <a href="thread.html#3220">[ thread ]</a> + <a href="subject.html#3220">[ subject ]</a> + <a href="author.html#3220">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le vendredi 25 mars 2011 à 19:47 +0100, nicolas vigier a écrit : +><i> On Fri, 25 Mar 2011, Buchan Milne wrote: +</I>><i> +</I>><i> > +</I>><i> > ----- "nicolas vigier" <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-sysadm">boklm at mars-attacks.org</A>> wrote: +</I> +><i> > +</I>><i> > > I usually have the following problems : +</I>><i> > > - modules are made for other distributions +</I>><i> > > - modules have dependencies on other modules, and it is not easy to +</I>><i> > > see +</I>><i> > > which ones +</I>><i> > +</I>><i> > And puppet-module (<A HREF="https://github.com/puppetlabs/puppet-module-tool">https://github.com/puppetlabs/puppet-module-tool</A>) isn't able to resolve them? +</I>><i> +</I>><i> Oh, I didn't use this tool, I was only cloning modules git repositories. +</I>><i> Indeed it supports dependencies between modules. However it seems modules +</I>><i> developers need to list them manually. +</I> +First step, let's do a package of that. + +><i> > Well, the first question is, is servers a target use case of Mageia? +</I>><i> +</I>><i> I don't know if target use cases have been defined yet. But it can +</I>><i> probably be a target, if enough people want to work on this. +</I> +Personally, I would be interested ( and slightly more in this space than +on the desktop side ). + +><i> > If so, should we not rather draw up requirements for all the requirements +</I>><i> > for increasing the efficiency of managing Mageia servers? Possibly draw up +</I>><i> > reference architectures for different types of deployments? +</I>><i> +</I>><i> Yes, that's a good idea. +</I> +I think usage of puppet directly in the distribution was something that +as discussed by Ubuntu Server Team. Not sure it went far. + +><i> > +</I>><i> > > We could do something like this : +</I>><i> > > - one package per module +</I>><i> > > - modules installed in /usr/share/puppet/modules +</I>><i> > > - use rpm find-requires and find-provides to automatically manage +</I>><i> > > dependencies between modules +</I>><i> > > - remove any hardcoded values from modules, but use parameterised +</I>><i> > > classes, so you don't have to modify modules to use them +</I>><i> > > - setup puppet so that someone who wants to overwrite a module +</I>><i> > > installed +</I>><i> > > by a package can create one with the same name in +</I>><i> > > /etc/puppet/modules. +</I>><i> > > Or overwrite one template file. +</I>><i> > +</I>><i> > +1 +</I>><i> > +</I>><i> > However, we may need to review what modules we would need, improve any of +</I>><i> > the ones we have developed (e.g. my Xymon one probably needs quite a +</I>><i> > bit of work). +</I>><i> +</I>><i> Yes. Maybe we should also define some policies about how modules should +</I>><i> be written to allow packaging / standardized parameters. +</I> +We also have done some choices that are not easy to change : + +- mostly postgresql rather than mysql ( with a high integration like +remote database setup and more to come ( I plan to be able to manage the +initial sql setup with it ) + +- web applications are on application.example.org rather than +www.example.org/application/ + +- fastcgi to cope with the fact we have lots of interpreter rather than +using only ruby, python or perl + +- highly dependent on the ldap and on the group structure ( ie, there is +group policy everywhere and this can be quite hard to abstract ) + +- the domain name of web application are everywhere ( could be +abstracted like password however ) + +The repository is quite free of mageia.org reference, hopefully. + +><i> > > Those module could also be used locally by some tools. For instance +</I>><i> > > if +</I>><i> > > we want to create a graphical tool like drakwizard, to setup some +</I>><i> > > software +</I>><i> > > on a machine. This graphical interface would ask some parameters, +</I>><i> > > then +</I>><i> > > install the corresponding puppet modules, generate a puppet file +</I>><i> > > containing the parameters entered and run puppet on it locally. +</I>><i> > +</I>><i> > What is the capability of Puppet Dashboard (<A HREF="http://www.puppetlabs.com/puppet/related-projects/dashboard/">http://www.puppetlabs.com/puppet/related-projects/dashboard/</A>) ? +</I>><i> +</I>><i> I never used it, so I don't know. But they mention "classes and parameters +</I>><i> can be applied to nodes directly or inherited from groups". +</I> +That just a web interface, and I fear we would lose the vcs feature if +we use this to manage our server. +On the other hand, this could help on the reporting side. + +And there is also theforeman, that does the same. + +><i> > +</I>><i> > > However compared to what we do currently : +</I>><i> > > - it will be more work, to avoid hardcoding anything +</I>><i> > > - modules can become more complexe if they support more things +</I>><i> > > - we will have to be careful when changing API of released modules, +</I>><i> > > or +</I>><i> > > write it in release notes so users of the packages know what they +</I>><i> > > need +</I>><i> > > to change when updating to a newer release of the distribution. +</I>><i> > +</I>><i> > Well, we may want to upstream modules as well, especially ones that we didn't write from scratch. +</I>><i> +</I>><i> Yes, we can also share them on puppet forge so people using other +</I>><i> distributions can use them. +</I> +Then it would be easier to split our svn into self contained module, +like 1 git/svn/whatever per modules in modules/ + +And one big one with svn:external, git-slave, whatever to keep the +current way of work. + +I do like the idea of sharing them on puppet forge. Not specially for +being reused in all case, but at least to be useful as a reference and +example. Because if we want to be reused, we need to take in account +different package name. I do manage 1 gentoo, 3 mandriva, and 1 fedora +with puppet, and the openssh modules I wrote is full of "if". ( and I +didn't add os x or debian to the mix yet, but for fun I am thinking ). + +><i> > I think we can try and package some modules we use that are well-tested, or any of ours that we believe are of sufficient quality now. +</I>><i> > +</I>><i> > But, while some of the contributors on this list may want to contribute to such a project, maybe it +</I>><i> > would be better to have a separate team/project/special interest group looking at the requirements/features +</I>><i> > for a server release. And, I think mandating puppet for this would be premature (from a design perspective), +</I>><i> > as there may be other better architectures/tools (e.g. Chef?). +</I>><i> +</I>><i> Yes, that should be a separate team/project. I posted this on sysadmin +</I>><i> list because I think that's where most interested people are, but +</I>><i> anybody using Mageia could be interested to participate. +</I>><i> +</I>><i> And Chef should also be considered. +</I> +The first step would be to package chef, but I am far from being happy +when instruction start by "use gem install". +( for the record, I also considered looking at bcfg2 ). + +-- +Michael Scherer + +</PRE> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="003200.html">[Mageia-sysadm] Packaging puppet modules +</A></li> + <LI>Next message: <A HREF="003221.html">[Mageia-sysadm] Packaging puppet modules +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#3220">[ date ]</a> + <a href="thread.html#3220">[ thread ]</a> + <a href="subject.html#3220">[ subject ]</a> + <a href="author.html#3220">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-sysadm">More information about the Mageia-sysadm +mailing list</a><br> +</body></html> |