Issue #15206 has been updated by Ashley Penney.
I think we could probably get away with just a header in the puppet doc parsing. It would be nice to find a way to make adding metadata in general to comments easier and provide some easy way to add a specific action if that header exists. I'm pretty much just thinking ahead but if Visibility is one option I can foresee other uses for being able to extend the comment parsing in a way that puppet doc would want to handle. That might be getting ahead of ourselves for no reason, admittedly, and maybe just extending it to add Visibility would do for now. The only benefit to adding it as a language feature rather than a comment is you could then enforce that classes marked as private can only be included from other classes and never by a node, gives it a bit of strong enforcement. We've talked about moving away from an ENC altogether to using Hiera so that's an area in which having it as part of the language would add a safety net and forbid people to include subclasses rather than a higher level one. ---------------------------------------- Feature #15206: Ability to hide classes from an ENC/UI https://projects.puppetlabs.com/issues/15206#change-69090 Author: Ashley Penney Status: Needs Decision Priority: Normal Assignee: Ashley Penney Category: modules Target version: Affected Puppet version: Keywords: Branch: Hi, For a while now I've been wishing I could mark classes as hidden in some obvious way that makes it clear to the reader that this class is not supposed to be included on a node but only via other classes. While there are ways this could be hacked up today (checking a puppetdoc at the top etc) I'd prefer for it to be an official part of creating a class. Something like "internal class blah { }". Ideally this feature wouldn't -stop- you from including it on a host, just provide a mechanism by which the dashboard/foreman/other ENCs could hide this class from a user. My use case is as follows: I have three modules. Cman, Corosync, Pacemaker. None of these modules are really usable by themselves. Between them they have -14- classes. These are the normal corosync::params and pacemaker::config and other kinds of classes you'd expect to see. When users are assigning classes to machines I only want them to be able to attach one single class from the above 14 - cman/manifests/init.pp. I would love to be able to mark the others as "you shouldn't really attach this to a host" as a way of decluttering the interface. It would also assist in showing how a module "should" be used when encountering it for the first time. If you spot that two classes are public and the rest are private then you have a great starting point for understanding how to assign them to nodes. -- 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.
