[Pulp-dev] [breaking] Redeploy your Environment

Mike DePaulo mikedep333 at redhat.com
Thu Oct 17 20:26:36 UTC 2019


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.aguiar at 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 <bmbouter at 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20191017/e968c1f0/attachment.htm>


More information about the Pulp-dev mailing list