Hi,
[First, a quick introduction... I''m one of the sysadmins at
Koumbit.org,
and we''re evaluating puppet for managing our modest server farm.
I''ve
already started writing recipes and manifests and intend to share those
with this community. Part of my time worked on this will be directly
paid by Koumbit.]
So we''ve got a few half-finished puppet modules here:
https://hg.koumbit.net/puppet-modules/file/tip
I''m sure a lot of people here also have their own little (or big)
versionned repository of manifests.
The problem I see now is that we''re starting to have a *lot* of those
little (and big) repositories everywhere. No coordination, lots of
duplicated efforts (for example, I know I''m not the only one working on
network configuration abstractions...), my crucial question now is: how
to avoid wasting efforts?
The wiki is nice and all, but for sharing recipes, it sucks, with all
due respect: there''s no way to branch off the recipes there and deploy
them easily on our own nodes. So for me the wiki''s out, unless as a
temporary solution for documenting the known modules repositories (is
there a page for that yet?)
What I think we should have is a common "module forge" or some place
where people can push their modules. That doesn''t have to be on
reductive lab''s Trac (but it can be!!) and it sure could use a broader
comitters community than the Puppet core. I would very well see a
distinction here, the way a lot of open source project proceed, between
"contributed" (e.g. modules) and "core" stuff (ie. the
puppet ruby core).
At the very least, let''s start by documenting explicitely all the
public repositories out there. I created a ModuleRepositories page,
where I added my repo and David Schmitt''s (because those are the only
ones I reliably know of right now, feel free to add yours!).
But I think we should seriously think about how to scale this further..
Other wild idea: What about namespace clashes? How many puppet modules
named "common" do we have out there!? How can we deal with this?
Thanks for comments,
PS: I dug through the archive to find such a discussion and couldn''t
find anything, sorry if this was already beaten to death before.
--
We are discreet sheep; we wait to see how the drove is going, and then go
with the drove.
- Mark Twain
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
After a discussion with David on IRC, I think that the ModuleRepositories page is actually a bad idea and will only discourage collaboration, so we''re removing it. David is writing a better summary of that enlightening discussion. A. -- The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. - Douglas Adams (1952-2001) _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Sunday 25 November 2007, The Anarcat wrote:> Hi, > > [First, a quick introduction... I''m one of the sysadmins at Koumbit.org, > and we''re evaluating puppet for managing our modest server farm. I''ve > already started writing recipes and manifests and intend to share those > with this community. Part of my time worked on this will be directly > paid by Koumbit.] > > So we''ve got a few half-finished puppet modules here: > > https://hg.koumbit.net/puppet-modules/file/tip[lotsa good points snipped]> But I think we should seriously think about how to scale this further..After a short but good discussion on IRC (see attachment) anarcat and I have decided to try to push my modules the final step to generic goodness. Tomorrow I''ll split off my site-specific parts into a seperate repo and make a "alpha-release" of what I currently have. I''ll start announcing that I solicite/accept patches (or git pulls) from others to enhance functionality and portability of the modules.> At the very least, let''s start by documenting explicitely all the > public repositories out there. I created a ModuleRepositories page, > where I added my repo and David Schmitt''s (because those are the only > ones I reliably know of right now, feel free to add yours!).As discussed on IRC I deleted this page again. The Common Puppet Modules should be a focus for integrating, not enumerating, the various repositories out there. I''ll probably also rearrange CompleteConfiguration around to be an index into the modules and have some docs + usage examples. Input on how people can use such a central (git) repo in the wild would be highly appreciated.> Other wild idea: What about namespace clashes? How many puppet modules > named "common" do we have out there!? How can we deal with this?The last time this was brought up, Luke said, he''d be glad to have such problems :) Actually I think the way forward would be to have a "local" module for what people call "common" today and having it contina only like 1% of what''s currently there. Or maintain local changes on top of the "upstream" repository.> Thanks for comments, > > PS: I dug through the archive to find such a discussion and couldn''t > find anything, sorry if this was already beaten to death before.Thank you for bringing this up! Regards, DavidS -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Nov 25, 2007, at 1:31 PM, The Anarcat wrote:> Hi, > > [First, a quick introduction... I''m one of the sysadmins at > Koumbit.org, > and we''re evaluating puppet for managing our modest server farm. I''ve > already started writing recipes and manifests and intend to share > those > with this community. Part of my time worked on this will be directly > paid by Koumbit.]Great.> So we''ve got a few half-finished puppet modules here: > > https://hg.koumbit.net/puppet-modules/file/tip > > I''m sure a lot of people here also have their own little (or big) > versionned repository of manifests. > > The problem I see now is that we''re starting to have a *lot* of those > little (and big) repositories everywhere. No coordination, lots of > duplicated efforts (for example, I know I''m not the only one > working on > network configuration abstractions...), my crucial question now is: > how > to avoid wasting efforts?I agree, this is a problem. I created http://modules.reductivelabs.com with the idea that it would initially just host a copy of others'' module repositories, but my goal for the site is to build a forge-style site where people can publish individual modules and branches of existing modules. Unfortunately, Puppet itself has monopolized all of my time, so I''ve not had time to do the extra bits, and I''ve been hesitant to ask for much help from the community because I''m hoping to find a way to make such a site important to my business and I don''t want people volunteering on false assumptions or whatever.> The wiki is nice and all, but for sharing recipes, it sucks, with all > due respect: there''s no way to branch off the recipes there and deploy > them easily on our own nodes. So for me the wiki''s out, unless as a > temporary solution for documenting the known modules repositories (is > there a page for that yet?)I completely agree.> What I think we should have is a common "module forge" or some place > where people can push their modules. That doesn''t have to be on > reductive lab''s Trac (but it can be!!) and it sure could use a broader > comitters community than the Puppet core. I would very well see a > distinction here, the way a lot of open source project proceed, > between > "contributed" (e.g. modules) and "core" stuff (ie. the puppet ruby > core).Definitely important, since I''ve decided based on recent experience that this is the last release in which I''ll accept code that doesn''t have complete tests, which will cause a lot of code that could go into core to instead be part of contrib.> At the very least, let''s start by documenting explicitely all the > public repositories out there. I created a ModuleRepositories page, > where I added my repo and David Schmitt''s (because those are the only > ones I reliably know of right now, feel free to add yours!).One problem I have with David''s repository -- he and I have already discussed it at length and I don''t have a good solution that gets us both what we want -- is that it doesn''t provide a very good a la carte solution. Most people are going to want to cherry-pick modules, while these collection repositories end up containing lots of modules, making cherry-picking hard. You''re always going to have some kind of problems here, because once the user downloads the module, they have to integrate it into their own module repository, so we need clean paths between external repos and internal repos, which is always going to be a bit difficult.> But I think we should seriously think about how to scale this > further.. > > Other wild idea: What about namespace clashes? How many puppet modules > named "common" do we have out there!? How can we deal with this?As David mentioned, this hasn''t been too much of a problem in the Ruby community, and as long as we somewhat actively maintain it, it shouldn''t get out of hand. I agree, though, that there should be some standard internal namespaces, like ''common'' and ''site''.> PS: I dug through the archive to find such a discussion and couldn''t > find anything, sorry if this was already beaten to death before.I think most of the discussion has been on IRC rather than on the email lists. -- If a dog jumps onto your lap it is because he is fond of you; but if a cat does the same thing it is because your lap is warmer. -- Alfred North Whitehead --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Sun, 2007-11-25 at 16:43 -0600, Luke Kanies wrote:> On Nov 25, 2007, at 1:31 PM, The Anarcat wrote: > > But I think we should seriously think about how to scale this > > further.. > > > > Other wild idea: What about namespace clashes? How many puppet modules > > named "common" do we have out there!? How can we deal with this? > > As David mentioned, this hasn''t been too much of a problem in the > Ruby community, and as long as we somewhat actively maintain it, it > shouldn''t get out of hand. I agree, though, that there should be > some standard internal namespaces, like ''common'' and ''site''.The module spec[1] explicitly says that ''site'' shouldn''t be used for distributed modules. We could easily add more names if that seems needed (of course, that doesn''t address how to tell people that that standard exists) David [1] http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation