Jira (FACT-622) changes to ordering in custom facts breaks things

2014-07-24 Thread Tim Hartmann (JIRA)
Title: Message Title










 

 Tim Hartmann commented on an issue


















  Re: changes to ordering in custom facts breaks things 










Any ideas, or is this our own hacktastic ruby biting us in the bum? 












   

 Add Comment

























 Facter /  FACT-622



  changes to ordering in custom facts breaks things 







 *edit* Looks like this also exists in 2.0.1 - so this may just mean that our custom facts aren't backwards compatible with the new loading logic. Is there a way to order facts if they are sourced from two different files, so that one depends correctly on the other, without filename precedence? *edit*   We have a set of custom fact called node_type.rb whi...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (FACT-622) changes to ordering in custom facts breaks things

2014-07-18 Thread Tim Hartmann (JIRA)
Title: Message Title










 

 Tim Hartmann commented on an issue


















  Re: changes to ordering in custom facts breaks things 










Adrien Thebo NP I'll post the code in question, does a gist work?












   

 Add Comment

























 Facter /  FACT-622



  changes to ordering in custom facts breaks things 







 *edit* Looks like this also exists in 2.0.1 - so this may just mean that our custom facts aren't backwards compatible with the new loading logic. Is there a way to order facts if they are sourced from two different files, so that one depends correctly on the other, without filename precedence? *edit*   We have a set of custom fact called node_type.rb whi...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (FACT-622) changes to ordering in custom facts breaks things

2014-07-18 Thread Tim Hartmann (JIRA)
Title: Message Title










 

 Tim Hartmann commented on an issue


















  Re: changes to ordering in custom facts breaks things 










Here ya go  
Adding  if Facter.value(puppet_classes).nil? puts 'NIL' #done else
to the nodes_type.rb facts script returns NIL so, it looks like the pupept_classes value is empty... some of the time... by that I mean, on two nodes configured identically one gets a nil back, and the other gets the fact values set. 
https://gist.github.com/tfhartmann/570874b88e74a01125b4 https://gist.github.com/tfhartmann/bc556037f9e945a4a856












   

 Add Comment

























 Facter /  FACT-622



  changes to ordering in custom facts breaks things 







 *edit* Looks like this also exists in 2.0.1 - so this may just mean that our custom facts aren't backwards compatible with the new loading logic. Is there a way to order facts if they are sourced from two different files, so that one depends correctly on the other, without filename precedence? *edit*   We have a set of custom fact called node_type.rb whi...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 

Jira (FACT-622) changes to ordering in custom facts breaks things

2014-07-17 Thread Tim Hartmann (JIRA)
Title: Message Title










 

 Tim Hartmann commented on an issue


















  Re: changes to ordering in custom facts breaks things 










Crap, and my super cool hacky fix of renaming the fact.rb file didn't seem to work after all.. (sadpanda)












   

 Add Comment

























 Facter /  FACT-622



  changes to ordering in custom facts breaks things 







 *edit* Looks like this also exists in 2.0.1 - so this may just mean that our custom facts aren't backwards compatible with the new loading logic. Is there a way to order facts if they are sourced from two different files, so that one depends correctly on the other, without filename precedence? *edit*   We have a set of custom fact called node_type.rb whi...















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (FACT-622) changes to ordering in custom facts breaks things

2014-07-15 Thread Tim Hartmann (JIRA)
Title: Message Title










 

 Tim Hartmann created an issue


















 Facter /  FACT-622



  changes to ordering in custom facts breaks things 










Issue Type:

  Bug




Affects Versions:


 2.0.2




Assignee:

 Eric Sorenson




Created:


 15/Jul/14 8:47 AM




Priority:

  Normal




Reporter:

 Tim Hartmann










We have a set of custom fact called node_type.rb which requires the output of a fact called puppet_classes which is in puppet_classes.rb, in with facter 2.0.1, puppet_classes is loaded first and then node_type runs, creating a set of facts that we use, however in version 2.0.2 this isn't the case. Renaming the puppet_classes.rb file to something like apuppet_classes.rb resolved the issue. 
It's unclear from the facter docs how to explicitly set the ordering in the code, is this a place where we should be using a confine? Facter precedence with weighting? 
I know this is something we can fix on our end, but having it break unexpectedly was a bit of a shocker. 
Thanks for taking a look! 
 facter]# facter -p | grep _node gluster_node = false gpu_node = false holyoke_node = false lustre_node = false
