Hi all,
I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation:
1. I have a vagrant RPM that installs and works as expected, there's some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240 , I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
So, as a summary: - yum install vagrant should work, at which point you need to install VirtualBox and it will run as expected - vagrant-kvm installs but I don't know how to add the right polkit rules (I need help)
Looks pretty good, right?
Alex
On 09/23/2013 08:37 AM, Alexandre Drahon wrote:
Hi all,
I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation:
- I have a vagrant RPM that installs and works as expected, there's
some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240, I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
So, as a summary:
- yum install vagrant should work, at which point you need to install
VirtualBox and it will run as expected
- vagrant-kvm installs but I don't know how to add the right polkit
rules (I need help)
Looks pretty good, right?
Alex
Hey Alex, looks awesome, thanks for submitting this.
Unfortunately I'm not too familiar w/ the polkit stuff, but regarding the Ruby packaging, it looks similar to other situations we've encountered when attempting to package Ruby code for our platform. Unfortunately alot of upstream ruby tools are geared towards heavily vendoring / bundling deps (often the primary platform is Mac OSX). We're making headways on improving support for and working around these situations (see stuff like [1], [2], and [3]), often sending things upstream (which a variable acceptance rate depending on community practices).
In any case, if you're looking for any assistance RE the ruby stuff, I'd checkout the Ruby SIG [4] (if you haven't already). Or even just forward this there, I'm sure there will be interest. Thanks again!
-Mo
[1] https://github.com/bundlerext/bundler_ext [2] https://github.com/ManageIQ/gem_dependency_checker/blob/master/gem_dependenc... [3] https://github.com/voxik/gem-nice-install [4] http://fedoraproject.org/wiki/Ruby_SIG
Hi Mo,
Thanks for the pointers, I'll definitely look at this and ask for help on the Ruby SIG list. The issue here is that Vagrant plugins are rubygems that get installed in the user's ~/.vagrant.d/ directory with all their dependencies (ie. Vagrant won't reuse system-wide installed gems). I already face the issue with vagrant-kvm with the dependency on Nokogiri, which needs gcc to install. OTOH I'm trying to keep Vagrant patching to a minimum. I think the best course of action is: - have Vagrant look for plugins system-wide first (in /usr/share/gems) and then in ~/.vagrant.d - still allow plugin install from rubygems.org ('vagrant plugin install whatever') and ensure it works - provide vagrant-kvm as a system-wide rubygem and ensure it uses system-wide dependencies - maybe provide some other Vagrant plugins as RPM (not sure it's wise)
bundler_ext seems like it could help here, I'm going to have a look at that.
Alex
----- Original Message -----
From: "Mo Morsi" mmorsi@redhat.com To: cloud@lists.fedoraproject.org Sent: Monday, 23 September, 2013 2:17:01 PM Subject: Re: Vagrant in Fedora
On 09/23/2013 08:37 AM, Alexandre Drahon wrote:
Hi all,
I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation:
1. I have a vagrant RPM that installs and works as expected, there's some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240 , I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
So, as a summary: - yum install vagrant should work, at which point you need to install VirtualBox and it will run as expected - vagrant-kvm installs but I don't know how to add the right polkit rules (I need help)
Looks pretty good, right?
Alex
Hey Alex, looks awesome, thanks for submitting this.
Unfortunately I'm not too familiar w/ the polkit stuff, but regarding the Ruby packaging, it looks similar to other situations we've encountered when attempting to package Ruby code for our platform. Unfortunately alot of upstream ruby tools are geared towards heavily vendoring / bundling deps (often the primary platform is Mac OSX). We're making headways on improving support for and working around these situations (see stuff like [1], [2], and [3]), often sending things upstream (which a variable acceptance rate depending on community practices).
In any case, if you're looking for any assistance RE the ruby stuff, I'd checkout the Ruby SIG [4] (if you haven't already). Or even just forward this there, I'm sure there will be interest. Thanks again!
-Mo
[1] https://github.com/bundlerext/bundler_ext [2] https://github.com/ManageIQ/gem_dependency_checker/blob/master/gem_dependenc... [3] https://github.com/voxik/gem-nice-install [4] http://fedoraproject.org/wiki/Ruby_SIG
_______________________________________________ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 09/24/2013 07:51 AM, Alexandre Drahon wrote:
Hi Mo,
Thanks for the pointers, I'll definitely look at this and ask for help on the Ruby SIG list. The issue here is that Vagrant plugins are rubygems that get installed in the user's ~/.vagrant.d/ directory with all their dependencies (ie. Vagrant won't reuse system-wide installed gems). I already face the issue with vagrant-kvm with the dependency on Nokogiri, which needs gcc to install. OTOH I'm trying to keep Vagrant patching to a minimum. I think the best course of action is:
- have Vagrant look for plugins system-wide first (in
/usr/share/gems) and then in ~/.vagrant.d
- still allow plugin install from rubygems.org ('vagrant plugin
install whatever') and ensure it works
- provide vagrant-kvm as a system-wide rubygem and ensure it uses
system-wide dependencies
- maybe provide some other Vagrant plugins as RPM (not sure it's wise)
bundler_ext seems like it could help here, I'm going to have a look at that.
Alex
Sounds like the plugin system works somewhat similar to engines in rails. IIUC, so long as we have the deps to startup the base system from a yum install, we should be good as far as loading plugins from wherever. Additional plugins shipped as rpm's would be a nice feature but might not be a required from the get-go.
-Mo
On Mon, Sep 23, 2013 at 08:37:33AM -0400, Alexandre Drahon wrote:
nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
Hi Alex. Thanks so much for letting me trick you into doing this. :)
- I have a vagrant RPM that installs and works as expected, there's some
minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt
Excellent!
- There was also some patching involved to make the plugin system work,
although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora.
Are there some in particular we should be looking at? Maybe we can get other people to chip in there once the base package is in.
- I had to build my own rubygems-childprocess (current Fedora package is
very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240 , I added it as a dependency to the Vagrant ticket.
It looks like Mo Morsi is an approved committer for that package https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-childprocess and could maybe add you as a co-maintainer too. Mo just responded to this thread in another post so that seems like a good possibility. :)
- I've packaged vagrant-kvm as a RPM and it installs, but I'm running
into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
I used to know all about policykit but it has changed a lot in newer versions. I know who to ask, though, for anything beyond what I can help with -- Miloslav Trmač (mitr) is the current RH maintainer. What's the issue?
Looks pretty good, right?
Absolutely!
On 09/23/2013 09:29 AM, Matthew Miller wrote:
- I had to build my own rubygems-childprocess (current Fedora package is
very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240 , I added it as a dependency to the Vagrant ticket.
It looks like Mo Morsi is an approved committer for that package https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-childprocess and could maybe add you as a co-maintainer too. Mo just responded to this thread in another post so that seems like a good possibility. :)
Updated in rawhide / F20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5971496 http://koji.fedoraproject.org/koji/taskinfo?taskID=5971582 https://admin.fedoraproject.org/updates/rubygem-childprocess-0.3.9-1.fc20
Feel free to test the update out / give it karma.
-Mo
----- Original Message -----
From: "Mo Morsi" mmorsi@redhat.com To: cloud@lists.fedoraproject.org, "Ruby SIG mailing list" ruby-sig@lists.fedoraproject.org Sent: Monday, 23 September, 2013 3:25:57 PM Subject: Re: Vagrant in Fedora
On 09/23/2013 09:29 AM, Matthew Miller wrote:
- I had to build my own rubygems-childprocess (current Fedora package is
very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240 , I added it as a dependency to the Vagrant ticket.
It looks like Mo Morsi is an approved committer for that package https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-childprocess and could maybe add you as a co-maintainer too. Mo just responded to this thread in another post so that seems like a good possibility. :)
Updated in rawhide / F20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5971496 http://koji.fedoraproject.org/koji/taskinfo?taskID=5971582 https://admin.fedoraproject.org/updates/rubygem-childprocess-0.3.9-1.fc20
Feel free to test the update out / give it karma.
-Mo
This looks good, I'll test it. BTW, shouldn't https://bugzilla.redhat.com/show_bug.cgi?id=960554 be updated?
Alex
On 23/09/13 15:25, Mo Morsi wrote:
On 09/23/2013 09:29 AM, Matthew Miller wrote:
- I had to build my own rubygems-childprocess (current Fedora package is
very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240 , I added it as a dependency to the Vagrant ticket.
It looks like Mo Morsi is an approved committer for that package https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-childprocess and could maybe add you as a co-maintainer too. Mo just responded to this thread in another post so that seems like a good possibility. :)
Updated in rawhide / F20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5971496 http://koji.fedoraproject.org/koji/taskinfo?taskID=5971582 https://admin.fedoraproject.org/updates/rubygem-childprocess-0.3.9-1.fc20
Feel free to test the update out / give it karma.
-Mo
I tested it with my vagrant package, it works. I don't know how to "give karma", though, what should I do.
Thanks, Alex
On Tue, Sep 24, 2013 at 10:03:17PM +0100, Alex Drahon wrote:
I tested it with my vagrant package, it works. I don't know how to "give karma", though, what should I do.
Go to https://admin.fedoraproject.org/updates/rubygem-childprocess-0.3.9-1.fc20
Login using your fedora account, and then add a comment with the "Works for me" box checked. Technically you don't even need to _say_ anything in the comment but it's nice to say how extensively you tested. "Works as used in the vagrant package I'm making", for example. Or "ran extensive regression suite and had my whole family hand test for 17 hours". Whichever applies. :)
Hi Matthew,
The rubygems issues look like they can be solved with Mo's help. The policykit stuff is more tricky, mainly because I have no idea how it works, so I really need help here. Here are the problems I'm currently facing: 1. I'm working on a minimal install to make sure I pull the right dependencies (including qemu etc.), but I need an auth agent for polkit, should I have a dependency on pkexec? 2. Every time the vagrant command is invoked, the user needs to connect to qemu:///system, may have to change virtual networks (destroy/create), change some NFS shares and firewall rules. What's the best way to manage all that, should I provide a custom policy (how do I create it?), maybe as an option? Should I create a vagrant group with some privileges? Or give them to the wheel group? Will it create security issues on the system?
Maybe solving point 1 is enough to have a working vagrant-kvm environment, but the issues in 2 hinder the usability of Vagrant (because you have to authenticate during the command execution) and makes vagrant-kvm not as fluid as with VirtualBox. My goal has been from the beginning to provide the full Vagrant experience using KVM, so I hope we can solve that.
Alex
----- Original Message -----
From: "Matthew Miller" mattdm@fedoraproject.org To: "Fedora Cloud SIG" cloud@lists.fedoraproject.org Sent: Monday, 23 September, 2013 2:29:23 PM Subject: Re: Vagrant in Fedora
On Mon, Sep 23, 2013 at 08:37:33AM -0400, Alexandre Drahon wrote:
nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
Hi Alex. Thanks so much for letting me trick you into doing this. :)
- I have a vagrant RPM that installs and works as expected, there's some
minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt
Excellent!
- There was also some patching involved to make the plugin system work,
although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora.
Are there some in particular we should be looking at? Maybe we can get other people to chip in there once the base package is in.
- I had to build my own rubygems-childprocess (current Fedora package is
very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240 , I added it as a dependency to the Vagrant ticket.
It looks like Mo Morsi is an approved committer for that package https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-childprocess and could maybe add you as a co-maintainer too. Mo just responded to this thread in another post so that seems like a good possibility. :)
- I've packaged vagrant-kvm as a RPM and it installs, but I'm running
into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
I used to know all about policykit but it has changed a lot in newer versions. I know who to ask, though, for anything beyond what I can help with -- Miloslav Trmač (mitr) is the current RH maintainer. What's the issue?
Looks pretty good, right?
Absolutely!
On Tue, Sep 24, 2013 at 08:15:34AM -0400, Alexandre Drahon wrote:
The rubygems issues look like they can be solved with Mo's help. The policykit stuff is more tricky, mainly because I have no idea how it works, so I really need help here. Here are the problems I'm currently facing:
- I'm working on a minimal install to make sure I pull the right
dependencies (including qemu etc.), but I need an auth agent for polkit, should I have a dependency on pkexec?
I think you probably should just should do "Requires: polkit" (which is the package which contains pkexec). This is faster than file dependencies.
- Every time the vagrant command is invoked, the user needs to connect to
qemu:///system, may have to change virtual networks (destroy/create), change some NFS shares and firewall rules. What's the best way to manage all that, should I provide a custom policy (how do I create it?), maybe as an option? Should I create a vagrant group with some privileges? Or give them to the wheel group? Will it create security issues on the system?
I think that all falls squarely under this:
https://lists.fedoraproject.org/pipermail/devel/2013-September/189003.html
Maybe solving point 1 is enough to have a working vagrant-kvm environment, but the issues in 2 hinder the usability of Vagrant (because you have to authenticate during the command execution) and makes vagrant-kvm not as fluid as with VirtualBox. My goal has been from the beginning to provide the full Vagrant experience using KVM, so I hope we can solve that.
On 24/09/13 13:19, Matthew Miller wrote:
On Tue, Sep 24, 2013 at 08:15:34AM -0400, Alexandre Drahon wrote:
The rubygems issues look like they can be solved with Mo's help. The policykit stuff is more tricky, mainly because I have no idea how it works, so I really need help here. Here are the problems I'm currently facing:
- I'm working on a minimal install to make sure I pull the right
dependencies (including qemu etc.), but I need an auth agent for polkit, should I have a dependency on pkexec?
I think you probably should just should do "Requires: polkit" (which is the
Thank you, will try this.
package which contains pkexec). This is faster than file dependencies.
- Every time the vagrant command is invoked, the user needs to connect to
qemu:///system, may have to change virtual networks (destroy/create), change some NFS shares and firewall rules. What's the best way to manage all that, should I provide a custom policy (how do I create it?), maybe as an option? Should I create a vagrant group with some privileges? Or give them to the wheel group? Will it create security issues on the system?
I think that all falls squarely under this:
https://lists.fedoraproject.org/pipermail/devel/2013-September/189003.html
Very interesting, I'll look into that.
Maybe solving point 1 is enough to have a working vagrant-kvm environment, but the issues in 2 hinder the usability of Vagrant (because you have to authenticate during the command execution) and makes vagrant-kvm not as fluid as with VirtualBox. My goal has been from the beginning to provide the full Vagrant experience using KVM, so I hope we can solve that.
On 09/23/2013 06:37 AM, Alexandre Drahon wrote:
Hi all,
I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation:
- I have a vagrant RPM that installs and works as expected, there's
some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240, I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
So, as a summary:
- yum install vagrant should work, at which point you need to install
VirtualBox and it will run as expected
- vagrant-kvm installs but I don't know how to add the right polkit
rules (I need help)
Looks pretty good, right?
It does... Since some of the work needed to get this working requires packages that aren't in fedora already are you able to provide a link to a bunch of src.rpms of everything needed. I'd like to test and wanted to help with this feature awhile back but got sidetracked... However I don't have F20 running on anything so would likely use mock to compile for F18 and see if I can help resolve/test/do something like that.
On Tue 24 Sep 2013 06:46:41 BST, Nathanael Noblet wrote:
On 09/23/2013 11:43 PM, Nathanael Noblet wrote:
However I don't have F20 running on anything so would likely use mock to compile for F18 and see if I can help resolve/test/do something like that.
*F19 ...not 18
Well you could use a F20 box in Vagrant ;)
On Tue 24 Sep 2013 06:43:43 BST, Nathanael Noblet wrote:
On 09/23/2013 06:37 AM, Alexandre Drahon wrote:
Hi all,
I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation:
- I have a vagrant RPM that installs and works as expected, there's
some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240, I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
So, as a summary:
- yum install vagrant should work, at which point you need to
install VirtualBox and it will run as expected
- vagrant-kvm installs but I don't know how to add the right polkit
rules (I need help)
Looks pretty good, right?
It does... Since some of the work needed to get this working requires packages that aren't in fedora already are you able to provide a link to a bunch of src.rpms of everything needed. I'd like to test and wanted to help with this feature awhile back but got sidetracked... However I don't have F20 running on anything so would likely use mock to compile for F18 and see if I can help resolve/test/do something like that.
I'll post a link to the srpms as soon as I find a place to post them. Thanks for the help!
Alex
On 24/09/13 06:43, Nathanael Noblet wrote:
On 09/23/2013 06:37 AM, Alexandre Drahon wrote:
Hi all,
I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation:
- I have a vagrant RPM that installs and works as expected, there's
some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240, I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
So, as a summary:
- yum install vagrant should work, at which point you need to
install VirtualBox and it will run as expected
- vagrant-kvm installs but I don't know how to add the right polkit
rules (I need help)
Looks pretty good, right?
It does... Since some of the work needed to get this working requires packages that aren't in fedora already are you able to provide a link to a bunch of src.rpms of everything needed. I'd like to test and wanted to help with this feature awhile back but got sidetracked... However I don't have F20 running on anything so would likely use mock to compile for F18 and see if I can help resolve/test/do something like that.
I posted the current source packages here http://srpms.adrahon.org/
Vagrant should work with VirtualBox (http://download.virtualbox.org/virtualbox/4.2.18/VirtualBox-4.2-4.2.18_88780... ).
vagrant-kvm still has issues, not sure it's in a testable state yet.
On Thu, Sep 26, 2013 at 10:09:37PM +0100, Alex Drahon wrote:
vagrant-kvm still has issues, not sure it's in a testable state yet.
So, this is maybe a silly question, but how does vagrant-kvm relate to vagrant-libvirt?
On 26/09/13 22:43, Matthew Miller wrote:
On Thu, Sep 26, 2013 at 10:09:37PM +0100, Alex Drahon wrote:
vagrant-kvm still has issues, not sure it's in a testable state yet.
So, this is maybe a silly question, but how does vagrant-kvm relate to vagrant-libvirt?
The two were developed independently. Vagrant-libvirt is more generic and abstract while vagrant-kvm aims at offering the same workflow you would get with VirtualBox. For instance vagrant-libvirt will "share" directories with rsync (like vagrant-aws) while vagrant-kvm uses NFS (because qemu folder sharing isn't really maintained apparently). I'm in contact with with the vagrant-libvirt creator and we exchanged some ideas and some code.
On 09/26/2013 03:09 PM, Alex Drahon wrote:
I posted the current source packages here http://srpms.adrahon.org/
Vagrant should work with VirtualBox (http://download.virtualbox.org/virtualbox/4.2.18/VirtualBox-4.2-4.2.18_88780... ).
vagrant-kvm still has issues, not sure it's in a testable state yet.
Hello,
So I downloaded and used mock to compile them for F19. It seems you've fixed the warning about using non-official versions which is nice. I followed your instructions here: https://github.com/adrahon/vagrant-kvm#quick-start
at vagrant up --provider=kvm I get the following error:
"The provider 'kvm' could not be found, but was requested to back the machine 'default'. Please use a provider that exists."
Is that a plugin loading or a PolicyKit issue? It seems like plugin loading which I thought from your email you got working. In any case it seems like progress is being made since previously the src rpms I had gotten died in much more horrible and verbose ways trying to load plugins.
Thoughts?
On 26/09/13 22:09, Alex Drahon wrote:
On 24/09/13 06:43, Nathanael Noblet wrote:
On 09/23/2013 06:37 AM, Alexandre Drahon wrote:
Hi all,
I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation:
- I have a vagrant RPM that installs and works as expected, there's
some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240, I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
So, as a summary:
- yum install vagrant should work, at which point you need to
install VirtualBox and it will run as expected
- vagrant-kvm installs but I don't know how to add the right polkit
rules (I need help)
Looks pretty good, right?
It does... Since some of the work needed to get this working requires packages that aren't in fedora already are you able to provide a link to a bunch of src.rpms of everything needed. I'd like to test and wanted to help with this feature awhile back but got sidetracked... However I don't have F20 running on anything so would likely use mock to compile for F18 and see if I can help resolve/test/do something like that.
I posted the current source packages here http://srpms.adrahon.org/
Vagrant should work with VirtualBox (http://download.virtualbox.org/virtualbox/4.2.18/VirtualBox-4.2-4.2.18_88780... ).
vagrant-kvm still has issues, not sure it's in a testable state yet.
After trying several solutions, I think I have found the right compromise and finally have working packages (with a some caveats). Again the source packages are at http://srpms.adrahon.org/ : - vagrant looks for plugins both in the user's ~/.vagrant.d directory and /usr/share/gems for system-wide plugins (like vagrant-kvm) - my patched vagrant version looks in /etc/vagrant for the system-wide plugin registry - I added commands to vagrant plugin to manage registration of system-wide plugins (installed with yum) - rpm-packaged plugins register/unregister themselves at installation/uninstallation
This means that Vagrant's behaviour hasn't changed and we can still package plugins as RPMs.
How to test: - you need to install rubygem-log4r, then vagrant, then rubygem-vagrant-kvm - "vagrant init fedora19" (name of your box) then edit the Vagrantfile (you need a private network with a 192.168.192.0 address) - "vagrant up --provider=kvm" should work
Caveats: 1. polkit integration is a problem, if you don't have an agent you won't get the right to connect to the libvirt socket 2. a custom polkit rule works, maybe one should be included (as an example) 3. firewalld blocks nfs connections from the guest to the host, so directory sharing will fail. I suppose I need a custom rule, or at least give instructions to the user on how to do it, but I don't know how it works.
1. Isn't a big problem in most cases because you'll have a desktop environment and a polkit agent, I don't know how the console polkit agent works. 2. should be provided in the readme file? 3. this is the main issue now, I need some help, I'm sure it's not to complex but I don't know if an application package should touch the user's firewalld config.
Hope some of you can test it.
Alex
On 10/15/2013 01:06 PM, Alex Drahon wrote:
Hope some of you can test it.
I'm building it for F19 and F20 for the two machines I use vagrant on to test with and will get back to you.
One thing I noticed is you have a separate vagrant-doc sub-package. I'm wondering what for? I am used to the docs for a particular package to be included with that package. Any reason for this?
On 16/10/13 23:24, Nathanael D. Noblet wrote:
On 10/15/2013 01:06 PM, Alex Drahon wrote:
Hope some of you can test it.
I'm building it for F19 and F20 for the two machines I use vagrant on to test with and will get back to you.
One thing I noticed is you have a separate vagrant-doc sub-package. I'm wondering what for? I am used to the docs for a particular package to be included with that package. Any reason for this?
It's just my lack of experience, I started with gem2rpm and that's what it did by default, I'll correct that.
On 10/15/2013 01:06 PM, Alex Drahon wrote:
On 26/09/13 22:09, Alex Drahon wrote:
On 24/09/13 06:43, Nathanael Noblet wrote:
On 09/23/2013 06:37 AM, Alexandre Drahon wrote:
Hi all,
I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation:
- I have a vagrant RPM that installs and works as expected, there's
some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240, I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
So, as a summary:
- yum install vagrant should work, at which point you need to
install VirtualBox and it will run as expected
- vagrant-kvm installs but I don't know how to add the right polkit
rules (I need help)
Looks pretty good, right?
It does... Since some of the work needed to get this working requires packages that aren't in fedora already are you able to provide a link to a bunch of src.rpms of everything needed. I'd like to test and wanted to help with this feature awhile back but got sidetracked... However I don't have F20 running on anything so would likely use mock to compile for F18 and see if I can help resolve/test/do something like that.
I posted the current source packages here http://srpms.adrahon.org/
Vagrant should work with VirtualBox (http://download.virtualbox.org/virtualbox/4.2.18/VirtualBox-4.2-4.2.18_88780... ).
vagrant-kvm still has issues, not sure it's in a testable state yet.
After trying several solutions, I think I have found the right compromise and finally have working packages (with a some caveats). Again the source packages are at http://srpms.adrahon.org/ :
- vagrant looks for plugins both in the user's ~/.vagrant.d directory
and /usr/share/gems for system-wide plugins (like vagrant-kvm)
- my patched vagrant version looks in /etc/vagrant for the system-wide
plugin registry
- I added commands to vagrant plugin to manage registration of
system-wide plugins (installed with yum)
- rpm-packaged plugins register/unregister themselves at
installation/uninstallation
This means that Vagrant's behaviour hasn't changed and we can still package plugins as RPMs.
How to test:
- you need to install rubygem-log4r, then vagrant, then
rubygem-vagrant-kvm
- "vagrant init fedora19" (name of your box) then edit the Vagrantfile
(you need a private network with a 192.168.192.0 address)
- "vagrant up --provider=kvm" should work
When installing rubygem-vagrant-kvm I get this output on a F19 box... Running transaction Installing : rubygem-vagrant-kvm-0.1.4-1.fc19.noarch 1/1 translation missing: en.vagrant.commands.plugin.unregistering translation missing: en.vagrant.commands.plugin.unregistering /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/state_file.rb:51:in `initialize': No such file or directory - /etc/vagrant/plugins.json (Errno::ENOENT) ... long stack trace.
There is no /etc/vagrant directory. and querying the packages built from your source none of them have a /etc/vagrant directory. I see your vagrant.spec file creates the directory in the buildroot but doesn't claim it in the %files section.
When I add %dir %{_sysconfdir}/vagrant
to your vagrant.spec and rebuild I get further. At least its attempting to fire up a new vagrant instance and I get the polkit prompt...
Also a small packaging issue/suggestion. Typically when trying to get a package included in Fedora you go through issues where you have to regenerate a package. When I was submitting my first packages I don't know how many times I had to make changes, however it is still good to bump the 'Release' tag so that updates continue to function. With the packages you've posted the release number is still 1 so I have to yum remove them and then yum install them. When I did this I was told that its good to use 0.x as the release version so that once submitted to the packagedb the release number starts at 1. Just a thought, either way it would be nice if the release version changed with each of your changes.
On 16/10/13 23:49, Nathanael D. Noblet wrote:
On 10/15/2013 01:06 PM, Alex Drahon wrote:
On 26/09/13 22:09, Alex Drahon wrote:
On 24/09/13 06:43, Nathanael Noblet wrote:
On 09/23/2013 06:37 AM, Alexandre Drahon wrote:
Hi all,
I wanted to give an update on the status of Vagrant in Fedora 20, I just realised it's my first post to the list so I'll take this opportunity to introduce myself. I'm Alex, I work at Red Hat as a Solution Architect (ie. nothing engineering related), I wrote the vagrant-kvm plugin on my spare time to make it work on my Fedora laptop, though there's now a (much more qualified) second maintainer who is also providing support for Ubuntu through a PPA. Matthew asked me if I wanted to work on packaging Vagrant and the KVM plugin for Fedora 20, and I foolishly accepted ;)
It's quite exhilarating having the opportunity to contribute to Fedora, and at the same time I feel totally lost. I don't mean this as a criticism, it's just this "first week at school" feeling, it will take me some time to get an idea of how things work. That said, here's the Vagrant situation:
- I have a vagrant RPM that installs and works as expected, there's
some minimal patching involved which has to do with the fact that Vagrant expect to be running in it's own Ruby 1.9.3 environment in /opt 2. There was also some patching involved to make the plugin system work, although I haven't tested plugins extensively (some stuff breaks like rubygems loading path) and providing common plugins as RPMs looks like the better way in Fedora. 3. I had to build my own rubygems-childprocess (current Fedora package is very old) and rubygems-log4r (not provided in Fedora) RPMs, but I don't know how I should submit them (package review ticket?). There's a existing ticket for log4r https://bugzilla.redhat.com/show_bug.cgi?id=905240, I added it as a dependency to the Vagrant ticket. 4. I've packaged vagrant-kvm as a RPM and it installs, but I'm running into serious issues with Policykit. I don't think I'll be able to solve that without help, I'm not even sure what's the right way to do it.
So, as a summary:
- yum install vagrant should work, at which point you need to
install VirtualBox and it will run as expected
- vagrant-kvm installs but I don't know how to add the right polkit
rules (I need help)
Looks pretty good, right?
It does... Since some of the work needed to get this working requires packages that aren't in fedora already are you able to provide a link to a bunch of src.rpms of everything needed. I'd like to test and wanted to help with this feature awhile back but got sidetracked... However I don't have F20 running on anything so would likely use mock to compile for F18 and see if I can help resolve/test/do something like that.
I posted the current source packages here http://srpms.adrahon.org/
Vagrant should work with VirtualBox (http://download.virtualbox.org/virtualbox/4.2.18/VirtualBox-4.2-4.2.18_88780...
).
vagrant-kvm still has issues, not sure it's in a testable state yet.
After trying several solutions, I think I have found the right compromise and finally have working packages (with a some caveats). Again the source packages are at http://srpms.adrahon.org/ :
- vagrant looks for plugins both in the user's ~/.vagrant.d directory
and /usr/share/gems for system-wide plugins (like vagrant-kvm)
- my patched vagrant version looks in /etc/vagrant for the system-wide
plugin registry
- I added commands to vagrant plugin to manage registration of
system-wide plugins (installed with yum)
- rpm-packaged plugins register/unregister themselves at
installation/uninstallation
This means that Vagrant's behaviour hasn't changed and we can still package plugins as RPMs.
How to test:
- you need to install rubygem-log4r, then vagrant, then
rubygem-vagrant-kvm
- "vagrant init fedora19" (name of your box) then edit the Vagrantfile
(you need a private network with a 192.168.192.0 address)
- "vagrant up --provider=kvm" should work
When installing rubygem-vagrant-kvm I get this output on a F19 box... Running transaction Installing : rubygem-vagrant-kvm-0.1.4-1.fc19.noarch 1/1 translation missing: en.vagrant.commands.plugin.unregistering translation missing: en.vagrant.commands.plugin.unregistering /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/state_file.rb:51:in `initialize': No such file or directory - /etc/vagrant/plugins.json (Errno::ENOENT) ... long stack trace.
There is no /etc/vagrant directory. and querying the packages built from your source none of them have a /etc/vagrant directory. I see your vagrant.spec file creates the directory in the buildroot but doesn't claim it in the %files section.
When I add %dir %{_sysconfdir}/vagrant
to your vagrant.spec and rebuild I get further. At least its attempting to fire up a new vagrant instance and I get the polkit prompt...
Also a small packaging issue/suggestion. Typically when trying to get a package included in Fedora you go through issues where you have to regenerate a package. When I was submitting my first packages I don't know how many times I had to make changes, however it is still good to bump the 'Release' tag so that updates continue to function. With the packages you've posted the release number is still 1 so I have to yum remove them and then yum install them. When I did this I was told that its good to use 0.x as the release version so that once submitted to the packagedb the release number starts at 1. Just a thought, either way it would be nice if the release version changed with each of your changes.
I missed the /etc/vagrant issue, bad testing. It seems strange that I didn't get an alert about having `install -d -m 755 %{buildroot}/etc/vagrant` in %install but no reference to it in %files (`%dir %{_sysconfdir}/vagrant` goes in %files I guess).
Well noted for the release number issue and it makes sense.
Thanks for the feedback.
On 10/15/2013 01:06 PM, Alex Drahon wrote:
Hope some of you can test it.
After doing a vagrant up --provider=kvm I get prompted via polkit and then the terminal output is as follows:
[gnat@iridium kvm]$ vagrant up --provider=kvm Bringing machine 'default' up with 'kvm' provider... [default] Importing base box 'precise32'... WARNING: Nokogiri was built against LibXML version 2.9.0, but has dynamically loaded 2.9.1 qemu-img: /home/gnat/.vagrant.d/tmp/storage-pool/box-disk1-1381964017.img: error while converting raw: Permission denied
/usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in `lookup_volume_by_name': Call to virStorageVolLookupByName failed: Storage volume not found: no storage vol with matching name 'box-disk1-1381964017.img' (Libvirt::RetrieveError) from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in `import_ovf' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/import.rb:27:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/check_box.rb:31:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `block in run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/util/busy.rb:19:in `busy' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builtin/call.rb:51:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/init_storage_pool.rb:14:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/set_name.rb:25:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/check_kvm.rb:18:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builder.rb:116:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `block in run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/util/busy.rb:19:in `busy' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/machine.rb:147:in `action' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/batch_action.rb:63:in `block (2 levels) in run'
On 16/10/13 23:54, Nathanael D. Noblet wrote:
On 10/15/2013 01:06 PM, Alex Drahon wrote:
Hope some of you can test it.
After doing a vagrant up --provider=kvm I get prompted via polkit and then the terminal output is as follows:
[gnat@iridium kvm]$ vagrant up --provider=kvm Bringing machine 'default' up with 'kvm' provider... [default] Importing base box 'precise32'... WARNING: Nokogiri was built against LibXML version 2.9.0, but has dynamically loaded 2.9.1 qemu-img: /home/gnat/.vagrant.d/tmp/storage-pool/box-disk1-1381964017.img: error while converting raw: Permission denied
/usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in `lookup_volume_by_name': Call to virStorageVolLookupByName failed: Storage volume not found: no storage vol with matching name 'box-disk1-1381964017.img' (Libvirt::RetrieveError) from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in `import_ovf' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/import.rb:27:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/check_box.rb:31:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `block in run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/util/busy.rb:19:in `busy' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builtin/call.rb:51:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/init_storage_pool.rb:14:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/set_name.rb:25:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/check_kvm.rb:18:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builder.rb:116:in `call'
from/usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `block in run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/util/busy.rb:19:in `busy' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/machine.rb:147:in `action' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/batch_action.rb:63:in `block (2 levels) in run'
OK, what it means is that you got the polkit prompt, which gave you access to libvirtd, but then the storage pool in /home/gnat/.vagrant.d/tmp/storage-pool/ was created by libvirt with root as the owner so when vagrant calls qemu-img (without root privileges) it fails. Bad testing on my side again...
Sorry for the cross + top post however I figured perhaps -devel folks may have some ideas as to what is going on belowl
On 10/17/2013 06:36 AM, Alex Drahon wrote:
On 16/10/13 23:54, Nathanael D. Noblet wrote:
On 10/15/2013 01:06 PM, Alex Drahon wrote:
Hope some of you can test it.
After doing a vagrant up --provider=kvm I get prompted via polkit and then the terminal output is as follows:
[gnat@iridium kvm]$ vagrant up --provider=kvm Bringing machine 'default' up with 'kvm' provider... [default] Importing base box 'precise32'... WARNING: Nokogiri was built against LibXML version 2.9.0, but has dynamically loaded 2.9.1 qemu-img: /home/gnat/.vagrant.d/tmp/storage-pool/box-disk1-1381964017.img: error while converting raw: Permission denied
/usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in `lookup_volume_by_name': Call to virStorageVolLookupByName failed: Storage volume not found: no storage vol with matching name 'box-disk1-1381964017.img' (Libvirt::RetrieveError)
OK, what it means is that you got the polkit prompt, which gave you access to libvirtd, but then the storage pool in /home/gnat/.vagrant.d/tmp/storage-pool/ was created by libvirt with root as the owner so when vagrant calls qemu-img (without root privileges) it fails. Bad testing on my side again...
So a couple days ago I started trying to get this working again. Something else must be going on. The first problem I had was that kvm/libvirt couldn't read .vmdk vagrant images. I converted them to qcow2, and then ran vagrant as root. This skips the whole polkit step however I get a similar error message as root.
[root@mba Vagrant]# vagrant up --provider=kvm Bringing machine 'default' up with 'kvm' provider... [default] Importing base box 'f19'... qemu-img: /root/.vagrant.d/tmp/storage-pool/box-disk1-1385699731.img: error while converting raw: No such file or directory
/usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in `lookup_volume_by_name': Call to virStorageVolLookupByName failed: Storage volume not found: no storage vol with matching name 'box-disk1-1385699731.img' (Libvirt::RetrieveError)
So I don't think this is a polkit/libvirt error persay as much as it is something isn't creating whatever img its looking for. Anyone have any ideas as to what could be causing this issue?
On Thu, Nov 28, 2013 at 09:47:34PM -0700, Nathanael Noblet wrote:
[root@mba Vagrant]# vagrant up --provider=kvm Bringing machine 'default' up with 'kvm' provider... [default] Importing base box 'f19'... qemu-img: /root/.vagrant.d/tmp/storage-pool/box-disk1-1385699731.img: error while converting raw: No such file or directory
QEMU errors are notoriously obscure. Have a look at the image file and check (a) it really exists (b) any backing file(s) it uses really exist too. It's also probably a good idea to determine precisely what qemu-img command is being run here, and run 'qemu-img info' on the file to find out what format it is in.
/usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in `lookup_volume_by_name': Call to virStorageVolLookupByName failed: Storage volume not found: no storage vol with matching name 'box-disk1-1385699731.img' (Libvirt::RetrieveError)
Again, it looks like a missing file or backing file, but hard to tell without examining the file.
Rich.
On Thu, 2013-10-17 at 13:36 +0100, Alex Drahon wrote:
OK, what it means is that you got the polkit prompt, which gave you access to libvirtd, but then the storage pool in /home/gnat/.vagrant.d/tmp/storage-pool/ was created by libvirt with root as the owner so when vagrant calls qemu-img (without root privileges) it fails. Bad testing on my side again...
Hello
So I'm extremely interested in using vagrant-kvm on fedora. I've repackaged your latest git commits in an effort to get it working however I'm still unable to do so. My tests seem to indicate that the issue isn't one of polkit since I've tested it as root and the error messages are the same. I noticed that the standard box format for vagrant-kvm is qcow2. So I converted a box from vmdk to raw to qcow2 to use, however even so I still can't get a box started.
I can't install vagrant-mutate since there is no rpm. vagrant plugin install vagrant-mutate results in an error. Not sure why its trying to uninstall the bigdecimal gem that is provided as a rpm. Also I *just* noticed that it's trying to uninstall the vagrant-mutate plugin?? So it seems I have one installed but I guess not up to date. However vagrant plugin list does not list mutate as a plugin, only kvm.. so something is odd there.
Installing the 'vagrant-mutate' plugin. This can take a few minutes... Installed the plugin 'vagrant-mutate (0.2.2)'! Uninstalling the 'vagrant-mutate' plugin... Uninstalling the 'vagrant-mutate' plugin... Uninstalling the 'vagrant-mutate' plugin... /usr/share/rubygems/rubygems/uninstaller.rb:118:in `uninstall': bigdecimal is not installed in GEM_HOME, try: (Gem::InstallError) gem uninstall -i /usr/share/gems bigdecimal from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/action/prune_gems.rb:139:in `block (2 levels) in call' from /usr/share/ruby/set.rb:232:in `each_key' from /usr/share/ruby/set.rb:232:in `each' from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/action/prune_gems.rb:129:in `block in call' from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/gem_helper.rb:42:in `block in with_environment' from /usr/share/rubygems/rubygems/user_interaction.rb:40:in `use_ui' from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/gem_helper.rb:41:in `with_environment' from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/action/prune_gems.rb:128:in `call'
<snip>....
Trying to run vagrant up --provider=kvm as root results in:
[root@mba Vagrant]# vagrant up --provider=kvm Bringing machine 'default' up with 'kvm' provider... [default] Importing base box 'f19'... Failed to convert image to specified format.
the VagrantFile contents are: VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "f19" config.vm.network :private_network, ip: "192.168.192.10" end
the /root/.vagrant.d/boxes/f19/kvm directory was copied from the virtualbox one. I then ran VBoxManage clonehd box-disk1.vmdk box-disk1.raw. Then qemu-img convert -O qcow2 box-disk1.raw box-disk1.qcow2. Edited the box.ovf and changed only the following so instead of .vmdk it was .qcow2.
<References> <File ovf:href="box-disk1.qcow2" ovf:id="file1"/> </References>
Any ideas what is going on? How to move forward etc..
On Wed 08 Jan 2014 23:30:35 GMT, Nathanael D. Noblet wrote:
On Thu, 2013-10-17 at 13:36 +0100, Alex Drahon wrote:
OK, what it means is that you got the polkit prompt, which gave you access to libvirtd, but then the storage pool in /home/gnat/.vagrant.d/tmp/storage-pool/ was created by libvirt with root as the owner so when vagrant calls qemu-img (without root privileges) it fails. Bad testing on my side again...
Hello
So I'm extremely interested in using vagrant-kvm on fedora. I've repackaged your latest git commits in an effort to get it working however I'm still unable to do so. My tests seem to indicate that the issue isn't one of polkit since I've tested it as root and the error messages are the same. I noticed that the standard box format for vagrant-kvm is qcow2. So I converted a box from vmdk to raw to qcow2 to use, however even so I still can't get a box started.
I can't install vagrant-mutate since there is no rpm. vagrant plugin install vagrant-mutate results in an error. Not sure why its trying to uninstall the bigdecimal gem that is provided as a rpm. Also I *just* noticed that it's trying to uninstall the vagrant-mutate plugin?? So it seems I have one installed but I guess not up to date. However vagrant plugin list does not list mutate as a plugin, only kvm.. so something is odd there.
Installing the 'vagrant-mutate' plugin. This can take a few minutes... Installed the plugin 'vagrant-mutate (0.2.2)'! Uninstalling the 'vagrant-mutate' plugin... Uninstalling the 'vagrant-mutate' plugin... Uninstalling the 'vagrant-mutate' plugin... /usr/share/rubygems/rubygems/uninstaller.rb:118:in `uninstall': bigdecimal is not installed in GEM_HOME, try: (Gem::InstallError) gem uninstall -i /usr/share/gems bigdecimal from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/action/prune_gems.rb:139:in `block (2 levels) in call' from /usr/share/ruby/set.rb:232:in `each_key' from /usr/share/ruby/set.rb:232:in `each' from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/action/prune_gems.rb:129:in `block in call' from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/gem_helper.rb:42:in `block in with_environment' from /usr/share/rubygems/rubygems/user_interaction.rb:40:in `use_ui' from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/gem_helper.rb:41:in `with_environment' from /usr/share/gems/gems/vagrant-1.3.3/plugins/commands/plugin/action/prune_gems.rb:128:in `call'
<snip>....
Trying to run vagrant up --provider=kvm as root results in:
[root@mba Vagrant]# vagrant up --provider=kvm Bringing machine 'default' up with 'kvm' provider... [default] Importing base box 'f19'... Failed to convert image to specified format.
the VagrantFile contents are: VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.vm.box = "f19" config.vm.network :private_network, ip: "192.168.192.10" end
the /root/.vagrant.d/boxes/f19/kvm directory was copied from the virtualbox one. I then ran VBoxManage clonehd box-disk1.vmdk box-disk1.raw. Then qemu-img convert -O qcow2 box-disk1.raw box-disk1.qcow2. Edited the box.ovf and changed only the following so instead of .vmdk it was .qcow2.
<References> <File ovf:href="box-disk1.qcow2" ovf:id="file1"/> </References>
Any ideas what is going on? How to move forward etc..
cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Hi Nathanael,
Sorry for the late response, I haven't been following the list for some time. Most of the work and bug fixing is currently done upstream at https://github.com/adrahon/vagrant-kvm and we are still facing an issue with the storage pool, both on Fedora and Ubuntu. We're working on a workaround (using the default storage pool and allow the user to choose another one). When it's fixed and we can do a gem release, I'll go back to packaging it for Fedora (and look at dependencies issues). For now, I think it's best to 'vagrant plugin install vagrant-kcm' on a standard Vagrant install.
Alex
On 16/10/13 23:54, Nathanael D. Noblet wrote:
On 10/15/2013 01:06 PM, Alex Drahon wrote:
Hope some of you can test it.
After doing a vagrant up --provider=kvm I get prompted via polkit and then the terminal output is as follows:
[gnat@iridium kvm]$ vagrant up --provider=kvm Bringing machine 'default' up with 'kvm' provider... [default] Importing base box 'precise32'... WARNING: Nokogiri was built against LibXML version 2.9.0, but has dynamically loaded 2.9.1 qemu-img: /home/gnat/.vagrant.d/tmp/storage-pool/box-disk1-1381964017.img: error while converting raw: Permission denied
/usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in `lookup_volume_by_name': Call to virStorageVolLookupByName failed: Storage volume not found: no storage vol with matching name 'box-disk1-1381964017.img' (Libvirt::RetrieveError) from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/driver/driver.rb:145:in `import_ovf' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/import.rb:27:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/check_box.rb:31:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `block in run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/util/busy.rb:19:in `busy' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builtin/call.rb:51:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/init_storage_pool.rb:14:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/set_name.rb:25:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-kvm-0.1.4/lib/vagrant-kvm/action/check_kvm.rb:18:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/builder.rb:116:in `call'
from/usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `block in run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/util/busy.rb:19:in `busy' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/action/runner.rb:61:in `run' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/machine.rb:147:in `action' from /usr/share/gems/gems/vagrant-1.3.3/lib/vagrant/batch_action.rb:63:in `block (2 levels) in run'
I updated the package, but this is still not solved, though it works on F18. If the directory is owned by the user then the image gets copied but libvirt then can't access it... Not sure where to begin with that.
On 10/18/2013 09:45 AM, Alex Drahon wrote:
I updated the package, but this is still not solved, though it works on F18. If the directory is owned by the user then the image gets copied but libvirt then can't access it... Not sure where to begin with that.
So I've never actually used libvirt/kvm/qemu so I'm not sure what does what. I'll try to dig into this a bit to see if I can help. I'll try to take a look today.
On 10/18/2013 09:45 AM, Alex Drahon wrote:
I updated the package, but this is still not solved, though it works on F18. If the directory is owned by the user then the image gets copied but libvirt then can't access it... Not sure where to begin with that.
Any idea if any of your changes would break bringing up a new box? I am no longer able to bring up another box. I have a simple Vagrantfile
Vagrant.configure("2") do |config| config.vm.box = "CentOS-6.3-x86_64-minimal.box" config.vm.box_url = "https://dl.dropbox.com/u/7225008/Vagrant/CentOS-6.3-x86_64-minimal.box" config.vm.network :private_network, ip: "192.168.56.150" end
however it fails to import the box (I use it a few places). With: There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below.
Command: ["import", "/home/gnat/.vagrant.d/boxes/CentOS-6.3-x86_64-minimal.box/virtualbox/box.ovf"]
Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% Interpreting /home/gnat/.vagrant.d/boxes/CentOS-6.3-x86_64-minimal.box/virtualbox/box.ovf... OK. 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%... Progress state: VBOX_E_FILE_ERROR VBoxManage: error: Appliance import failed VBoxManage: error: Machine settings file '/srv/vms/CentOS-6.3-x86_64-minimal/CentOS-6.3-x86_64-minimal.vbox' already exists VBoxManage: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component Machine, interface IMachine VBoxManage: error: Context: "int handleImportAppliance(HandlerArg*)" at line 781 of file VBoxManageAppliance.cpp
Thoughts? I don't have any VM or hd with that precise name so I'm not sure whate the issue is...
On 10/22/2013 12:34 PM, Nathanael D. Noblet wrote:
Thoughts? I don't have any VM or hd with that precise name so I'm not sure whate the issue is...
Scratch that somehow there was actually a file there with the same name unassociated with anything and not in VB's virtual media manager.. removing the file and all is well...
-
Alex Drahon -
Matthew Miller -
Mo Morsi -
Nathanael D. Noblet -
Richard W.M. Jones