Hi, As there has been no further input from the community, I created a PR to remove the unused files under the `deploy` dir: https://github.com/apache/cloudberry/pull/1090. Please help review it.
I kept the `deploy/build` files unremoved as a revision base in the coming months to avoid creating them from scratch. Best, Dianjin Wang On Fri, Apr 25, 2025 at 6:01 PM Ed Espino <esp...@apache.org> wrote: > > Hi Dianjin, > > Thanks for the detailed context and thoughtful suggestions. > > I agree with your assessment that much of the content under > deploy/—particularly > docker/, k8s/, script/, vagrant, cbdb_deploy.sh, and cbdb_env.sh—is > outdated and not aligned with Cloudberry's current or future direction as a > community-led Apache project. > > Given that these artifacts rely on internal or deprecated setups and are > not part of any active public workflow, I propose we proceed with deleting > the entire deploy/ directory. This would remove ambiguity for new > contributors and make the codebase cleaner and more compliant with ASF’s > principles of openness and transparency. > > We can leave a placeholder issue or GitHub Discussion open to encourage > community contributions toward a modern, accessible deployment workflow. > Docker Compose seems like a natural starting point, and it would be great > to see contributors take the lead in shaping tools that better reflect > real-world usage scenarios across platforms. > > Let’s continue to gather input from others, but unless there are > objections, we could aim to move forward with the cleanup in the next > couple of weeks. > > Best, > > -=e > > -=e > -- > Ed Espino > Apache Cloudberry (Incubating) & MADlib > > > On Fri, Apr 25, 2025 at 1:28 AM Dianjin Wang <wangdian...@gmail.com> wrote: > > > Hi Ed, > > > > Thanks for bringing this up — I’d like to contribute some context and > > suggestions as follows. > > > > Best, > > Dianjin Wang > > > > > > On Fri, Apr 25, 2025 at 5:32 AM Ed Espino <esp...@apache.org> wrote: > > > > > > - Is the `deploy/` directory still in active use or maintained? > > > > Files in `deploy/build/` were originally scattered under the top-level > > dir in Greenplum to guide users in building the project. We moved them > > here for better organization. These scripts and files are used to help > > users build Cloudberry on Linux and macOS. However, they do need > > updates — including bash compatibility, dependency management, and OS > > support. We might cherry-pick updates from Greenplum or revise them > > ourselves. > > > > The `vagrant/` directory, previously under `src/tools/vagrant/` in > > Greenplum, was also moved here. However, these files have not been > > maintained upstream for over 5–6 years and use VirtualBox as the > > provider, which has poor support for Apple silicon in my previous > > testing (I'm not sure how it goes now). > > > > > - Was it contributed primarily to support internal workflows, or is it > > > intended to serve as a general deployment guide for the community? > > > > Files under `k8s/`, `docker/`, `script/`, as well as `cbdb_deploy.sh` > > and `cbdb_env.sh`, were initially to support internal workflows. As > > you can see, some internal URLs referenced in the files are not usable > > by the general public. > > > > To my knowledge, these are also not used in the public Cloudberry > > workflows. > > > > > - If it isn’t currently usable without access to internal resources, > > should > > > we clarify that in the README or revisit how it’s presented? > > > > For legacy and unused files, I propose we remove them entirely: > > - `docker/` > > - `k8s/` > > - `script` > > - `vagrant` > > - `cbdb_deploy.sh` > > - `cbdb_env.sh` > > > > > - Would it be valuable to provide a community-accessible deployment path > > > using standard open tools (e.g., Docker Compose, Helm charts, Terraform)? > > > > +1. Starting with Docker Compose would be a great first step. It could > > help both new users and contributors get started more easily. > > > > > - Does the current setup align with ASF expectations around transparency > > > and community-driven development? > > > > As suggested above, once we clean up the internal and deprecated > > files, it should be more aligned with ASF’s expectations. > > > > > While it’s entirely understandable that early artifacts might reflect > > their > > > original environment, continued reliance on internal infrastructure could > > > make onboarding harder for external users — and may not reflect the > > Apache > > > spirit of openness and independence. > > > > Agree, I acknowledged with the vendor engineers that these files are > > not used anymore in their internal workflows. So we can clean up these > > files for better openness and public access. > > > > ～～～ > > > > BTW, I started a GitHub Discussion on cleanup of `deploy` dir[1] back > > in Feb, but we can continue the deep discussion on this mailing thread > > to gather more feedback and suggestions. > > > > [1] https://github.com/apache/cloudberry/discussions/948 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org > > For additional commands, e-mail: dev-h...@cloudberry.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cloudberry.apache.org For additional commands, e-mail: dev-h...@cloudberry.apache.org
