Uploaded image for project: 'Bigtop'
  1. Bigtop
  2. BIGTOP-1870

Latest version of Puppet::Apt doesn't work for our deployment recipes

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.8.0
    • Fix Version/s: 1.0.0
    • Component/s: deployment
    • Labels:
      None

      Description

      An attempt to deploy the cluster is producing

      Invalid parameter disable_keys
      

      It seems that with the latest version of Puppet::Apt module (2.0.1) the following two parameters are no longer valid

      • disable_keys
      • include_src

      We have an option to pin version 1.8.0 of the Apt module, or fix our deployment recipes. Evans Ye is it possible for you to take a look at it? Thanks!

        Issue Links

          Activity

          Hide
          evans_ye Evans Ye added a comment -

          I think the same. Close as resolved.

          Show
          evans_ye Evans Ye added a comment - I think the same. Close as resolved.
          Hide
          cos Konstantin Boudnik added a comment -

          I guess now we can close this one?

          Show
          cos Konstantin Boudnik added a comment - I guess now we can close this one?
          Hide
          evans_ye Evans Ye added a comment -

          OK. Let create one and put the patch over there.

          Show
          evans_ye Evans Ye added a comment - OK. Let create one and put the patch over there.
          Hide
          cos Konstantin Boudnik added a comment -

          Looks good! Shall we commit it as a separate JIRA? Although, I don't care other way

          Show
          cos Konstantin Boudnik added a comment - Looks good! Shall we commit it as a separate JIRA? Although, I don't care other way
          Hide
          evans_ye Evans Ye added a comment -

          That would be much easier to me. As I know there's no easy way to get module version instead of doing Exec with grep and awk, so I'll just suggest users to leverage our toolchain to get the newest version of modules. The code will be neat if we don't go if-else implementation as well.
          Attach BIGTOP-1870-document.patch to address cos's comment.

          Show
          evans_ye Evans Ye added a comment - That would be much easier to me. As I know there's no easy way to get module version instead of doing Exec with grep and awk, so I'll just suggest users to leverage our toolchain to get the newest version of modules. The code will be neat if we don't go if-else implementation as well. Attach BIGTOP-1870 -document.patch to address cos's comment.
          Hide
          cos Konstantin Boudnik added a comment -

          Honestly - I would just document it on the wiki or something. This seems to be a pretty rare corner case, that might or mightn't happen in the wild.
          Another option is to do the version check and err out: supporting all possible versions of the module seems to be an overkill.

          Show
          cos Konstantin Boudnik added a comment - Honestly - I would just document it on the wiki or something. This seems to be a pretty rare corner case, that might or mightn't happen in the wild. Another option is to do the version check and err out: supporting all possible versions of the module seems to be an overkill.
          Hide
          evans_ye Evans Ye added a comment -

          OKAY. Olaf Flebbe sent me many words to describe his scenario. I can reproduce it now.
          The failure happened when running bigtop puppet alone with old apt module installed by apt-get install puppet-module-puppetlabs-apt.

          Mine works because I was running full life cycle of docker provisioner, which install apt module by
          puppet module install puppetlabs-apt and have the newest version 2.0.1 installed.

          Since the this is a backward not compatible change in apt module itself, I guess I can only try to test the version and do if-else to overcome the problem. Do you think this is reasonable?

          Show
          evans_ye Evans Ye added a comment - OKAY. Olaf Flebbe sent me many words to describe his scenario. I can reproduce it now. The failure happened when running bigtop puppet alone with old apt module installed by apt-get install puppet-module-puppetlabs-apt . Mine works because I was running full life cycle of docker provisioner, which install apt module by puppet module install puppetlabs-apt and have the newest version 2.0.1 installed. Since the this is a backward not compatible change in apt module itself, I guess I can only try to test the version and do if-else to overcome the problem. Do you think this is reasonable?
          Hide
          evans_ye Evans Ye added a comment -

          Oops, sorry about breaking things.
          Olaf Flebbe can you help to provide some context of reproducing steps?
          I developed and tested this on debian container and it does not fail though.

          My evaluation step:

          ./gradlew -Pconfig=vagrantconfig_debian.yaml docker-provisioner
          
          Show
          evans_ye Evans Ye added a comment - Oops, sorry about breaking things. Olaf Flebbe can you help to provide some context of reproducing steps? I developed and tested this on debian container and it does not fail though. My evaluation step: ./gradlew -Pconfig=vagrantconfig_debian.yaml docker-provisioner
          Hide
          cos Konstantin Boudnik added a comment -

          It is I guess. But then we'll end up with two commits per JIRA. Which isn't awful, but not-pretty Either way is good for me, really. Thanks for catching it up!

          Show
          cos Konstantin Boudnik added a comment - It is I guess. But then we'll end up with two commits per JIRA. Which isn't awful, but not-pretty Either way is good for me, really. Thanks for catching it up!
          Hide
          oflebbe Olaf Flebbe added a comment -

          The patch breaks functionality, so I think reopening the offending ticket it is the way to go.

          Show
          oflebbe Olaf Flebbe added a comment - The patch breaks functionality, so I think reopening the offending ticket it is the way to go.
          Hide
          cos Konstantin Boudnik added a comment -

          Argh.... Let's do this as a separate ticket perhaps?

          Show
          cos Konstantin Boudnik added a comment - Argh.... Let's do this as a separate ticket perhaps?
          Hide
          oflebbe Olaf Flebbe added a comment -

          Sorry this breaks debian:

          root@node1:~# puppet apply -t /etc/puppet/manifests/site.pp 
          Info: Loading facts
          Info: Loading facts
          Info: Loading facts
          Warning: The use of 'import' is deprecated at /etc/puppet/manifests/site.pp:58. See http://links.puppetlabs.com/puppet-import-deprecation
             (at /usr/lib/ruby/vendor_ruby/puppet/parser/parser_support.rb:110:in `import')
          Warning: Variable access via 'domain' is deprecated. Use '@domain' instead. template[inline]:1
             (at /usr/lib/ruby/vendor_ruby/puppet/parser/templatewrapper.rb:76:in `method_missing')
          Notice: Compiled catalog for node1.fritz.box in environment production in 1.40 seconds
          Info: Applying configuration version '1431545598'
          Error: Could not apply complete catalog: Found 1 dependency cycle:
          (Anchor[apt::source::Bigtop] => Apt::Source[Bigtop] => Exec[apt_update] => Class[Apt::Update] => Anchor[apt::source::Bigtop])
          Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz
          Notice: Finished catalog run in 0.11 seconds
          
          Show
          oflebbe Olaf Flebbe added a comment - Sorry this breaks debian: root@node1:~# puppet apply -t /etc/puppet/manifests/site.pp Info: Loading facts Info: Loading facts Info: Loading facts Warning: The use of ' import ' is deprecated at /etc/puppet/manifests/site.pp:58. See http: //links.puppetlabs.com/puppet- import -deprecation (at /usr/lib/ruby/vendor_ruby/puppet/parser/parser_support.rb:110:in ` import ') Warning: Variable access via 'domain' is deprecated. Use '@domain' instead. template[inline]:1 (at /usr/lib/ruby/vendor_ruby/puppet/parser/templatewrapper.rb:76:in `method_missing') Notice: Compiled catalog for node1.fritz.box in environment production in 1.40 seconds Info: Applying configuration version '1431545598' Error: Could not apply complete catalog: Found 1 dependency cycle: (Anchor[apt::source::Bigtop] => Apt::Source[Bigtop] => Exec[apt_update] => Class [Apt::Update] => Anchor[apt::source::Bigtop]) Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz Notice: Finished catalog run in 0.11 seconds
          Hide
          cos Konstantin Boudnik added a comment -

          +1 - it works! Thanks Evans Ye!
          Committed and pushed

          Show
          cos Konstantin Boudnik added a comment - +1 - it works! Thanks Evans Ye ! Committed and pushed
          Hide
          evans_ye Evans Ye added a comment -

          Patch is ready!
          In the patch I've also updated the script in docker provisioner to leverage toolchain's puppetmodule instead of doing module installation separately in centos and debian.

          Show
          evans_ye Evans Ye added a comment - Patch is ready! In the patch I've also updated the script in docker provisioner to leverage toolchain's puppetmodule instead of doing module installation separately in centos and debian.
          Hide
          evans_ye Evans Ye added a comment -

          Sure. Let me take a look at it.

          Show
          evans_ye Evans Ye added a comment - Sure. Let me take a look at it.

            People

            • Assignee:
              evans_ye Evans Ye
              Reporter:
              cos Konstantin Boudnik
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development