On Thu, Feb 27, 2014 at 03:12:53AM -0800, zerozerouno...@gmail.com wrote:
> On Thursday, February 27, 2014 8:52:04 AM UTC+1, nikolavp wrote:
> 
> A specific example I think will be of much help. Some ideas: 
> >
> > 1) Is "role B" just a more specific "role A" or they aren't so much 
> > related. You can use inheritance if they are and change the file/define
> 
> 
> Yes, B is some sort of "more specific A".
> Not easy to explain because they use custom apps, services, and files (and 
> I don't even fully know how they work), but maybe this example will fit:
> 
>    - role A is "web server"
>    - role B is "secure web server"
>    - the same set of resources (packages, users, files, configuration 
>    edits...) is applied for both roles, but role A sets some permissions in 
>    httpd.conf while role B needs more strict permissions for the same web 
>    paths, so they need to use different parameters for the same line in the 
>    same file.
> 
> Maybe inheritance is the way to go?
> I can put my resource (and related ones) in a separate class with a 
> parameter for the value to be inserted in the conf file, and then create 
> two different classes for roles A and B which inherit the class and 
> override the resource attribute through the parameter.
> Is that right?

With inheritance you get the following:

    class webA {
    ...
        file { '/etc/myapp/config.properties':
            content => template('my-default-template')
            ....
        }
    ...
    }

    class webB inherits webA {
        File['/etc/myapp/config.properties'] { # note the capital File and the 
same resource name as above
            content => template('my-custom-template'),
        }
    }

More can be found in
http://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#inheritance
look at the "Overriding Resource Attributes" section. Although I don't
like inheritance as you describe it if roleB is a secure web server and
roleA is a web server I would go for it.

> 
> Other ways to do this would be to just "propagate" the parameter for the 
> > change to both "role A" and "role B" with default values.
> >
> 
> What do you mean?

Something like

    class webA (
    port = '8080' # this is the default
    ) {
        ...
    }


    class webB (
    port = '8081' # this is the default
    ) {
        ...
    }

now at this point if you want to declare them both you just use another
definition...

class mynewrole {
    class { 'webA':
        port => '8081',
    }

    class { 'webB':
        port => '8081',
    }
}

sadly this way the augeas or the way you do the change will be fired two
times :(

>  
> 
> > I am not sure if understood the idea. I am not saying that you have to 
> > create a dependant fact but just to set a fact with the value you want 
> > to change. So let's say you want to have a database connection URI. Role 
> > A sets it to something by default and Role B sets it to something else. 
> > You can specify the wanted connection URI on the host with custom fact. 
> >
> 
> Ok, but how can I create this custom fact on the hosts?
> I'm provisioning the hosts through Foreman, I need the installation and 
> configuration of the hosts to be automated, based on the classes/roles 
> selected in the Foreman GUI. I do not want to create the custom fact "by 
> hand" on each host.
> That's why I was thinking about checking the classes applied to the host, 
> as a way to automatically detect the value to be assigned to the fact.

Ok so the fact is not an option ;)

>  
> 
> > N.B. Can you also tell us how do you assign the roles for each host 
> > because that might help us be more specific with a solution. 
> 
> 
> I assign puppet classes to the hosts using the Foreman web GUI; either 
> specific classes during tests, or by associating the classes to different 
> host groups and then assigning hosts to groups.
> 
> Thank you very much.
> Marco

-- 
Nikola

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/20140227161643.GB23232%40nikolavp-desktop.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to