10.2.5-0ubuntu3 was not committed to the git repo in Debian, so got lost
by my upload of 10.2.6-0ubuntu1; that version does not include the fix,
but as this only effects trusty installs, I'm going to mark tasks for
yakkety and zesty as Invalid - the ceph packages in those archives are
never backported to trusty (just the one in xenial).
As a side note I'm sorting out the git repo so that we have a mirror on
launchpad so we don't have an excuse for dropping changes by mistake.
** Changed in: ceph (Ubuntu Zesty)
Status: Fix Released => Invalid
** Changed in: ceph (Ubuntu Yakkety)
Status: New => Invalid
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1636322
Title:
[SRU] upstart: ceph-all service starts before networks up
Status in Ubuntu Cloud Archive:
Triaged
Status in Ubuntu Cloud Archive icehouse series:
Triaged
Status in Ubuntu Cloud Archive kilo series:
Triaged
Status in Ubuntu Cloud Archive liberty series:
Triaged
Status in Ubuntu Cloud Archive mitaka series:
Triaged
Status in ceph package in Ubuntu:
Invalid
Status in ceph source package in Trusty:
New
Status in ceph source package in Xenial:
New
Status in ceph source package in Yakkety:
Invalid
Status in ceph source package in Zesty:
Invalid
Bug description:
As reported in upstream bug http://tracker.ceph.com/issues/17689, the
ceph-all service starts at runlevels [2345] and introduces a race
condition which allows the ceph service (e.g. ceph-mon) to start prior
to the network the service binds to is up on the server. This causes
the service to fail on start because it was unable to bind to the
specific network the service is configured to listen on.
A work around is to provide a post-up directive to the network stanza
configuring the network device in the /etc/network/interfaces file
which restarts the necessary ceph service.
[Impact]
* Ceph service fails to start on reboot of machine/container when
networking takes some time to come up.
* The provided patch to the upstart service configuration adds the
static-network-up event as a dependency for the start on service
directive. The static-network-up event is started after all the
network stanzas have been processed in the necessary config files.
[Test Case]
* Configure multiple network interfaces and have the ceph service bind
to one of the last configured network devices to introduce a delayed
start of the network interface.
[Regression Potential]
* Upstream previously had the directive to start the service after any
network-device-up for a network which is not the loopback interface.
This caused some "weirdness" to be seen when the multiple network
interfaces were configured. This was likely due the events that it
keyed on being the local filesystems being available and a single
network interface being available. This would add the change to start
only after all the network interface stanzas are processed in the
/e/n/i configuration files.
* Additionally, this will cause some ceph services to start later than
they previously would have since this change causes additional start
dependencies. However, the results should be that the interfaces have
always had a chance to be started prior to the attempt to start the
ceph service.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1636322/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
