doc: proposal to restructure the content in the demo folder

[ttzeng]

Unlike each plugin implementation has dedicated folders under the cmd/ directory to host the documents of each device plugin, all the testing containers, demo scripts, configurations, and yaml files are flat scattered in the demo/ directory with a single readme.md description file, this leads to a very lengthy readme file and an unorganized demo/ directory in the repository.

We are proposing to restructure the current demo/ directory to group resources for the same plugin type in a single subdirectory tree. For instance, create a new demo/qat_plugin/ directory and move all the qat demo related resources in there, including the screencast scripts, K8s configuration files, and the existing folders containing the testing Docker build contexts. The following are the proposed working items in high level:

Phase 0 - modify demo build targets (#954)

• modify Makefile rules to build demo containers' images not limited in the level-1 folders.

Phase 1 - restructure existing files

• create a new root subdirectory for each plugin type under the current demo folder.
• move the files designed for the same plugin type to the new root.
• update the hyperlinks of the moved files in the demo readme.md file.
• update a few hyperlinks of the moved files in some of the plugin README.md files.

Phase 2 - create readme.md hierarchy

• create new readme.md files in each subdirectories.
• move the sections of the description for each plugin types to the new readme.md and linked from the main readme.md.

Does it make sense? or while we take a stab at restructuring the content in the demo folder, any suggestions would be very appreciated.

[msivosuo]

Hi, this sounds good to me! Agreeably our demo section has ben growing together with the amount of plugins and creating a more scalable structure is a very welcome idea.

[mythi]

modify Makefile rules to build demo containers' images not limited in the level-1 folders.

my preference would be to make it like the plugin images: one directory for all Dockerfiles and the filename defines the image name. one other thing to consider is would we want something like build/plugin-images and build/application-images. Some of the "demo" images are more than just demos these days, we use them in e2e validation as well.

[ttzeng]

@mythi I am afraid keeping Dockerfiles along may not be sufficient, some demo images have their own entry scripts (e.g. dlb-dpdk-demo), if we host all files together with the Dockerfiles, that may lead to an unorganized folder. How do you think?

[mythi]

@mythi I am afraid keeping Dockerfiles along may not be sufficient, some demo images have their own entry scripts (e.g. dlb-dpdk-demo), if we host all files together with the Dockerfiles, that may lead to an unorganized folder. How do you think?

at least this approach would be same as what the plugin images use. there are always pros and cons.