#chef

/

      • coderanger
        More likely you just have bitrot in your dependencies
      • lesceil
        because I can't afford messing that one up
      • coderanger
        And, again, you need to track down the conflict, manually
      • This is not related to Chef Server
      • Find the conflict and then decide what to about it
      • cheeseplus
        I'm with coderanger on this one, it's no fun but I think the attribution of it's failure is a red herring
      • coderanger
        I mean the failure of Chef Server and subsequent re-uploading probably removed something that was masking the bitrot
      • But bitrot it is none the less
      • lesceil
        Probably fundamentally true. Most likely scenario is that the bitrot of dependencies was masked by chef server state and using the chef server as a source, and so when the one chef server got damaged, using it as a source did no longer mask the issue
      • GenteelBen has quit
      • coderanger
        lesceil: The usual term for this is "metastable solution"
      • cdown has quit
      • Unfortunately berks (or any SAT solver) has no way to tell if the solution it found was metastable or not
      • lesceil
        I can probably prove it out without breaking prod by temporarily removing source there and remove Berksfile.lock and run berks install but not berks upload
      • coderanger
        Or, and I can't say this any differently, look at each cookbook mentioned in the error, figure out where it is coming from and manually asses the dependency constraints
      • I don't really know why you are refusing to do this, but that's what you need to do
      • If you're unfamiliar with Chef and cookbook metadata, maybe ping someone else on your team that can help, but regardless it's the way forward.
      • You'll probably find something that is newer than you expect and needs to be pinned bac
      • back
      • lesceil
        I agree.
      • The problem is that it is not my cookbooks that changed but the ones being pulled in as dependency, so checking those is more complicated.
      • but I guess I just have to work through that.
      • coderanger
        Indeed
      • I didn't say it was easy
      • _f1gm3nt joined the channel
      • hi11111 has quit
      • ryancrowq has quit
      • lesceil
        such a nightmare.
      • coderanger
        Dependency management is hard, and from the looks of your berksfile you were probably set up for bad times by whomever came before you
      • cheeseplus
        it did read like a bit of a boobytrap
      • lesceil
        because of using chef-server as a secondary source ?
      • any feedback welcome
      • coderanger
        That and the heavy use of path and git sources
      • Both of which are usually a bad idea
      • lesceil
        isnt it the only way out of the external dependency hell ? I should have pulled each and every working cookbook into our own git repo and used that in a stable manner
      • immortalhsk has quit
      • coderanger
        Git is the wrong thing to use
      • lesceil
        but then again if the underlying OS changes I wont get the fixes and adaptions
      • coderanger
        Making a private supermarket and manually mirroring stuff over is thumbsup
      • And then use that server as the _only_ source for berks
      • lesceil
        whats the dfiference
      • I mean, what does it do better that way that failed here
      • coderanger
        git doesn't allow a version solution to be run, so you have to manually manage whats in master or specify other branches in every berksfile
      • If you want a "ride master all the time" workflow, Policies are much better than berks for that
      • since then you can get the same version day to day even when using a git-based or snapshot-based release flow
      • But berks works best treating things like more traditional packages
      • use path/git sources for local dev or specific overrides
      • lesceil
        I did have to hack my own branch of apache2 to get php7 to work on debian8
      • using dotdeb
      • coderanger
        Yeah, for stuff like that it's acceptable as a hack, but not a good long term solution :)
      • lesceil
        but long term I need the flexibility to apply such a hack, even if this one hack goes away later when apache2 properly supports php7 or we move to debian 9 or whatever it will be
      • that supports php7 out of the box
      • coderanger
        Long term you would formally fork the cookbook and rename it, and then upload it to your private supermarket
      • Note that this means anything using the old name becomes a liability
      • Dealing with coop forks in any release flow is ... hard
      • wlightning-fuel has quit
      • wlightning-fuel joined the channel
      • wlightning-fuel has quit
      • wlightning-fuel joined the channel
      • kexmex has quit
      • geggam joined the channel
      • AllanEspinosa joined the channel
      • mikedodge04 joined the channel
      • lesceil
        Any reason not to install the private supermarket on the same server as the chef server ?
      • coderanger
        Yes, I don't think we support that because both expect to own port 443
      • treenerd__ has quit
      • eroux has quit
      • eroux joined the channel
      • geggam has quit
      • lesceil
        could just use a different port ?
      • coderanger
        Both are shipped as appliances more or less, so not recommended
      • Just use two VMs
      • despai has quit
      • despai joined the channel
      • cajone has quit
      • che3000 joined the channel