On Wed, Jan 19, 2022 at 9:00 AM Ken Dreyer <kdreyer@xxxxxxxxxx> wrote: > > On Wed, Jan 19, 2022 at 10:27 AM Mark Nelson <mnelson@xxxxxxxxxx> wrote: > > > > Probably the easiest first pass approach would simply be to compile with > > symbols and then create a debug container and a non-debug container with > > the symbols stripped. > > I am not a Ceph debugging expert, and I think that's why this issue is > cloudy for me. If we did that, would it be simple for Ceph users to > utilize? And Teuthology? For example, would we lose some debugging > data if users have to swap container environments like that? I don't know much about packaging and debug symbols either, but let's be clear: this is a very narrowly-scoped issue. "Ceph users" really don't enter into it at all; it's entirely about developers being able to run teuthology tests more quickly than our current "push to CI repo, wait 60-180 minutes depending on mood of servers and length of queue, schedule tests". So we need debugging to work in a way that is accessible to dedicated Ceph developers, but the setup cost can be arbitrarily high as long as it's one-time-only. Our actual releases (and anything we wanted to give out to others, or really deploy) would continue to go through the existing build systems. -Greg > > > Longer term, I *think* this is the usecase for elfutil's debuginfod > > server tools: > > > > > > https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server > > > I've never really looked at it seriously, but my understanding is that > > you basically create a debuginfod server for your executables and then > > they can be automatically fetched when you need the symbol information. > > The specifically mention debugging in containers that weren't built with > > symbols. > > Thanks for this link. It looks interesting. I'm going to find the > teams who are working on debuginfod to understand if that will work > with our use-case. I'm also curious about the disconnected use-cases - > what would users do in disconnected environments? Or environments > where they're building their own forks outside of ceph.com? (a likely > use-case where debuginfo is especially useful :) > > - Ken > > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx > _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
