search

opensearch-project / opensearch-build

🧰 OpenSearch / OpenSearch-Dashboards Build Systems
Apache License 2.0
136 stars 271 forks source link

Separate monorepos (e.g. OS and OSD plugins) to different repositories #2188

Closed peterzhuamazon closed 1 year ago

peterzhuamazon commented 2 years ago

As of now, plugins such as SQL, Reports, Notifications are using the same git repo for their OS and OSD plugin. This cause a mass discrepancies in tags commit id differences.

In 2.0.0, we build OS and OSD artifact at the same time. During sanity testing, OSD found some bugs in reports so we rebuild OSD. This means, reports BE in OS and reports FE in OSD are using different commit id. However, since they are both in the same repo, you can only tag 2.0.0 with one commit id. We are forced to use the newer commit id in the tag. This means for anyone to checkout the 2.0.0 tag in sql repo, will have a different commit id compares to the manifest.yml file bundled in OS tarball.

We need to start the discussion on the potential separation of these plugins into different repositories.

bbarani commented 2 years ago

@anirudha @praveensameneni Please make a note of this campaign as it affects your repositories.

CC: @CEHENKLE @xinlamzn

anirudha commented 2 years ago

This won't be resourced for 2.1 . lets review more details in depth

anirudha commented 2 years ago

@peterzhuamazon "This cause a mass dependencies in tags commit id differences." -> can you better explain the problem you are trying to solve

anirudha commented 2 years ago

If the requirement is that a tag should not change after it associated with a commit-id , i.e a tag is supposed to be treated as an immutable identifier for the code. Then the build system must tag only after all release activities are completed.

Why is the build system tagging repos with a release-tag before we finalize the release ? if there is a bug after this, we can cut a patch version, its that right ?

Ideally all release activities, I would do on a branch and then tag is the final stamp of immutability. After a tag is cut, every bug should be a new version-patch.

moreover, you may also use tag formats and the ability run actions based on tag format to come up with a solution that best solves this problem for the build system. GitHub Actions supports executing different actions based on the format of a tag.

anirudha commented 2 years ago

As a developer, i would to like have a single place to build, test unit, ITs and validate all components of the ecosystem. A UI without a backend is meaningless as a release artifact

As a user, and a developer, I would like to have a single place to develop and file issues , PRs and pre-commit checks.

As a maintainer, i would like to easily maintain projects in 1 repo rather an 6 repos for SQL, 2 for Observability and 2 per plugin.

As a maintainer, user, developer simplicity is the key in long term sustainability and maintainability of the project.

this problem can be technically solved by the build system, mono-repo are a common place in the dev. eco system

qreshi commented 2 years ago

Are we trending towards making this a soft rule that having these in a single repo can't happen?

I'm not necessarily heavily in favor of one repo format over another but there are some tradeoffs between the two, some of which Ani mentioned above.

I think what's important is that our long term goal for OpenSearch from a maintainer perspective (as I originally remembered it, please correct me if this changed) is not being just a single distribution where plugin owners can follow what they deem to be the most effective for their repo and will even manage the cadence for their releases. However, standardizing things like repo contents and structuring for infra is seemingly going in the opposite direction. I understand these decisions are so we can move and release faster in the short term while we're still one big distribution but we might want to think about what this looks like when we do split. We'd want to keep our mechanisms flexible to ease us into that eventuality.

On the other hand, if that isn't what we want, we can lean fully into all plugins being the same and do things like a mono-repo and lose the overhead of the build scripts and version bump/gradle changes, etc. that is scaling with each new repo being added. The long term plan should be clear for repo owners though so they have the context to recommend what they think is best from an implementation perspective.

bbarani commented 2 years ago

If the requirement is that a tag should not change after it associated with a commit-id , i.e a tag is supposed to be treated as an immutable identifier for the code. Then the build system must tag only after all release activities are completed.

Why is the build system tagging repos with a release-tag before we finalize the release ? if there is a bug after this, we can cut a patch version, its that right ?

Ideally all release activities, I would do on a branch and then tag is the final stamp of immutability. After a tag is cut, every bug should be a new version-patch.

moreover, you may also use tag formats and the ability run actions based on tag format to come up with a solution that best solves this problem for the build system. GitHub Actions supports executing different actions based on the format of a tag.

@anirudha I am not sure if I understand your question. The real issue is the fact that the tags are cut based on the latest commit corresponding to a branch used by a build and it makes complicated to differentiate between OSD and OS commit id since the code is present in the same repo. We cut the tags based on the latest commit id on that repo used on the build but its not the right thing to do since that commit id might be corresponding to Dashboards OR OpenSearch changes rendering the tag almost useless in this scenario.

CC: @dblock @peterzhuamazon @qreshi

dblock commented 2 years ago

The tl;dr is that we release 2 products: OpenSearch and OpenSearch Dashboards from the same repo, not at the same time. For example, a patch may be released for OpenSearch 2.0.1 at time X, then another patch will be released for OpenSearch Dashboards 2.0.1 at time X+1. What should the 2.0.1 tag be in this case for dashboards-reporting?

CEHENKLE commented 2 years ago

My goal is to move us to a point where we can release all of the different components of the OpenSearch project separately -- Not just Dashboards and OpenSearch separately, but each plugin individually as well. We have a lot of water to get under a lot of bridges before that can happen (primarily around the dependency management described here https://github.com/opensearch-project/OpenSearch/issues/2447) but I see the work described in this ticket as directional. And as dB points out, it's already solving a pain point we have today.

@anirudha, @praveensameneni When can you commit to doing this work?

joshuali925 commented 2 years ago

Is this to fix a technical limitation or to make it better conceptually?

However, since they are both in the same repo, you can only tag 2.0.0 with one commit id. We are forced to use the newer commit id in the tag.

@peterzhuamazon Not sure if I understood but this sounds like a technical limitation on infra side, that if OS and OSD plugins are in the same repo, then infra can only use one commit id for both plugins. From what I understand the manifests for OS and OSD are separate and they takes refs (i.e. branches, tags, commits), I don't see where the limitation is coming from? On our side we don't tag 2.0.0 in plugins. We tag 2.0.0.0 and patch fixes bumps it to 2.0.0.1 (not the process currently but should be the correct way).

The tl;dr is that we release 2 products: OpenSearch and OpenSearch Dashboards from the same repo, not at the same time. For example, a patch may be released for OpenSearch 2.0.1 at time X, then another patch will be released for OpenSearch Dashboards 2.0.1 at time X+1. What should the 2.0.1 tag be in this case for dashboards-reporting?

@dblock I understood this. From how I see it we are releasing reporting frontend and backend together:

  1. OpenSearch 2.0.1 is released with reporting backend 2.0.1.0 and tag 2.0.1.0
  2. Dashboards 2.0.1 needs to be released, we bump reporting frontend to 2.0.1.0 and bump tag to 2.0.1.1, because this is the second 2.0.1.x release of reporting plugins

Change between tags should be covered by release notes. If possible we can make tags more specific (e.g. 2.0.1.0-backend).

qreshi commented 2 years ago

@CEHENKLE @dblock I understand the request but tags are a repo concept and it seems we're scoping them to be 1 to 1 for each artifact. Does that mean we're asking all component owners that they should have a repo per artifact regardless of scope? For example Notifications backend is technically one holistic component but has the core and general plugin producing two artifacts.

My short term reservations against increasing the number of repos is we currently have infra overhead that comes with them. Such as the bumping of versions, the way we're handling build scripts, all of the GitHub Actions that are not defined in a single place yet, etc. Just the alpha -> rc1 bump was quite a bit of work. Since plugins have to match up to the patch version anyway, I recall some suggestions being a gradle plugin that plugins could consume to get the version/qualifier info for the distributions (based on the version of OS/OSD being used) with an option to override. Is this being prioritized at the same level as asking component owners to take on more repos?

praveensameneni commented 2 years ago

My goal is to move us to a point where we can release all of the different components of the OpenSearch project separately -

Furthermore reason for plugins to have a single repo so they can be autonomous in their releases.

We started with two repos and as we grew and learnt a bit or two along the way and the team came up with one repo (combining backend and front end, making it easier to maintain and deploy faster.

dblock commented 2 years ago

@dblock I understood this. From how I see it we are releasing reporting frontend and backend together:

  1. OpenSearch 2.0.1 is released with reporting backend 2.0.1.0 and tag 2.0.1.0
  2. Dashboards 2.0.1 needs to be released, we bump reporting frontend to 2.0.1.0 and bump tag to 2.0.1.1, because this is the second 2.0.1.x release of reporting plugins

So in (2) you re-release a second version 2.0.1.0, but only for some of the code, and tag it as 2.0.1.1? What are you going to do when it's OpenSearch 3.0 and OpenSearch Dashboards 8.0? How is anyone supposed to make sense of this?

dblock commented 2 years ago

We are forced to use the newer commit id in the tag.

@peterzhuamazon Not sure if I understood but this sounds like a technical limitation on infra side, that if OS and OSD plugins are in the same repo, then infra can only use one commit id for both plugins. From what I understand the manifests for OS and OSD are separate and they takes refs (i.e. branches, tags, commits), I don't see where the limitation is coming from?

There's no "limitation". Manifests support refs and many other things. However, infra automation that creates tags post release (so you don't have to) is currently not able to guess when it releases OpenSearch Dashboards 2.0 it should be tagging your plugin as 2.0.0.1 and not 2.0.0.0 like it does for the other 12 plugins, because you're a special case.

I think there are 3 choices:

  1. Split the 4 repos as proposed in this issue.
  2. Adjust infra automation to guess what tag to create when there's already an existing tag. Make sure to use that tag in the manifest. Document for anyone who looks at the 4 repos that 2.0.0.0 is OpenSearch 2.0, but 2.0.0.1 is Dashboards 2.0.0.0.
  3. Continue tagging and updating manifests post release manually. Document as in (2).

What do you think is best @praveensameneni @qreshi @joshuali925 ?

dblock commented 2 years ago

@qreshi On the 1 repo = 1 component, yes that is generally my personal preference. Repos are cheap. Having completely different CIs, languages, tools in the same repo burdens the developers in having to often install unnecessary pre-requisites, having to understand a much larger codebase, etc.

anirudha commented 2 years ago

My goal is to move us to a point where we can release all of the different components of the OpenSearch project separately -

we can do this without forcing team to maintain multiple repos. The current proposed solution creates a lot of issues for us as described here. https://github.com/opensearch-project/opensearch-build/issues/2188#issuecomment-1161969668

CEHENKLE commented 2 years ago

@anirudha @praveensameneni @xinlamzn Can you do a deeper dive on tagging options w/pros and cons and report back here?

peterzhuamazon commented 2 years ago

Hi All,

20220719 notes:

  1. We are thinking about tagging OS and OSD components with separate tags.
  2. Starting on v3.x we will tag all backend component with <version>-opensearch and frontend component with <version>-opensearch-dashboards. This includes both the split repos and the combined repos, core and components.
  3. As for v1.x and v2.x we will keep using 1 tag <version> for both components. We will work with component owners to make sure their changes are delivered in time to avoid having commit ID discrepancies.

Thanks.

penghuo commented 2 years ago

I think merge all the OpenSearch plugin into OpenSearch repo could be another alternative solution.

dblock commented 2 years ago

OpenSearch is huge enough, we can barely get a reliable CI. More code will just exacerbate the problem. Then, it wouldn't help the SQL components problem (which contains multiple release artifacts: ppl, sql-cli, sql-jdbc, sql-odbc, sql).

penghuo commented 2 years ago

My 2 cents. I think plugin is just a way to implement the feature in OpenSearch which is not necessary as a separate repo. We have repos for ODFE SQL plugin is majorly because we do not maintain Elasticsearch. In OpenSearch, we should have such flexibility to add plugin in OpenSearch repo.

And I believe it is a generic pattern to maintain connectors, plugins, client in same repo. for example, in Trino.

The pros are

The cons are

OpenSearch is huge enough, we can barely get a reliable CI. More code will just exacerbate the problem. Then, it wouldn't help the SQL components problem (which contains multiple release artifacts: ppl, sql-cli, sql-jdbc, sql-odbc, sql).

bbarani commented 2 years ago

@penghuo I think the main caveat here is the fact that OpenSearch and OpenSearch dashboards are 2 different products with different lifecycle. We should look for strategic long term plan and shouldn't get confined based on existing state and assumptions. Tagging issue is more of an effect (and not a cause) hence I don't think solving that issue would help us with finalizing the decision here. It would be great if we can document pros and cons from all affected parties before making the final decision. @joshuali925 @qreshi Can you please list your pros and cons as well similar to what Peng has listed above? @dblock I would need your inputs here as well.

dblock commented 2 years ago

Long term, I recommend to split repos, because I think all these components will release independently and often, and follow semver.

Short term, to fix the tagging issue, I recommend we stop tagging the repos incorrectly, altogether, and open bugs in those repos that cannot be tagged because they contain components that release at different times. The plugin owners need to then start figuring out how to tag manually.

joshuali925 commented 2 years ago

From what i understand the issue is both technical and conceptual:

Technical: we cannot directly retag 2.0.0.0 for dashboards plugin after cutting 2.0.0.0 tag for opensearch plugin if they ended on different commits for 2.0.0 release, and doing so creates side effects

Conceptual: 1 repo should = 1 component, from dB:

Having completely different CIs, languages, tools in the same repo burdens the developers in having to often install unnecessary pre-requisites, having to understand a much larger codebase, etc.

My proposal was here same as peter's comment. We don't retag 2.0.0.0, instead we bump patch version (which won't work as dB mentioned "OpenSearch 3.0 and OpenSearch Dashboards 8.0" can be compatible?) or use more specific tags like 2.0.0.0-opensearch.

Pros:

Cons:

But i'm not sure if I agree with 1 repo = 1 component since monorepo is a defined concept and works for other projects. And having code in the same repo doesn't mean all developers need to install tools or understand it.

The other way is to split repos, pros would be it solves both technical and conceptual issues.

Cons:

Currently we have 3 monorepos: sql, reporting, observability. After splitting to 1 repo = 1 component, there will be sql, sql-cli, sql-jdbc, sql-odbc, sql-workbench, dashboards-reports, reports-scheduler, dashboards-observability, opensearch-observability. For any repo-level PR (e.g. version bump, repo/doc standardization), we needed 6 approvals (3 PRs) previously but will need 18 approvals (9 PRs) after split. And this is not counting backports.

Also I did not understand why split repos will help components to "release independently and often, and follow semver", I think monorepos are also capable of releasing components independently. Appreciate if @dblock can explain this more.

dblock commented 2 years ago

@joshuali925 thanks for the detailed pros/cons, I agree with those. I appreciate the amount of additional work in, for example, backporting, would be created. I also agree that the tagging problem can be solved by naming tags. Thank you for also saying that splitting repos solves both technical and conceptual issues (while creating more work for developers).

Not splitting means we optimize for making front-end and back-end changes together. When I say "release independently and often", I am thinking about how Dashboards is an independent product from OpenSearch (conceptually and technically). Thus, consider a situation where reports-scheduler wants to make a breaking change to its API with a major version bump. Now you must always do the work to be compatible for dashboards-reports, and you also have to be extra careful to remain backwards compatible with the previous version of reports-scheduler, or you can't upgrade Dashboards, then OpenSearch without downtime. Advancing two products in a tightly coupled way is limiting.

As another example of a consequence of making front-end and back-end changes together, I was recently providing feedback on adding alerts to multiple areas of Dashboards, and I couldn't easily tell what API changes were being made, whether those API changes would stand on their own, or whether the API changes are just serving a particular change in the UX. I would have found it easier to have two separate conversations: one on the merits of an API change that stands on its own, and another of how the new APIs are used for the UX and solves the user problems.

Re: sql I would keep the monorepo and release everything together at all times.

joshuali925 commented 2 years ago

Thanks @dblock for the explanation. Since all approaches proposed will solve the technical issue, I'll focus on the conceptual issue. To make sure I understood correctly, let's say reports-scheduler is about to add new features that breaks API backwards compatibility, and it will go from 2.0.0.0 to 3.0.0.0. Now dashboards-reports is still on 2.0.0.0 which is compatible with reports-scheduler 2.x, I see 3 ways to handle dashboards-reports:

  1. Release 3.0.0.0 to be compatible with reports-scheduler 3.x only.
    • This is what we are doing right now, advancing two products in a tightly coupled way.
  2. release 2.1.0.0, ask the version of reports-scheduler at runtime and display UI features differently based reports-scheduler version.
    • This works but increases code complexity for checking at runtime and maintaining two versions of UI (which seems uncommon).
  3. Do not release with reports-scheduler, have its own release later.
    • This breaks dashboards-reports for users who upgraded reports-scheduler 3.0.0.0.

In fact the last case happened historically for data-prepper and trace-analytics (now part of dashboards-observability). Data-prepper made breaking changes to index schema and released a new version, but there were no Dashboards releases. Trace-analytics couldn't recognize the new schema and UI did not function correctly, which broke user experience. How would you handle such cases if we do not advance front-end and back-end together?

The second point I think making PR/commits more granular would help? If one PR only does one thing regardless of how much code/component it changes, it should be clear whether the change stands on its own or for UX to solve user problems. Splitting repos forces separation of front-end and back-end component changes, but I'm not sure if that's the only/best solution. (I also might have misunderstood some parts, wasn't aware of the alerting case)

dblock commented 2 years ago

In fact the last case happened historically for data-prepper and trace-analytics (now part of dashboards-observability). Data-prepper made breaking changes to index schema and released a new version, but there were no Dashboards releases. Trace-analytics couldn't recognize the new schema and UI did not function correctly, which broke user experience. How would you handle such cases if we do not advance front-end and back-end together?

I would work backwards from the desired user experience, as always. At no time we should have had a broken user experience. When we advance front-end and back-end together with a breaking change, requiring upgrading data-prepper, then dashboards, even if released together, does it require hard downtime to upgrade? That's the definition of broken UX.

In this example, data-prepper v1 should have first deprecated the feature, visibly. Dashboards would want to release a version that is compatible with data-prepper v2 and v1, and users would upgrade. Then data-prepper v2 would be released.

Note that data-prepper cannot possibly know about all its clients that exist. So it needs to be deprecating features "slowly", and making breaking changes "almost never", which corresponds to major releases.

The second point I think making PR/commits more granular would help?

Sure, more granular commits help. But it's still an approach of a monolithic application, rather than an API serving multiple clients. So I suppose an important question to ask is whether you're shipping a UX product, or shipping an API and a UX product that uses it?

dblock commented 2 years ago

The combined repos were created because features were built with an end-user experience in mind at the time of ODFE. Both backend and front end user experience are parts of the UX we want to achieve. The dashboards plugin provide the users to configure a monitor (alerting) or a detector (anomaly detection) and have a workflow that enables feature rich functionality that is easy to understand and implement. Separately, advance users (power users) can configure a monitor (https://opensearch.org/docs/latest/monitoring-plugins/alerting/monitors/) or a notification channel through a back end API (https://opensearch.org/docs/latest/monitoring-plugins/alerting/api/) that is available in the back end plugin.

The current best version of pros (keep monorepos) and cons (split per component) is as follows.

Help me update the lists? What's missing in either? Please be as specific as possible of what words you'd like to change below.

Pros (keep 4 monorepos):

Cons (split per component):

joshuali925 commented 2 years ago

Agree with the other points. Two comments, feel free to correct or ignore my comments if my understanding is inaccurate.

Cretes a confusing naming / structure, as the repo such as dashboards-reports is hosting both dashboards-reports in frontend, and reports-scheduler in backend.

I'm assuming the confusing part is that the repo name and the sub-component name are both dashboards-reports. I think the pros/cons list should apply to all mono-repos, but this one seems to be specific with dashboards-reports, and it's more of a naming issue rather than issue caused by using a mono-repo. For example, making observability a mono-repo did not create a similar issue for it. So maybe remove this one or specify it is a possibility and might not apply to all?

Burdens developers as having completely different CIs, languages, and tools in the same repo requires them to install unrelated CI frameworks (e.g. Cypress for front end is not helpful for backend), and having to understand a much larger codebase.

Similarly I think this is more of a documentation issue rather than mono-repo issue. It can be avoided by documenting properly. For example the SQL repo contains Workbench and Cypress for frontend, but none of the SQL developers are required to install Cypress or understand Workbench code in order to work on SQL. The DEVELOPER_GUIDE.md of SQL does not mention setting up Workbench, and there is a separate DEVELOPER_GUIDE.md for Workbench.

dblock commented 2 years ago

Thanks @joshuali925. Also I want to add "Prevents versioning OpenSearch and OpenSearch Dashboards independently".

For example, with diverging version numbers of say OpenSearch 2.0 developed at the same time as OpenSearch Dashboards 3.0. How do you branch the monorepo (at time of OpenSearch 2.0 we create a branch 2.0, then at time of OpenSearch Dashboards 3.0 we create a branch 3.0, then at time of OpenSearch 3.0 what do we do?).

pjfitzgibbons commented 2 years ago

I have a thought that is I think might be a positive-consequence of splitting the repos - allowing developer-environment setup for FE/BE with multiple plugins “at one time”.

I don’t know how infra does the release-compiling, especially with our “batteries-included” zip/download that contains Core, Reporting, Observability, etc.

As a newish contributor to OSD/Observability, though (3rd month on team now), I have learned that our developers are largely unaware of how to setup the development environment to run multiple plugins (Observability + Reporting, for example) in one development environment. The technical difficulties of this have to do with file-paths, linux soft-link behaviour, node-js/require-js file-loading behaviour.

I believe splitting plugins FE/BE will clarify the basic DEVELOPER_GUIDE.md on each project, as well as greatly simplify plugin development, as each plugin/git-clone would truly be “drop-in” — clone the plugin to /.plugins and “go”.

dblock commented 2 years ago

Thanks @pjfitzgibbons I think that maybe my way of putting pros/cons doesn't sufficiently address these two options in situ. Here's an updated list (I made it option A and B).

Option A: Continue allowing related components of one feature to exist in a single GitHub repository.

Pros:

Cons:

Option B: Split the 4 combined repositories into separate OpenSearch vs. OpenSearch Dashboards component repositories.

Pros:

Cons:

bbarani commented 1 year ago

@dblock Do we have a decision for this issue? I would like to understand the next steps so we can be better prepared from build tooling perspective for 3.x releases.

dblock commented 1 year ago

@dblock Do we have a decision for this issue? I would like to understand the next steps so we can be better prepared from build tooling perspective for 3.x releases.

Yes. We decided that we will split repos for frontend and backend plugins. The current plugin owners with joint repos (@anirudha and @praveensameneni) will start the work to split repos after OpenSearch 2.4 release, and target completion by 2.5. The plugin teams will figure out a way to run integration tests at PR level for both frontend and backend components.

MaxKsyunz commented 1 year ago

@dblock Do we have a decision for this issue? I would like to understand the next steps so we can be better prepared from build tooling perspective for 3.x releases.

Yes. We decided that we will split repos for frontend and backend plugins. The current plugin owners with joint repos (@anirudha and @praveensameneni) will start the work to split repos after OpenSearch 2.4 release, and target completion by 2.5. The plugin teams will figure out a way to run integration tests at PR level for both frontend and backend components.

Where will JDBC/ODBC drivers, opensearchsql-cli, and Tableau/PowerBI connectors go?

dblock commented 1 year ago

@MaxKsyunz The intention of this issue was to split front-end and back-end plugins, for those other things I'd defer to the team that understands the code dependencies better. Maybe open another issue on those? How often do they release and what are their dependencies?

dblock commented 1 year ago

I've added https://github.com/opensearch-project/opensearch-build/issues/2188 for dashboards-maps.

prudhvigodithi commented 1 year ago

One more change required with this separation is with gradle updateVersion task (Task to auto increment to the next development iteration) is to remove the reference of package.json files to update the version number, since with the separation, the backend plugins would not have a json files to increment hence should be excluded from the updateVersion task Example: considering for reporting now after separation of the dashboard plugin following lines needs to be excluded, the lines that increment the version for dashboard plugin.

penghuo commented 1 year ago

Add existing SQL plugin issues, all of these issues can be categorized as release process issues

  1. https://github.com/opensearch-project/OpenSearch/issues/5815
  2. https://github.com/opensearch-project/sql/pull/1248
  3. https://github.com/opensearch-project/sql/pull/1175

As I commented, Integrate OpenSearch plugin into OpenSearch repo could solve all these problem automatically.

The pros are:

  1. Plugin owner do not need to bump OpenSearch version. Plugin could directly depend on version defined in same repo.
  2. Plugin owner do not need to change OpenSearch build mainfest. Release team change mainfest one time for each release.
  3. Plugin owner do not need to cut new branch. Release team cut branch one time for each release.
  4. Plugin BWC test on main could be executed for PR directly on 2.x branch without waiting for snapshot build. solved https://github.com/opensearch-project/OpenSearch/issues/5815
  5. Plugin could directly depend on other plugin at project level, instead of maven distribution. solve https://github.com/opensearch-project/sql/pull/1248 and https://github.com/opensearch-project/sql/pull/1175

The cons are: Not very clear now, As I explore Apache Spark, Apache Flink and Trino. All these projects use monorepos approach.

bbarani commented 1 year ago

Closing this issue as we have completed splitting OpenSearch and OpenSearch dashboards monolithic repos in to individual repos.