[Bug 1894453] Re: Building Ceph packages with RelWithDebInfo

[Ponnuvel Palaniyappan]

Hi Brian,

I have updated the description. Does it help?

On Tue, Oct 27, 2020 at 10:01 PM Brian Murray <1894453 at bugs.launchpad.net>
wrote:

> >From the bug description its not clear to me why this change should be
> SRU'ed to Focal or what the benefit to end users is. Could someone
> please elaborate on that? Thanks!
>
> ** Changed in: ceph (Ubuntu Focal)
>        Status: Triaged => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1894453
>
> Title:
>   Building Ceph packages with RelWithDebInfo
>
> Status in Ubuntu Cloud Archive:
>   Invalid
> Status in Ubuntu Cloud Archive queens series:
>   Triaged
> Status in Ubuntu Cloud Archive stein series:
>   Triaged
> Status in Ubuntu Cloud Archive train series:
>   Triaged
> Status in Ubuntu Cloud Archive ussuri series:
>   Triaged
> Status in ceph package in Ubuntu:
>   Fix Released
> Status in ceph source package in Bionic:
>   Triaged
> Status in ceph source package in Focal:
>   Incomplete
>
> Bug description:
>   [Impact]
>   This is to consider/discuss the possibility of whether the Ceph packages
> (UCA) should be built with RelWithDebInfo build option (CMAKE_BUILD_TYPE
> [0]) which can be supplied to the build script do_cmake.sh [1].
>
>   Currently, Upstream as well as UCA builds default to 'Debug' [0]
>   builds. But is any reason why shouldn't go for RelWithDebInfo (i.e.
>   "Release with Debug information")?
>
>   There's one issue noted with RelWithDebInfo which has a workaround too
>   [2].
>
>   In general, gcc's -O2 [3] build should generate better code as well as
>   there's a specific case for Ceph [4] that it improves performance.
>
>   [0] https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html
>
>   [1] https://github.com/ceph/ceph/blob/master/do_cmake.sh
>
>   [2] https://docs.ceph.com/docs/master/dev/perf/#common-issues
>
>   [3] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>
>   [4] https://bugs.gentoo.org/show_bug.cgi?id=733316
>
>   [Test Case]
>   Standard ceph-backed OpenStack regression will be run, consisting of
> juju-deployed OpenStack+ceph and tempest regression testing against the
> deployment.
>
>   [Regression Potential]
>   As Ponnuvel mentioned, the size of binaries will be slightly bigger and
> also the build/compilation will be longer.
>   Ponnuvel also did a search of pponnuvel i'd search of upstream bugs at
> https://tracker.ceph.com and didn't find any relevant bugs.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/cloud-archive/+bug/1894453/+subscriptions
>


-- 
Regards,
Ponnuvel


** Bug watch added: Gentoo Bugzilla #733316
   https://bugs.gentoo.org/show_bug.cgi?id=733316

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/1894453

Title:
  Building Ceph packages with RelWithDebInfo

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in Ubuntu Cloud Archive stein series:
  Triaged
Status in Ubuntu Cloud Archive train series:
  Triaged
Status in Ubuntu Cloud Archive ussuri series:
  Triaged
Status in ceph package in Ubuntu:
  Fix Released
Status in ceph source package in Bionic:
  Triaged
Status in ceph source package in Focal:
  Incomplete

Bug description:
  [Impact]
  This is to consider/discuss the possibility of whether the Ceph packages (UCA) should be built with RelWithDebInfo build option (CMAKE_BUILD_TYPE [0]) which can be supplied to the build script do_cmake.sh [1].

  Currently, Upstream as well as UCA builds default to 'Debug' [0]
  builds. But is any reason why shouldn't go for RelWithDebInfo (i.e.
  "Release with Debug information")?

  There's one issue noted with RelWithDebInfo which has a workaround,
  too [2].

  In general, gcc's -O2 [3] build should generate better code as well as
  there's a specific case for Ceph [4] that it improves performance.

  Building rocksdb with optimizations enabled improves the performance and
  rocksdb being an important part of OSD and MON components of Ceph, this
  enables better performance of Ceph cluster. Comments #17, #18, & #19
  show relevant test results.

  [0] https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html

  [1] https://github.com/ceph/ceph/blob/master/do_cmake.sh

  [2] https://docs.ceph.com/docs/master/dev/perf/#common-issues

  [3] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

  [4] https://bugs.gentoo.org/show_bug.cgi?id=733316

  [Test Case]
  Standard ceph-backed OpenStack regression will be run, consisting of juju-deployed OpenStack+ceph and tempest regression testing against the deployment.

  [Regression Potential]
  As Ponnuvel mentioned, the size of binaries will be slightly bigger and also the build/compilation will be longer.
  There are no upstream bugs for this. rocksdb is one of the submodules in Ceph and how each of the submodule gets built is left to end-users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1894453/+subscriptions