Updates repo diagram to reflect current components

[modcarroll]

Description

Fixes issue #3553: This change converts the repo diagram to two tables instead of a static image. It updates the components to reflect components that are active today. After discussion with @mrutkows, we decided to use a markdown table instead of an image to promote maintainability.

Related issue and scope

• I opened an issue to propose and discuss this change (#???)

My changes affect the following components

• API
• Controller
• Message Bus (e.g., Kafka)
• Loadbalancer
• Invoker
• Intrinsic actions (e.g., sequences, conductors)
• Data stores (e.g., CouchDB)
• Tests
• Deployment
• CLI
• General tooling
• Documentation

Types of changes

• Bug fix (generally a non-breaking change which closes an issue).
• Enhancement or new feature (adds new functionality).
• Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

• I signed an Apache CLA.
• I reviewed the style guides and followed the recommendations (Travis CI will check :).
• I added tests to cover my changes.
• My changes require further changes to the documentation.
• I updated the documentation where necessary.

[dgrove-oss]

We have tooling that generates https://github.com/apache/openwhisk/blob/master/docs/dev/modules.md

Should we be leveraging that here instead of having a manual list?

[mrutkows]

Hi Morgan, so happy to have an update that reflects that the current state of project repos. and components.

Here are a few things I was wondering if we could swizzle around...

• Is there a way graphically to carryover the concepts in markdown that feature the repos. and show the directory/components of the repos. nested/under the repo. names?
  • e.g., openwhisk (column) should have openwhisk directories under, but runtimes have repos. which represent diff. granularities...
  • i.e., we should IMO the rows under each column should show top-level (hyperlinked) repos. and perhaps unordered bulleted list for significant subdirs/areaas
• Can we hyperlink to the repos.; this feature would be a great "launch point" since the main OW repo. is where 99.999% of people coming to the project start at (README).
• can we co-locate
  • openwhisk with API Gateway as I see them as integral parts of the "Paltform" (maybe call the column "Platform components"?
  • co-locate "catalog" with top-level "openwhisk-package-X" repos. under column "packages" where the catalog is denoted as "whisk.system" package components.

[dgrove-oss]

@mrutkows -- The first line of this paragraph is a link to the generated dev/modules.md file. The module list is fairly well organized, has the hyperlinks. Why duplicate?

[mrutkows]

@dgrove-oss mostly for 2 reasons

1. had a vague recollection (only after your linking) that this existed.
2. was strictly trying to address the old diagram on the README and provide a current substitute to a person seeing the README first coming to the project (and an issue that likely predates that automation). Believe a graphical depiction is more powerful (would hate to delete and provide a link that may never be followed).

Perhaps automation (despite markdown not supporting imports) would be possible, but a short term correction may be in order. we can link to that document, but perhaps seek to avoid duplication.

[mrutkows]

@dgrove-oss so what do want done with the green diagram which is incorrect?

[modcarroll]

@dgrove-oss if you think the best solution is a static image, I can just create a new image with the correct components listed. Further, I could do some image mapping using HTML to create a link to each component from within the image. Just let me know what option you would prefer.

[dgrove-oss]

Hi Morgan, its great you are putting the time into updating this. I'm fine with either a markdown table or an image.

I agree with you that a markdown table will probably be easier to maintain. You might be able to seed that markdown table by grabbing the rows for the "active" projects from the modules.md file, copying them into the main readme, and adjusting. I was initially hoping to be able to generate this new table using the same machinery we are using to generate modules.md, but since markdown doesn't support including files its probably not worth the effort. Module structure doesn't change that rapidly.