--=-0uQkNJQzolsX4XkvG6de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mardi 24 juin 2014 =C3=A0 09:59 +0200, Ewoud Kohl van Wijngaarden a =C3=A9crit :
On Mon, Jun 23, 2014 at 06:02:51PM +0200, Michael Scherer wrote:
Le lundi 23 juin 2014 =C3=A0 16:42 +0200, Ewoud Kohl van Wijngaarden a =C3=A9crit :
On Mon, Jun 23, 2014 at 04:30:55PM +0200, Michael Scherer wrote:
( https://github.com/adrienthebo/r10k ) , it requires use to have t= he modules/ directory to be managed by librarian-puppet. In turn we ne= ed to have the modules in git, we can address them by path:=20 =20 mod "puppetlabs/apt", :git =3D> "git://github.com/fake/puppet-modules.git", :path =3D> "modules/apt" =20 =20 This wouldn't requires to change much, besides adding the module to= Puppetfile and creating a git repository. =20 If no one disagree, I will request the git repository. =20 ( in the mean time, i did create a sample awstats repository for st= ats.ovirt.org, so we can have something to push ) =20 Unless we plan to make them reusable for other projects, I don't see = the benefit. If we do plan to make them reusable, we should IMHO also publish them on the forge. =20 Another potential issue is how we decide when to deploy. We could hav= e a specific commit ID and update our Puppetfile every time, but again, little benefit over having them in one tree. =20 I was under the impression you could just give a tag and so use master = ? ( and using branch for development ) =20 You can, but how do we know we want to update and to which version? branches can easily break compatibility and it will bite you at some point.
It depend on the release model of our own modules. We can have a policy of "master should be deployable and forever retro compatible" but once expressed like this, it doesn't sound sustainable (even if that's what we would do with a single git repository ).=20
In case you're unaware, we already load modules/* (which is managed b= y r10k) and site/* (tracked in git). That means we can host our modules= in site and spit off when they are reusable. =20 It was not very obvious that site/* was for modules, indeed :) =20 But my fault, I should also have read the doc in the git repository who clearly say that. =20 I must also say that using r10k for different environments seems a bit overkill, as we seem to only have 1 single environment anyway ( but I a= m not using r10k usually, as I do not have enough systems for that and write all stuff myself ).=20 =20 The alternative is either include them or git submodules. I'm not a fan of the former and I've seen people have issues with the latter where people accidentally commit an older version. It's also hard to spot in reviews because you only see two git commit IDs with no idea if it's an upgrade or downgrade. That's why a Puppetfile-based solution was chosen.
I am not fan of git submodule either. But the Puppetfile file part is good, it just the multiple env that I found weird. Now, if that's unavoidable, no problem.
Minor nitpick: technically we have 2 environments and we should make an effort to remove master. This is done by changing the default branch to production and then remove master. The only way I know is logging into gerrit through SSH and changing infra-puppet.git/HEAD to point to production instead of master. Then you can use the gerrit UI to delete the master branch.
As we discussed on IRC later, I would be +1 for this, provided that this doesn't break too much assumption in docs ( especially gerrit doc around ). But as we discussed too, maybe we should just push to use git-review.
And if we do plan on creating modules repos, I'd be in favor of havin= g one git repo per puppet module since that is what most people would expect. =20 One git repo per module is a bit annoying when we are planning to write a lot of modules. But I guess it all depend on the time it take to create one. I would definitely prefer a approach of 1 big git as long a= s we are "growing" fast and maybe split later, since it permit faster growth ? =20 That's exactly what I was thinking.
This also bring the question of using external module vs using our own. I am more the kind of guy that write his own (while I am not the kind of guy who write his own code), mostly because I started to use puppet before the forge was up, and because I did have very precise ideas on what I wanted to achieve, but I am not against using stuff if that's the best practices :) I would however make sure we have proper guidelines on when we take a module, as I am not sure they are all equally good :/ --=20 Michael Scherer Open Source and Standards, Sysadmin --=-0uQkNJQzolsX4XkvG6de Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJTqfJBAAoJEE89Wa+PrSK98pUQAJfpr4bpjL+fV7f2F/PE9eXd ZXpeO4pih2AkfKmppIRo7Icc+UZkz4rD92fm7G1WjW/0eLQQrCtFDKWPhiDBq26z 7qjvIAqOP5nH/cc/0alS7b6B6HRGOzvlmoTeOJG7MhhoV3fKrtBDAZkefWL2QDAI Fvss7v1scSMSyVUpD//Ats6EKcJXIebGcYEzIqxFwzVe66D6q6ruF6MOVwBUGH/X xclKyqMdNsZy58kRhM30/Ths/G9lio+q6VFfKxDS29T9NhO39SL//FekaLyTeAoi whtNeEJHTq5Dg1RAdPW8hR0n7JOyGfpPUulgq/XQg0qngSnj7xehCu0nnpjw3uvj aDAVD36ocUbx9J6PpCMWcEwtPgIMSN+DsdVT8yTuadfzzPW+eexTb4hNz1mNR2xb sNvxkuS5sz6M/oVs6oVS3BaAXOGJs7ZUJMIlUYNRRj+PM6rpo81OKOqzhlCQF3oO HrC7a7Wsslq7TZWcgJ5kc62choT9WVizIU9kWQOLWJxD4kHxuidryRpN6O4dtjk9 GZQi8aIr/VHGG+xu84gNef4OXCWtG4N2+R6r1pCKiHuWrCcrRg8nQlktW3F2EItu dsg/v9lSkdNDe7pBZHuzM7JGG+EY4IwpR+i0PEeQ8Q/WM0Wq5IQBARD7YgNCOrWf K6RwXhpb+JWZX4U58C2s =MU7c -----END PGP SIGNATURE----- --=-0uQkNJQzolsX4XkvG6de--