isn't this something best done in a manifest?

I've been trying to think if adding multiple roles to a server is a good idea, i mean, according to "my" best practice, I tend to think that a server has a main primary role (which is a collection of classes), anything else should go to so called sub functions where you can just add classes to the host.

I've sort of covered this under #35. But I see the foreman as usable for many environments and not just for production - so a server could be many roles in a test/dev environment.

I don't think you would want to have multiple groups to a node. It would be to easy to have scoping issues. I would however see use in having a group inherit from another group.

(13:31:41) Matt: I have a group my-webserver, and my-db - they both have separate variables but also share some. A node is only usually my-webserver or my-db, but sometimes I want a node to be both. To do that currently i'll have to create a new group and type in all the variables, and add the classes. Or just assign one group and do it at the node level
(13:32:08) Matt: I think the variable clashes should just be handled by priority of what group was added last.
(13:32:19) Ohad Levy: ok, so a host should be able to have many groups

This would be a really nice feature. Don't know how you are going to implement this but, if I may suggest something, it would be nice to treat groups (inside the foreman interface) in a similar way as you treat a puppetclass. Just listed together in the class list (with a remark that it's a group). Puppetclasses/groups list example:
------------------
module1::class-foo
module2::class-bar
Group-MyGroup1
Group-MyGroup2 etc...
------------------

This way you can drag & drop classes and/or groups to both "hosts" and to "groups" within the same interface. In this way you might as well just remove the "hostgroup" field in the "HOSTS" edit interface (as your group(s) would just be listed in the greenbox).
I believe that would give us great flexibility.

I'd like to see the feature. But I don't think the clash of variables should be handled with one group taking authority. I think if a node is assigned multiple groups that contain the same variable names but with different values, then that should throw an error.

So this would throw an error due to yumrepo variable
mywebserver: yumrepo = "xxx", masterip = "aaa", webserverconf = "bbb"
mydb: yumrepo = "aaa", masterip = "aaa", dbconf = "aaa"

This would be ok
mywebserver: yumrepo = "xxx", masterip = "aaa", webserverconf = "bbb"
mydb: yumrepo = "xxx", masterip = "aaa", dbconf = "aaa"

Ohad Levy wrote:

I'm still in mixed feelings about this one :-(

Hi Ohad,
Could you explain us a little bit more your thoughts on this ?

It's a pity to see this feature out of the next release :-((((

Marcello de Sousa wrote:

Ohad Levy wrote:

I'm still in mixed feelings about this one :-(

Hi Ohad,
Could you explain us a little bit more your thoughts on this ?

It's a pity to see this feature out of the next release :-((((

maybe we can find the time to talk on #theforeman irc channel

my concern breaks into two main parts:
1. technical - e.g. how to handle parameters etc
2. logical, does it really make sense to have hostgroup inherit other groups? (in terms of best practice etc).

Hi Ohad,
I would like to be implemented too. We are currently trying yo migrate from Puppet Dashboard to Foreman and this functionality is much desired. Although not a show-stopper, it is forcing us to restructure all parameter placement hierarchies we had before.

Hi Ohad,

Would like this to be implemented. Im trying to do something similar to Atha and it would be great if we had this functionality

Sounds perfect to me!