** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927219
Title:
context deadline exceeded: unknown in containerd with latest runc
version
To manage notifications about this bug go
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927208
Title:
nfs-ganesha doesn't include built shared object files to enable
storing configuration in RADOS
To manage notificati
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1927207
Title:
NFS Ganesha is built without RADOS support
To manage notifications about this bug go to:
https://bugs.launchpad.net/u
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1834213
Title:
After kernel upgrade, nf_conntrack_ipv4 module unloaded, no IP traffic
to instances
To manage notifications about t
Spent some time debugging this and I found some interesting bits. I was
able to reproduce this by deploying a xenial-queens environment with
VXLAN and the OVS firewall. Investigating this, here is what I found:
1) This module is first loaded on the compute nodes when libvirt-bin is
installed. This
Just tested on devstack deployed on Xenial. The module gets loaded at
some point during neutron configuration on the deployment script.
It seems like a neutron bug to me. It relies on conntrack for the
firewall to work, but never actually loads the module. In most cases
something else will end up
Fix up for review: https://review.opendev.org/#/c/678956/
** Changed in: charm-neutron-openvswitch
Assignee: (unassigned) => Tiago Pasqualini da Silva (tiago.pasqualini)
** Changed in: charm-neutron-openvswitch
Status: Confirmed => In Progress
--
You received this bug notifi
Fix: https://review.opendev.org/#/c/655803/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1821767
Title:
Cinder ISCSI drivers require /sbin/iscsiadm permissions in apparmor
To manage notification
Hello all,
Just tested eoan-proposed. Will now start testing train and stein.
Thanks
** Tags removed: verification-needed-eoan
** Tags added: verification-done-eoan
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launch
Tested stein and train, all good.
Thanks
** Tags removed: verification-stein-needed verification-train-needed
** Tags added: verification-stein-done verification-train-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs
** Also affects: cloud-archive
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867386
Title:
Beast frontend does not allow tuning of maximum backlog of pen
** Description changed:
+ [Impact]
+
Currently, RGW has no option to configure the maximum size for the queue
of connections waiting to be accepted when using the Beast frontend.
Instead, it uses the value from
boost::asio::socket_base::max_connections.
+ [Test Case]
+
+ Add the 'max_
** Patch added: "eoan.debdiff"
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1867386/+attachment/5338155/+files/eoan.debdiff
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/
** Tags added: sts-sru-needed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867386
Title:
Beast frontend does not allow tuning of maximum backlog of pending
connections
To manage notifications a
Public bug reported:
Currently, RGW has no option to configure the maximum size for the queue
of connections waiting to be accepted when using the Beast frontend.
Instead, it uses the value from
boost::asio::socket_base::max_connections.
This bug is similar to 1838109, which reports the same issu
This is already fixed upstream:
https://github.com/ceph/ceph/pull/33053
https://github.com/ceph/ceph/pull/33340
https://github.com/ceph/ceph/pull/33341
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/18
Hi Mateusz and JP,
This has been fixed and released through another bug:
https://bugs.launchpad.net/cloud-archive/+bug/1941048
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1900851
Title:
[SRU] Can
** Merge proposal linked:
https://code.launchpad.net/~tiago.pasqualini/curtin/+git/curtin/+merge/474394
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2076943
Title:
Incorrect GPG signature file d
It is currently possible to achieve this by using templates, which is
supported by curtin. This is currently not documented anywhere besides
one of the examples:
https://github.com/canonical/curtin/blob/master/examples/apt-
source.yaml#L109
I have proposed a PR that adds documentation for this in
** Merge proposal linked:
https://code.launchpad.net/~tiago.pasqualini/curtin/+git/curtin/+merge/473681
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2076943
Title:
Incorrect GPG signature file d
20 matches
Mail list logo