[Pulp-dev] [breaking] Redeploy your Environment
bmbouter at redhat.com
Fri Oct 18 14:40:34 UTC 2019
I believe this is also affecting CI preventing merging on at least one
plugin. This was unexpected as the container-build pipeline was updated and
my understanding is the tests run on top of that.
Just an FYI, I'm investigating.
On Thu, Oct 17, 2019 at 4:27 PM Mike DePaulo <mikedep333 at redhat.com> wrote:
> 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:
> 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):
> 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
>> Got this solution from here:
>> 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>
>>> With 51395
>>> 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
>>> 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
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
> Mike DePaulo
> He / Him / His
> Service Reliability Engineer, Pulp
> Red Hat <https://www.redhat.com/>
> IM: mikedep333
> GPG: 51745404
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev