Refactor #1195
closed
let the user specify the dirs to scan for import
Description
Let the user specify the import dirs to scan from the task to import classes through the settings.yaml file.
When using roles to assign hosts instead of directories using classes it is common to declare roles (classes) in /etc/puppet/manifests dir and then include the needed modules classes.
Example
class role_abc {
$role = role_abc
include http
include database
}
then one could assign role role_abc to a host named test.example.com. (roles is mentioned in puppetlabs best practices guide)
Patch:
https://github.com/gustavosoares/foreman/commit/e40249ad0180d6817226e2112af30888d45953b1
Updated by Ohad Levy about 13 years ago
hmm.. maybe I'm missing something here, but isnt hostgroup == roles in you example?
Updated by Gustavo Soares about 13 years ago
Ohad Levy wrote:
hmm.. maybe I'm missing something here, but isnt hostgroup == roles in you example?
more or less.. I think. Take a look at this design guideline: http://projects.puppetlabs.com/projects/1/wiki/Infrastructure_Design_Guidelines
IMHO I see hostgroups as a way to implement inheritance between nodes. It's subtle difference, I believe.
For instance:
node 'ntp.example42.com' inherits basenode {
$my_ntp_server = "0.pool.ntp.org"
include role_general
}then I could declare the role_general like this
class role_general {
include yum
include hosts
include puppet
include iptables
include sysctl
include nrpe
include ntp
include syslog
}
This file file would be located outside the modules dir...
Wouldn't "basenode" be a hostgroup in Foreman? Or there is another way to do this?
The provided patch would allow both ways to coexist.
Updated by Ohad Levy about 13 years ago
Gustavo Soares wrote:
Ohad Levy wrote:
hmm.. maybe I'm missing something here, but isnt hostgroup == roles in you example?
more or less.. I think. Take a look at this design guideline: http://projects.puppetlabs.com/projects/1/wiki/Infrastructure_Design_Guidelines
IMHO I see hostgroups as a way to implement inheritance between nodes. It's subtle difference, I believe.
For instance:
node 'ntp.example42.com' inherits basenode {
$my_ntp_server = "0.pool.ntp.org"include role_general
}then I could declare the role_general like this
class role_general {
include yum
include hosts
include puppet
include iptables
include sysctl
include nrpe
include ntp
include syslog
}This file file would be located outside the modules dir...
Wouldn't "basenode" be a hostgroup in Foreman? Or there is another way to do this?
It seems like you are not using foreman as your ENC, if you do, then all of this is not required....
The provided patch would allow both ways to coexist.
You patch force the user to enter that value afaik
Updated by Gustavo Soares about 13 years ago
Ohad Levy wrote:
Gustavo Soares wrote:
Ohad Levy wrote:
hmm.. maybe I'm missing something here, but isnt hostgroup == roles in you example?
more or less.. I think. Take a look at this design guideline: http://projects.puppetlabs.com/projects/1/wiki/Infrastructure_Design_Guidelines
IMHO I see hostgroups as a way to implement inheritance between nodes. It's subtle difference, I believe.
For instance:
node 'ntp.example42.com' inherits basenode {
$my_ntp_server = "0.pool.ntp.org"include role_general
}then I could declare the role_general like this
class role_general {
include yum
include hosts
include puppet
include iptables
include sysctl
include nrpe
include ntp
include syslog
}This file file would be located outside the modules dir...
Wouldn't "basenode" be a hostgroup in Foreman? Or there is another way to do this?
It seems like you are not using foreman as your ENC, if you do, then all of this is not required....
The node example was just to (try) to illustrate my point. I do use foremam as my ENC. Maybe i am missing something here...
The provided patch would allow both ways to coexist.
You patch force the user to enter that value afaik
Updated by Greg Sutcliffe over 8 years ago
- Description updated (diff)
- Status changed from New to Resolved
There's a few things to note as of today:
- the Proxy gets the environments from puppet, so all classes included roles should be found
- the ignored_environments.yaml file on the Foreman box can be used to excluded classes that shouldn't be seen in the UI, via regexes
- Config groups are now implemented, and can be used as roles (a host may have multiple config_groups)
Taken together, that should solve this bug, so I'm closing this. If there's more functionality needed, please do re-open it.