mv puppet_classes.rb apuppet_classes.rb
facter]# facter -p | grep _node access_node = false backup_node = false compute_node = false gluster_node = false gpu_node = false holyoke_node = false hybrid_node = false kvm_node = false lustre_node = false ncf_node = false







 

Jira (FACT-622) changes to ordering in custom facts breaks things

2014-07-15 Thread Tim Hartmann (JIRA)
Title: Message Title










 

 Tim Hartmann updated an issue


















 Facter /  FACT-622



  changes to ordering in custom facts breaks things 










Change By:

 Tim Hartmann




Affects Version/s:

 2.0.1









 *edit*Lookslikethisalsoexistsin2.0.1-sothismayjustmeanthatourcustomfactsaren'tbackwardscompatiblewiththenewloadinglogic.Isthereawaytoorderfactsiftheyaresourcedfromtwodifferentfiles,sothatonedependscorrectlyontheother,withoutfilenameprecedence? Wehaveasetofcustomfactcallednode_type.rbwhichrequirestheoutputofafactcalledpuppet_classeswhichisinpuppet_classes.rb,inwithfacter2.0.1,puppet_classesisloaded*first*andthennode_typeruns,creatingasetoffactsthatweuse,howeverinversion2.0.2thisisn'tthecase.Renamingthepuppet_classes.rbfiletosomethinglikeapuppet_classes.rbresolvedtheissue.It'sunclearfromthefacterdocshowtoexplicitlysettheorderinginthecode,isthisaplacewhereweshouldbeusingaconfine?Facterprecedencewithweighting?Iknowthisissomethingwecanfixonourend,buthavingitbreakunexpectedlywasabitofashocker.Thanksfortakingalook!facter]#facter-p|grep_nodegluster_node=falsegpu_node=falseholyoke_node=falselustre_node=falsemvpuppet_classes.rbapuppet_classes.rbfacter]#facter-p|grep_nodeaccess_node=falsebackup_node=falsecompute_node=falsegluster_node=falsegpu_node=falseholyoke_node=falsehybrid_node=falsekvm_node=falselustre_node=falsencf_node=false












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
You received this message because 

Jira (FACT-622) changes to ordering in custom facts breaks things

2014-07-15 Thread Tim Hartmann (JIRA)
Title: Message Title










 

 Tim Hartmann updated an issue


















 Facter /  FACT-622



  changes to ordering in custom facts breaks things 










Change By:

 Tim Hartmann









 *edit*Lookslikethisalsoexistsin2.0.1-sothismayjustmeanthatourcustomfactsaren'tbackwardscompatiblewiththenewloadinglogic.Isthereawaytoorderfactsiftheyaresourcedfromtwodifferentfiles,sothatonedependscorrectlyontheother,withoutfilenameprecedence? *edit* Wehaveasetofcustomfactcallednode_type.rbwhichrequirestheoutputofafactcalledpuppet_classeswhichisinpuppet_classes.rb,inwithfacter2.0.1,puppet_classesisloaded*first*andthennode_typeruns,creatingasetoffactsthatweuse,howeverinversion2.0.2thisisn'tthecase.Renamingthepuppet_classes.rbfiletosomethinglikeapuppet_classes.rbresolvedtheissue.It'sunclearfromthefacterdocshowtoexplicitlysettheorderinginthecode,isthisaplacewhereweshouldbeusingaconfine?Facterprecedencewithweighting?Iknowthisissomethingwecanfixonourend,buthavingitbreakunexpectedlywasabitofashocker.Thanksfortakingalook!facter]#facter-p|grep_nodegluster_node=falsegpu_node=falseholyoke_node=falselustre_node=falsemvpuppet_classes.rbapuppet_classes.rbfacter]#facter-p|grep_nodeaccess_node=falsebackup_node=falsecompute_node=falsegluster_node=falsegpu_node=falseholyoke_node=falsehybrid_node=falsekvm_node=falselustre_node=falsencf_node=false












   

 Add Comment






















 This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)




 














-- 
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