Re: Why does so much virt stuff depend on glusterfs?

2013-07-25 Thread Daniel P. Berrange 
On Wed, Jul 24, 2013 at 01:39:14PM -0400, Cole Robinson wrote:
 On 07/24/2013 01:36 PM, Cole Robinson wrote:
  On 07/24/2013 05:18 AM, Daniel P. Berrange wrote:
  On Tue, Jul 23, 2013 at 11:28:20AM -0700, Adam Williamson wrote:
  On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote:
  On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote:
  On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
   
  So this thread is complaining about..
 
 Removing:
  glusterfs   x86_64 3.4.0-2.fc19 
  @updates-testing 4.7 M
 Removing for dependencies:
  glusterfs-api   x86_64 3.4.0-2.fc19 
  @updates-testing  88 k
  glusterfs-fuse  x86_64 3.4.0-2.fc19 
  @updates-testing 233 k
 
   5M of deps, meanwhile..
 
  qemu-system-alpha   x86_64 2:1.4.2-4.fc19   
  @updates-testing 4.1 M
  qemu-system-arm x86_64 2:1.4.2-4.fc19   
  @updates-testing 5.2 M
  qemu-system-crisx86_64 2:1.4.2-4.fc19   
  @updates-testing 2.8 M
  qemu-system-lm32x86_64 2:1.4.2-4.fc19   
  @updates-testing 2.8 M
  qemu-system-m68kx86_64 2:1.4.2-4.fc19   
  @updates-testing 3.8 M
  qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   
  @updates-testing 5.6 M
  qemu-system-mipsx86_64 2:1.4.2-4.fc19   
  @updates-testing  21 M
  qemu-system-or32x86_64 2:1.4.2-4.fc19   
  @updates-testing 2.7 M
  qemu-system-ppc x86_64 2:1.4.2-4.fc19   
  @updates-testing  18 M
  qemu-system-s390x   x86_64 2:1.4.2-4.fc19   
  @updates-testing 3.1 M
  qemu-system-sh4 x86_64 2:1.4.2-4.fc19   
  @updates-testing 7.5 M
  qemu-system-sparc   x86_64 2:1.4.2-4.fc19   
  @updates-testing 7.3 M
  qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   
  @updates-testing 2.7 M
  qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   
  @updates-testing 5.6 M
 
  Do we really *need* all those ?
 
  Hopefully those *are* removable.
 
  Unfortunately some packages depend on the 'qemu' meta package which
  pulls in all of the emulators.
 
  I don't know if that's the case for me, I just did a 'yum install
  @Virtualization' on the host in question which is why I have all the
  stuff the metapackages pull in. I know about that, which is why I didn't
  complain about it.
 
  Hmm, if @Virtualization pulls in all the QEMU emulators then we probably
  have a bogus comps config. I'd say @Virtualization should probably only
  pull in the KVM binary, leaving the QEMU emulators alone, since few
  people will want them.
 
  
  Yeah comps still has a dep on plain 'libvirt' which will pull all of that 
  in.
  If no one objects, I'll push a change to make it libvirt-daemon-driver-kvm
  which should only pull in the required libvirt bits.
 
 Err, s/libvirt-daemon-driver-kvm/libvirt-daemon-kvm/

Yes, that sounds like a good idea.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-25 Thread Daniel P. Berrange 
On Wed, Jul 24, 2013 at 02:02:42PM -0400, Bill Nottingham wrote:
 Daniel P. Berrange (berra...@redhat.com) said: 
  But the qemu-kvm binary can still run in TCG mode - you don't need to
  install the QEMU emulators too. So your dep could be
  
 %ifarch %{ix86} x86_64
 Requires:  libvirt-daemon-kvm = 0.10.2-3
 %else
 Requires:  libvirt-daemon-qemu = 0.10.2-3
 %endif
  
  thus avoiding install of QEMU emulators unless they're the only
  option available.
 
 libvirt-sandbox-libs also brings in libvirt-daemon-qemu - that seems strange
 at first glance.

Yes, that needs fixing in the same way as above too really


Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-25 Thread Richard W.M. Jones 
On Thu, Jul 25, 2013 at 09:55:14AM +0100, Daniel P. Berrange wrote:
 On Wed, Jul 24, 2013 at 02:02:42PM -0400, Bill Nottingham wrote:
  Daniel P. Berrange (berra...@redhat.com) said: 
   But the qemu-kvm binary can still run in TCG mode - you don't need to
   install the QEMU emulators too. So your dep could be
   
  %ifarch %{ix86} x86_64
  Requires:  libvirt-daemon-kvm = 0.10.2-3
  %else
  Requires:  libvirt-daemon-qemu = 0.10.2-3
  %endif
   
   thus avoiding install of QEMU emulators unless they're the only
   option available.
  
  libvirt-sandbox-libs also brings in libvirt-daemon-qemu - that seems strange
  at first glance.
 
 Yes, that needs fixing in the same way as above too really

I have changed the libguestfs dependency now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-25 Thread Kashyap Chamarthy 
On 07/23/2013 10:27 PM, Dave Jones wrote:
 On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
  
 So this thread is complaining about..
 
Removing:
 glusterfs   x86_64 3.4.0-2.fc19 
 @updates-testing 4.7 M
Removing for dependencies:
 glusterfs-api   x86_64 3.4.0-2.fc19 
 @updates-testing  88 k
 glusterfs-fuse  x86_64 3.4.0-2.fc19 
 @updates-testing 233 k
 
  5M of deps, meanwhile..
 
 qemu-system-alpha   x86_64 2:1.4.2-4.fc19   
 @updates-testing 4.1 M
 qemu-system-arm x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.2 M
 qemu-system-crisx86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-lm32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-m68kx86_64 2:1.4.2-4.fc19   
 @updates-testing 3.8 M
 qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M
 qemu-system-mipsx86_64 2:1.4.2-4.fc19   
 @updates-testing  21 M
 qemu-system-or32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-ppc x86_64 2:1.4.2-4.fc19   
 @updates-testing  18 M
 qemu-system-s390x   x86_64 2:1.4.2-4.fc19   
 @updates-testing 3.1 M
 qemu-system-sh4 x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.5 M
 qemu-system-sparc   x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.3 M
 qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M
 
 Do we really *need* all those ?  (And why are mips  ppc so much bigger ?)

To get a minimal working KVM based virt, I used to run:

 $ yum install libvirt-daemon-kvm libvirt-daemon-config-network \
   libvirt-daemon-config-nwfilter -y
 $ yum install virt-install -y


 # This is what is pulling in all the other arch qemu deps
 $ yum install libguestfs libguestfs-tools libguestfs-tools-c -y




-- 
/kashyap
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-24 Thread Daniel P. Berrange 
On Tue, Jul 23, 2013 at 09:46:30PM +0100, Richard W.M. Jones wrote:
 On Tue, Jul 23, 2013 at 03:00:46PM -0400, Bill Nottingham wrote:
  Richard W.M. Jones (rjo...@redhat.com) said: 
   On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote:
However for some reason I can't quite understand, libvirt-daemon
depends on 'qemu'.  That may be a bug?
   
   I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'.
  
  Isn't it simplest for that to depend on a virtual 'qemu-system', which is
  provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches?
 
 Right, which is why I said this may be a bug.  Dan Berrange (CC'd on
 this subthread) will know.

The libvirt-daemon-qemu package is intended to pull in the QEMU emulators.
If you only want to pull in KVM, then you should depend on the separate
libvirt-daemon-kvm package instead.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-24 Thread Daniel P. Berrange 
On Tue, Jul 23, 2013 at 11:28:20AM -0700, Adam Williamson wrote:
 On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote:
  On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote:
   On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:

   So this thread is complaining about..
   
  Removing:
   glusterfs   x86_64 3.4.0-2.fc19 
   @updates-testing 4.7 M
  Removing for dependencies:
   glusterfs-api   x86_64 3.4.0-2.fc19 
   @updates-testing  88 k
   glusterfs-fuse  x86_64 3.4.0-2.fc19 
   @updates-testing 233 k
   
