Can we have that in Xenial as well?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1298325
Title:
ifenslave can't delete interfaces from a bond
To manage notifications about this bug go to:
+1 for getting it back in the distro. I was quite confused when it was
suddenly gone.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1766555
Title:
openscad package missing from 18.04
To manage
Ah, sounds like good holidays.
Yes, we tested that line and it worked.
The charm had additional issues with the way it created the directory, but that
was just a distraction.
What I don't know 100% is the impact of not having this socket. Because in
order to test if rbd works, I need that
Honestly, I would only modify package maintained files from a charm as the very
last resort.
Using those paths is not only something strange in the charm. Anyone using ceph
rbd would use those paths.
IMO, the question is, should a properly confined qemu allow rbd or not?
This has btw
I'm still testing the full extent of the impact. It could be that just the
admin socket isn't set up and the nasty error message.
Customer claims it's disabling the whole cache. But I'm not sure if that is
actually true. And not quite sure how to test it TBH.
Best case, it's just ugly
Partner bug in Charm https://bugs.launchpad.net/charm-cinder-
ceph/+bug/1779676
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1779674
Title:
AppArmor does not permitt access to rbd admin socket
Public bug reported:
The OpenStack charm nova-compute sets up rbd with hardcoded paths which
libvirt has no access too when confined by AppArmor
The charm sets up
'admin socket': '/var/run/ceph/rbd-client-$pid.asok'
via
This wasn't exactly the section of postinst that was causing the issue.
I have a workaround for it in debian/rules:
override_dh_installinit: dh_installinit --name dirsrv-admin -- defaults 15 85
vs
override_dh_installinit: dh_installinit --name dirsrv-admin --no-start --
defaults 15 85
And a
I can confirm this bug on Zesty.
As far as I understand the situation, the following is the case.
The package leases the service in a un-configured state. There is no
/etc/dirsrv/admin-serv/adm.conf and /var/log/dirsrv/admin-serv/ does not exist.
This is why the service doesn't start. The