Jira (PDB-2576) Consider expiring multiple nodes in a single sql command
Title: Message Title Rob Browning created an issue PuppetDB / PDB-2576 Consider expiring multiple nodes in a single sql command Issue Type: Improvement Assignee: Unassigned Created: 2016/03/28 7:53 PM Priority: Normal Reporter: Rob Browning Currently, we expire one node at a time, and we make at least two round trips to the database for each. It looks like it should be straightforward to unify the process into a single SQL command. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (PUP-6103) puppet epp render should load local facts by default
Title: Message Title Henrik Lindberg commented on PUP-6103 Re: puppet epp render should load local facts by default A --node would be very useful to get the last reported facts for a given node (or for the local node) if no name is given. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6103) puppet epp render should load local facts by default
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-6103 puppet epp render should load local facts by default Change By: Henrik Lindberg Sprint: Language Triage Scrum Team: Language Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6103) puppet epp render should load local facts by default
Title: Message Title
Ben Ford updated an issue
Puppet / PUP-6103
puppet epp render should load local facts by default
Change By:
Ben Ford
{{puppet epp render}} should load local facts by default. It's very common when developing code to run local {{puppet apply}} evaluations to see what code does. Currently, the fastest way to get a quick render of an erb template is something like:{code} [root@training templates]# $ puppet apply -e 'notice(template("/full/path/to/example.erb"))'{code}When using EPP templates, you must first save facts to a file{code} [root@training templates]# $ facter --yaml > facts.yaml [root@training templates]# $ puppet epp render ec2data.epp --values_file facts.yaml{code}Since this is such a common use case, it would be really nice to just load local facts by default if none were provided. Maybe even print out a notice like {{Notice: no values provided, using local facts.}}
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6103) puppet epp render should load local facts by default
Title: Message Title
Ben Ford created an issue
Puppet / PUP-6103
puppet epp render should load local facts by default
Issue Type:
Bug
Assignee:
Unassigned
Components:
Language
Created:
2016/03/28 5:03 PM
Priority:
Normal
Reporter:
Ben Ford
puppet epp render should load local facts by default. It's very common when developing code to run local `puppet apply` evaluations to see what code does. Currently, the fastest way to get a quick render of an erb template is something like:
[root@training templates]# puppet apply -e 'notice(template("/full/path/to/example.erb"))'
When using EPP templates, you must first save facts to a file
Jira (PUP-6103) puppet epp render should load local facts by default
Title: Message Title
Ben Ford updated an issue
Puppet / PUP-6103
puppet epp render should load local facts by default
Change By:
Ben Ford
{{puppet epp render}} should load local facts by default. It's very common when developing code to run local ` {{ puppet apply ` }} evaluations to see what code does. Currently, the fastest way to get a quick render of an erb template is something like:{code}[root@training templates]# puppet apply -e 'notice(template("/full/path/to/example.erb"))'{code}When using EPP templates, you must first save facts to a file{code}[root@training templates]# facter --yaml > facts.yaml[root@training templates]# puppet epp render ec2data.epp --values_file facts.yaml{code}Since this is such a common use case, it would be really nice to just load local facts by default if none were provided. Maybe even print out a notice like {{Notice: no values provided, using local facts.}}
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6102) A type alias that has an alias name of a built-in type should be illegal
Title: Message Title Peter Huene commented on PUP-6102 Re: A type alias that has an alias name of a built-in type should be illegal The native compiler will catch this statically when definitions are scanned for in the AST: Error: site.pp:1:6: node 'foo': type alias 'String' conflicts with a built-in type of the same name. type String = Integer ^~ Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6102) A type alias that has an alias name of a built-in type should be illegal
Title: Message Title Henrik Lindberg commented on PUP-6102 Re: A type alias that has an alias name of a built-in type should be illegal This should be caught by static validation since it is can never be correct. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1909) Priority setting also given to started processes/services
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-1909 Priority setting also given to started processes/services Change By: Henrik Lindberg Scrum Team: Client Platform Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4412) Allow automatic parameter lookups to collect metaparameters
Title: Message Title Henrik Lindberg commented on PUP-4412 Re: Allow automatic parameter lookups to collect metaparameters The suggested "combine" function (not sure about the name though) is a useful general purpose function that would fit in stdlib. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1909) Priority setting also given to started processes/services
Title: Message Title
Geoff Williams updated an issue
Puppet / PUP-1909
Priority setting also given to started processes/services
Change By:
Geoff Williams
CS Priority:
Needs Priority
CS Impact:
Gold partner in NZ has run into this and its having an impact on a large puppet installation. I can verify that latest PE2015-3.3 is also affected by this. Agent priority is not visibly changed using {{ps}} unless the adjustment is made in the {{[main]}} section and then it affects other parts of puppet as well.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6100) Question / Feature Request: Make value of "configuration version" visible to puppet manifests
Title: Message Title Henrik Lindberg commented on PUP-6100 Re: Question / Feature Request: Make value of "configuration version" visible to puppet manifests Johnson Earls Do you mean in types/providers agent side, or do you mean master side when compiling the catalog? Master side it is kind of complicated as the catalog.version is assigned to the catalog later in the compilation process. From what I can tell it is not available at the point the evaluation of manifests take place, but it looks like it could be made available. Not sure if that has any side effects (if done at the different point in time that when it is currently done). The method in question is Puppet::Resource::TypeCollection#version. It would be possible to get that via a function. Agent side this would trivially mean being able to lookup catalog.version. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6102) A type alias that has an alias name of a built-in type should be illegal
Title: Message Title Peter Huene created an issue Puppet / PUP-6102 A type alias that has an alias name of a built-in type should be illegal Issue Type: Bug Affects Versions: PUP 4.4.1 Assignee: Unassigned Created: 2016/03/28 3:37 PM Fix Versions: PUP 4.4.2 Priority: Normal Reporter: Peter Huene I would expect the following to be illegal: type String = Integer As String is a built-in type and should not be "redefined".
Jira (PDB-2573) (maint) Use trapperkeeper-metrics webservices in PuppetDB
Title: Message Title Andrew Roetker updated an issue PuppetDB / PDB-2573 (maint) Use trapperkeeper-metrics webservices in PuppetDB Change By: Andrew Roetker Scope Change Category: Adopted Scope Change Reason: Easy update, had some down time Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5829) Update Puppet Acceptance tests for cisco-wrlinux-7
Title: Message Title Stan Duffy commented on PUP-5829 Re: Update Puppet Acceptance tests for cisco-wrlinux-7 The work for both platforms was done in a single PR Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2575) use vars in entities in query-eng entitity-fn-idx
Title: Message Title Wyatt Alt created an issue PuppetDB / PDB-2575 use vars in entities in query-eng entitity-fn-idx Issue Type: Bug Assignee: Unassigned Created: 2016/03/28 2:28 PM Priority: Normal Reporter: Wyatt Alt use vars for the query recs and then deref the vars when used. this will allow developers to reevaluate the code in engine.clj without needing to reevaluate the query-eng.clj code as well Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter that is the problem, we rebooted servers and we end up with a nic called rename3 or rename4 I have changed the module to comment out the HWADDR as a short term fix. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title
zendesk.jira commented on FACT-1374
Re: cfacter: toplevel macaddress fact behaves differently from ruby facter
its the eth interfaces i need to get the correct mac for. the networking fact is also incorrect, you will see below that eth2 and eth3 both have the same mac address.
{ "interfaces" : { "eth2" : { "dhcp" : "10.31.67.100", "mac" : "b4:99:ba:bc:57:28", "mtu" : 1500 }
, "bond1.402" : { "ip" : "94.142.188.46", "bindings6" : [ { "address" : "fe80::260:ddff:fe45:4440", "netmask" : ":::::", "network" : "fe80::" }
], "mtu" : 9000, "bindings" : [ { "address" : "94.142.188.46", "netmask" : "255.255.255.224", "network" : "94.142.188.32" }
], "network6" : "fe80::", "netmask6" : ":::::", "ip6" : "fe80::260:ddff:fe45:4440", "netmask" : "255.255.255.224", "network" : "94.142.188.32", "mac" : "00:60:dd:45:44:40" }, "bond0" : { "ip" : "10.31.67.42", "bindings6" : [ { "address" : "fe80::b699:baff:febc:5728", "netmask" : ":::::", "network" : "fe80::" }
], "mtu" : 1500, "bindings" : [ { "address" : "10.31.67.42", "netmask" : "255.255.255.0", "network" : "10.31.67.0" }
], "network6" : "fe80::", "netmask6" : ":::::", "ip6" : "fe80::b699:baff:febc:5728", "netmask" : "255.255.255.0", "network" : "10.31.67.0", "mac" : "b4:99:ba:bc:57:28" }, "bond1" : { "bindings6" : [ { "address" : "fe80::260:ddff:fe45:4440", "netmask" : ":::::", "network" : "fe80::" }
], "ip6" : "fe80::260:ddff:fe45:4440", "mac" : "00:60:dd:45:44:40", "mtu" : 9000, "netmask6" : ":::::", "network6" : "fe80::" }, "bond1.64" : { "ip" : "10.31.64.35", "bindings6" : [ { "address" : "fe80::260:ddff:fe45:4440", "netmask" : ":::::", "network" : "fe80::" }
], "mtu" : 9000, "bindings" : [ { "address" : "10.31.64.35", "netmask" : "255.255.255.0", "network" : "10.31.64.0" }
], "network6" : "fe80::", "netmask6" : ":::::", "ip6" : "fe80::260:ddff:fe45:4440", "netmask" : "255.255.255.0", "network" : "10.31.64.0", "mac" : "00:60:dd:45:44:40" }, "lo" : { "ip" : "127.0.0.1", "bindings6" : [ { "address" : "::1", "netmask" : ":::::::", "network" : "::1" }
], "mtu" : 65536, "bindings" : [ { "address" : "127.0.0.1", "netmask" : "255.0.0.0", "network" : "127.0.0.0" }
], "network6" : "::1", "netmask6" : ":::::::", "ip6" : "::1", "netmask" : "255.0.0.0", "network" : "127.0.0.0" }, "eth0" : { "mac" : "00:60:dd:45:44:40", "mtu" : 9000 }
, "eth3" : { "mac" : "b4:99:ba:bc:57:28", "mtu" : 1500 }
, "eth1" : { "mac" : "00:60:dd:45:44:40", "mtu" : 9000 }
}, "ip" : "94.142.188.46", "primary" : "bond1.402", "mtu" : 9000, "network6" : "fe80::", "hostname" : "ld4prdsrv-api13", "fqdn" : "ld4prdsrv-api13.nebex.local", "netmask6" : ":::::", "ip6" : "fe80::260:ddff:fe45:4440", "netmask" : "255.255.255.224", "network" : "94.142.188.32", "domain" : "nebex.local", "mac" : "00:60:dd:45:44:40" }
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Kranium, This was given to us in handoff today, can you please update the summary with more details on what's been done, ruled out, and possible next steps? This comment was made by Nathanael Cole on Wed Feb 17 07:44:51 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter on bonded interfaces facter does not return the real mac address. This has caused us major issues as we use the mac address fact when setting up interfaces. we have had some servers with failed bonds after reboot due to this. New Facter is not production ready, this has lead to major concerns about puppet and confidence has gone down in it so much since the last upgrade we are looking at other automation / configuration solutions. is this a know issue? are there any work arounds? Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Discussed on office hours with Scott. Next steps are to reproduce it and open a jira ticket to ask engineering if our product is working as designed in this case. There is a difference in behaviour. Raise this as facter ticket and assign to Kylo. This comment was made by Gary Camblin on Wed Mar 16 03:46:45 PDT 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter I don’t think it is, this worked with ruby facter but not latest facter so is down to PE and not OS or hardware Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter cant find dhcpcd -with the `-U` flag in debian7 also tried centos6 but could not find the package to install tried dhclient dhcp etc. This comment was made by Kranium Gikos on Fri Feb 12 06:52:02 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter need to document case on how to repro and raise a jira This comment was made by Kranium Gikos on Mon Feb 22 07:18:46 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Hi Simon, I tried setting 2 nics with the same macaddress on my virtualbox vm but my centos setup kept renaming the second nic to rename4. Will you be able to check the bios/vendor for the actual mac address for eth2 and eth3? I'm not familiar with HP hardware if the macs can be customized. Please also attach the output of the commands below for reference. 1. ifconfig -a 2. ip addr 3. `cat /sys/class/net/eth2/address` 4. `cat /sys/class/net/eth3/address` 5. `cat /etc/sysconfig/network-scripts/ifcfg-eth2` 6. `cat /etc/sysconfig/network-scripts/ifcfg-eth3` Thank you. Regards, Kranium This comment was made by Kranium Gikos on Wed Feb 17 02:09:44 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter this customer also had dmidecode uuid issues earlier at #16313 This comment was made by Kranium Gikos on Fri Feb 12 01:59:21 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Hi Bill, Any we have news from engineering on fixing the ip/mac related cfacter issues? Thanks! Kranium This comment was made by Kranium Gikos on Mon Mar 14 02:16:15 PDT 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Thanks Simon. It looks like facter is looking for the dhcpcd command but I'm not sure if this is causing the issue. ``` 2016-02-12 10:43:44.638003 DEBUG leatherman.execution:87 - executing command: dhcpcd -U bond0 2016-02-12 10:43:44.638049 DEBUG leatherman.execution:412 - dhcpcd was not found on the PATH. 2016-02-12 10:43:44.638149 DEBUG leatherman.execution:87 - executing command: dhcpcd -U bond1 2016-02-12 10:43:44.638192 DEBUG leatherman.execution:412 - dhcpcd was not found on the PATH. 2016-02-12 10:43:44.638291 DEBUG leatherman.execution:87 - executing command: dhcpcd -U bond1.64 2016-02-12 10:43:44.638334 DEBUG leatherman.execution:412 - dhcpcd was not found on the PATH. 2016-02-12 10:43:44.638406 DEBUG leatherman.execution:87 - executing command: dhcpcd -U bond1.64:0 2016-02-12 10:43:44.638447 DEBUG leatherman.execution:412 - dhcpcd was not found on the PATH. 2016-02-12 10:43:44.638518 DEBUG leatherman.execution:87 - executing command: dhcpcd -U bond1.64:1 2016-02-12 10:43:44.638559 DEBUG leatherman.execution:412 - dhcpcd was not found on the PATH. 2016-02-12 10:43:44.638630 DEBUG leatherman.execution:87 - executing command: dhcpcd -U bond1.64:2 2016-02-12 10:43:44.638707 DEBUG leatherman.execution:412 - dhcpcd was not found on the PATH. 2016-02-12 10:43:44.638797 DEBUG leatherman.execution:87 - executing command: dhcpcd -U bond1.64:3 ``` bond0, eth4 and eth5 also seems to be sharing the mac ``` 2016-02-12 10:43:44.640346 DEBUG puppetlabs.facter - fact "macaddress_bond0" has resolved to "ac:16:2d:87:ca:9e". 2016-02-12 10:43:44.640393 DEBUG puppetlabs.facter - fact "macaddress" has resolved to "ac:16:2d:87:ca:9e". 2016-02-12 10:43:44.642457 DEBUG puppetlabs.facter - fact "macaddress_eth4" has resolved to "ac:16:2d:87:ca:9e". 2016-02-12 10:43:44.642556 DEBUG puppetlabs.facter - fact "macaddress_eth5" has resolved to "ac:16:2d:87:ca:9e". ``` I'm not sure what you mean by the information coming from the device. Can you share the command or if you have a device file (/proc, /sys. etc) for reference? Please also pass me the output of `ifconfig -a` and the mac address you are expecting facter to return. Thanks! Kranium This comment was made by Kranium Gikos on Fri Feb 12 06:47:18 PST 2016 from Zendesk Add Comment
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter you can also look at cat /sys/class/net/eth2/address etc Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Hi, it only affects all physical servers with bonded interfaces. we dont have any vm's with bonds but i am sure it will be replicated and have the same affect. attached is the output of facter --debug i cannot install the old ruby facter on production servers but can confirm this used to be correct and the mac address of the interface was the physical address not the bonded address. to me it looks like it now gets the information from ifconfig rather than from the device cheers Simon Attachments: facter-macaddress.txt - https://support.puppetlabs.com/attachments/token/pdPQs1iqfGmr5tZLpxgY8AJfx/?name=facter-macaddress.txt Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Linking ZenDesk with JIRA BUG ticket and assigned JIRA to Kylo as instructed in Gary's note below. This comment was made by Bill Niestempski on Mon Mar 28 14:27:42 PDT 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Thanks Simon. I think this is more of a network hardware issue and falls outside the purview of PE. In the meantime, I have raised DOCUMENT-506 which should clarify how the toplevel macaddress works. Let me know if theres anything else you need help on the puppet side or if you are comfortable in closing out this case. Thank you. Regards, Kranium This comment was made by Kranium Gikos on Wed Feb 17 05:31:04 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Sure Simon we can still keep this open. I need a few more things just so we can confirm that we can still extract the eth2 and eth3 macaddresses with ruby facter. Here are the steps needed to install ruby facter with the distro-provided rubygems. ``` yum install rubygems /usr/bin/gem install facter --user ~/.gem/ruby/1.8/bin/facter --debug ``` Let me know if you have any questions. Thank you. Regards, Kranium This comment was made by Kranium Gikos on Wed Feb 17 06:43:04 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Hi Simon, Thanks for writing in. I'm not able to find bugs related to mac addresses for new facter. I need your help in getting similar details (like we did in your earlier uuid case) so I could file a bug. 1. `ifconfig -a` output (or any other utility showing the bonded mac address) 2. `/opt/puppetlabs/bin/facter --debug` for the new facter output 3. `~/.gem/ruby/1.8/bin/facter --debug` for the ruby facter output (installed with the distro ie. `gem install facter --user && ~/.gem/ruby/2.2.0/bin/facter`) 4. is this issue present on all machines or is it isolated on a specific nic brand, os version, architecture? 5. is this issue present on physical or virtual machines or both? Let me know if you have any questions. Regards, Kranium This comment was made by Kranium Gikos on Fri Feb 12 02:41:27 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter added in todays handoff need help getting someone more experienced in mac adresses and bonding for the second issue below. This comment was made by Kranium Gikos on Tue Feb 23 07:51:58 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title
zendesk.jira commented on FACT-1374
Re: cfacter: toplevel macaddress fact behaves differently from ruby facter
notice how ruby facter uses `08:00:27:10:18:FB` instead of `08:00:27:ee:78:ab`. Need to check how ruby figures out what to use or the macaddress (maybe ordering of interfaces brought up?)
``` [root@centos67manualinst ~]# cat /sys/class/net/bond0/address 08:00:27:10:18:fb
[root@centos67manualinst ~]# cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: load balancing (round-robin) MII Status: up MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0
Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:10:18:fb Slave queue ID: 0
Slave Interface: eth2 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:19:d9:26 Slave queue ID: 0 ```
``` [root@centos67manualinst ~]# /opt/puppetlabs/puppet/bin/facter networking.mac 08:00:27:ee:78:ab [root@centos67manualinst ~]# /opt/puppetlabs/puppet/bin/facter macaddress 08:00:27:ee:78:ab [root@centos67manualinst ~]# ~/.gem/ruby/1.8/bin/facter macaddress 08:00:27:10:18:FB ```
``` [root@centos67manualinst ~]# /opt/puppetlabs/puppet/bin/facter macaddress_bond0 08:00:27:10:18:fb [root@centos67manualinst ~]# /opt/puppetlabs/puppet/bin/facter networking.interfaces.bond0.mac 08:00:27:10:18:fb [root@centos67manualinst ~]# ~/.gem/ruby/1.8/bin/facter macaddress_bond0 08:00:27:10:18:FB ```
``` [root@centos67manualinst ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 IPADDR=192.168.122.12 NETMASK=255.255.255.0 GATEWAY=192.168.122.1 NM_CONTROLLED=no BOOTPROTO=none _ONBOOT_=yes USERCTL=no
[root@centos67manualinst ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 DEVICE=eth1 USERCTL=no _ONBOOT_=yes NM_CONTROLLED=no MASTER=bond0 SLAVE=yes BOOTPROTO=none
[root@centos67manualinst ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth2 DEVICE=eth2 USERCTL=no _ONBOOT_=yes NM_CONTROLLED=no MASTER=bond0 SLAVE=yes BOOTPROTO=none ```
Facter::Util::FileRead.read('/etc/medialibrary.host')
This comment was made by Kranium Gikos on Tue Feb 16 13:38:12 PST 2016 from Zendesk
Add Comment
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter we cannot install on prod servers which are the ones with bonds. i can confirm this was all ok with ruby facter Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Customer not convinced that we have issues even if ifconfig shows the macaddress. need feedback if theres anything details we can ask from him. This comment was made by Kranium Gikos on Wed Feb 17 07:35:03 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Kranium and I spoke on this earlier today. We are tracking a half dozen or so ticket related to changes in facter that are breaking customer setups. Seem that IPADDR and MACADDRESS have changed. And UUID was reported as acting different across upgrades by this same customer. Need to see what is going on here... This comment was made by Bill Niestempski on Tue Feb 23 10:55:43 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter We do not use dhcpd for any ip addressing and use static ip assigned via puppet. the issue is that puppet assigned the bond mac rather than the physical mac. at os level the mac is the same so that the bond works but at boot the mac needs to be different when the interfaces are initialized. puppet used to get the correct ip but now does not. it looks to be getting the info from ifconfig bond0 Link encap:Ethernet HWaddr AC:16:2D:87:CA:9E inet addr:10.31.67.18 Bcast:10.31.67.255 Mask:255.255.255.0 inet6 addr: fe80::ae16:2dff:fe87:ca9e/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:22230068 errors:0 dropped:0 overruns:0 frame:0 TX packets:22848832 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4080886567 (3.8 GiB) TX bytes:5987578512 (5.5 GiB) bond1 Link encap:Ethernet HWaddr 00:60:DD:44:EB:22 inet6 addr: fe80::260:ddff:fe44:eb22/64 Scope:Link UP BROADCAST RUNNING MASTER MULTICAST MTU:9000 Metric:1 RX packets:1327059026 errors:0 dropped:0 overruns:0 frame:0 TX packets:314556466 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4849116919351 (4.4 TiB) TX bytes:1030275236233 (959.5 GiB) bond1.64 Link encap:Ethernet HWaddr 00:60:DD:44:EB:22 inet addr:10.31.64.32 Bcast:10.31.64.255 Mask:255.255.255.0 inet6 addr: fe80::260:ddff:fe44:eb22/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:1325390035 errors:0 dropped:0 overruns:0 frame:0 TX packets:314198253 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4825124440505 (4.3 TiB) TX bytes:1028969720131 (958.3 GiB) bond1.64:0 Link encap:Ethernet HWaddr 00:60:DD:44:EB:22 inet addr:10.31.64.130 Bcast:10.31.64.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 bond1.64:1 Link encap:Ethernet HWaddr 00:60:DD:44:EB:22 inet addr:10.31.64.129 Bcast:10.31.64.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 bond1.64:2 Link encap:Ethernet HWaddr 00:60:DD:44:EB:22 inet addr:10.31.64.128 Bcast:10.31.64.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 bond1.64:3 Link encap:Ethernet HWaddr 00:60:DD:44:EB:22 inet addr:10.31.64.127 Bcast:10.31.64.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 eth0 Link encap:Ethernet HWaddr 00:60:DD:44:EB:22 inet6 addr: fe80::260:ddff:fe44:eb22/64 Scope:Link UP BROADCAST RUNNING SLAVE MULTICAST MTU:9000 Metric:1 RX packets:900913132 errors:0 dropped:0 overruns:0 frame:0 TX packets:306737862 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:315472739 (2.8 TiB) TX bytes:1025296344196 (954.8 GiB) Interrupt:113 eth1 Link encap:Ethernet HWaddr 00:60:DD:44:EB:22 inet6 addr: fe80::260:ddff:fe44:eb22/64 Scope:Link UP BROADCAST RUNNING SLAVE MULTICAST MTU:9000 Metric:1 RX packets:426145894 errors:0 dropped:0 overruns:0 frame:0 TX packets:7818604 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1694316926612 (1.5 TiB) TX bytes:4978892037 (4.6 GiB) Interrupt:113 eth2 Link encap:Ethernet HWaddr AC:16:2D:87:CA:9C BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter reference FACT-1374 for the jira bug This comment was made by Kranium Gikos on Wed Mar 23 07:51:56 PDT 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter I think your missing the point. Just setup a vm with 2 interfaces and then bond them. At device level they will have different macs but at os level they will be the same to enable failover. Ruby facter used the device level and was correct. New facter seems to use ifconfig or similar and gets incorrect mac address. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Hi, any update on this case? Please review the case once more for possible resolution. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter i managed to replicate his issue where setting up duplicate mac addresses on virtualbox renames the interfaces to something like rename3/rename4. this is not a bug in puppet though. while 'facter macaddress' behaves differently in cfacter and ruby facter. this is not related the issue. he claims that eth2 and eth3 on his setup should have unique macs in PE 3.8.x i asked him to install ruby facter using the distro's gem command just to confirm if there is indeed a regression. next steps: we need data to convince him that this is not a facter issue as `ifconfig` already shows that the mac is the same. need to further investigate if his ruby facter returns a unique eth2/eth3 result This comment was made by Kranium Gikos on Wed Feb 17 08:01:38 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter nothing in JIRA. closest is but this might be related to IPs and not mac addrs FACT-1315(https://tickets.puppetlabs.com/browse/FACT-1315) facter error with IP aliases containing '@' (e.g. while running in Docker containers) This comment was made by Kranium Gikos on Fri Feb 12 03:00:23 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter I'll try to setup an enviroment where we can get multiple nics to have duplicate mac addresses. Can you send us a tar/zip of the server's /etc/sysconfig/network-scripts/ so we can replicate your setup? Regards, Kranium This comment was made by Kranium Gikos on Fri Feb 19 07:50:09 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter Hi Simon, I've been testing this and there is indeed a difference in behavior due to the toplevel macaddress fact being introduced for backwards compatibility. Can you show us how the macaddress is referenced in your configuration? The fix may just be using `networking.interfaces.bond0.mac` for your case. ``` [root@centos67manualinst ~]# /opt/puppetlabs/puppet/bin/facter networking.interfaces.bond0.mac 08:00:27:10:18:fb [root@centos67manualinst ~]# cat /sys/class/net/bond0/address 08:00:27:10:18:fb [root@centos67manualinst ~]# cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: load balancing (round-robin) MII Status: up MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:10:18:fb Slave queue ID: 0 Slave Interface: eth2 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 08:00:27:19:d9:26 Slave queue ID: 0 ``` If you still encounter issues, please send us a zip of the whole /etc/sysconfig/network-scripts/ so we can could have a test case closer to your setup. Thank you. Regards, Kranium This comment was made by Kranium Gikos on Tue Feb 16 14:16:42 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title zendesk.jira commented on FACT-1374 Re: cfacter: toplevel macaddress fact behaves differently from ruby facter this boils down to 2 issues 1. regression in the toplevel mac address ``` [root@centos67manualinst ~]# /opt/puppetlabs/puppet/bin/facter macaddress 08:00:27:ee:78:ab [root@centos67manualinst ~]# ~/.gem/ruby/1.8/bin/facter macaddress 08:00:27:10:18:FB ``` 2. customer claims that we arent pulling the right mac for bonded interfaces. ifconfig doesnt even show the right requests but this customer insists that this is our issue. This comment was made by Kranium Gikos on Tue Feb 23 07:13:16 PST 2016 from Zendesk Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1374) cfacter: toplevel macaddress fact behaves differently from ruby facter
Title: Message Title Bill Niestempski assigned an issue to Kylo Ginsberg Facter / FACT-1374 cfacter: toplevel macaddress fact behaves differently from ruby facter Change By: Bill Niestempski Assignee: Kylo Ginsberg Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2574) return reason for json malformation if a malformed query is submitted
Title: Message Title Wyatt Alt created an issue PuppetDB / PDB-2574 return reason for json malformation if a malformed query is submitted Issue Type: Bug Assignee: Unassigned Created: 2016/03/28 2:19 PM Priority: Normal Reporter: Wyatt Alt When a malformed query is submitted, we no longer return the reason it's invalid (imbalanced brackets, expecting comma, etc). This makes it difficult to debug malformed queries. The bug was introduced here: https://github.com/puppetlabs/puppetdb/pull/1845 probably a simple fix. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (PUP-3830) Automatic quoting of install_options breaks NullSoft installation directory parameter
Title: Message Title Rob Reynolds commented on PUP-3830 Re: Automatic quoting of install_options breaks NullSoft installation directory parameter Nobody to tell this to, but you do this with install_options => [ '/D=C:\Path', 'with', 'spaces'], Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6035) Puppet Throws Exception when Running Under Unicode Windows User
Title: Message Title Steve Barlow updated an issue Puppet / PUP-6035 Puppet Throws Exception when Running Under Unicode Windows User Change By: Steve Barlow Fix Version/s: PUP 4.4.2 Fix Version/s: PUP 4.5.0 Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6034) Bundler Fails when Running Under a Unicode Windows User
Title: Message Title Steve Barlow updated an issue Puppet / PUP-6034 Bundler Fails when Running Under a Unicode Windows User Change By: Steve Barlow Fix Version/s: PUP 4.4.2 Fix Version/s: PUP 4.x Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-532) (#22719) Allow exec to runas different user on windows
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-532 (#22719) Allow exec to runas different user on windows Change By: Rob Reynolds Labels: exec windows Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6026) Audit Windows::Error.new for additional eaten exceptions
Title: Message Title Steve Barlow updated an issue Puppet / PUP-6026 Audit Windows::Error.new for additional eaten exceptions Change By: Steve Barlow Fix Version/s: PUP 4.4.2 Fix Version/s: PUP 4.x Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-532) (#22719) Allow exec to runas different user on windows
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-532 (#22719) Allow exec to runas different user on windows Change By: Rob Reynolds Component/s: Windows Component/s: Types and Providers Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-532) (#22719) Allow exec to runas different user on windows
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-532 (#22719) Allow exec to runas different user on windows Change By: Rob Reynolds Component/s: PE Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-532) (#22719) Allow exec to runas different user on windows
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-532 (#22719) Allow exec to runas different user on windows Change By: Rob Reynolds Story Points: 3 5 Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4866) PMT and Plug-in Sync Should Use Long File Name (LFN) Paths on Windows
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-4866 PMT and Plug-in Sync Should Use Long File Name (LFN) Paths on Windows Change By: Rob Reynolds Sprint: Windows Triage Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-532) (#22719) Allow exec to runas different user on windows
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-532 (#22719) Allow exec to runas different user on windows Change By: Rob Reynolds Sprint: Windows Triage Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6101) fail to start puppetserver
Title: Message Title Yishuang Liang created an issue Puppet / PUP-6101 fail to start puppetserver Issue Type: Bug Assignee: Unassigned Created: 2016/03/28 1:38 PM Environment: REHL5 Ruby 1.8.7 Fix Versions: PUP 4.4.1, PUP 4.4.0 Priority: Normal Reporter: Yishuang Liang Hi, I tried to install puppet open source 4.4 but couldn't start the puppetserver on my server. Here's the exception message from the log file: java.lang.IllegalStateException: There was a problem adding a JRubyPuppet instance to the pool. at puppetlabs.services.jruby.jruby_puppet_agents$eval6667$prime_pool_BANG__6668$fn_6672.invoke(jruby_puppet_agents.clj:60) ~[na:na] at puppetlabs.services.jruby.jruby_puppet_agents$eval6667$prime_pool_BANG___6668.invoke(jruby_puppet_agents.clj:38) ~[na:na] at puppetlabs.services.jruby.jruby_puppet_agents$eval6773$send_prime_pool_BANG__6774$fn6775$fn_6777.invoke(jruby_puppet_agents.clj:133) ~[na:na] at puppetlabs.trapperkeeper.internal$shutdown_on_error_STAR_.invoke(internal.clj:254) [na:na] at puppetlabs.trapperkeeper.internal$shutdown_on_error_STAR_.invoke(internal.clj:238) [na:na] at
Jira (PUP-6101) fail to start puppetserver
Title: Message Title Yishuang Liang updated an issue Puppet / PUP-6101 fail to start puppetserver Change By: Yishuang Liang Environment: REHL5 REHL 5 Ruby 1.8.7 Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6100) Question / Feature Request: Make value of "configuration version" visible to puppet manifests
Title: Message Title Johnson Earls created an issue Puppet / PUP-6100 Question / Feature Request: Make value of "configuration version" visible to puppet manifests Issue Type: Improvement Assignee: Unassigned Components: Puppet Server Created: 2016/03/28 1:21 PM Priority: Normal Reporter: Johnson Earls Is there any way to see the contents of the "configuration version" from a Puppet manifest? I'm talking about the string referenced in this line of the agent log: Info: Applying configuration version '1459195956' I know that configuration version can be generated by an external script, or can have a default value of a timestamp of when the agent run began. In either case, I would like to be able to access this value from my Puppet modules. is this possible? Add Comment
Jira (PUP-5482) Should a not found resource type be marked as such?
Title: Message Title Nicholas Fagerlund commented on PUP-5482 Re: Should a not found resource type be marked as such? Jorie Tappa This might entail a change to the config_important_settings page. Maybe. But if I remember correctly, Puppet Server hardcoded the prior version of this setting to the proper value. Hopefully they'll do the same for this one, and it'll be a no-op for the user, just a performance improvement. (But anyone still using Passenger will have to set it themselves.) Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5482) Should a not found resource type be marked as such?
Title: Message Title Nicholas Fagerlund updated an issue Puppet / PUP-5482 Should a not found resource type be marked as such? Change By: Nicholas Fagerlund Component/s: DOCS Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6097) YUM/APT package providers require architecture as part of package version
Title: Message Title Michael Smith updated an issue Puppet / PUP-6097 YUM/APT package providers require architecture as part of package version Change By: Michael Smith Story Points: 3 Sprint: Client 2016-04-20 (Bigga Bugs) Scrum Team: Client Platform Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6097) YUM/APT package providers require architecture as part of package version
Title: Message Title Michael Smith commented on PUP-6097 Re: YUM/APT package providers require architecture as part of package version Need to review how much this duplicates existing tickets. William Hopper probably has the most context. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2547) Add in new clj-i18n scaffolding to PuppetDB
Title: Message Title Andrew Roetker assigned an issue to Unassigned PuppetDB / PDB-2547 Add in new clj-i18n scaffolding to PuppetDB Change By: Andrew Roetker Assignee: Andrew Roetker Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2570) tweak docs on fact path querying
Title: Message Title Wyatt Alt assigned an issue to Wyatt Alt PuppetDB / PDB-2570 tweak docs on fact path querying Change By: Wyatt Alt Assignee: Wyatt Alt Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6075) Solution to optimize resolution of TypeReference for known Resource types is broken
Title: Message Title Sean Griffin assigned an issue to Sean Griffin Puppet / PUP-6075 Solution to optimize resolution of TypeReference for known Resource types is broken Change By: Sean Griffin Assignee: qa Sean Griffin Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6099) Additional file and mount autorequire
Title: Message Title
Matt Schuchard updated an issue
Puppet / PUP-6099
Additional file and mount autorequire
Change By:
Matt Schuchard
Given the following catalog:{noformat}File[/path/to/dir]Mount[/path/to/dir]File[/path/to/dir/alsodir/]Mount[/path/to/dir/alsodir]{noformat}there will be the following autorequires:{noformat}File[/path/to/dir] -> File[/path/to/dir/alsodir]Mount[/path/to/dir] -> Mount[/path/to/dir/alsodir]{noformat}but not the following autorequires:{noformat}File[/path/to/dir] -> Mount[/path/to/dir]File[/path/to/dir/alsodir] -> Mount[/path/to/dir/alsodir] File Mount [/path/to/dir /alsodir ] -> Mount File [/path/to/dir /alsodir ]{noformat}I will seek to remedy this (may be a few days before I PR this).
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6099) Additional file and mount autorequire
Title: Message Title
Matt Schuchard updated an issue
Puppet / PUP-6099
Additional file and mount autorequire
Change By:
Matt Schuchard
Given the following catalog:{ { noformat} File[/path/to/dir]Mount[/path/to/dir]File[/path/to/dir/alsodir/]Mount[/path/to/dir/alsodir] {noformat } } there will be the following autorequires:{ { noformat} File[/path/to/dir] -> File[/path/to/dir/alsodir]Mount[/path/to/dir] -> Mount[/path/to/dir/alsodir] {noformat } } but not the following autorequires:{ { noformat} File[/path/to/dir] -> Mount[/path/to/dir]File[/path/to/dir/alsodir] -> Mount[/path/to/dir/alsodir]File[/path/to/dir/alsodir] -> Mount[/path/to/dir] {noformat } } I will seek to remedy this (may be a few days before I PR this).
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6099) Additional file and mount autorequire
Title: Message Title
Matt Schuchard created an issue
Puppet / PUP-6099
Additional file and mount autorequire
Issue Type:
Improvement
Assignee:
Matt Schuchard
Components:
Types and Providers
Created:
2016/03/28 6:58 AM
Environment:
Linux
Fix Versions:
PUP 4.4.2
Priority:
Normal
Reporter:
Matt Schuchard
Given the following catalog:
{{File[/path/to/dir] Mount[/path/to/dir] File[/path/to/dir/alsodir/] Mount[/path/to/dir/alsodir]}}
there will be the following autorequires:
{{File[/path/to/dir] -> File[/path/to/dir/alsodir] Mount[/path/to/dir] -> Mount[/path/to/dir/alsodir]}}
but not the following autorequires:
{{File[/path/to/dir] -> Mount[/path/to/dir] File[/path/to/dir/alsodir] -> Mount[/path/to/dir/alsodir] File[/path/to/dir/alsodir] -> Mount[/path/to/dir]}}
I will seek to remedy this (may be a
Jira (PUP-4412) Allow automatic parameter lookups to collect metaparameters
Title: Message Title Matt Schuchard commented on PUP-4412 Re: Allow automatic parameter lookups to collect metaparameters Would this be a worthwhile addition to stdlib? I assume that function is too esoteric for a Puppet intrinsic. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