5M of deps, meanwhile..
   
   qemu-system-alpha   x86_64 2:1.4.2-4.fc19   
   @updates-testing 4.1 M
   qemu-system-arm x86_64 2:1.4.2-4.fc19   
   @updates-testing 5.2 M
   qemu-system-crisx86_64 2:1.4.2-4.fc19   
   @updates-testing 2.8 M
   qemu-system-lm32x86_64 2:1.4.2-4.fc19   
   @updates-testing 2.8 M
   qemu-system-m68kx86_64 2:1.4.2-4.fc19   
   @updates-testing 3.8 M
   qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   
   @updates-testing 5.6 M
   qemu-system-mipsx86_64 2:1.4.2-4.fc19   
   @updates-testing  21 M
   qemu-system-or32x86_64 2:1.4.2-4.fc19   
   @updates-testing 2.7 M
   qemu-system-ppc x86_64 2:1.4.2-4.fc19   
   @updates-testing  18 M
   qemu-system-s390x   x86_64 2:1.4.2-4.fc19   
   @updates-testing 3.1 M
   qemu-system-sh4 x86_64 2:1.4.2-4.fc19   
   @updates-testing 7.5 M
   qemu-system-sparc   x86_64 2:1.4.2-4.fc19   
   @updates-testing 7.3 M
   qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   
   @updates-testing 2.7 M
   qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   
   @updates-testing 5.6 M
   
   Do we really *need* all those ?
  
  Hopefully those *are* removable.
  
  Unfortunately some packages depend on the 'qemu' meta package which
  pulls in all of the emulators.
 
 I don't know if that's the case for me, I just did a 'yum install
 @Virtualization' on the host in question which is why I have all the
 stuff the metapackages pull in. I know about that, which is why I didn't
 complain about it.

Hmm, if @Virtualization pulls in all the QEMU emulators then we probably
have a bogus comps config. I'd say @Virtualization should probably only
pull in the KVM binary, leaving the QEMU emulators alone, since few
people will want them.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-24 Thread Richard W.M. Jones 
On Wed, Jul 24, 2013 at 10:17:14AM +0100, Daniel P. Berrange wrote:
 On Tue, Jul 23, 2013 at 09:46:30PM +0100, Richard W.M. Jones wrote:
  On Tue, Jul 23, 2013 at 03:00:46PM -0400, Bill Nottingham wrote:
   Richard W.M. Jones (rjo...@redhat.com) said: 
On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote:
 However for some reason I can't quite understand, libvirt-daemon
 depends on 'qemu'.  That may be a bug?

I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'.
   
   Isn't it simplest for that to depend on a virtual 'qemu-system', which is
   provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches?
  
  Right, which is why I said this may be a bug.  Dan Berrange (CC'd on
  this subthread) will know.
 
 The libvirt-daemon-qemu package is intended to pull in the QEMU emulators.
 If you only want to pull in KVM, then you should depend on the separate
 libvirt-daemon-kvm package instead.

In libguestfs I have:

  Requires:  libvirt-daemon-qemu = 0.10.2-3
  %ifarch %{ix86} x86_64
  Requires:  libvirt-daemon-kvm = 0.10.2-3
  %endif

because I don't know if I'm going to be needing TCG or can use KVM.

Although, qemu-kvm is now an empty package ..  So all I really want is
qemu-system-%{arch}.

There's also code in libguestfs (src/launch-libvirt.c:parse_capabilities)
to parse the capabilities output looking for qemu or kvm.  It would be
nice if there was a best option instead.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-24 Thread Daniel P. Berrange 
On Wed, Jul 24, 2013 at 11:08:41AM +0100, Richard W.M. Jones wrote:
 On Wed, Jul 24, 2013 at 10:17:14AM +0100, Daniel P. Berrange wrote:
  On Tue, Jul 23, 2013 at 09:46:30PM +0100, Richard W.M. Jones wrote:
   On Tue, Jul 23, 2013 at 03:00:46PM -0400, Bill Nottingham wrote:
Richard W.M. Jones (rjo...@redhat.com) said: 
 On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote:
  However for some reason I can't quite understand, libvirt-daemon
  depends on 'qemu'.  That may be a bug?
 
 I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'.

Isn't it simplest for that to depend on a virtual 'qemu-system', which 
is
provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM 
arches?
   
   Right, which is why I said this may be a bug.  Dan Berrange (CC'd on
   this subthread) will know.
  
  The libvirt-daemon-qemu package is intended to pull in the QEMU emulators.
  If you only want to pull in KVM, then you should depend on the separate
  libvirt-daemon-kvm package instead.
 
 In libguestfs I have:
 
   Requires:  libvirt-daemon-qemu = 0.10.2-3
   %ifarch %{ix86} x86_64
   Requires:  libvirt-daemon-kvm = 0.10.2-3
   %endif
 
 because I don't know if I'm going to be needing TCG or can use KVM.

But the qemu-kvm binary can still run in TCG mode - you don't need to
install the QEMU emulators too. So your dep could be

   %ifarch %{ix86} x86_64
   Requires:  libvirt-daemon-kvm = 0.10.2-3
   %else
   Requires:  libvirt-daemon-qemu = 0.10.2-3
   %endif

thus avoiding install of QEMU emulators unless they're the only
option available.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-24 Thread Cole Robinson 
On 07/24/2013 05:18 AM, Daniel P. Berrange wrote:
 On Tue, Jul 23, 2013 at 11:28:20AM -0700, Adam Williamson wrote:
 On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote:
 On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote:
 On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
  
 So this thread is complaining about..

Removing:
 glusterfs   x86_64 3.4.0-2.fc19 
 @updates-testing 4.7 M
Removing for dependencies:
 glusterfs-api   x86_64 3.4.0-2.fc19 
 @updates-testing  88 k
 glusterfs-fuse  x86_64 3.4.0-2.fc19 
 @updates-testing 233 k

  5M of deps, meanwhile..

 qemu-system-alpha   x86_64 2:1.4.2-4.fc19   
 @updates-testing 4.1 M
 qemu-system-arm x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.2 M
 qemu-system-crisx86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-lm32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-m68kx86_64 2:1.4.2-4.fc19   
 @updates-testing 3.8 M
 qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M
 qemu-system-mipsx86_64 2:1.4.2-4.fc19   
 @updates-testing  21 M
 qemu-system-or32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-ppc x86_64 2:1.4.2-4.fc19   
 @updates-testing  18 M
 qemu-system-s390x   x86_64 2:1.4.2-4.fc19   
 @updates-testing 3.1 M
 qemu-system-sh4 x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.5 M
 qemu-system-sparc   x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.3 M
 qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M

 Do we really *need* all those ?

 Hopefully those *are* removable.

 Unfortunately some packages depend on the 'qemu' meta package which
 pulls in all of the emulators.

 I don't know if that's the case for me, I just did a 'yum install
 @Virtualization' on the host in question which is why I have all the
 stuff the metapackages pull in. I know about that, which is why I didn't
 complain about it.
 
 Hmm, if @Virtualization pulls in all the QEMU emulators then we probably
 have a bogus comps config. I'd say @Virtualization should probably only
 pull in the KVM binary, leaving the QEMU emulators alone, since few
 people will want them.
 

Yeah comps still has a dep on plain 'libvirt' which will pull all of that in.
If no one objects, I'll push a change to make it libvirt-daemon-driver-kvm
which should only pull in the required libvirt bits.

- Cole

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-24 Thread Cole Robinson 
On 07/24/2013 01:36 PM, Cole Robinson wrote:
 On 07/24/2013 05:18 AM, Daniel P. Berrange wrote:
 On Tue, Jul 23, 2013 at 11:28:20AM -0700, Adam Williamson wrote:
 On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote:
 On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote:
 On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
  
 So this thread is complaining about..

Removing:
 glusterfs   x86_64 3.4.0-2.fc19 
 @updates-testing 4.7 M
Removing for dependencies:
 glusterfs-api   x86_64 3.4.0-2.fc19 
 @updates-testing  88 k
 glusterfs-fuse  x86_64 3.4.0-2.fc19 
 @updates-testing 233 k

  5M of deps, meanwhile..

 qemu-system-alpha   x86_64 2:1.4.2-4.fc19   
 @updates-testing 4.1 M
 qemu-system-arm x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.2 M
 qemu-system-crisx86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-lm32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-m68kx86_64 2:1.4.2-4.fc19   
 @updates-testing 3.8 M
 qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M
 qemu-system-mipsx86_64 2:1.4.2-4.fc19   
 @updates-testing  21 M
 qemu-system-or32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-ppc x86_64 2:1.4.2-4.fc19   
 @updates-testing  18 M
 qemu-system-s390x   x86_64 2:1.4.2-4.fc19   
 @updates-testing 3.1 M
 qemu-system-sh4 x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.5 M
 qemu-system-sparc   x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.3 M
 qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M

 Do we really *need* all those ?

 Hopefully those *are* removable.

 Unfortunately some packages depend on the 'qemu' meta package which
 pulls in all of the emulators.

 I don't know if that's the case for me, I just did a 'yum install
 @Virtualization' on the host in question which is why I have all the
 stuff the metapackages pull in. I know about that, which is why I didn't
 complain about it.

 Hmm, if @Virtualization pulls in all the QEMU emulators then we probably
 have a bogus comps config. I'd say @Virtualization should probably only
 pull in the KVM binary, leaving the QEMU emulators alone, since few
 people will want them.

 
 Yeah comps still has a dep on plain 'libvirt' which will pull all of that in.
 If no one objects, I'll push a change to make it libvirt-daemon-driver-kvm
 which should only pull in the required libvirt bits.

