Hide Forgot
Description of problem: I know we don't officially support F24 yet but soon it will be something we want to consider. I also don't know if the source of the bug is from the files being built wrong in the cdk.zip or a bug in the software on the system. Either way I am filing it here so the cdk team can run it to ground. On F24 I first had to workaround an existing bug https://bugzilla.redhat.com/show_bug.cgi?id=1317773 with a one line patch. After I did that I tried to install the plugins for the CDK from the cdk.zip file and I get the following error: ``` $ vagrant plugin install ./vagrant-service-manager-1.0.1.gem Installing the './vagrant-service-manager-1.0.1.gem' plugin. This can take a few minutes... Bundler, the underlying system Vagrant uses to install plugins, reported an error. The error is shown below. These errors are usually caused by misconfigured plugin installations or transient network issues. The error from Bundler is: Could not find gem 'vagrant-service-manager (= 1.0.1) ruby' in any of the gem sources listed in your Gemfile or available on this machine. Warning: this Gemfile contains multiple primary sources. Using `source` more than once without a block is a security risk, and may result in installing unexpected gems. To resolve this warning, use a block to indicate which gems should come from the secondary source. To upgrade this warning to an error, run `bundle config disable_multisource true`. ``` Version-Release number of selected component (if applicable): - cdk-2.0.0.zip ced1ae9a5017c1cc70758eb9f57c933726a97852749b087eb966396f7b63ddf4 - vagrant-1.8.1-1.fc24.noarch - vagrant-libvirt-0.0.32-2.fc24.noarch - ruby-2.3.0-54.fc24.x86_64 - rubygems-2.5.1-54.fc24.noarch - rubygem-bundler-1.10.6-3.fc24.noarch
@Dusty I tried to reproduce this bug but hit by another one. # vagrant plugin install ./vagrant-service-manager-1.0.1.gem Installing the './vagrant-service-manager-1.0.1.gem' plugin. This can take a few minutes... /usr/share/rubygems/rubygems/specification.rb:946:in `all=': undefined method `group_by' for nil:NilClass (NoMethodError) from /usr/share/vagrant/lib/vagrant/bundler.rb:268:in `with_isolated_gem' from /usr/share/vagrant/lib/vagrant/bundler.rb:126:in `install_local' from /usr/share/vagrant/lib/vagrant/plugin/manager.rb:47:in `install_plugin' from /usr/share/vagrant/plugins/commands/plugin/action/install_gem.rb:37:in `call' from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call' from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy' from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run' from /usr/share/vagrant/plugins/commands/plugin/command/base.rb:14:in `action' from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:32:in `block in execute' from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:31:in `each' from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:31:in `execute' from /usr/share/vagrant/plugins/commands/plugin/command/root.rb:56:in `execute' from /usr/share/vagrant/lib/vagrant/cli.rb:42:in `execute' from /usr/share/vagrant/lib/vagrant/environment.rb:302:in `cli' from /usr/share/vagrant/bin/vagrant:174:in `<main>' - vagrant-1.8.1-1.fc24.noarch - vagrant-libvirt-0.0.32-2.fc24.noarch - ruby-2.3.0-54.fc24.x86_64 - rubygems-2.5.1-54.fc24.noarch - rubygem-bundler-1.10.6-3.fc24.noarch
Alright I make another try after fixing above issue using https://github.com/mitchellh/vagrant/pull/7198/files and then able to produce same bug which you are seeing. Now if I execute below command # vagrant plugin install vagrant-service-manager Installing the 'vagrant-service-manager' plugin. This can take a few minutes... Installed the plugin 'vagrant-service-manager (1.0.1)'! But when I do using gem provide in zip I get same issue which you are getting. I thought that may be because that gem is created on rhel7 box and may be that caused issue but even I built plugin gem on f24 and still same issue :(
I am also able to reproduce it. I also found that this issue exists with other plugins too like 'vagrant-registration', 'vagrant-sshfs'. I believe it is related to "Fedora 24" rather than Ruby or Bundler. Similar, issue I found in Vagrant project here [1]. In this issue, Mitchell pointed out [2] out "Vagrant is just using Bundler and pointing to different paths. Vagrant itself doesn't do any of the dep resolution. I imagine this is some strange behavior with Vagrant." [1] https://github.com/mitchellh/vagrant/issues/5643 [2] https://github.com/mitchellh/vagrant/issues/5643#issuecomment-157912977
Adding Vit into the loop. Vit, Do you have any insight into whether this is a packaging issue (i.e. something wrong with the gem files) or an issue with vagrant in Fedora 24? Thanks for any help you can provide.
Just to sum this up, installing the plugin from remote repository works just fine: $ vagrant plugin install vagrant-service-manager Installed the plugin 'vagrant-service-manager (1.0.1)'! While installing the locally cached gem does not: $ vagrant plugin install ./vagrant-service-manager-1.0.1.gem Installing the './vagrant-service-manager-1.0.1.gem' plugin. This can take a few minutes... /usr/share/gems/gems/abrt-0.1.1/lib/abrt.rb:6:in `require': cannot load such file -- abrt/handler (LoadError) from /usr/share/gems/gems/abrt-0.1.1/lib/abrt.rb:6:in `block in <top (required)>' /usr/share/rubygems/rubygems/specification.rb:946:in `all=': undefined method `group_by' for nil:NilClass (NoMethodError) from /usr/share/vagrant/lib/vagrant/bundler.rb:268:in `with_isolated_gem' from /usr/share/vagrant/lib/vagrant/bundler.rb:126:in `install_local' from /usr/share/vagrant/lib/vagrant/plugin/manager.rb:47:in `install_plugin' from /usr/share/vagrant/plugins/commands/plugin/action/install_gem.rb:37:in `call' from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call' from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy' from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run' from /usr/share/vagrant/plugins/commands/plugin/command/base.rb:14:in `action' from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:32:in `block in execute' from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:31:in `each' from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:31:in `execute' from /usr/share/vagrant/plugins/commands/plugin/command/root.rb:56:in `execute' from /usr/share/vagrant/lib/vagrant/cli.rb:42:in `execute' from /usr/share/vagrant/lib/vagrant/environment.rb:302:in `cli' from /usr/share/vagrant/bin/vagrant:174:in `<main>' Unfortunately, that is how Bundler (which is used in background) works. There is no way how to specify that you want to use some local gem. Actually Bundler can use unpacked gem, but that is different story. These are some related issues: http://stackoverflow.com/questions/5633939/how-do-i-specify-local-gem-files-in-my-gemfile http://stackoverflow.com/questions/4271947/how-to-use-bundler-with-offline-gem-file I'm going to reject this issue, since there is nothing I can do about it I am afraid. If you want to pursue this, I'd suggest to ask Bundler upstream to implement such feature, but I am not very confident this is something acceptable for them. If you really need this functionality, there is one possible workaround to install the plugin, such as: $ GEM_HOME=~/.vagrant.d/gems/ gem install vagrant-service-manager Successfully installed vagrant-service-manager-1.0.1 Parsing documentation for vagrant-service-manager-1.0.1 Installing ri documentation for vagrant-service-manager-1.0.1 Done installing documentation for vagrant-service-manager after 0 seconds 1 gem installed $ ruby -e ' $LOAD_PATH.unshift "/usr/share/vagrant/lib" require "vagrant/plugin/manager" Vagrant::Plugin::StateFile.new(Pathname.new(File.expand_path "~/.vagrant.d/plugins.json")).add_plugin "vagrant-service-manager" ' Or similarly to uninstall: $ ruby -e ' $LOAD_PATH.unshift "/usr/share/vagrant/lib" require "vagrant/plugin/manager" Vagrant::Plugin::StateFile.new(Pathname.new(File.expand_path "~/.vagrant.d/plugins.json")).remove_plugin "vagrant-service-manager"' $ GEM_HOME=~/.vagrant.d/gems/ gem uninstall vagrant-service-manager Successfully uninstalled vagrant-service-manager-1.0.1 You can check macros.vagrant [1] for the vagrant_plugin_{,un}register macros. [1] http://pkgs.fedoraproject.org/cgit/rpms/vagrant.git/tree/macros.vagrant
Eh, may be I should not reject it, but ... ;)
(In reply to Vít Ondruch from comment #6) > Eh, may be I should not reject it, but ... ;) Since I am not the assignee ....
Hey vit, Thanks for the information. I'm re-opening as new because I refuse to accept that this used to work and now it doesn't. We, the CDK team, will need to understand what caused this and remedy it. So I am now seeing this in RHEL7 when using the latest vagrant from centos sclo: sclo-vagrant1-vagrant-1.8.1-5.el7.noarch I know we recommend using vagrant 1.7.4 but that is what I got when I followed the install guide. Either way we are now seeing this issue on RHEL as well. We need to understand it and get it fixed.
(In reply to Dusty Mabe from comment #8) > So I am now seeing this in RHEL7 when using the latest vagrant from centos > sclo: > > sclo-vagrant1-vagrant-1.8.1-5.el7.noarch > > I know we recommend using vagrant 1.7.4 but that is what I got when I > followed the install guide. Hi Dusty, We only recommend a specific version (1.7.x) of Vagrant on Windows -- there's no recommendation regarding version when installed on RHEL.
(In reply to Robert Krátký from comment #9) > > Hi Dusty, > > We only recommend a specific version (1.7.x) of Vagrant on Windows -- > there's no recommendation regarding version when installed on RHEL. Thanks for the clarification!
(In reply to Dusty Mabe from comment #8) > Thanks for the information. I'm re-opening as new because I refuse to accept > that this used to work and now it doesn't. Was it? What were the versions you were using, I'd be interested in version of vagrant, ruby and bundler ...
(In reply to Vít Ondruch from comment #11) > (In reply to Dusty Mabe from comment #8) > > Thanks for the information. I'm re-opening as new because I refuse to accept > > that this used to work and now it doesn't. > > Was it? What were the versions you were using, I'd be interested in version > of vagrant, ruby and bundler ... I managed to find a system with the old versions on it. Here is an example of me installing the plugins successfully from the file as well as the versions of the packages: [dustymabe@summit-demo plugins]$ vagrant plugin install ./vagrant-registration-1.2.1.gem ./vagrant-sshfs-1.1.0.gem ./vagrant-service-manager-1.0.1.gem Installing the './vagrant-registration-1.2.1.gem' plugin. This can take a few minutes... Installed the plugin 'vagrant-registration (1.2.1)'! Installing the './vagrant-sshfs-1.1.0.gem' plugin. This can take a few minutes... Installed the plugin 'vagrant-sshfs (1.1.0)'! Installing the './vagrant-service-manager-1.0.1.gem' plugin. This can take a few minutes... Installed the plugin 'vagrant-service-manager (1.0.1)'! [dustymabe@summit-demo plugins]$ [dustymabe@summit-demo plugins]$ rpm -q sclo-vagrant1-vagrant rh-ruby22-ruby rh-ruby22-rubygem-bundler sclo-vagrant1-vagrant-1.7.4-3.el7.noarch rh-ruby22-ruby-2.2.2-12.el7.x86_64 rh-ruby22-rubygem-bundler-1.7.8-2.el7.noarch
Interestingly enough on my other RHEL 7 system (the one that I observe the problem on) I observe that the only difference between the two systems is the version of vagrant: [student@cloudhost plugins]$ vagrant plugin install ./vagrant-registration-1.2.1.gem Installing the './vagrant-registration-1.2.1.gem' plugin. This can take a few minutes... Bundler, the underlying system Vagrant uses to install plugins, reported an error. The error is shown below. These errors are usually caused by misconfigured plugin installations or transient network issues. The error from Bundler is: Could not find gem 'vagrant-registration (= 1.2.1) ruby' in the gems available on this machine. [student@cloudhost plugins]$ rpm -q sclo-vagrant1-vagrant rh-ruby22-ruby rh-ruby22-rubygem-bundler sclo-vagrant1-vagrant-1.8.1-5.el7.noarch rh-ruby22-ruby-2.2.2-12.el7.x86_64 rh-ruby22-rubygem-bundler-1.7.8-2.el7.noarch
Hi Vit, Any comment on the above information?
Hello, this is affecting both fedora and RHEL-7, the reason is, that sclo-vagrant1 collection has been updated since cdk-2.0. Previously, there was 1.7.4, now 1.8.1. If user downgrade to 1.7.4 (and rm -rf ~/.vagrant.d if problems persists), it works. So we need to: a) fix this fast b) document downgrading or installation of specific vagrant version for RHEL/Fedora
Decision from long discussion on #cdk was to recommend vagrant-1.7.4 because of this issue and problems with plugins in general. It's possible to install 1.7.4 from repo, it just need to be documented. DOC issue: https://issues.jboss.org/browse/RHDEVDOCS-39
Installing rh-ruby22-ruby-devel and gcc-c++ allowed me to setup the CDK on RHEL7. Can someone verify?
same issue here on F24 and its not that simple to downgrade vagrant because it has a lot of other dependencies.
Just completed a brand new install of RHEL 7.2, CDK 2.1, and the 7.2-25 libvirt Vagrant box following all the current CDK RHEL installation instructions and encountered the same issue. However, based on Dusty's information above, I backed out all sclo-vagrant packages and installed the 1.7.4-3 Vagrant package followed by the additional libvirt packages: # yum remove sclo-vagrant\* # yum install sclo-vagrant1-vagrant-1.7.4-3.el7.noarch # yum install sclo-vagrant1-vagrant-libvirt \ sclo-vagrant1-vagrant-libvirt-doc \ sclo-vagrant1-vagrant-registration [ryan@greyghost ~]$ scl enable sclo-vagrant1 bash [ryan@greyghost ~]$ which vagrant /opt/rh/sclo-vagrant1/root/usr/bin/vagrant [ryan@greyghost ~]$ vagrant version Installed Version: 1.7.4 Latest Version: 1.8.4 ... [ryan@greyghost ~]$ cd cdk/plugins/ [ryan@greyghost plugins]$ vagrant plugin install *.gem Installing the 'vagrant-registration-1.2.2.gem' plugin. This can take a few minutes... Installed the plugin 'vagrant-registration (1.2.2)'! Installing the 'vagrant-service-manager-1.1.0.gem' plugin. This can take a few minutes... Installed the plugin 'vagrant-service-manager (1.1.0)'! Installing the 'vagrant-sshfs-1.1.0.gem' plugin. This can take a few minutes... Installed the plugin 'vagrant-sshfs (1.1.0)'! [ryan@greyghost plugins]$ vagrant plugin list vagrant-libvirt (0.0.32, system) vagrant-registration (1.2.2) - Version Constraint: 1.2.2 vagrant-service-manager (1.1.0) - Version Constraint: 1.1.0 vagrant-sshfs (1.1.0) - Version Constraint: 1.1.0 [ryan@greyghost ~]$ cd ~/cdk/components/rhel/rhel-ose/ [ryan@greyghost rhel-ose]$ ls README.rst Vagrantfile [ryan@greyghost rhel-ose]$ vagrant up Bringing machine 'default' up with 'libvirt' provider... ==> default: Uploading base box image as volume into libvirt storage... ==> default: Creating image (snapshot of base box volume). ==> default: Creating domain with the following settings... ==> default: -- Name: rhel-ose_default ==> default: -- Domain type: kvm ==> default: -- Cpus: 2 ==> default: -- Memory: 3072M ==> default: -- Management MAC: ==> default: -- Loader: ==> default: -- Base box: cdkv2 ... A few things to note: I did *not* remove/reinstall any of the rh-ruby22 or rh-ror41 packages initially installed as dependencies for sclo-vagrant1. The sclo-vagrant1-vagrant-libvirt, -libvirt-doc, and -registration packages may or may not have needed to be removed/reinstalled to get this to work. Hopefully this will help anyone running into this issue before the pending documentation update is published.
(In reply to Ryan Highley from comment #19) > Hopefully this will help anyone running into this issue before the pending > documentation update is published. Hi Ryan, We have already documented this for the CDK 2.1 release. See the Installation Guide: https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/installation-guide/#installing_virtualization_and_container_development_kit_components (4.2.1.2. Installing and Initializing Virtualization Software) Please, let me know if think this is sufficient from the docs point of view.
So the option to use fedora was removed?
For CDK 2.1, Fedora is not officially supported -- only RHEL. That said, installation on Fedora should work without problems (the same limitation applies with regard to the Vagrant version -- 1.7.x is required).
(In reply to Robert Krátký from comment #20) > (In reply to Ryan Highley from comment #19) > > > Hopefully this will help anyone running into this issue before the pending > > documentation update is published. > > Hi Ryan, > > We have already documented this for the CDK 2.1 release. See the > Installation Guide: > > https://access.redhat.com/documentation/en/red-hat-container-development-kit/ > 2.1/installation-guide/ > #installing_virtualization_and_container_development_kit_components > > (4.2.1.2. Installing and Initializing Virtualization Software) > > Please, let me know if think this is sufficient from the docs point of view. Hello Robert, The CDK 2.1 documentation change looks sufficient to me. I see why I didn't get that version of the installation guide though. If you follow the CDK Get Started documentation links from developers.redhat.com [1], you arrive at the CDK installation guide under RHEL Atomic Host 7 [2], not the Container Development Kit product on access.redhat.com [3]. Only if you go directly to CDK through the access.redhat.com product documentation links will you arrive at the version you referenced above. Looks like the developers.redhat.com links need updated but until then, perhaps the RHEL Atomic Host doc pages can reference the more complete CDK versions. Ryan [1] http://developers.redhat.com/products/cdk/get-started/ [2] https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/version-7/container-development-kit-installation-guide/#installing_the_cdk_on_fedora_or_red_hat_enterprise_linux [3] https://access.redhat.com/documentation/en/red-hat-container-development-kit/2.1/installation-guide/chapter-4-installing-container-development-kit-on-red-hat-enterprise-linux
(In reply to Ryan Highley from comment #24) > The CDK 2.1 documentation change looks sufficient to me. I see why I didn't > get that version of the installation guide though. > > If you follow the CDK Get Started documentation links from > developers.redhat.com [1], you arrive at the CDK installation guide under > RHEL Atomic Host 7 [2], not the Container Development Kit product on > access.redhat.com [3]. > > Only if you go directly to CDK through the access.redhat.com product > documentation links will you arrive at the version you referenced above. > > Looks like the developers.redhat.com links need updated but until then, > perhaps the RHEL Atomic Host doc pages can reference the more complete CDK > versions. Hi Ryan, I know about the problem(s). Links on dev.rh.com: -------------------- I have submitted a pull request to fix the links to docs two weeks ago, but the devs of the dev.rh.com portal still haven't gotten to it :-( I keep pinging them... For a long-term solution, I'm working with out tooling team to automate the way all docs links on dev.rh.com are updated when new versions are released. Old docs in Atomic space on access.rh.com: ------------------------------------------ When the CDK docs were moved from the Atomic space to an independent CDK space, redirects were set up, so that the old URLs would resolve to the new ones. Unfortunately, the redirects have now stopped working for some reason. I'm working with the Customer Portal team to have the redirects reinstated.
Just to add an update with the issue, the upstream vagrant project has this fix and will be released a part of upcoming release version 1.8.5. PR for the fix[1]. [1] https://github.com/mitchellh/vagrant/pull/7505
@Vit Since this issue already resolved in Fedora side (#1330208) after applying the upstream patch can you do same for SCL here?
Created attachment 1186334 [details] Fix local plugin installation
@Vit please check attached patch which will address current issue I also did a scratch build using it for f24 tree. http://koji.fedoraproject.org/koji/taskinfo?taskID=15090183
I tried the patch and it fixed the local gem installation issue for me.
Can we get those patches into Fedora 24 and CentOS?
Hi, right now I am working on an update of CentOS SCL to 1.8.5, which solves this issue. In Fedora 23 and 24, I can patch it. > Can we get those patches into Fedora 24 and CentOS? Dusty, apart from the attached patch, what other one do you have in mind? Would you mind creating a Fedora bug for it? (I don't want to steal this one.)
(In reply to Pavel Valena from comment #32) > Hi, > > right now I am working on an update of CentOS SCL to 1.8.5, which solves > this issue. > > In Fedora 23 and 24, I can patch it. > > > Can we get those patches into Fedora 24 and CentOS? > Dusty, apart from the attached patch, what other one do you have in mind? Sorry I guess there was only 1. > > Would you mind creating a Fedora bug for it? (I don't want to steal this > one.) https://bugzilla.redhat.com/show_bug.cgi?id=1365305
This bug doesn't seem to be related to CDK anymore.