Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1962124 - Vagrant cannot provision Windows machines winrm-elevated plugin installation fails
Summary: Vagrant cannot provision Windows machines winrm-elevated plugin installation ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rubygem-erubi
Version: 34
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Vít Ondruch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1961480
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-19 10:50 UTC by Vít Ondruch
Modified: 2021-05-29 01:04 UTC (History)
10 users (show)

Fixed In Version: rubygem-erubi-1.10.0-1.fc35 rubygem-erubi-1.10.0-1.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1961480
Environment:
Last Closed: 2021-05-19 11:02:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Vít Ondruch 2021-05-19 10:50:12 UTC
Making clone for request to update erubi.

+++ This bug was initially created as a clone of Bug #1961480 +++

Description of problem:

My Windows vagrant boxes depend on winrm-elevated plugin for provisioning the machine. After upgrading to F34, installation of winrm-elevated Vagrant plugin fails.

Version-Release number of selected component (if applicable):
vagrant-2.2.16-1.fc34.noarch
vagrant-libvirt-0.4.1-2.fc34.noarch

How reproducible:
Always

Steps to Reproduce:
1. sudo dnf install vagrant-libvirt
2. vagrant plugin install winrm-elevated

Actual results:

Vagrant failed to properly resolve required dependencies. These
errors can commonly be caused by misconfigured plugin installations                                                                                                                                                                         
or transient network issues. The reported error is:                                                                                                                                                                                         

conflicting dependencies erubi (~> 1.8) and erubi (= 1.7.0)                                                                                                                                                                                 
  Activated erubi-1.7.0                                                                                                                                                                                                                     
  which does not match conflicting dependency (~> 1.8)                                                                                                                                                                                      

  Conflicting dependency chains:                                                                                                                                                                                                            
    erubi (= 1.7.0), 1.7.0 activated                                                                                                                                                                                                        

  versus:                                                                                                                                                                                                                                   
    winrm-elevated (> 0), 1.1.1 activated, depends on                                                                                                                                                                                       
    winrm-fs (~> 1.0), 1.3.5 activated, depends on                                                                                                                                                                                          
    erubi (~> 1.8)

Expected results:

Success in installing the plugin

Additional info:

This is already kind-of reported in https://bugzilla.redhat.com/show_bug.cgi?id=1551797 but that's an automatic bug for upgrade of rubygem-erubi, and this is a functionality bug that results from lack of the erubi upgrade.

--- Additional comment from Vít Ondruch on 2021-05-18 10:23:39 CEST ---

Hm, we could update erubi which should fix this.

Nevertheless, I'd appreciate if you go to winrm and winrm-elevated upstream and asked them to relax the erubi dependency, because I believe that the erubi ~> 1.8 was picked up just randomly and it does not have anything to do with features provided by erubi 1.8+. I'd be surprised if 1.7 did not worked.

Also, the erubi dependency is coming from Vagrant [1]. There is no restriction at all, putting the additional version on erubi in some plugin is not vise IMO because they risk collisions like this with Vagrant itself, if e.g. Vagrant decides to depend on erubi ~> 2.0 (should there be such version of erubi).

Writing all this, maybe the winrm* could even drop the dependency on erubi and assume, that erubi is pulled in via Vagrant.


[1]: https://github.com/hashicorp/vagrant/blob/main/vagrant.gemspec#L21

--- Additional comment from Uri Simchoni on 2021-05-18 14:03:03 CEST ---

Dropping the dependencies altogether probably won't be accepted, because winrm* are generic rubygems, allowing Ruby programs to interact with Windows machines.

I don't know the first thing about Ruby development, but I was able to relax the erubi requirement and spin up a VM like so:
1. Installed winrm (vagrant plugin install winrm)
2. downloaded the source code for winrm-fs from Github
3. modified winrm-fs.gemspec to relax the erubi dependency
4. built the gem - (gem build winrm-fs.gemspec)
5. installed the plugin (vagrant plugin install /path/to/winrm-fs-1.3.5.gem
6. repeat this process for winrm-elevated

Winrm works that way.

Now that I finally have a Windows machine up and running, I'll try to run winrm-fs and winrm-elevated integration tests and if all's well I'll post a PR upstream.

Having said all that, isn't it the "fedora way" to have latest packages, esp. when it's required in order to fix actual problems?

Thanks,
Uri

--- Additional comment from Vít Ondruch on 2021-05-19 11:57:06 CEST ---

(In reply to Uri Simchoni from comment #2)
> Dropping the dependencies altogether probably won't be accepted, because
> winrm* are generic rubygems, allowing Ruby programs to interact with Windows
> machines.

Interesting. I have not realized this.

Honestly, I don't know much about winrm* except that we remove this dependency. I thought that it is Windows specific in a way that it needs Windows as a host OS, but it seems it is useful also from Linux host. I have never tried to run Windows box neither I think I'll try it in near future, so I am glad for this feedback.

> I don't know the first thing about Ruby development, but I was able to relax
> the erubi requirement and spin up a VM like so:
> 1. Installed winrm (vagrant plugin install winrm)
> 2. downloaded the source code for winrm-fs from Github
> 3. modified winrm-fs.gemspec to relax the erubi dependency
> 4. built the gem - (gem build winrm-fs.gemspec)
> 5. installed the plugin (vagrant plugin install /path/to/winrm-fs-1.3.5.gem
> 6. repeat this process for winrm-elevated
> 
> Winrm works that way.

Yes, that is similar to what we do in Fedora packages if needed.

> Now that I finally have a Windows machine up and running, I'll try to run
> winrm-fs and winrm-elevated integration tests and if all's well I'll post a
> PR upstream.
> 
> Having said all that, isn't it the "fedora way" to have latest packages,
> esp. when it's required in order to fix actual problems?

Well, it ideally is. But sometimes it is easier to say then do ;) Nevertheless, it is not always about the "latest packages" but I about the right solution. 
After all, if I understand your issue correctly, it is not necessarily about winrm, it is simply about running Windows via Vagrant.

Therefore, in this case, the right solution might involve one or all items from the following list:

1) Updating erubi (but have latest erubi is not goal on itself, because vagrant + winrm are not its only users).
2) Discussing the not necessarily strict requirements with upstream
3) Possibly packaging winrm* for Fedora