Err, s/libvirt-daemon-driver-kvm/libvirt-daemon-kvm/

- COle

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-24 Thread Bill Nottingham 
Daniel P. Berrange (berra...@redhat.com) said: 
 But the qemu-kvm binary can still run in TCG mode - you don't need to
 install the QEMU emulators too. So your dep could be
 
%ifarch %{ix86} x86_64
Requires:  libvirt-daemon-kvm = 0.10.2-3
%else
Requires:  libvirt-daemon-qemu = 0.10.2-3
%endif
 
 thus avoiding install of QEMU emulators unless they're the only
 option available.

libvirt-sandbox-libs also brings in libvirt-daemon-qemu - that seems strange
at first glance.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Richard W.M. Jones 
On Mon, Jul 22, 2013 at 08:26:18PM -0400, Matthew Miller wrote:
 On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
  Today in Absurd Dependency Bingo:
glusterfs   x86_64 3.4.0-2.fc19 @updates-testing 
   4.7 M
 [...]
qemu-common x86_64 2:1.4.2-4.fc19   @updates-testing 
   624 k
 
 $ rpm -q --changelog qemu-common
 [...]
 * Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2
 - Enable gluster support
 
 And then all the rest just falls out from there because they require qemu.
 
 
vinagre x86_64 3.8.2-1.fc19 @side
   3.0 M
 
 (This one requires spice.)
 
 At 4.7M glusterfs isn't exactly tiny, and is another one of these things
 that's not so useful unless configured (even though that's awesomely easy);
 maybe the libs could be split out?

The problem is that qemu's block layer isn't a stable API with
pluggable / loadable modules.  There's been some talk and even patches
upstream trying making it so (at least, the loadable modules part, the
stable API part will probably never happen).  But it's not done yet.

qemu's internal block API:
http://git.qemu.org/?p=qemu.git;a=blob;f=include/block/block_int.h;h=c6ac871e210ea21f91d799e44a102119048dde54;hb=HEAD#l83

Therefore if you want to use qemu to access, in this case, a glusterfs
cluster, then you have to compile qemu with gluster support, and that
pulls in glusterfs.  We could compile it out, but then no one would be
able to use gluster to store their virtual machines at all.

Not sure if glusterfs could be split into client and server parts
and/or if that would help (only a client bit is needed).

There's not a good way around this except a bunch of work in qemu
upstream.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Kaleb KEITHLEY 

On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:


Not sure if glusterfs could be split into client and server parts
and/or if that would help (only a client bit is needed).


glusterfs already exists in client (glusterfs and/or glusterfs-api and 
associated -devel rpms) and server (glusterfs-server) parts.


--

Kaleb

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Richard W.M. Jones 
On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:
 On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:
 
 Not sure if glusterfs could be split into client and server parts
 and/or if that would help (only a client bit is needed).
 
 glusterfs already exists in client (glusterfs and/or glusterfs-api
 and associated -devel rpms) and server (glusterfs-server) parts.

Perhaps it could be made lighter?  I didn't think that glusterfsd 
the translators were required for a pure client.

Rich.

$ rpm -ql glusterfs
/etc/logrotate.d/glusterd
/etc/logrotate.d/glusterfs-fuse
/etc/logrotate.d/glusterfsd
/etc/sysconfig/glusterd
/etc/sysconfig/glusterfsd
/usr/lib64/glusterfs
/usr/lib64/glusterfs/3.4.0beta4
/usr/lib64/glusterfs/3.4.0beta4/auth
/usr/lib64/glusterfs/3.4.0beta4/auth/addr.so
/usr/lib64/glusterfs/3.4.0beta4/auth/login.so
/usr/lib64/glusterfs/3.4.0beta4/rpc-transport
/usr/lib64/glusterfs/3.4.0beta4/rpc-transport/socket.so
/usr/lib64/glusterfs/3.4.0beta4/xlator
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/afr.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/dht.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/distribute.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/nufa.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/pump.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/replicate.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/stripe.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/switch.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/debug
/usr/lib64/glusterfs/3.4.0beta4/xlator/debug/error-gen.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/debug/io-stats.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/debug/trace.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/encryption
/usr/lib64/glusterfs/3.4.0beta4/xlator/encryption/rot-13.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/access-control.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/index.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/locks.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/mac-compat.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/marker.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/quiesce.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/quota.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/read-only.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/worm.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/mount
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-cache.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-threads.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/md-cache.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/open-behind.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/quick-read.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/read-ahead.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/stat-prefetch.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/write-behind.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/protocol
/usr/lib64/glusterfs/3.4.0beta4/xlator/protocol/client.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/system
/usr/lib64/glusterfs/3.4.0beta4/xlator/system/posix-acl.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/testing
/usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance
/usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance/symlink-cache.so
/usr/lib64/libgfrpc.so.0
/usr/lib64/libgfrpc.so.0.0.0
/usr/lib64/libgfxdr.so.0
/usr/lib64/libgfxdr.so.0.0.0
/usr/lib64/libglusterfs.so.0
/usr/lib64/libglusterfs.so.0.0.0
/usr/libexec/glusterfs
/usr/libexec/glusterfs/gsyncd
/usr/libexec/glusterfs/python
/usr/libexec/glusterfs/python/syncdaemon
/usr/libexec/glusterfs/python/syncdaemon/README.md
/usr/libexec/glusterfs/python/syncdaemon/__init__.py
/usr/libexec/glusterfs/python/syncdaemon/__init__.pyc
/usr/libexec/glusterfs/python/syncdaemon/__init__.pyo
/usr/libexec/glusterfs/python/syncdaemon/configinterface.py
/usr/libexec/glusterfs/python/syncdaemon/configinterface.pyc
/usr/libexec/glusterfs/python/syncdaemon/configinterface.pyo
/usr/libexec/glusterfs/python/syncdaemon/gconf.py
/usr/libexec/glusterfs/python/syncdaemon/gconf.pyc
/usr/libexec/glusterfs/python/syncdaemon/gconf.pyo
/usr/libexec/glusterfs/python/syncdaemon/gsyncd.py
/usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyc
/usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyo
/usr/libexec/glusterfs/python/syncdaemon/ipaddr.py
/usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyc
/usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyo
/usr/libexec/glusterfs/python/syncdaemon/libcxattr.py
/usr/libexec/glusterfs/python/syncdaemon/libcxattr.pyc
/usr/libexec/glusterfs/python/syncdaemon/libcxattr.pyo
/usr/libexec/glusterfs/python/syncdaemon/master.py
/usr/libexec/glusterfs/python/syncdaemon/master.pyc
/usr/libexec/glusterfs/python/syncdaemon/master.pyo
/usr/libexec/glusterfs/python/syncdaemon/monitor.py
/usr/libexec/glusterfs/python/syncdaemon/monitor.pyc

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Daniel P. Berrange 
On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
 Today in Absurd Dependency Bingo:
 
 
  Dependencies Resolved
  
  
   Package Arch   Version  Repository
  Size
  
  Removing:
   glusterfs   x86_64 3.4.0-2.fc19 @updates-testing 
  4.7 M
  Removing for dependencies:
   glusterfs-api   x86_64 3.4.0-2.fc19 @updates-testing  
  88 k
   glusterfs-fuse  x86_64 3.4.0-2.fc19 @updates-testing 
  233 k
   gnome-boxes x86_64 3.8.3-1.fc19 @fedora  
  4.1 M
   libcacard   x86_64 2:1.4.2-4.fc19   @updates-testing  
  81 k
   libvirt x86_64 1.0.5.4-1.fc19   @updates-testing 
  0.0  
   libvirt-daemon  x86_64 1.0.5.4-1.fc19   @updates-testing 
  4.5 M
   libvirt-daemon-config-network   x86_64 1.0.5.4-1.fc19   @updates-testing 
  0.0  
   libvirt-daemon-config-nwfilter  x86_64 1.0.5.4-1.fc19   @updates-testing 
  6.1 k
   libvirt-daemon-driver-interface x86_64 1.0.5.4-1.fc19   @updates-testing  
  93 k
   libvirt-daemon-driver-libxl x86_64 1.0.5.4-1.fc19   @updates-testing 
  197 k
   libvirt-daemon-driver-lxc   x86_64 1.0.5.4-1.fc19   @updates-testing 
  219 k
   libvirt-daemon-driver-network   x86_64 1.0.5.4-1.fc19   @updates-testing 
  126 k
   libvirt-daemon-driver-nodedev   x86_64 1.0.5.4-1.fc19   @updates-testing  
  93 k
   libvirt-daemon-driver-nwfilter  x86_64 1.0.5.4-1.fc19   @updates-testing 
  159 k
   libvirt-daemon-driver-qemu  x86_64 1.0.5.4-1.fc19   @updates-testing 
  919 k
   libvirt-daemon-driver-secretx86_64 1.0.5.4-1.fc19   @updates-testing  
  76 k
   libvirt-daemon-driver-storage   x86_64 1.0.5.4-1.fc19   @updates-testing 
  192 k
   libvirt-daemon-driver-uml   x86_64 1.0.5.4-1.fc19   @updates-testing 
  115 k
   libvirt-daemon-driver-xen   x86_64 1.0.5.4-1.fc19   @updates-testing 
  226 k
   libvirt-daemon-kvm  x86_64 1.0.5.4-1.fc19   @updates-testing 
  0.0  
   libvirt-daemon-qemu x86_64 1.0.5.4-1.fc19   @updates-testing 
  0.0  
   qemux86_64 2:1.4.2-4.fc19   @updates-testing 
  0.0  
   qemu-common x86_64 2:1.4.2-4.fc19   @updates-testing 
  624 k
   qemu-imgx86_64 2:1.4.2-4.fc19   @updates-testing 
  1.9 M
   qemu-kvmx86_64 2:1.4.2-4.fc19   @updates-testing 
  0.0  
   qemu-system-alpha   x86_64 2:1.4.2-4.fc19   @updates-testing 
  4.1 M
   qemu-system-arm x86_64 2:1.4.2-4.fc19   @updates-testing 
  5.2 M
   qemu-system-crisx86_64 2:1.4.2-4.fc19   @updates-testing 
  2.8 M
   qemu-system-lm32x86_64 2:1.4.2-4.fc19   @updates-testing 
  2.8 M
   qemu-system-m68kx86_64 2:1.4.2-4.fc19   @updates-testing 
  3.8 M
   qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   @updates-testing 
  5.6 M
   qemu-system-mipsx86_64 2:1.4.2-4.fc19   @updates-testing  
  21 M
   qemu-system-or32x86_64 2:1.4.2-4.fc19   @updates-testing 
  2.7 M
   qemu-system-ppc x86_64 2:1.4.2-4.fc19   @updates-testing  
  18 M
   qemu-system-s390x   x86_64 2:1.4.2-4.fc19   @updates-testing 
  3.1 M
   qemu-system-sh4 x86_64 2:1.4.2-4.fc19   @updates-testing 
  7.5 M
   qemu-system-sparc   x86_64 2:1.4.2-4.fc19   @updates-testing 
  7.3 M
   qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   @updates-testing 
  2.7 M
   qemu-system-x86 x86_64 2:1.4.2-4.fc19   @updates-testing  
  11 M
   qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   @updates-testing 
  5.6 M
   qemu-user   x86_64 2:1.4.2-4.fc19   @updates-testing  
  52 M
   spice-glib  x86_64 0.20-2.fc19  @updates-testing 
  1.2 M
   spice-gtk   x86_64 0.20-2.fc19  @updates-testing 
  134 k
   spice-gtk-pythonx86_64 0.20-2.fc19  @updates-testing  
  52 k
   spice-gtk3  x86_64 0.20-2.fc19  @updates-testing 
  228 k
   vinagre x86_64 3.8.2-1.fc19 @side
  3.0 M
   virt-managernoarch 0.10.0-1.fc19@updates-testing 
  3.6 M
   virt-viewer x86_64 0.5.6-1.fc19 @updates-testing 
  990 k
 
 WAT?

