On 06/02/2016 11:25 AM, Jason Brooks wrote: > On Thu, Jun 2, 2016 at 7:23 AM, Dusty Mabe <[email protected]> wrote: >> >> There is a small subtlety with the libvirt vagrant provider that many >> people aren't aware of. >> >> On the first `vagrant up` the vagrant box will be uploaded to the >> libvirt storage pool and then used as a backing device for the vm that >> gets started. So now you have the vagrant box file (lives in the >> .vagrant.d directory) as well as a file in the libvirt storage pool. >> >> The problem comes about when you remove/re-add a box to a machine. >> When you remove the box, it removes the box from vagrant but it does >> not remove the box from the libvirt storage pool. If you subsequently >> re-add the box (a newer version this time) to vagrant and perform a >> `vagrant up` then no box gets uploaded because there is already a >> "backing image" in libvirt with that name. > > Here's what to watch for: > > $ vagrant box remove centos/atomic-host > Removing box 'centos/atomic-host' (v7.20160331) with provider 'libvirt'... > Vagrant-libvirt plugin removed box only from you LOCAL > ~/.vagrant/boxes directory >>From libvirt storage pool you have to delete image manually(virsh, > virt-manager or by any other tool) > > If you see that message, you need to do what it says. > > "vagrant box update" works fine, but is this not an option for the CDK? >
Since the CDK doesn't use atlas, it can't use versioning, which I think means that we can't use `vagrant box update`. If we could use versioning, the version gets stored alongside the name of the file in the libvirt storage pool, so this would be less of a problem. Dusty _______________________________________________ Container-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/container-tools