Since I don't have recent experience with Windows, I'd appreciate if you (or anyone else) can help us to identify the blind spots and I'd be even happier, if somebody could do this long term.

--- Additional comment from Vít Ondruch on 2021-05-19 11:57:58 CEST ---

BTW forget to mention that the steps what you took so far looks like the right attitude and I appreciate that.

--- Additional comment from Pavel Valena on 2021-05-19 12:15:46 CEST ---

I've written my response in the meantime, please excuse the duplicate responses.

(In reply to Uri Simchoni from comment #2)
> Dropping the dependencies altogether probably won't be accepted, because
> winrm* are generic rubygems, allowing Ruby programs to interact with Windows
> machines.

The intention was to relax the strict dependency, not dropping it. IOW '>= 1.7' instead of '~> 1.8'.

I've created a PR:
  https://github.com/WinRb/winrm-fs/pull/86

> 
> I don't know the first thing about Ruby development, but I was able to relax
> the erubi requirement and spin up a VM like so:
> 1. Installed winrm (vagrant plugin install winrm)

As a workaround, IMO installing winrm-fs is fully sufficient (before installing vagrant-libvirt). Afterwards you need to modify the installed .gemspec file to relax the dependency.

> 2. downloaded the source code for winrm-fs from Github
> 3. modified winrm-fs.gemspec to relax the erubi dependency
> 4. built the gem - (gem build winrm-fs.gemspec)
> 5. installed the plugin (vagrant plugin install /path/to/winrm-fs-1.3.5.gem

If interested in packaging winrm* for Fedora I'd recommend you to use COPR (which can handle the above+distribution for you). You'd need to do some packaging, though.

> 6. repeat this process for winrm-elevated
> 
> Winrm works that way.
> 
> Now that I finally have a Windows machine up and running, I'll try to run
> winrm-fs and winrm-elevated integration tests and if all's well I'll post a
> PR upstream.

Great!

> 
> Having said all that, isn't it the "fedora way" to have latest packages,
> esp. when it's required in order to fix actual problems?

Yes, that would be ideal, but it's not easily "done". Feel free to submit update PRs!

Also, ideally, you would have the vagrant-winrm* plugins packaged in Fedora. This would enable us to handle the dependencies directly in Fedora.

That said, your approach, mixing upstream and downstream(Fedora) dependencies is not supported, I'm afraid, as we are can't possibly handle all upstream dependency changes (sometimes conflicting as well).
Therefore I'm closing this.

> 
> Thanks,
> Uri

--- Additional comment from Vít Ondruch on 2021-05-19 12:23:54 CEST ---

(In reply to Pavel Valena from comment #5)
> That said, your approach, mixing upstream and downstream(Fedora)
> dependencies is not supported, I'm afraid, as we are can't possibly handle
> all upstream dependency changes (sometimes conflicting as well).
> Therefore I'm closing this.

Just FTR, this is partially our fault:

https://src.fedoraproject.org/rpms/vagrant/blob/rawhide/f/vagrant.spec#_152

Therefore I reopening and I'll look into updating erubi, which should be good start.

Comment 1 Fedora Update System 2021-05-19 11:02:01 UTC
FEDORA-2021-f309b8dd99 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f309b8dd99

Comment 2 Fedora Update System 2021-05-19 11:02:44 UTC
FEDORA-2021-f309b8dd99 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 3 Fedora Update System 2021-05-19 12:33:00 UTC
FEDORA-2021-a4e5358635 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a4e5358635

Comment 4 Fedora Update System 2021-05-21 01:35:07 UTC
FEDORA-2021-a4e5358635 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a4e5358635`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a4e5358635

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 5 Uri Simchoni 2021-05-21 05:45:11 UTC
The upgrade of erubi fixes the issue for me. Thanks!

Comment 6 Fedora Update System 2021-05-29 01:04:19 UTC
FEDORA-2021-a4e5358635 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.