There are many things going on here

First, 'yum remove' is being overly dramtic. It is possible to remove
glusterfs without removing 'libvirt' - only the 'libvirt-daemon'
package depends on glusterfs-client. yum seems to want to remove far
more than is strictly required by the deps.

There is a genuine bogus dep from libcacard.so to the glusterfs
libraries, likely caused by bad Makefile linker

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Daniel P. Berrange 
On Tue, Jul 23, 2013 at 12:32:23PM +0100, Daniel P. Berrange wrote:
 On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
  Today in Absurd Dependency Bingo:
 
 There are many things going on here
 
 First, 'yum remove' is being overly dramtic. It is possible to remove
 glusterfs without removing 'libvirt' - only the 'libvirt-daemon'
 package depends on glusterfs-client. yum seems to want to remove far
 more than is strictly required by the deps.
 
 There is a genuine bogus dep from libcacard.so to the glusterfs
 libraries, likely caused by bad Makefile linker flags in QEMU.
 This means that when you try to remove gluster, it needs to pull
 out libcacard which pulls out spice, which pulls out virt-manage,
 virt-viewer, vinagre. Fixing libcacard deps would improve things
 here

Now filed

  https://bugzilla.redhat.com/show_bug.cgi?id=987441

 The glusterfs packaging is sub-optimal too - the client library
 APIs should be isolated from the rest of the RPM, so QEMU linking
 against glusterfs doesn't automatically pull in everything.


Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Daniel P. Berrange 
On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:
 On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:
 
 Not sure if glusterfs could be split into client and server parts
 and/or if that would help (only a client bit is needed).
 
 glusterfs already exists in client (glusterfs and/or glusterfs-api
 and associated -devel rpms) and server (glusterfs-server) parts.

Hmm, I wonder if there's another QEMU linkage problem here. QEMU
seems to only use glfs_* functions in its code, but it is
linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could
probably link to just libgfapi.so, and thus only depend on
glusterfs-api and not main glusterfs RPM.


Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Richard W.M. Jones 
On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote:
 On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:
  On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:
  
  Not sure if glusterfs could be split into client and server parts
  and/or if that would help (only a client bit is needed).
  
  glusterfs already exists in client (glusterfs and/or glusterfs-api
  and associated -devel rpms) and server (glusterfs-server) parts.
 
 Hmm, I wonder if there's another QEMU linkage problem here. QEMU
 seems to only use glfs_* functions in its code, but it is
 linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could
 probably link to just libgfapi.so, and thus only depend on
 glusterfs-api and not main glusterfs RPM.

Ah yes, that's the key ...

$ rpm -ql glusterfs-api
/usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
/usr/lib64/libgfapi.so.0
/usr/lib64/libgfapi.so.0.0.0

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Matthew Miller 
On Tue, Jul 23, 2013 at 12:32:23PM +0100, Daniel P. Berrange wrote:
 First, 'yum remove' is being overly dramtic. It is possible to remove
 glusterfs without removing 'libvirt' - only the 'libvirt-daemon'
 package depends on glusterfs-client. yum seems to want to remove far
 more than is strictly required by the deps.

Hey, I think you're casting the blame in the wrong place here. Yum is just
following the deps and not being dramatic.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Kaleb KEITHLEY 

On 07/23/2013 04:41 PM, Richard W.M. Jones wrote:

On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:

On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:


Not sure if glusterfs could be split into client and server parts
and/or if that would help (only a client bit is needed).


glusterfs already exists in client (glusterfs and/or glusterfs-api
and associated -devel rpms) and server (glusterfs-server) parts.


Perhaps it could be made lighter?  I didn't think that glusterfsd 
the translators were required for a pure client.


/usr/sbin/glusterfs is a symlink to /usr/sbin/glusterfsd; glusterfs(d) 
is absolutely required for a client-side fuse mount, as are most of the 
translators — that's how gluster works.


You can't predict, you can't second guess which translators will be 
required by any client — that's determined by how the server 
administrator configures the volumes.




Rich.

