Hey all, I just want to insert a plug for this work. It's not quite production-ready, but is functional enough to at least pass a single cephadm test that uses OSDs. I'm aiming to make it generic enough to also be able to build ceph containers, but I haven't begun to tackle that yet. Soon - hopefully next week - I'll write up a bit more and send it to this list. Here's the repo: https://github.com/zmc/ceph-devstack P.S. The name is provisional; I'm open to others if they're prettier or more descriptive :) Zack On Thu, Aug 11, 2022 at 3:35 PM Josh Durgin <jdurgin@xxxxxxxxxx> wrote: > > I think it's a great idea - it's related to ideas in this thread: https://lists.ceph.io/hyperkitty/list/dev@xxxxxxx/thread/UD43OL6YBN5A2QHLKRUQLYQRXMHM5FKJ/ > > The main idea there is to make it simple to update containers so you can run teuthology tests against code you just changed with very little overhead (no need to wait for hours for package + container complete rebuilds). > > Zack Cerza has made a lot of progress on the teuthology side of this - running the tests locally using an existing container image. The 2nd half, of making it easy and fast to update a container image, is still TBD. > > Josh > > On Thu, Aug 11, 2022 at 12:09 PM Tom R <precision.automobilia@xxxxxxxxx> wrote: >> >> John >> >> I think your proposal to separate the build process such that the user can select an os flavor of their liking is a fantastic idea. >> >> I'm not familiar with the process to assist but would love to follow if this proposal is accepted. >> >> >> >> On Thu, Aug 11, 2022, 1:37 PM John Mulligan <phlogistonjohn@xxxxxxxxxxxxx> wrote: >>> >>> On the user's list one thread about the packages took a turn into discussing >>> building in containers [1]. This is a topic that I have had some idle >>> conversations about with Adam King and so I figured that I would raise this to >>> a wider audience. >>> >>> My thought is to use container images specifically for building ceph - and not >>> just it's container images. The builds may continue to produce packages, but a >>> container would be used as an abstraction between the actual OS and the build >>> process of (do_cmake.sh, etc.). >>> >>> Builder images would be be available for use both by the build system (jenkins >>> builders) as well as individual users. One advantage of this is that the user >>> can build the packages for distros that don't match the local distro. I've >>> also found it advantageous for my own builds to use the container to limit >>> memory and CPU for the build. >>> >>> I'm curious if anyone has discussed this before. Does it interest anyone? I >>> am willing to volunteer some time to help as well. >>> >>> Thanks for reading! >>> >>> >>> [1] https://lists.ceph.io/hyperkitty/list/ceph-users@xxxxxxx/message/ >>> VR3ZKP4T2PLZ6BJ23GPZAG3KBV6AI3LA/ >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
