Splitting this repo to smaller knative-sandbox repos (umbrella issue)

[lionelvillard]

The issue describes both the process and where individual components should be moved to.

Process

1. Open an issue requesting the creation of a new repo: https://github.com/knative/community/issues/new/choose

2. Wait for the repository to be created

3. Push eventing-contrib to the new remote:

       cd eventing-contrib
       git remote add newrepo https://github.com/knative-sandbox/newrepo.git
       git push newrepo

4. Cleanup: fork the repo and create a PR

   • delete everything not related to newrepo
   • update hack/release.sh
   • update hack/update-codegen.sh
   • update hack/update-deps.sh
   • update go.mod module to be knative.dev/newrepo
   • rename knative.dev/eventing-contrib//... packages to knative.dev/newrepo/... Move code accordingly to match the other repo structure
   • remove OWNERS files in subdirectories. Only keep the top-level one
   • cleanup OWNES_ALIASES
   • edit README.md
   • run hack/release.sh and make sure it produces the proper artifacts
   • update .github/workflows/knative-downstream.yaml

5. Remove the component from eventing-contrib

Components

This tracks the components to be moved, where they should moved and who should do it (based on the current owners).

• awssqs -> eventing-awssqs (@lberk)

  • repo request
  • Push eventing-contrib
  • Cleanup newrepo
  • Cleanup eventing-contrib
  • Setup automated releases

• camel -> eventing-camel (@nicolaferraro, @matzew)

  • repo request
  • Push eventing-contrib
  • Cleanup newrepo
  • Cleanup eventing-contrib
  • Setup automated releases

• ceph -> eventing-ceph (@lberk?)

  • repo request
  • Push eventing-contrib
  • Cleanup newrepo
  • Cleanup eventing-contrib
  • Setup automated releases

• couchdb -> eventing-couchdb (@lionelvillard)

  • repo request
  • Push eventing-contrib
  • Cleanup newrepo
  • Cleanup eventing-contrib
  • Setup automated releases

• github -> eventing-github (@lionelvillard)

  • repo request
  • Push eventing-contrib
  • Cleanup newrepo
  • Cleanup eventing-contrib
  • Setup automated releases

• gitlab -> eventing-gitlab (@sebgoa, @tzununbekov)

  • repo request
  • Push eventing-contrib
  • Cleanup newrepo
  • Cleanup eventing-contrib
  • Setup automated releases

• kafka -> ? (@lberk, @matzew)

• natss -> eventing-natss (@devguyio)

  • repo request
  • Push eventing-contrib
  • Cleanup newrepo
  • Cleanup eventing-contrib
  • Setup automated releases

• prometheus -> eventing-prometheus (@syedriko, @matzew)

  • repo request
  • Push eventing-contrib
  • Cleanup newrepo
  • Cleanup eventing-contrib
  • Setup automated releases

Please add your comments below and I'll update the process and component list accordingly.

@n3wscott @vaikas @grantr @nachocano @Harwayne

[lionelvillard]

@matzew @davyodom @lberk Can we move the kafka bits over to knative-sandox/eventing-kafka? IMO it's fine to have 2 different implementations there.

[lionelvillard]

@mattmoor @lberk I can take care of moving the GitHub code over.

[davyodom]

It feels strange to split apart eventing-contrib but combine separate kafka implementations together in a different place. We'll then face the same pain (dependency management, etc) which is trying to be alleviated by splitting eventing-contrib apart. If it is decided to take this approach it would take some effort to make these two things exist together coherently in the eventing-kafka repo I think.

[lionelvillard]

We'll then face the same pain

Well not quite (I hope). It's one thing to have 10 (and counting) different components in one repo vs only 2.

I don't have strong feelings about it, other people can jump in and give their opinion. Personally I find our Kafka story quite confusing, with no clear reason why to pick one implementation vs the other, since both are now using the same library. Having only one repo would help straighten the story, especially for people going straight to GitHub (vs reading the doc first).

[matzew]

I'd think that we move the current kafka source and kafka channel to something like "knative/eventing-kafka" repo.

If we feel like adding a second implementation approach of a channel, using the same APIs, why not ?
I think the channels have different goals and philosophies and therefore is reasonable to have both.

Now, with the kafka client being the same, I think it may make sense, at somepoint to see if - eventually - it really makes sense to merge the two channels - or use some of their impl. for other ideas like sink (real sinks, as in CRDs)

IMO it's bad if we now just pick one, to only have one.... the benefit of a sandbox repo is to have independent room for exploring ideas

[davyodom]

Agreed on the general points here. Perhaps we can discuss in the next delivery WG meeting further? If we do combine the two channels into one repo and also the source, we probably need to do some restructuring (extract common packages like the API, client and its configuration?, etc). Some probably mandatory as a first step, so builds and releases still work, and other refactoring could be done afterwards.

[travis-minke-sap]

@davyodom suggested I take a stab at potential options for what the kafka consolidation might look like. I've captured my thoughts in a doc, which is meant only to facilitate the pending WG conversation. Definitely open to other approaches, and there's a lot about eventing-contrib that I'm not aware of or up to speed on so forgive any omissions/errors ; )

[slinkydeveloper]

For what regards kafka, i think atm we're not ready to host both projects in the same repo.

Also, i think the kafka impl in eventing-contrib should continue to live under knative org, since it's a "mature" project of the knative umbrella. I would say the same for gitlab, github, camel and other sources that are under eventing since quite some time... Moving them to knative-sandbox seems like "degraduating" them to unstable projects

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.