$ rpm -ql glusterfs
/etc/logrotate.d/glusterd
/etc/logrotate.d/glusterfs-fuse
/etc/logrotate.d/glusterfsd
/etc/sysconfig/glusterd
/etc/sysconfig/glusterfsd
/usr/lib64/glusterfs
/usr/lib64/glusterfs/3.4.0beta4
/usr/lib64/glusterfs/3.4.0beta4/auth
/usr/lib64/glusterfs/3.4.0beta4/auth/addr.so
/usr/lib64/glusterfs/3.4.0beta4/auth/login.so
/usr/lib64/glusterfs/3.4.0beta4/rpc-transport
/usr/lib64/glusterfs/3.4.0beta4/rpc-transport/socket.so
/usr/lib64/glusterfs/3.4.0beta4/xlator
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/afr.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/dht.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/distribute.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/nufa.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/pump.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/replicate.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/stripe.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/cluster/switch.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/debug
/usr/lib64/glusterfs/3.4.0beta4/xlator/debug/error-gen.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/debug/io-stats.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/debug/trace.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/encryption
/usr/lib64/glusterfs/3.4.0beta4/xlator/encryption/rot-13.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/access-control.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/index.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/locks.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/mac-compat.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/marker.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/quiesce.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/quota.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/read-only.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/features/worm.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/mount
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-cache.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/io-threads.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/md-cache.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/open-behind.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/quick-read.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/read-ahead.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/stat-prefetch.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/performance/write-behind.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/protocol
/usr/lib64/glusterfs/3.4.0beta4/xlator/protocol/client.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/system
/usr/lib64/glusterfs/3.4.0beta4/xlator/system/posix-acl.so
/usr/lib64/glusterfs/3.4.0beta4/xlator/testing
/usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance
/usr/lib64/glusterfs/3.4.0beta4/xlator/testing/performance/symlink-cache.so
/usr/lib64/libgfrpc.so.0
/usr/lib64/libgfrpc.so.0.0.0
/usr/lib64/libgfxdr.so.0
/usr/lib64/libgfxdr.so.0.0.0
/usr/lib64/libglusterfs.so.0
/usr/lib64/libglusterfs.so.0.0.0
/usr/libexec/glusterfs
/usr/libexec/glusterfs/gsyncd
/usr/libexec/glusterfs/python
/usr/libexec/glusterfs/python/syncdaemon
/usr/libexec/glusterfs/python/syncdaemon/README.md
/usr/libexec/glusterfs/python/syncdaemon/__init__.py
/usr/libexec/glusterfs/python/syncdaemon/__init__.pyc
/usr/libexec/glusterfs/python/syncdaemon/__init__.pyo
/usr/libexec/glusterfs/python/syncdaemon/configinterface.py
/usr/libexec/glusterfs/python/syncdaemon/configinterface.pyc
/usr/libexec/glusterfs/python/syncdaemon/configinterface.pyo
/usr/libexec/glusterfs/python/syncdaemon/gconf.py
/usr/libexec/glusterfs/python/syncdaemon/gconf.pyc
/usr/libexec/glusterfs/python/syncdaemon/gconf.pyo
/usr/libexec/glusterfs/python/syncdaemon/gsyncd.py
/usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyc
/usr/libexec/glusterfs/python/syncdaemon/gsyncd.pyo
/usr/libexec/glusterfs/python/syncdaemon/ipaddr.py
/usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyc
/usr/libexec/glusterfs/python/syncdaemon/ipaddr.pyo

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Kaleb KEITHLEY 

On 07/23/2013 05:20 PM, Richard W.M. Jones wrote:

On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote:

On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:

On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:


Not sure if glusterfs could be split into client and server parts
and/or if that would help (only a client bit is needed).


glusterfs already exists in client (glusterfs and/or glusterfs-api
and associated -devel rpms) and server (glusterfs-server) parts.


Hmm, I wonder if there's another QEMU linkage problem here. QEMU
seems to only use glfs_* functions in its code, but it is
linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could
probably link to just libgfapi.so, and thus only depend on
glusterfs-api and not main glusterfs RPM.


Ah yes, that's the key ...

$ rpm -ql glusterfs-api
/usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
/usr/lib64/libgfapi.so.0
/usr/lib64/libgfapi.so.0.0.0



Even if libgfapi (from glusterfs-api) is used instead of client-side 
gluster fuse mount you still need the translators (from glusterfs)


--

Kaleb

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Matthew Miller 
On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote:
 $ rpm -ql glusterfs-api
 /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
 /usr/lib64/libgfapi.so.0
 /usr/lib64/libgfapi.so.0.0.0
 Even if libgfapi (from glusterfs-api) is used instead of client-side
 gluster fuse mount you still need the translators (from glusterfs)

Can this work without any client-side configuration?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Kaleb KEITHLEY 

On 07/23/2013 05:34 PM, Matthew Miller wrote:

On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote:

$ rpm -ql glusterfs-api
/usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
/usr/lib64/libgfapi.so.0
/usr/lib64/libgfapi.so.0.0.0

Even if libgfapi (from glusterfs-api) is used instead of client-side
gluster fuse mount you still need the translators (from glusterfs)


Can this work without any client-side configuration?



Huh?

qemu, when it's using glusterfs, is — by definition — a glusterfs client.

--

Kaleb
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Richard W.M. Jones 
On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote:
 On 07/23/2013 05:20 PM, Richard W.M. Jones wrote:
 On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote:
 On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:
 On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:
 
 Not sure if glusterfs could be split into client and server parts
 and/or if that would help (only a client bit is needed).
 
 glusterfs already exists in client (glusterfs and/or glusterfs-api
 and associated -devel rpms) and server (glusterfs-server) parts.
 
 Hmm, I wonder if there's another QEMU linkage problem here. QEMU
 seems to only use glfs_* functions in its code, but it is
 linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could
 probably link to just libgfapi.so, and thus only depend on
 glusterfs-api and not main glusterfs RPM.
 
 Ah yes, that's the key ...
 
 $ rpm -ql glusterfs-api
 /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
 /usr/lib64/libgfapi.so.0
 /usr/lib64/libgfapi.so.0.0.0
 
 
 Even if libgfapi (from glusterfs-api) is used instead of client-side
 gluster fuse mount you still need the translators (from glusterfs)

OK I see that glusterfs-api depends on the other libraries which would
pull in glusterfs.

So it seems there is no way to fix this except to split up qemu's
block drivers, although there is a minor packaging problem that could
be fixed too.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Daniel P. Berrange 
On Tue, Jul 23, 2013 at 05:27:20PM +0530, Kaleb KEITHLEY wrote:
 On 07/23/2013 05:20 PM, Richard W.M. Jones wrote:
 On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote:
 On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:
 On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:
 
 Not sure if glusterfs could be split into client and server parts
 and/or if that would help (only a client bit is needed).
 
 glusterfs already exists in client (glusterfs and/or glusterfs-api
 and associated -devel rpms) and server (glusterfs-server) parts.
 
 Hmm, I wonder if there's another QEMU linkage problem here. QEMU
 seems to only use glfs_* functions in its code, but it is
 linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could
 probably link to just libgfapi.so, and thus only depend on
 glusterfs-api and not main glusterfs RPM.
 
 Ah yes, that's the key ...
 
 $ rpm -ql glusterfs-api
 /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
 /usr/lib64/libgfapi.so.0
 /usr/lib64/libgfapi.so.0.0.0
 
 
 Even if libgfapi (from glusterfs-api) is used instead of client-side
 gluster fuse mount you still need the translators (from glusterfs)

Hmm, so normally the point of putting libraries in a sub-RPM is that
you can install it without pulling in the main toolchain, to save
space. Since the glusterfs-api RPM depends on glusterfs, you obviously
can't do that.

So I'm curious as to what the purpose of having glusterfs-api as a
sub-RPM is ?  Removing it saves 80 KB of disk space, so I guess it
isn't space related.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Matthew Miller 
On Tue, Jul 23, 2013 at 05:40:03PM +0530, Kaleb KEITHLEY wrote:
 Can this work without any client-side configuration?
 Huh?
 qemu, when it's using glusterfs, is — by definition — a glusterfs client.

Sorry, let me rephrase. Is the qemu-level configuration all you need, or do
you also need to have pre-configured gluster on the system first?


