Hi Fabricio, 1st, this seems unrelated to the change.
Rather than doing that, I suggest you: 1. Make sure vagrant is up-to date. The Fedora 30 RPMs work well. The upstream RPM may or may not on work well Fedora 30, and require additional plugin updates / configuration work. My Fedora 30 vagrant* RPMs (including plugins) are: vagrant-sshfs-1.3.1-3.fc30.noarch vagrant-hostmanager-1.8.9-2.fc30.noarch vagrant-2.2.5-1.fc30.noarch vagrant-libvirt-0.0.45-1.fc30.noarch 2. Cleanup / delete old VMs with `virt-manager`. You should see both "QEMU/KVM" and "QEMU/KVM User Session". The former are "system" VMs, the latter are "user session" VMs. It is better to run pulplift VMs as user session for most circumstances. You don't need to be in the libvirt group, or run as root. The VMs are stored under your home dir instead of /var/lib/libvirt/ . gnome-boxes uses user session VMs. If you still want to run pulplift VMs as system VMs, forklift has a variable (see pulplift/forklift/README.md): libvirt_qemu_use_session -Mike On Thu, Oct 17, 2019 at 4:11 PM Fabricio Aguiar <fabricio.agu...@redhat.com> wrote: > > I don't know if I did something wrong, or it was related to this update, > but I got this error: > > ➜ pulplift git:(master) vagrant up pulp3-source-fedora30 > Bringing machine 'pulp3-source-fedora30' up with 'libvirt' provider... > Name `pulplift_pulp3-source-fedora30` of domain about to create is already > taken. Please try to run`vagrant up` command again. > > > after trying so many things, what worked for me was including: > > domain.qemu_use_session = false > > here: > https://github.com/theforeman/forklift/blob/master/vagrant/lib/forklift/box_distributor.rb#L54 > > Got this solution from here: > https://www.techchorus.net/microblog/vagrant-libvirt-issue-after-upgrading-to-fedora-30/ > > Best regards, > Fabricio Aguiar > Software Engineer, Pulp Project > Red Hat Brazil - Latam <https://www.redhat.com/> > +55 11 999652368 > > > On Thu, Oct 17, 2019 at 2:43 PM Brian Bouterse <bmbou...@redhat.com> > wrote: > >> With 51395 >> <https://github.com/pulp/pulpcore/commit/513952bde418e8370471a21814c1bcaffd36fef1> >> pulpcore no longer has a hard-coded settings file, but the installer >> maintains this functionality by keeping it's settings at >> /etc/pulp/settings.py. This was part of https://pulp.plan.io/issues/5560 >> >> You'll see issues of it not finding the secrets, or a database >> authentication issue where it can't find the settings in your environment >> anymore. >> >> To fix, redeploy your environment. When you use the latest installer (or >> the latest pulplift) and re-deploy it will configure Pulp in a way that >> settings can still be delivered as they did before. >> >> Sorry for the interruption. This is part of a larger piece of work to >> have our settings overlay in a way that is useful to users and various >> environments. >> >> Thanks, >> Brian >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > -- Mike DePaulo He / Him / His Service Reliability Engineer, Pulp Red Hat <https://www.redhat.com/> IM: mikedep333 GPG: 51745404 <https://www.redhat.com/>
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
