Is there a way to tell the puppetmaster that I want to import all modules rather than listing each one individually?
On Tue, 2007-04-10 at 14:53 -0700, Digant C Kasundra wrote:> Is there a way to tell the puppetmaster that I want to import all modules > rather than listing each one individually?No, there isn''t; from a language point of view, it sounds a little dubious to add that in. How many modules do you have ? ;) David
--On Tuesday, April 10, 2007 3:51 PM -0700 David Lutterkort <dlutter@redhat.com> wrote:> On Tue, 2007-04-10 at 14:53 -0700, Digant C Kasundra wrote: >> Is there a way to tell the puppetmaster that I want to import all >> modules rather than listing each one individually? > > No, there isn''t; from a language point of view, it sounds a little > dubious to add that in. How many modules do you have ? ;)37. I don''t want to list each module. I think it makes sense to support a wildcard because if I didn''t want to use a module, I wouldn''t have it in my modules directory. I can understand not wanting to import modules in the sense that when puppet starts distributing modules, I may not want all of them. But I would like my wildcard to work when doing: import "modules/*"
On Apr 10, 2007, at 6:06 PM, Digant C Kasundra wrote:> > > 37. I don''t want to list each module. I think it makes sense to > support a > wildcard because if I didn''t want to use a module, I wouldn''t have > it in my > modules directory. > > I can understand not wanting to import modules in the sense that when > puppet starts distributing modules, I may not want all of them. But I > would like my wildcard to work when doing: > > import "modules/*"It seems like a reasonable thing to want, at least on the server, since you''re unlikely to install modules that you don''t use, although I agree with David that it''s unlikely to make a lot of sense in the long term. I don''t like the ''modules/*'' thing much, but we''re kind of stuck here since we need some sort of keyword to indicate we want all modules, not all things named "modules", and I guess "modules" is as good as any, but it means we''d have to make it a keyword in the import system, meaning that you could never have a module named ''modules'', nor a directory in your manifests directory with that name. -- Today I dialed a wrong number...The other person said, "Hello?" and I said, "Hello, could I speak to Joey?"... They said, "Uh...I don''t think so...he''s only 2 months old." I said, "I''ll wait." -- Steven Wright --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On Monday, April 16, 2007 12:18 PM -0500 Luke Kanies <luke@madstop.com> wrote:> On Apr 10, 2007, at 6:06 PM, Digant C Kasundra wrote: >> >> >> 37. I don''t want to list each module. I think it makes sense to >> support a >> wildcard because if I didn''t want to use a module, I wouldn''t have >> it in my >> modules directory. >> >> I can understand not wanting to import modules in the sense that when >> puppet starts distributing modules, I may not want all of them. But I >> would like my wildcard to work when doing: >> >> import "modules/*" > > It seems like a reasonable thing to want, at least on the server, > since you''re unlikely to install modules that you don''t use, although > I agree with David that it''s unlikely to make a lot of sense in the > long term. > > I don''t like the ''modules/*'' thing much, but we''re kind of stuck here > since we need some sort of keyword to indicate we want all modules, > not all things named "modules", and I guess "modules" is as good as > any, but it means we''d have to make it a keyword in the import > system, meaning that you could never have a module named ''modules'', > nor a directory in your manifests directory with that name.We could go with a different keyword here for importing modules. Or we could use just one folder for modules and symlink the modules we want to use, similar to how Apache modules and sites are enabled on Debian. -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University
On Apr 16, 2007, at 1:27 PM, Digant C Kasundra wrote:> > We could go with a different keyword here for importing modules. > Or we > could use just one folder for modules and symlink the modules we > want to > use, similar to how Apache modules and sites are enabled on Debian.Linking over wouldn''t really work, I think, since I don''t think Puppet looks for ''module/init.pp'' unless it knows it''s looking at a module. Do you specifically want globbing (e.g., would you want to be able to do something like "import ''modules/a*''"), or would it be sufficient to have a keyword in ''import'' that knew how to iterate across all modules? Then you could just do something like ''import all'', and make ''all'' a keyword (or whatever keyword we use, but there are other cases where ''all'' is somewhat useful as a keyword. -- It''s not that I''m afraid to die. I just don''t want to be there when it happens. -- Woody Allen --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On Monday, April 16, 2007 1:46 PM -0500 Luke Kanies <luke@madstop.com> wrote:> On Apr 16, 2007, at 1:27 PM, Digant C Kasundra wrote: >> >> We could go with a different keyword here for importing modules. >> Or we >> could use just one folder for modules and symlink the modules we >> want to >> use, similar to how Apache modules and sites are enabled on Debian. > > Linking over wouldn''t really work, I think, since I don''t think > Puppet looks for ''module/init.pp'' unless it knows it''s looking at a > module. > > Do you specifically want globbing (e.g., would you want to be able to > do something like "import ''modules/a*''"), or would it be sufficient > to have a keyword in ''import'' that knew how to iterate across all > modules? Then you could just do something like ''import all'', and > make ''all'' a keyword (or whatever keyword we use, but there are other > cases where ''all'' is somewhat useful as a keyword. > > -- > It''s not that I''m afraid to die. I just don''t want to be there when it > happens. -- Woody Allen > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-usersImport all would suffice for me. I can imagine some might want globbing, if only by namespace. -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University
On Mon, 2007-04-16 at 12:54 -0700, Digant C Kasundra wrote:> --On Monday, April 16, 2007 1:46 PM -0500 Luke Kanies <luke@madstop.com> > wrote: > > Do you specifically want globbing (e.g., would you want to be able to > > do something like "import ''modules/a*''"), or would it be sufficient > > to have a keyword in ''import'' that knew how to iterate across all > > modules? Then you could just do something like ''import all'', and > > make ''all'' a keyword (or whatever keyword we use, but there are other > > cases where ''all'' is somewhat useful as a keyword. > > Import all would suffice for me. I can imagine some might want globbing, if > only by namespace.Small nit: imports and modules are strictly file-based constructs; as such, you can''t import a namespace, since that''s a language construct. With that, I don''t know how much sense globbing on the module level would make. I assume that a quick way to import all modules is desirable since you usually don''t have manifests and/or modules hanging out on your puppetmaster that aren''t used by at least one node. The biggest problem seems to be what the right syntax for that is; it would be nice if we didn''t need a new keyword for that. Would something like ''import "::"'' be too hideous ? David
--On Monday, April 16, 2007 11:03 PM +0000 David Lutterkort <dlutter@redhat.com> wrote:> With that, I don''t know how much sense globbing on the module level > would make. > > I assume that a quick way to import all modules is desirable since you > usually don''t have manifests and/or modules hanging out on your > puppetmaster that aren''t used by at least one node. The biggest problem > seems to be what the right syntax for that is; it would be nice if we > didn''t need a new keyword for that. Would something like ''import "::"'' > be too hideous ?Or, can puppet just import and valid modules it finds in the modulepath? I think we all concur that you wouldn''t have a module that you weren''t using, and importing it doesn''t mean it becomes part of the catalog anyway so it isn''t harmful. -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University
On Apr 16, 2007, at 7:13 PM, Digant C Kasundra wrote:> > Or, can puppet just import and valid modules it finds in the > modulepath? I > think we all concur that you wouldn''t have a module that you > weren''t using, > and importing it doesn''t mean it becomes part of the catalog anyway > so it > isn''t harmful.Hmm, I like that, but let''s modify it a bit: If you attempt to load a class that Puppet does not have in memory, Puppet will automatically attempt to load a module with the same name. This way, as long as you name your modules appropriately, you shouldn''t need to import any of them; only modules that define classes that have different names (which normally shouldn''t happen, right?) would need to get manually imported. We could do the same thing for definitions, since there''s no way to really know whether a module''s init.pp file defines a definition or a class. Would that give you what you want? Anyone disagree with that? -- There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On Monday, April 16, 2007 7:19 PM -0500 Luke Kanies <luke@madstop.com> wrote:> Hmm, I like that, but let''s modify it a bit: If you attempt to load > a class that Puppet does not have in memory, Puppet will > automatically attempt to load a module with the same name. This > way, as long as you name your modules appropriately, you shouldn''t > need to import any of them; only modules that define classes that > have different names (which normally shouldn''t happen, right?) would > need to get manually imported.Our ssh module defines the ssh class and 4 subclasses that inherit from the ssh class. :-/ -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University
On Apr 16, 2007, at 7:41 PM, Digant C Kasundra wrote:> > Our ssh module defines the ssh class and 4 subclasses that inherit > from the > ssh class. :-/Do you include the top-level class first, and then sometimes the others, or does anyone just include a subclass? We could require the individual modules to load the classes included, and then just automatically load the top-level class. Or, we could attempt to automatically translate classes into files based on name, so if you included ''ssh::whatever'', Puppet would try to load ''ssh/ whatever.pp''. I like this a lot better than iterating over all modules and loading them by default. -- He played the king as if afraid someone else would play the ace. --John Mason Brown --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Apr 16, 2007, at 6:03 PM, David Lutterkort wrote:> Small nit: imports and modules are strictly file-based constructs; as > such, you can''t import a namespace, since that''s a language construct.True, but you could have hooks that tried to import missing classes or namespaces based on convention.> With that, I don''t know how much sense globbing on the module level > would make.I agree; auto-loading by convention seems to make much more sense.> I assume that a quick way to import all modules is desirable since you > usually don''t have manifests and/or modules hanging out on your > puppetmaster that aren''t used by at least one node. The biggest > problem > seems to be what the right syntax for that is; it would be nice if we > didn''t need a new keyword for that. Would something like ''import "::"'' > be too hideous ?What do you think about the autoloading? -- We cannot really love anybody with whom we never laugh. --Agnes Repplier --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On Monday, April 16, 2007 7:45 PM -0500 Luke Kanies <luke@madstop.com> wrote:> On Apr 16, 2007, at 7:41 PM, Digant C Kasundra wrote: >> >> Our ssh module defines the ssh class and 4 subclasses that inherit >> from the >> ssh class. :-/ > > Do you include the top-level class first, and then sometimes the > others, or does anyone just include a subclass? > > We could require the individual modules to load the classes included, > and then just automatically load the top-level class. Or, we could > attempt to automatically translate classes into files based on name, > so if you included ''ssh::whatever'', Puppet would try to load ''ssh/ > whatever.pp''. > > I like this a lot better than iterating over all modules and loading > them by default.Well, I need to review how namespaces work and what the best practice around them will be. Currently, we do sometimes include just the subclass, and I can see that being useful. I do like the idea of doing ssh::whatever (in our case, it would be things like ssh::ssh-global, and then I suppose we''d have a file called ssh-global.pp with the ssh-global class in it).
On Apr 17, 2007, at 2:22 AM, Digant C Kasundra wrote:> > Well, I need to review how namespaces work and what the best practice > around them will be. > > Currently, we do sometimes include just the subclass, and I can see > that > being useful. I do like the idea of doing ssh::whatever (in our > case, it > would be things like ssh::ssh-global, and then I suppose we''d have > a file > called ssh-global.pp with the ssh-global class in it).Ok. I''m fine with attempting to autoload any class based on a convention around mapping namespaces and classes to files. -- Fallacies do not cease to be fallacies because they become fashions. --G. K. Chesterton --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Tue, 2007-04-17 at 15:44 -0500, Luke Kanies wrote:> On Apr 17, 2007, at 2:22 AM, Digant C Kasundra wrote: > > > > Well, I need to review how namespaces work and what the best practice > > around them will be. > > > > Currently, we do sometimes include just the subclass, and I can see > > that > > being useful. I do like the idea of doing ssh::whatever (in our > > case, it > > would be things like ssh::ssh-global, and then I suppose we''d have > > a file > > called ssh-global.pp with the ssh-global class in it). > > Ok. I''m fine with attempting to autoload any class based on a > convention around mapping namespaces and classes to files.My suggestion is to use the first namespace in an identifier and do an implicit import of that if the identifier is not defined yet. So if you have a manifest like node foo { include bar::baz::something } if bar::baz::something is not defined, essentially insert a import ''bar'' Doing this only when an identifier is undefined makes sure that users still have control over which modules get loaded. It''ll be a little tricky to implement, since it interleaves evaluation and importing/parsing. On the plus-side, this helps enforce the convention that all identifiers in a module should live in a namespace named after the module. This can get a little tricky if we ever allow people to open namespaces, i.e. do the equivalent of ''module'' in ruby. Then it becomes unclear if the auto-imported stuff gets added to the current namespace or if it gets added globally. David
After discussions with David last night, we came up with what I think is a complete spec: http://www.reductivelabs.com/trac/puppet/wiki/AutoloadingModules I''ve opened an enhancement request for it. -- Don''t throw away the old bucket until you know whether the new one holds water. -- Swedish Proverb --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com