(I think gluster is neat but I haven't used it much, as you can see!)

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread John Mark Walker 

- Original Message -
 On 07/23/2013 05:20 PM, Richard W.M. Jones wrote:

  Ah yes, that's the key ...
 
  $ rpm -ql glusterfs-api
  /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
  /usr/lib64/libgfapi.so.0
  /usr/lib64/libgfapi.so.0.0.0
 
 
 Even if libgfapi (from glusterfs-api) is used instead of client-side
 gluster fuse mount you still need the translators (from glusterfs)
 
 --
 
 Kaleb
 

Even if we're talking about use as *just* a client? I thought the translators 
were only needed if you're hosting the bricks on the same machine. I thought it 
was possible to have just libgfapi on the client, and then the machine with the 
bricks would need glusterfs.

-JM
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Adam Williamson 
On Tue, 2013-07-23 at 11:14 +0100, Richard W.M. Jones wrote:
 On Mon, Jul 22, 2013 at 08:26:18PM -0400, Matthew Miller wrote:
  On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
   Today in Absurd Dependency Bingo:
 glusterfs   x86_64 3.4.0-2.fc19 
@updates-testing 4.7 M
  [...]
 qemu-common x86_64 2:1.4.2-4.fc19   
@updates-testing 624 k
  
  $ rpm -q --changelog qemu-common
  [...]
  * Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2
  - Enable gluster support
  
  And then all the rest just falls out from there because they require qemu.
  
  
 vinagre x86_64 3.8.2-1.fc19 @side  
  3.0 M
  
  (This one requires spice.)
  
  At 4.7M glusterfs isn't exactly tiny, and is another one of these things
  that's not so useful unless configured (even though that's awesomely easy);
  maybe the libs could be split out?
 
 The problem is that qemu's block layer isn't a stable API with
 pluggable / loadable modules.  There's been some talk and even patches
 upstream trying making it so (at least, the loadable modules part, the
 stable API part will probably never happen).  But it's not done yet.
 
 qemu's internal block API:
 http://git.qemu.org/?p=qemu.git;a=blob;f=include/block/block_int.h;h=c6ac871e210ea21f91d799e44a102119048dde54;hb=HEAD#l83
 
 Therefore if you want to use qemu to access, in this case, a glusterfs
 cluster, then you have to compile qemu with gluster support, and that
 pulls in glusterfs.  We could compile it out, but then no one would be
 able to use gluster to store their virtual machines at all.
 
 Not sure if glusterfs could be split into client and server parts
 and/or if that would help (only a client bit is needed).
 
 There's not a good way around this except a bunch of work in qemu
 upstream.

Well. Will qemu still actually _run_ without glusterfs being present? If
so, do we actually need to express a dependency on glusterfs?

To me, the semantics of 'X requires Y' are fairly close to 'X will not
function correctly without Y'. 'X can do some extra stuff if Y is
present' does not seem to meet the case.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Richard W.M. Jones 
On Tue, Jul 23, 2013 at 08:47:14AM -0700, Adam Williamson wrote:
 Well. Will qemu still actually _run_ without glusterfs being present? If
 so, do we actually need to express a dependency on glusterfs?

No, I don't think so.  I think it'll fail to start up because of a
missing library.

We could change qemu so it includes the block drivers, but each block
drive dlopen(3)'s the special libraries it needs on start up, but that
would make the code more complex.

I really think the way to fix this is to make the block drivers
loadable, and that is something which as far as I understand is
desirable upstream too, just no one has written a set of patches which
is acceptable.

If we did this, packaging it right in Fedora would be simple; you'd
end up with:

  qemu-block-gluster
  qemu-block-iscsi
  qemu-block-ssh
  etc.

which would be independently installable subpackages that would depend
on the correct libraries.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Dave Jones 
On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
 
So this thread is complaining about..

   Removing:
glusterfs   x86_64 3.4.0-2.fc19 @updates-testing 
   4.7 M
   Removing for dependencies:
glusterfs-api   x86_64 3.4.0-2.fc19 @updates-testing  
   88 k
glusterfs-fuse  x86_64 3.4.0-2.fc19 @updates-testing 
   233 k

 5M of deps, meanwhile..

qemu-system-alpha   x86_64 2:1.4.2-4.fc19   @updates-testing 
   4.1 M
qemu-system-arm x86_64 2:1.4.2-4.fc19   @updates-testing 
   5.2 M
qemu-system-crisx86_64 2:1.4.2-4.fc19   @updates-testing 
   2.8 M
qemu-system-lm32x86_64 2:1.4.2-4.fc19   @updates-testing 
   2.8 M
qemu-system-m68kx86_64 2:1.4.2-4.fc19   @updates-testing 
   3.8 M
qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   @updates-testing 
   5.6 M
qemu-system-mipsx86_64 2:1.4.2-4.fc19   @updates-testing  
   21 M
qemu-system-or32x86_64 2:1.4.2-4.fc19   @updates-testing 
   2.7 M
qemu-system-ppc x86_64 2:1.4.2-4.fc19   @updates-testing  
   18 M
qemu-system-s390x   x86_64 2:1.4.2-4.fc19   @updates-testing 
   3.1 M
qemu-system-sh4 x86_64 2:1.4.2-4.fc19   @updates-testing 
   7.5 M
qemu-system-sparc   x86_64 2:1.4.2-4.fc19   @updates-testing 
   7.3 M
qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   @updates-testing 
   2.7 M
qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   @updates-testing 
   5.6 M

Do we really *need* all those ?  (And why are mips  ppc so much bigger ?)

Dave

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Richard W.M. Jones 
On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote:
 On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
  
 So this thread is complaining about..
 
Removing:
 glusterfs   x86_64 3.4.0-2.fc19 
 @updates-testing 4.7 M
Removing for dependencies:
 glusterfs-api   x86_64 3.4.0-2.fc19 
 @updates-testing  88 k
 glusterfs-fuse  x86_64 3.4.0-2.fc19 
 @updates-testing 233 k
 
  5M of deps, meanwhile..
 
 qemu-system-alpha   x86_64 2:1.4.2-4.fc19   
 @updates-testing 4.1 M
 qemu-system-arm x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.2 M
 qemu-system-crisx86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-lm32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-m68kx86_64 2:1.4.2-4.fc19   
 @updates-testing 3.8 M
 qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M
 qemu-system-mipsx86_64 2:1.4.2-4.fc19   
 @updates-testing  21 M
 qemu-system-or32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-ppc x86_64 2:1.4.2-4.fc19   
 @updates-testing  18 M
 qemu-system-s390x   x86_64 2:1.4.2-4.fc19   
 @updates-testing 3.1 M
 qemu-system-sh4 x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.5 M
 qemu-system-sparc   x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.3 M
 qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M
 
 Do we really *need* all those ?

Hopefully those *are* removable.

Unfortunately some packages depend on the 'qemu' meta package which
pulls in all of the emulators.

Libvirt will happily manage any subset of qemu-system-* that you have
installed.  It probes for what binaries are available when the
libvirtd daemon starts up.  However for some reason I can't quite
understand, libvirt-daemon depends on 'qemu'.  That may be a bug?

 (And why are mips  ppc so much bigger ?)

ppc is really three separate emulator binaries for different
ppc-related architectures (ppc, ppc64 and embedded ppc).  mips is also
three binaries (mips, mips64 and something called mips64el).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Adam Jackson 
On Tue, 2013-07-23 at 12:57 -0400, Dave Jones wrote:

 qemu-system-alpha   x86_64 2:1.4.2-4.fc19   
 @updates-testing 4.1 M
 qemu-system-arm x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.2 M
 qemu-system-crisx86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-lm32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.8 M
 qemu-system-m68kx86_64 2:1.4.2-4.fc19   
 @updates-testing 3.8 M
 qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M
 qemu-system-mipsx86_64 2:1.4.2-4.fc19   
 @updates-testing  21 M
 qemu-system-or32x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-ppc x86_64 2:1.4.2-4.fc19   
 @updates-testing  18 M
 qemu-system-s390x   x86_64 2:1.4.2-4.fc19   
 @updates-testing 3.1 M
 qemu-system-sh4 x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.5 M
 qemu-system-sparc   x86_64 2:1.4.2-4.fc19   
 @updates-testing 7.3 M
 qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   
 @updates-testing 2.7 M
 qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   
 @updates-testing 5.6 M
 
 Do we really *need* all those ?  (And why are mips  ppc so much bigger ?)

qemu-system-mips{,64}{,el} and qemu-system-ppc{,64,emb}.

- ajax

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Richard W.M. Jones 
On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote:
 However for some reason I can't quite understand, libvirt-daemon
 depends on 'qemu'.  That may be a bug?

