#puppet-dev

/

      • nerfbat__ joined the channel
      • Dominic_ joined the channel
      • Rynor joined the channel
      • dieterde1eyer joined the channel
      • nibalize1 joined the channel
      • Charles_1UDITH joined the channel
      • shr3kst3r joined the channel
      • _morgan_ joined the channel
      • Hunner_ joined the channel
      • gnarf has quit
      • Dominic has quit
      • shr3kst3r_ has quit
      • dieterdemeyer has quit
      • Charles_JUDITH has quit
      • nerfbat_ has quit
      • _morgan has quit
      • Hunner has quit
      • gnarf_ joined the channel
      • nibalizer has quit
      • Rynor_ has quit
      • github joined the channel
      • NOTICE: [puppetdb] kbarber pushed 2 new commits to stable: https://github.com/puppetlabs/puppetdb/compare/4cbc0985539a...4999180847e5
      • NOTICE: puppetdb/stable 403073f wkalt: (maint/stable) fix documented behavior of =...
      • NOTICE: puppetdb/stable 4999180 Ken Barber: Merge pull request #1070 from wkalt/maint/stable/equality-operator-fix...
      • github has left the channel
      • book` has quit
      • book` joined the channel
      • book` has quit
      • book` joined the channel
      • book` has quit
      • book` joined the channel
      • ken_barber
        dalen: we were going to ship a wildcard capability in a different operator but backed it out since the regexp one does it anyway, if its solve-able on the client side this is great, we would also consider a server side "friendly" way of achieving this if we had enough demand.
      • RobertBirnie joined the channel
      • RobertBirnie has quit
      • KiloNiner joined the channel
      • KiloNiner has quit
      • daff has quit
      • hogepodge joined the channel
      • mfisch has quit
      • mfisch joined the channel
      • mfisch has quit
      • mfisch joined the channel
      • mfisch has quit
      • mfisch joined the channel
      • mfisch has quit
      • mfisch joined the channel
      • daff joined the channel
      • project2501a has quit
      • tobamai joined the channel
      • alaunay joined the channel
      • dgurtner joined the channel
      • project2501a joined the channel
      • alaunay has quit
      • alaunay joined the channel
      • Dominic_
        daenney: nah, nobody's working on it (pf, augeas). We have some of the core types done in augeasproviders, but most aren't there.
      • Dominic_ is now known as Dominic
      • daenney
        Dominic: Oh, bummer. I really liked that idea from the dev summit
      • helindbe joined the channel
      • helindbe
        ken_barber: I have a question about how things are stored in puppet db - yt?
      • From another thread I learned that integers are stored as PostgreSQL bigInt, which is 64 bit signed IIRC
      • oh, too early in the UK...
      • Dominic
        depends, *stifles yawn* :)
      • hadba joined the channel
      • Jippi joined the channel
      • tobamai has quit
      • friendly12345 has left the channel
      • dgurtner has quit
      • dgurtner joined the channel
      • JohnnyRun joined the channel
      • Jippi_ joined the channel
      • gcha joined the channel
      • Charles_1UDITH is now known as Charles_JUDITH
      • Jippi has quit
      • Jippi_ is now known as Jippi
      • raphink joined the channel
      • raphink has quit
      • raphink joined the channel
      • jeffweiss joined the channel
      • zz_ming2k is now known as ming2k
      • leoc
        Hi people. Does anyone have a hint on using service on debian > 6.0, which relies on insserv rather than update-rc.d. Have there been efforts to create a fix?
      • gwmngilfen is now known as gwmngilfen|afk
      • electrical
        Morning leoc
      • my puppet modules work on debian 6 and 7 without any issues. what issues are you running into?
      • leoc
        electrical: Hi! It seems like that my problems arise from a bug in puppet (or so I assume). Debian is using insserv/dependency based boot sequencing. The enabled? check for the service provider for debian returns a statuscode that seems not to be handled correctly by puppet. It says 101 - not allowed. But puppet assumes the service is not enabled, although it is enabled by insserv ... so it reenables the service each puppet run.
      • daenney
        I think just about any exit code other than 0 is treated as "not in the state we want it" and is tried again
      • electrical
        leoc: hmm interesting. Never had this kind of issue.
      • leoc
        105 is treated as "unknown" which leads to a manual check of /etc/rc*.d
      • I think 101 should also trigger a manual check instead of just assuming that the service is not enabled
      • daenney
        In that case you probably should look for a ticket on tickets.puppetlabs.com and if none exist raise a new one
      • 100-149 are exit codes in LSB 'reserved for distribution usage', so that's always fun
      • leoc
        Although, I am not quite sure why update-rc.d is still in use and not insserv? It seems a little messy to me. I read everywhere that insserv should be the way to go with debian > 6.0?
      • daenney
        insserv is only used if dependency based booting is enabled
      • If you come from an upgrade, there's no guarantee insserv is the right choice
      • update-rc.d has been rewritten to call insserv/do the right thing, when it detects dependency based booting has been enabled
      • It even outputs a message for that
      • It's mostly dependant on having hte right LSB headers in the init scripts
      • leoc
        Ah! I thought that might just be a hint for the user to use insserv.
      • daenney
      • It's only a part of update-rc.d but as you can see, it calls the insserve_updatercd routine if necessary
      • leoc
        Alright. Thanks for the clarification. I should stop assuming. :-)
      • So invoke-rc.d does not know anything about insserv ...
      • daenney
        Your idea about the exit code not being handled properly seems solid though
      • I wouldn't use invoke-rc.d, /sbin/service handles everything correctly
      • That'll also transition smoothly to systemd
      • leoc
        My atteempt to fix the provider right now is to just add 101, 105 to the manual checked exit codes. Although service sounds much cleaner :-/
      • daenney
        Which provider are you looking at?
      • leoc
        How would service check for enabled services? I thought that just handles start/stop/restart/status?
      • That would be the line to just add 101
      • Since the four files in /etc/rc*.d exist as expected
      • gwmngilfen|afk is now known as gwmngilfen
      • jeffweiss has quit
      • jeffweiss joined the channel
      • jeffweiss has quit
      • ming2k is now known as zz_ming2k
      • zz_ming2k is now known as ming2k
      • jeffweiss joined the channel
      • jeffweiss has quit
      • robinbowes is now known as yo61
      • helindbe
        Volcane: yt? have questions about hiera, environments and data in modules...
      • Volcane
        sure
      • how are you doing?
      • helindbe
        great - we are getting ready to release 3.7 and start on 4.0 in earnest
      • seems we will have time to address data in modules for 4.0
      • and since we talked last about it, a lot has happened with environments
      • my question is about how hiera supports environments, this because it starts very early
      • Volcane
        yeah - though hiera doesnt really do environments last i checked right?
      • helindbe
        to be able to be used in an ENC
      • Volcane
        yeah
      • helindbe
        yes, that is my recollection too
      • so what happens if someone wants to use hiera for ENC and also use data in modules
      • Volcane
        it would be good to have different hiera configs per env for sure and also to be able to set environment at a stretch
      • helindbe
        the set of modules changes per environment
      • Volcane
        the general solution is to just use %{::environment} in the hierarchy declaration
      • but this forces you to use the same hierarchy across all environments which many people find not to be ideal
      • helindbe
        yes, I can imagine
      • and with data in modules I suspect it gets quite messy
      • do you see usecases where data in modules are meaningful other then when the compiler is used?
      • Volcane
        when hiera was written it was an external plugin of course, and you cant add options to puppet from hte outside so that was all i could do - good target for improvement
      • no dont think it matters to data in modules at all? in what sense do you see it as messy?
      • helindbe
        ok, just a suspicion - expecting to get stuff from modules before it is fully known which modules to use etc (same kind of problems as with faces)
      • Volcane
        oh, no that wont be a problem
      • helindbe
        great
      • Volcane
        the data in modules only comes in when you use the module
      • well
      • i should say
      • it works cos of the lazy loading which i know ppl dont seem to like, so if you are gonna try and resolve all data upfront in a hiera rewrite rather than on demand as now, yes its a problem
      • but for now, when puppet comes across class foo($bar) it just looks up foo::bar
      • and data in modules only come in on that point and generally it just fiddles the hierarchy to include module foo's data in there at that point only
      • helindbe
        yes, I read the code