Issue #2847 has been updated by Ken Barber.
> > As far as Solaris support - that is very awesome, thanks very much. Hold on > > to that thought - lets at least get the Linux one in since there are still > > design discussions going on. Perhaps we can raise a second ticket and link > > it to this one for housekeeping purposes - (unless mkincaid wants to > > incorporate it into his patchset now of course). > > People over process, Ken :-) Please, I am begging you! :) This has got nothing to do with process, its trying to not muddy the water with too many logical changes at once, and getting some sort of an accepted design now as apposed to later. Like I said - if mkincaid wants to integrate it into the patchset thats fine, but its going to take longer and obviously hacking facter isn't his only day job :-). There is no harm in having a separate change for this, I just don't want to lose track of it. Anyway process is all about people isn't it? > > Anyway onto the point of exclusion lists ... (and this I'm looking for your > > points as well KW). Is there any reason why we shouldn't just allow the > > user of the fact to do the exclusion at runtime instead? ie. pass through > > all mount device types and let people filter in puppet code (ie. with a > > function or something). I think this is the main topic of contention at the > > moment that is blocking this ticket so I'd be interested in some objective > > views and points on this so we can push past this, as this ticket seems to > > be going on forever :-). > > I believe that there is nothing wrong with this fact per se. There are > already a numerous people using it whom have taken it straight from my > github. Therefore, the very reason why this ticket is going forever lies > somewhere else (yes, I am guilty of not having the time in most cases; my day > job stands in the way somewhat, but that is not the main reason for it) :-( So my question was - is there any reason why the user of the fact can't do the exclusion at runtime instead? What I want to know is if there is a technical restriction on this, or an issue that would cause it to be a bad idea. If there is not, then I can't see any harm in removing the exclusion list so we can cover the edge use-cases. Also - going back to the Solaris example, this concept of exclusion list would be harder to maintain once you start covering other operating systems as well. I guess conceptually you would have different exclusion lists for every OS. And - what if a new device type pops up that we didn't anticipate? In that case - shouldn't we just have a white-list instead? Where is the line drawn ... what belongs in the exclusion list anyway? My point primarily is that its going to always be user choice and we don't have a configuration file mechanism today that we are happy with. Users will eventually want to change that exclusion list themselves, so can we just do away with it and not feel a side-effect? > About allowing people to filter for themselves. Look at my comment > [here](https://github.com/puppetlabs/facter/pull/42/files#r323380). There is > also this old problem of limited number of facts and data they expose that > Facter can use (send over) as the length of parameters for GET request is > not infinite unless this was solved already (citation needed), therefore > sending everything may not be feasible and/or a good idea at all. In 2.7.x it's now a POST request. See #6117. ---------------------------------------- Feature #2847: mountpoint fact https://projects.puppetlabs.com/issues/2847 Author: anarcat - Status: In Topic Branch Pending Review Priority: Normal Assignee: Michael Kincaid Category: library Target version: 1.7.x Keywords: mounts, devices Branch: Affected Facter version: I have implemented, based on work by the Debian's Sysadmin team, a fact that allows listing of the mountpoints (and associated devices). I have attached the code for the fact, which is called "mountpoints" but also exports "devices". I have requested and got approval from the original author (Stephen Gran, which code can still be seen here: http://git.debian.org/?p=mirror/dsa-puppet.git;a=blob;f=facts/mounts.rb;hb=HEAD) before contacting you. To quote him: "git blame indicates that all the current code in the mounts fact is mine, so I'm happy to license it under the GPL (of any verson, as that is apparently the puppet license, at first glance) for purposes of pushing it upstream. OTOH, it is about 20 lines of fairly trivial code, so I'm not sure copyright is even an issue." Apparently, his original code was relying on the presence of the "Filesystem" Ruby library, which may not be desirable in this case, which is why I implemented a linux workaround. It's my first fact ever, so I'm very curious to see if I have done this properly or if there are possible improvements to the code. I know comments could be good... My working copy of the code is also available through git: http://git.koumbit.net/?p=puppet/modules/common.git;a=blob;f=plugins/facter/mountpoints.rb;hb=HEAD Thanks, A. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