I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Reindl Harald 


Am 23.07.2013 19:18, schrieb Richard W.M. Jones:
 On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote:
 However for some reason I can't quite understand, libvirt-daemon
 depends on 'qemu'.  That may be a bug?
 
 I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'

IMHO it is generally a problem to depend on meta-packages
pulling half of the world - in this case one big and fat
package would be the same and finally more efficient

that's not the idea behind sub-packages



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Adam Williamson 
On Tue, 2013-07-23 at 18:15 +0100, Richard W.M. Jones wrote:
 On Tue, Jul 23, 2013 at 12:57:50PM -0400, Dave Jones wrote:
  On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
   
  So this thread is complaining about..
  
 Removing:
  glusterfs   x86_64 3.4.0-2.fc19 
  @updates-testing 4.7 M
 Removing for dependencies:
  glusterfs-api   x86_64 3.4.0-2.fc19 
  @updates-testing  88 k
  glusterfs-fuse  x86_64 3.4.0-2.fc19 
  @updates-testing 233 k
  
   5M of deps, meanwhile..
  
  qemu-system-alpha   x86_64 2:1.4.2-4.fc19   
  @updates-testing 4.1 M
  qemu-system-arm x86_64 2:1.4.2-4.fc19   
  @updates-testing 5.2 M
  qemu-system-crisx86_64 2:1.4.2-4.fc19   
  @updates-testing 2.8 M
  qemu-system-lm32x86_64 2:1.4.2-4.fc19   
  @updates-testing 2.8 M
  qemu-system-m68kx86_64 2:1.4.2-4.fc19   
  @updates-testing 3.8 M
  qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   
  @updates-testing 5.6 M
  qemu-system-mipsx86_64 2:1.4.2-4.fc19   
  @updates-testing  21 M
  qemu-system-or32x86_64 2:1.4.2-4.fc19   
  @updates-testing 2.7 M
  qemu-system-ppc x86_64 2:1.4.2-4.fc19   
  @updates-testing  18 M
  qemu-system-s390x   x86_64 2:1.4.2-4.fc19   
  @updates-testing 3.1 M
  qemu-system-sh4 x86_64 2:1.4.2-4.fc19   
  @updates-testing 7.5 M
  qemu-system-sparc   x86_64 2:1.4.2-4.fc19   
  @updates-testing 7.3 M
  qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   
  @updates-testing 2.7 M
  qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   
  @updates-testing 5.6 M
  
  Do we really *need* all those ?
 
 Hopefully those *are* removable.
 
 Unfortunately some packages depend on the 'qemu' meta package which
 pulls in all of the emulators.

I don't know if that's the case for me, I just did a 'yum install
@Virtualization' on the host in question which is why I have all the
stuff the metapackages pull in. I know about that, which is why I didn't
complain about it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Peter Robinson 
On Tue, Jul 23, 2013 at 11:14 AM, Richard W.M. Jones rjo...@redhat.com wrote:
 On Mon, Jul 22, 2013 at 08:26:18PM -0400, Matthew Miller wrote:
 On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
  Today in Absurd Dependency Bingo:
glusterfs   x86_64 3.4.0-2.fc19 
   @updates-testing 4.7 M
 [...]
qemu-common x86_64 2:1.4.2-4.fc19   
   @updates-testing 624 k

 $ rpm -q --changelog qemu-common
 [...]
 * Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2
 - Enable gluster support

 And then all the rest just falls out from there because they require qemu.


vinagre x86_64 3.8.2-1.fc19 @side   
3.0 M

 (This one requires spice.)

 At 4.7M glusterfs isn't exactly tiny, and is another one of these things
 that's not so useful unless configured (even though that's awesomely easy);
 maybe the libs could be split out?

 The problem is that qemu's block layer isn't a stable API with
 pluggable / loadable modules.  There's been some talk and even patches
 upstream trying making it so (at least, the loadable modules part, the
 stable API part will probably never happen).  But it's not done yet.

 qemu's internal block API:
 http://git.qemu.org/?p=qemu.git;a=blob;f=include/block/block_int.h;h=c6ac871e210ea21f91d799e44a102119048dde54;hb=HEAD#l83

 Therefore if you want to use qemu to access, in this case, a glusterfs
 cluster, then you have to compile qemu with gluster support, and that
 pulls in glusterfs.  We could compile it out, but then no one would be
 able to use gluster to store their virtual machines at all.

 Not sure if glusterfs could be split into client and server parts
 and/or if that would help (only a client bit is needed).

I thought gluster 3.4 was suppose to support a libgfapi which
integrated into qemu [1] so in theory the bare minimum qemu should
need is libgfapi.

[1] http://www.gluster.org/2013/07/glusterfs-3-4-is-here/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Peter Robinson 
On Tue, Jul 23, 2013 at 11:19 AM, Kaleb KEITHLEY kkeit...@redhat.com wrote:
 On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:


 Not sure if glusterfs could be split into client and server parts
 and/or if that would help (only a client bit is needed).


 glusterfs already exists in client (glusterfs and/or glusterfs-api and
 associated -devel rpms) and server (glusterfs-server) parts.

Can't it be split out into libgfapi for things that use that like, in
theory, qemu and then the fuse client etc.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Peter Robinson 
On Tue, Jul 23, 2013 at 12:57 PM, Kaleb KEITHLEY kkeit...@redhat.com wrote:
 On 07/23/2013 05:20 PM, Richard W.M. Jones wrote:

 On Tue, Jul 23, 2013 at 12:45:59PM +0100, Daniel P. Berrange wrote:

 On Tue, Jul 23, 2013 at 03:49:37PM +0530, Kaleb KEITHLEY wrote:

 On 07/23/2013 03:44 PM, Richard W.M. Jones wrote:


 Not sure if glusterfs could be split into client and server parts
 and/or if that would help (only a client bit is needed).


 glusterfs already exists in client (glusterfs and/or glusterfs-api
 and associated -devel rpms) and server (glusterfs-server) parts.


 Hmm, I wonder if there's another QEMU linkage problem here. QEMU
 seems to only use glfs_* functions in its code, but it is
 linking to -lgfapi -lgfrpc -lgfxdr. It seems like it could
 probably link to just libgfapi.so, and thus only depend on
 glusterfs-api and not main glusterfs RPM.


 Ah yes, that's the key ...

 $ rpm -ql glusterfs-api
 /usr/lib64/glusterfs/3.4.0beta4/xlator/mount/api.so
 /usr/lib64/libgfapi.so.0
 /usr/lib64/libgfapi.so.0.0.0


 Even if libgfapi (from glusterfs-api) is used instead of client-side gluster
 fuse mount you still need the translators (from glusterfs)

Can't you split the translators into a glusterfs-common (or something)
that libgfapi depends on and then have glusterfs-fuse and other sub
packages. An in the case of translators why no split out all but the
defaults and any others the server admin should deal with.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Bill Nottingham 
Richard W.M. Jones (rjo...@redhat.com) said: 
 On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote:
  However for some reason I can't quite understand, libvirt-daemon
  depends on 'qemu'.  That may be a bug?
 
 I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'.

Isn't it simplest for that to depend on a virtual 'qemu-system', which is
provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches?

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Richard W.M. Jones 
On Tue, Jul 23, 2013 at 07:54:31PM +0100, Peter Robinson wrote:
 I thought gluster 3.4 was suppose to support a libgfapi which
 integrated into qemu [1] so in theory the bare minimum qemu should
 need is libgfapi.
 
 [1] http://www.gluster.org/2013/07/glusterfs-3-4-is-here/

Right, and that's what is happening.  However that dependency on
libgfapi is pulling in the glusterfs package.

By splitting out the qemu gluster driver into a loadable module it
would be possible to have a separate Fedora qemu-block-glusterfs
subpackage which have the libgfapi dependency.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Richard W.M. Jones 
On Tue, Jul 23, 2013 at 03:00:46PM -0400, Bill Nottingham wrote:
 Richard W.M. Jones (rjo...@redhat.com) said: 
  On Tue, Jul 23, 2013 at 06:15:32PM +0100, Richard W.M. Jones wrote:
   However for some reason I can't quite understand, libvirt-daemon
   depends on 'qemu'.  That may be a bug?
  
  I meant to write: 'libvirt-daemon-qemu' depends on 'qemu'.
 
 Isn't it simplest for that to depend on a virtual 'qemu-system', which is
 provided by qemu-kvm on KVM arches, and qemu-system-XYZ on non-KVM arches?

