Page History

...

docs/
├── _index.md
├── apis
│   ├── _index.md
│   └── api.md
├── configuration
│   ├── _index.md
│   └── configuration.md
├── design
│   ├── _index.md
│   ├── design.md
│   └── protocol.md
├── getting-started
│   ├── _index.md
│   ├── docker.md
│   ├── ecosystem.md
│   ├── introduction.md
│   ├── quickstart.md
│   ├── upgrade.md
│   └── uses.md
├── implementation
│   ├── _index.md
│   ├── distribution.md
│   ├── log.md
│   ├── message-format.md
│   ├── messages.md
│   └── network-layer.md
├── kafka-connect
│   ├── _index.md
│   ├── administration.md
│   ├── connector-development-guide.md
│   ├── overview.md
│   └── user-guide.md
├── operations
│   ├── _index.md
│   ├── basic-kafka-operations.md
│   ├── datacenters.md
│   ├── enter-migration-mode-on-the-brokers.md
│   ├── finalizing-the-migration.md
│   ├── geo-replication-(cross-cluster-data-mirroring).md
│   ├── hardware-and-os.md
│   ├── java-version.md
│   ├── kafka-configuration.md
│   ├── kraft.md
│   ├── limitations.md
│   ├── migrating-brokers-to-kraft.md
│   ├── migration-phases.md
│   ├── monitoring.md
│   ├── multi-tenancy.md
│   ├── preparing-for-migration.md
│   ├── provisioning-the-kraft-controller-quorum.md
│   ├── reverting-to-zookeeper-mode-during-the-migration.md
│   ├── terminology.md
│   ├── tiered-storage.md
│   └── zookeeper.md
├── security
│   ├── _index.md
│   ├── authentication-using-sasl.md
│   ├── authorization-and-acls.md
│   ├── encryption-and-authentication-using-ssl.md
│   ├── incorporating-security-features-in-a-running-cluster.md
│   ├── listener-configuration.md
│   ├── security-overview.md
│   ├── zookeeper-authentication.md
│   └── zookeeper-encryption.md
└── streams
    ├── _index.md
    ├── architecture.md
    ├── core-concepts.md
    ├── developer-guide
    │   ├── _index.md
    │   ├── app-reset-tool.md
    │   ├── config-streams.md
    │   ├── datatypes.md
    │   ├── dsl-api.md
    │   ├── dsl-topology-naming.md
    │   ├── interactive-queries.md
    │   ├── manage-topics.md
    │   ├── memory-mgmt.md
    │   ├── processor-api.md
    │   ├── running-app.md
    │   ├── security.md
    │   ├── testing.md
    │   └── write-streams-app.md
    ├── introduction.md
    ├── quickstart.md
    ├── tutorial.md
    └── upgrade-guide.md

Development Workflow

One of the key advantages of using hugo  is its built-in live reload functionality. During content creation and editing, Hugo automatically detects changes in source files and instantly refreshes the browser, providing immediate visual feedback. This rapid feedback loop significantly accelerates the development process, allowing contributors to quickly iterate on their proposals and preview the rendered output in real-time. As soon as a change is saved in the source files, the documentation site in the browser updates, eliminating the need for manual rebuilds and refreshes. This feature drastically improves the efficiency of writing and refining KIP content.

While docsy  provides a rich and well-structured theme for technical documentation, it does have some dependencies to be aware of. docsy  relies on Go for an easier setup, and additionally utilizes Node.js libraries such as autoprefixer and postcss for asset processing and styling. Managing these dependencies and ensuring consistent versions across different developer environments can sometimes introduce friction into the workflow.

To address dependency management and guarantee a uniform development experience for all contributors, I propose a Docker-based development workflow. This approach involves providing a pre-configured Docker container that encapsulates all necessary dependencies for Hugo and Docsy, including Go and Node.js with the required libraries. Developers can then mount their local KIP source code directory into this Docker container.

This Dockerized setup offers a few benefits:

• Consistent Development Environment: Docker ensures that every developer works within an identical environment, eliminating "works on my machine" issues caused by differing dependency versions or operating system configurations.
• Simplified Dependency Management: The Docker image pre-installs and manages all dependencies, removing the burden from individual developers to set up and maintain their local environments. This simplifies onboarding for new contributors and reduces potential compatibility problems.
• Live Reload Support within Docker: Hugo's live reload functionality seamlessly integrates with the Dockerized environment. By mounting the local source directory into the container, Hugo running inside Docker can still monitor file changes and trigger browser refreshes on the host machine, preserving the rapid feedback loop essential for efficient development.

An example of this is in the prototype.

Furthermore, since we do not rely on any server side constructs for serving the website generated by hugo, what the developer sees during development lifecycle is what will be available in production.

Build and Deployment

Leverage hugo  and docsy  toolchain to generate static html website from markdown source. Package the website as a docker container and host it behind existing website serving infrastructure.

...