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 1961480 - Vagrant cannot provision Windows machines winrm-elevated plugin installation fails
Summary: Vagrant cannot provision Windows machines winrm-elevated plugin installation ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: vagrant
Version: 34
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Vít Ondruch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1962124
TreeView+ depends on / blocked
 
Reported: 2021-05-18 05:23 UTC by Uri Simchoni
Modified: 2021-05-20 08:29 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1962124 (view as bug list)
Environment:
Last Closed: 2021-05-20 08:29:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Uri Simchoni 2021-05-18 05:23:58 UTC
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.

Comment 1 Vít Ondruch 2021-05-18 08:23:39 UTC
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

Comment 2 Uri Simchoni 2021-05-18 12:03:03 UTC
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

Comment 3 Vít Ondruch 2021-05-19 09:57:06 UTC
(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.

Comment 4 Vít Ondruch 2021-05-19 09:57:58 UTC
BTW forget to mention that the steps what you took so far looks like the right attitude and I appreciate that.

Comment 5 Pavel Valena 2021-05-19 10:15:46 UTC
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

Comment 6 Vít Ondruch 2021-05-19 10:23:54 UTC
(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 7 Vít Ondruch 2021-05-19 12:36:29 UTC
So the erubi update is here:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-a4e5358635

Please let us know if it helps.

Comment 8 Vít Ondruch 2021-05-19 12:40:53 UTC
@Uri: I have noticed your related comments in bug 1551797. Quite late :blush:

Comment 9 Uri Simchoni 2021-05-19 18:15:58 UTC
(In reply to Vít Ondruch from comment #7)
> So the erubi update is here:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-a4e5358635
> 
> Please let us know if it helps.

Works for me! winrm-elevated installs cleanly and seems to do its job.

Thanks!
Uri.

Comment 10 Vít Ondruch 2021-05-20 08:29:03 UTC
(In reply to Uri Simchoni from comment #9)
> (In reply to Vít Ondruch from comment #7)
> > So the erubi update is here:
> > 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2021-a4e5358635
> > 
> > Please let us know if it helps.
> 
> Works for me! winrm-elevated installs cleanly and seems to do its job.
> 
> Thanks!
> Uri.

Thank you for confirmation. I am going to CLOSE this now. Should something similar happen, please consider joining our effort and help providing winrm* packages in Fedora.


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