Johan De Wit
2013-Mar-28 10:32 UTC
[Puppet Users] Custom fact or function ? looking for opinion
Hi, I''m in the progress of writing custom facts to retrieve our network configuration for the nodes from the openldap ENC. Now, since the puppetmaster has also access to the ldap server, I''m thinking to move the custom facts to a function, so it runs on the puppetmaster only, end not on every node. I just wanted to here some other opinions about this issue. Thx Johan -- Johan De Wit Open Source Consultant Red Hat Certified Engineer (805008667232363) Puppet Certified Professional 2013 (PCP0000006) _________________________________________________________ Open-Future Phone +32 (0)2/255 70 70 Zavelstraat 72 Fax +32 (0)2/255 70 71 3071 KORTENBERG Mobile +32 (0)474/42 40 73 BELGIUM http://www.open-future.be _________________________________________________________ -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
jcbollinger
2013-Mar-28 13:20 UTC
[Puppet Users] Re: Custom fact or function ? looking for opinion
On Thursday, March 28, 2013 5:32:06 AM UTC-5, Johan De Wit wrote:> > Hi, > > I''m in the progress of writing custom facts to retrieve our network > configuration for the nodes from the openldap ENC. > >I''m confused. An ENC is a service for the master''s use, so nodes should have nothing to do with it. You can, of course, use the same LDAP server to back an ENC as well as client LDAP services, but for those different uses you should neither need nor want to access the same data.> Now, since the puppetmaster has also access to the ldap server, I''m > thinking to move the custom facts to a function, so it runs on the > puppetmaster only, end not on every node. > > I just wanted to here some other opinions about this issue. > >As a general principle, I would prefer to get the data from the most authoritative source, which might mean the master inquiring directly of LDAP. On the other hand, the master ought not to be peeking into data that do not belong to it. If the network configuration details you''re talking about are intended for the target nodes'' consumption, then for the master''s purposes, the nodes are the authoritative source. That''s most especially true if there is any possibility for any nodes networking to be custom configured apart from LDAP. Overall, though, I want to understand why there is even a question here. If your clients are getting their network configuration from LDAP, then why does the master need that information? And especially, what information are you seeking that is not already covered by *standard* facts? John -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Johan De Wit
2013-Mar-28 14:03 UTC
Re: [Puppet Users] Re: Custom fact or function ? looking for opinion
On 03/28/2013 02:20 PM, jcbollinger wrote:> > > On Thursday, March 28, 2013 5:32:06 AM UTC-5, Johan De Wit wrote: > > Hi, > > I''m in the progress of writing custom facts to retrieve our network > configuration for the nodes from the openldap ENC. > > > I''m confused. An ENC is a service for the master''s use, so nodes > should have nothing to do with it. You can, of course, use the same > LDAP server to back an ENC as well as client LDAP services, but for > those different uses you should neither need nor want to access the > same data. >In this case, the problem we have is with the network configuration. This is configured in ldap, and used both by puppet (using a n external script) and cobbler. Last one retrieves all interfaces and mac-addresses, and uses this in the autoyast file to populate the udev rules correctly.> Now, since the puppetmaster has also access to the ldap server, I''m > thinking to move the custom facts to a function, so it runs on the > puppetmaster only, end not on every node. >The puppet master has indeed access to some of the ldap data, but in our case not the network data since it is a subtree from the host ldap. The first blok is available as ''global variables''. That is no problem at all. The problem arise wit the network configuration .... ===== GLOBAL VAR ===DN: cn=puppetnode,ou=dmfstorage,ou=intranet,ou=Hosts,dc=vrt,dc=be objectClass: device objectClass: puppetClient objectClass: top objectClass: cobblerClient cn: puppetnode cobblervar: varsize=15360M environment: stag installInterface: eth0 parentnode: Some parent node powerMethod: ilo profile: sles11sp1 puppetclass: some::puppet::class puppetServer: 172.27.12.4 puppetvar: some=puppetvar puppetvar: other=puppetvar ==== END GLOBAL VAR ===== DN: cn=bond0,cn=puppetnode,ou=dmfstorage,ou=intranet,ou=Hosts,dc=vrt,dc=be objectClass: device objectClass: ieee802Device objectClass: top objectClass: networkClient cn: bond0 ipaddress: <someip> netmask: 255.255.255.0 DN: cn=eth0,cn=bond0,cn=puppetnode,ou=dmfstorage,ou=intranet,ou=Hosts,dc=vrt,dc=be objectClass: device objectClass: ieee802Device objectClass: top cn: eth0 description: desc macAddress: 98:4B:E1:04:9B:86 DN: cn=eth4,cn=bond0,cn=puppetnode,ou=dmfstorage,ou=intranet,ou=Hosts,dc=vrt,dc=be objectClass: device objectClass: ieee802Device objectClass: top cn: eth4 description: desc macAddress: F4:CE:46:A6:A3:DF N: cn=eth6,cn=puppetnode ,ou=dmfstorage,ou=intranet,ou=Hosts,dc=vrt,dc=be objectClass: device objectClass: ieee802Device objectClass: top cn: eth6 description: desc macAddress: F4:CE:46:A6:A3:DD Since these are subtrees from the host object, puppet does not read them, and they are not available. (and we do have a lot of nodes with +24 interfaces, almost all configured in bonds) At this moment, i do have some custom facts reading this data from ldap, so it is available for the ''network'' manifest. I think you gave me a third option in getting this data available : 1 - custom facts 2 - functions 3 - patching the ldap enc, to retrieve the complete subtree ha, maybe a forth ? 4 - Hiera custom ldap backend ? Somehow, I will have to provide proper providers and types also. (based on http://forge.puppetlabs.com/adrien/network as an example) This is a very specific setup, that maybe could have been implemented on a better way, but for now we have to live with it.> I just wanted to here some other opinions about this issue. > > > As a general principle, I would prefer to get the data from the most > authoritative source, which might mean the master inquiring directly > of LDAP. On the other hand, the master ought not to be peeking into > data that do not belong to it. If the network configuration details > you''re talking about are intended for the target nodes'' consumption, > then for the master''s purposes, the nodes are the authoritative > source. That''s most especially true if there is any possibility for > any nodes networking to be custom configured apart from LDAP. > > Overall, though, I want to understand why there is even a question > here. If your clients are getting their network configuration from > LDAP, then why does the master need that information? And especially, > what information are you seeking that is not already covered by > /standard/ facts? >Thx for responding> > John > > -- > 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+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > >-- Johan De Wit Open Source Consultant Red Hat Certified Engineer (805008667232363) Puppet Certified Professional 2013 (PCP0000006) _________________________________________________________ Open-Future Phone +32 (0)2/255 70 70 Zavelstraat 72 Fax +32 (0)2/255 70 71 3071 KORTENBERG Mobile +32 (0)474/42 40 73 BELGIUM http://www.open-future.be _________________________________________________________ -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
jcbollinger
2013-Mar-29 14:00 UTC
Re: [Puppet Users] Re: Custom fact or function ? looking for opinion
On Thursday, March 28, 2013 9:03:31 AM UTC-5, Johan De Wit wrote:> > On 03/28/2013 02:20 PM, jcbollinger wrote: > > > > On Thursday, March 28, 2013 5:32:06 AM UTC-5, Johan De Wit wrote: >> >> Hi, >> >> I''m in the progress of writing custom facts to retrieve our network >> configuration for the nodes from the openldap ENC. >> >> > I''m confused. An ENC is a service for the master''s use, so nodes should > have nothing to do with it. You can, of course, use the same LDAP server > to back an ENC as well as client LDAP services, but for those different > uses you should neither need nor want to access the same data. > > In this case, the problem we have is with the network configuration. > This is configured in ldap, and used both by puppet (using a n external > script) and cobbler. Last one retrieves all interfaces and mac-addresses, > and uses this in the autoyast file to populate the udev rules correctly. > >Ok, this is a bit clearer to me now. I think what you''re saying is that other than the custom facts you are working on, the nodes rely directly on LDAP only for their cobbler-managed initial provisioning. If that''s the case then it tells me that the LDAP data do not, in fact, belong to the nodes, but rather to the site generally. With that being the case, it does not make much sense to me for the nodes to play an intermediary role in providing that data to the master, unless possibly there is an insurmountable barrier to the master retrieving the data directly. There is a separate question however: are you trying to find the parameters the nodes *should* have (for which LDAP is authoritative) or the parameters the nodes actually *do* have (which can be provided only by the nodes). If the latter, then the nodes would not be acting as intermediaries when they provided the data to the master, as they would need to get it by self-inspection, not LDAP.> >> Now, since the puppetmaster has also access to the ldap server, I''m >> thinking to move the custom facts to a function, so it runs on the >> puppetmaster only, end not on every node. >> >> [...] > > I think you gave me a third option in getting this data available : > > 1 - custom facts > 2 - functions > 3 - patching the ldap enc, to retrieve the complete subtree > > ha, maybe a forth ? > > 4 - Hiera custom ldap backend ? >I think an LDAP back end for hiera might fit very nicely into your picture. I doubt it would be much harder to create than the custom facts or custom function(s) you are already contemplating, and it would provide great abstraction and flexibility.> > Somehow, I will have to provide proper providers and types also. (based > on http://forge.puppetlabs.com/adrien/network as an example) > > This is a very specific setup, that maybe could have been implemented on a > better way, but for now we have to live with it. > >Since the objective seems to be for the master to instruct agents how to configure the correct network parameters on each node, I''d say that the data flow LDAP -> master -> agent makes far more sense than LDAP -> agent -> master -> agent . Best, John -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Johan De Wit
2013-Mar-29 21:04 UTC
Re: [Puppet Users] Re: Custom fact or function ? looking for opinion
On 03/29/2013 03:00 PM, jcbollinger wrote:> > > On Thursday, March 28, 2013 9:03:31 AM UTC-5, Johan De Wit wrote: > > On 03/28/2013 02:20 PM, jcbollinger wrote: >> >> >> On Thursday, March 28, 2013 5:32:06 AM UTC-5, Johan De Wit wrote: >> >> Hi, >> >> I''m in the progress of writing custom facts to retrieve our >> network >> configuration for the nodes from the openldap ENC. >> >> >> I''m confused. An ENC is a service for the master''s use, so nodes >> should have nothing to do with it. You can, of course, use the >> same LDAP server to back an ENC as well as client LDAP services, >> but for those different uses you should neither need nor want to >> access the same data. >> > In this case, the problem we have is with the network > configuration. This is configured in ldap, and used both by > puppet (using a n external script) and cobbler. Last one > retrieves all interfaces and mac-addresses, and uses this in the > autoyast file to populate the udev rules correctly. > > > > Ok, this is a bit clearer to me now. I think what you''re saying is > that other than the custom facts you are working on, the nodes rely > directly on LDAP only for their cobbler-managed initial provisioning. > If that''s the case then it tells me that the LDAP data do not, in > fact, belong to the nodes, but rather to the site generally. > > With that being the case, it does not make much sense to me for the > nodes to play an intermediary role in providing that data to the > master, unless possibly there is an insurmountable barrier to the > master retrieving the data directly. > > There is a separate question however: are you trying to find the > parameters the nodes /should/ have (for which LDAP is authoritative) > or the parameters the nodes actually /do/ have (which can be provided > only by the nodes). If the latter, then the nodes would not be acting > as intermediaries when they provided the data to the master, as they > would need to get it by self-inspection, not LDAP.definitely the first case. LDAP is authoritative for the network configuration.> >> Now, since the puppetmaster has also access to the ldap >> server, I''m >> thinking to move the custom facts to a function, so it runs >> on the >> puppetmaster only, end not on every node. >> > [...] > > I think you gave me a third option in getting this data available : > > 1 - custom facts > 2 - functions > 3 - patching the ldap enc, to retrieve the complete subtree > > ha, maybe a forth ? > > 4 - Hiera custom ldap backend ? > > > I think an LDAP back end for hiera might fit very nicely into your > picture. I doubt it would be much harder to create than the custom > facts or custom function(s) you are already contemplating, and it > would provide great abstraction and flexibility.this is very temting to implement, and i think this will be the road i will take.> > > Somehow, I will have to provide proper providers and types also. > (based on http://forge.puppetlabs.com/adrien/network > <http://forge.puppetlabs.com/adrien/network> as an example) > > This is a very specific setup, that maybe could have been > implemented on a better way, but for now we have to live with it. > > > Since the objective seems to be for the master to instruct agents how > to configure the correct network parameters on each node, I''d say that > the data flow > LDAP -> master -> agent > makes far more sense than > LDAP -> agent -> master -> agentthanks for your input. The code will follow :) Greets Johan> . > > > Best, > > John > > -- > 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+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > >-- Johan De Wit Open Source Consultant Red Hat Certified Engineer (805008667232363) Puppet Certified Professional 2013 (PCP0000006) _________________________________________________________ Open-Future Phone +32 (0)2/255 70 70 Zavelstraat 72 Fax +32 (0)2/255 70 71 3071 KORTENBERG Mobile +32 (0)474/42 40 73 BELGIUM http://www.open-future.be _________________________________________________________ -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.