Right, which is why I said this may be a bug.  Dan Berrange (CC'd on
this subthread) will know.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-23 Thread Kaleb KEITHLEY 

On 07/24/2013 12:29 AM, Peter Robinson wrote:



Can't you split the translators into a glusterfs-common (or something)


The glusterfs RPM already is the glusterfs-common RPM that you want.

If you look, you'll see that the other things  in the glusterfs RPM 
really aren't that big; moving the translators to a different RPM 
doesn't buy you anything.



that libgfapi depends on and then have glusterfs-fuse and other sub
packages. An in the case of translators why no split out all but the
defaults and any others the server admin should deal with.



Again, you can't second guess which translators are defaults. Server 
admins configure volumes and options and the client-side could need any 
of them.


--

Kaleb

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why does so much virt stuff depend on glusterfs?

2013-07-22 Thread Adam Williamson 
Today in Absurd Dependency Bingo:


 Dependencies Resolved
 
 
  Package Arch   Version  Repository
 Size
 
 Removing:
  glusterfs   x86_64 3.4.0-2.fc19 @updates-testing 4.7 
 M
 Removing for dependencies:
  glusterfs-api   x86_64 3.4.0-2.fc19 @updates-testing  88 
 k
  glusterfs-fuse  x86_64 3.4.0-2.fc19 @updates-testing 233 
 k
  gnome-boxes x86_64 3.8.3-1.fc19 @fedora  4.1 
 M
  libcacard   x86_64 2:1.4.2-4.fc19   @updates-testing  81 
 k
  libvirt x86_64 1.0.5.4-1.fc19   @updates-testing 0.0 
  
  libvirt-daemon  x86_64 1.0.5.4-1.fc19   @updates-testing 4.5 
 M
  libvirt-daemon-config-network   x86_64 1.0.5.4-1.fc19   @updates-testing 0.0 
  
  libvirt-daemon-config-nwfilter  x86_64 1.0.5.4-1.fc19   @updates-testing 6.1 
 k
  libvirt-daemon-driver-interface x86_64 1.0.5.4-1.fc19   @updates-testing  93 
 k
  libvirt-daemon-driver-libxl x86_64 1.0.5.4-1.fc19   @updates-testing 197 
 k
  libvirt-daemon-driver-lxc   x86_64 1.0.5.4-1.fc19   @updates-testing 219 
 k
  libvirt-daemon-driver-network   x86_64 1.0.5.4-1.fc19   @updates-testing 126 
 k
  libvirt-daemon-driver-nodedev   x86_64 1.0.5.4-1.fc19   @updates-testing  93 
 k
  libvirt-daemon-driver-nwfilter  x86_64 1.0.5.4-1.fc19   @updates-testing 159 
 k
  libvirt-daemon-driver-qemu  x86_64 1.0.5.4-1.fc19   @updates-testing 919 
 k
  libvirt-daemon-driver-secretx86_64 1.0.5.4-1.fc19   @updates-testing  76 
 k
  libvirt-daemon-driver-storage   x86_64 1.0.5.4-1.fc19   @updates-testing 192 
 k
  libvirt-daemon-driver-uml   x86_64 1.0.5.4-1.fc19   @updates-testing 115 
 k
  libvirt-daemon-driver-xen   x86_64 1.0.5.4-1.fc19   @updates-testing 226 
 k
  libvirt-daemon-kvm  x86_64 1.0.5.4-1.fc19   @updates-testing 0.0 
  
  libvirt-daemon-qemu x86_64 1.0.5.4-1.fc19   @updates-testing 0.0 
  
  qemux86_64 2:1.4.2-4.fc19   @updates-testing 0.0 
  
  qemu-common x86_64 2:1.4.2-4.fc19   @updates-testing 624 
 k
  qemu-imgx86_64 2:1.4.2-4.fc19   @updates-testing 1.9 
 M
  qemu-kvmx86_64 2:1.4.2-4.fc19   @updates-testing 0.0 
  
  qemu-system-alpha   x86_64 2:1.4.2-4.fc19   @updates-testing 4.1 
 M
  qemu-system-arm x86_64 2:1.4.2-4.fc19   @updates-testing 5.2 
 M
  qemu-system-crisx86_64 2:1.4.2-4.fc19   @updates-testing 2.8 
 M
  qemu-system-lm32x86_64 2:1.4.2-4.fc19   @updates-testing 2.8 
 M
  qemu-system-m68kx86_64 2:1.4.2-4.fc19   @updates-testing 3.8 
 M
  qemu-system-microblaze  x86_64 2:1.4.2-4.fc19   @updates-testing 5.6 
 M
  qemu-system-mipsx86_64 2:1.4.2-4.fc19   @updates-testing  21 
 M
  qemu-system-or32x86_64 2:1.4.2-4.fc19   @updates-testing 2.7 
 M
  qemu-system-ppc x86_64 2:1.4.2-4.fc19   @updates-testing  18 
 M
  qemu-system-s390x   x86_64 2:1.4.2-4.fc19   @updates-testing 3.1 
 M
  qemu-system-sh4 x86_64 2:1.4.2-4.fc19   @updates-testing 7.5 
 M
  qemu-system-sparc   x86_64 2:1.4.2-4.fc19   @updates-testing 7.3 
 M
  qemu-system-unicore32   x86_64 2:1.4.2-4.fc19   @updates-testing 2.7 
 M
  qemu-system-x86 x86_64 2:1.4.2-4.fc19   @updates-testing  11 
 M
  qemu-system-xtensa  x86_64 2:1.4.2-4.fc19   @updates-testing 5.6 
 M
  qemu-user   x86_64 2:1.4.2-4.fc19   @updates-testing  52 
 M
  spice-glib  x86_64 0.20-2.fc19  @updates-testing 1.2 
 M
  spice-gtk   x86_64 0.20-2.fc19  @updates-testing 134 
 k
  spice-gtk-pythonx86_64 0.20-2.fc19  @updates-testing  52 
 k
  spice-gtk3  x86_64 0.20-2.fc19  @updates-testing 228 
 k
  vinagre x86_64 3.8.2-1.fc19 @side3.0 
 M
  virt-managernoarch 0.10.0-1.fc19@updates-testing 3.6 
 M
  virt-viewer x86_64 0.5.6-1.fc19 @updates-testing 990 
 k

WAT?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-22 Thread Matthew Miller 
On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
 Today in Absurd Dependency Bingo:
   glusterfs   x86_64 3.4.0-2.fc19 @updates-testing 
  4.7 M
[...]
   qemu-common x86_64 2:1.4.2-4.fc19   @updates-testing 
  624 k

$ rpm -q --changelog qemu-common
[...]
* Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2
- Enable gluster support

And then all the rest just falls out from there because they require qemu.


   vinagre x86_64 3.8.2-1.fc19 @side
  3.0 M

(This one requires spice.)

At 4.7M glusterfs isn't exactly tiny, and is another one of these things
that's not so useful unless configured (even though that's awesomely easy);
maybe the libs could be split out?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why does so much virt stuff depend on glusterfs?

2013-07-22 Thread Chris Murphy 

On Jul 22, 2013, at 6:26 PM, Matthew Miller mat...@fedoraproject.org wrote:

 On Mon, Jul 22, 2013 at 05:17:01PM -0700, Adam Williamson wrote:
 Today in Absurd Dependency Bingo:
 glusterfs   x86_64 3.4.0-2.fc19 @updates-testing 
 4.7 M
 [...]
 qemu-common x86_64 2:1.4.2-4.fc19   @updates-testing 
 624 k
 
 $ rpm -q --changelog qemu-common
 [...]
 * Wed May 15 2013 Cole Robinson crobi...@redhat.com - 2:1.4.1-2
 - Enable gluster support
 
 And then all the rest just falls out from there because they require qemu.
 
 
 vinagre x86_64 3.8.2-1.fc19 @side
 3.0 M
 
 (This one requires spice.)
 
 At 4.7M glusterfs isn't exactly tiny, and is another one of these things
 that's not so useful unless configured (even though that's awesomely easy);
 maybe the libs could be split out?

glusterfs is included on Desktop/live install media. And it produces a big red 
FAIL in systemctl status listing by default. It seemed at first this was due to 
an avc denial, but that's since been fixed, yet the failure to start by default 
remains.

https://bugzilla.redhat.com/show_bug.cgi?id=980683


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel