Commits on Sep 23, 2018

1. machines/libvirt/worker.machineset.yaml: Drop /var/lib/libvirt/images …

   The actuator looks up the baseVolumeID in the configured pool [1].
   That lookup works with both the volume name and full volume path:
   
     $ virsh -c qemu:///system vol-info --vol coreos_base --pool default
     Name:           coreos_base
     Type:           file
     Capacity:       16.00 GiB
     Allocation:     1.55 GiB
   
     $ virsh -c qemu:///system vol-info --vol /home/trking/VirtualMachines/coreos_base --pool default
     Name:           coreos_base
     Type:           file
     Capacity:       16.00 GiB
     Allocation:     1.55 GiB
   
   But it fails if you use the wrong full path:
   
     $ virsh -c qemu:///system vol-info --vol /var/lib/libvirt/images/coreos_base --pool default
     error: failed to get vol '/var/lib/libvirt/images/coreos_base'
     error: Storage volume not found: no storage vol with matching path '/var/lib/libvirt/images/coreos_base'
   
   My default pool happens to be in my home directory:
   
     $ virsh -c qemu:///system pool-dumpxml default
     <pool type='dir'>
       <name>default</name>
       <uuid>c20a2154-aa60-44cf-bf37-cd8b7818a4e4</uuid>
       <capacity unit='bytes'>105554829312</capacity>
       <allocation unit='bytes'>44134699008</allocation>
       <available unit='bytes'>61420130304</available>
       <source>
       </source>
       <target>
         <path>/home/trking/VirtualMachines</path>
         <permissions>
           <mode>0777</mode>
           <owner>114032</owner>
           <group>114032</group>
           <label>system_u:object_r:virt_image_t:s0</label>
         </permissions>
       </target>
     </pool>
   
   This commit allows configutions like mine by dropping our opinions
   about the default pool location and just using the volume names:
   
     $ virsh -c qemu:///system vol-list --pool default
      Name                 Path
     ------------------------------------------------------------------------------
      bootstrap            /home/trking/VirtualMachines/bootstrap
      bootstrap.ign        /home/trking/VirtualMachines/bootstrap.ign
      coreos_base          /home/trking/VirtualMachines/coreos_base
      master-0.ign         /home/trking/VirtualMachines/master-0.ign
      master0              /home/trking/VirtualMachines/master0
      worker.ign           /home/trking/VirtualMachines/worker.ign
   
   We've been using the full-path approach since the templates landed in
   2522d0f (add libvirt support, 2018-08-30, openshift#35), but there's no
   discussion there about why the path approach was chosen instead of the
   name approach I'm switching to here.
   
   Longer-term, it would be nice to pull both the pool and volume names
   from information pushed by the installer [2].  But I'm punting on
   *that* for this commit.
   
   Reported-by: Matt Rogers <mrogers@redhat.com>
   
   [1]: https://github.com/openshift/cluster-api-provider-libvirt/blob/2e5a516afc704c6c94d7b7cde74e78c43bbfeaa5/cloud/libvirt/actuators/machine/utils/volume.go#L174
   [2]: https://github.com/openshift/installer/blob/dc4764dc603cea5da0e54f575b7ae1a2c26d3102/pkg/types/machinepools.go#L53-L58

   

   wking committed Sep 23, 2018
   Configuration menu

   • View commit details
   • Copy full SHA for ea4a450
   • Browse repository at this point

   Copy the full SHA

   ea4a450 View commit details

   Browse the repository at this point in the history