Remove dapr and k3d (#119)

* remove from text

* fix diagrams

* fix linter

* fix review findings

* fix more

* another fix

.vscode/settings.json

@@ -13,7 +13,6 @@
         "controlplane",
         "COVESA",
         "cppdbg",
-        "Dapr",
         "Databroker",
         "datapoint",
         "datapoints",
@@ -31,7 +30,6 @@
         "gohugoio",
         "grpcio",
         "hediet",
-        "helmignore",
         "hitkodev",
         "hotfixes",
         "hvac",

content/en/docs/concepts/deployment_model/_index.md

@@ -13,8 +13,7 @@ The Velocitas project uses a common deployment model. It uses [OCI-compliant](ht
 The deployment model is guided by the following principles
 
 - Applications are provided as OCI-compliant container images.
-- The container runtime offers a Kubernetes-compatible control plane and API to manage the container lifecycle.
-- Helm charts are used as deployment descriptor specification.
+- The container runtime offers a control plane and API to manage the container lifecycle.
 
 The template projects provided come with a pre-configured developer toolchain that accelerates the development process. The developer toolchain ensures an easy creation through a high-degree of automation of all required artifacts needed to follow the _Velocitas_ principles.
 

content/en/docs/concepts/deployment_model/vehicle_app_releases/_index.md

@@ -43,7 +43,6 @@ The `Build multi-arch image workflow` is triggered on every commit to the main b
 - **Building a multi-arch container for the app** - actions create a containerized version of the _Vehicle App_ for multiple architectures (currently AMD64 and ARM64).
 - **Scanning for vulnerabilities** - actions scan your code and container for vulnerabilities and in case of findings the workflow will be marked as "failed".
 - **Storing container images to GitHub action artifacts** - at the end of the workflow, the container image created is stored in a Github Action Artifacts so that it can be referenced by the Release Workflow later.
-- **Generate Deployment Files** - actions generate a PodSpec-file and HelmCharts to ease the deployment of the _Vehicle App_ and the runtime services.
 
 ## Release Workflow ([release.yml](https://github.com/eclipse-velocitas/vehicle-app-python-template/blob/main/.github/workflows/release.yml))
 
@@ -85,5 +84,3 @@ The release process would be the same as described in the overview, except that
 ## Further information
 
 - Tutorial: [How to write integration tests](/docs/tutorials/vehicle_app_development/integration_tests)
-- Tutorial: [Deploy a _Vehicle App_ with Helm](/docs/tutorials/vehicle_app_deployment/helm_deployment.md)
-- Tutorial: [Deploy a _Vehicle App_ with PodSpecs](/docs/tutorials/vehicle_app_deployment/podspecs_deployment.md)

content/en/docs/concepts/development_model/_index.md

@@ -56,12 +56,13 @@ Asynchronous communication between [_Vehicle Apps_](#vehicle-apps) and other veh
 
 ### Middleware Abstraction
 
-Velocitas provides middleware abstraction interfaces for Service Discovery, PubSub Messaging Protocol and other cross-cutting functionality.
-By default, Velocitas leverages [Dapr](https://dapr.io) for gRPC service discovery, Open Telemetry tracing and the [publish/subscribe building block](https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-overview/).
+Velocitas basically provides middleware abstraction interfaces for service discovery, pubsub messaging, and other cross-cutting functionalites.
+At the moment, Velocitas just offers a (what we call) "native middleware" implementation, which does not provide (gRPC) service discovery. Instead, addresses and port number of services need to be provided via environment variables to an app; e.g. SDV_VEHICLEDATABROKER_ADDRESS=grpc://localhost:55555.
+The support of Dapr as middleware has recently been removed.
 
 ### Vehicle Edge Operating System
 
-[_Vehicle Apps_](#vehicle-apps) are expected to run on a [Linux](https://www.linux.org/)-based operating system. An OCI-compliant container runtime is required to host the _Vehicle App_ containers and the Dapr middleware mandates a Kubernetes control plane. For publish/subscribe messaging a MQTT broker must be available (e.g., [Eclipse Mosquitto](https://mosquitto.org/)).
+[_Vehicle Apps_](#vehicle-apps) are expected to run on a [Linux](https://www.linux.org/)-based operating system. An OCI-compliant container runtime is required to host the _Vehicle App_ containers. For publish/subscribe messaging a MQTT broker must be available (e.g., [Eclipse Mosquitto](https://mosquitto.org/)).
 
 ## _Vehicle App_ Characteristics
 

content/en/docs/concepts/development_model/vehicle_app_manifest/_index.md

@@ -48,7 +48,7 @@ To fully understand the _AppManifest_, let's have a look at **who** interacts wi
 * Description of your applications **functional interfaces**(VehicleModel, services, APIs, ...)
 * Enable **loose coupling** of functional interface descriptions and the Velocitas toolchain. Some parts of the toolchain are responsible for reading the file and acting upon it, depending on the type of functional interface
 * Providing an **extendable** syntax to enable custom functional interface types which may not provided by the Velocitas toolchain itself, but by a third party
-* Providing a **single source of truth** for generation of deployment specifications (i.e. Helm-Charts, Kanto spec, etc...)
+* Providing a **single source of truth** for generation of deployment specifications (i.e. Kanto spec, etc...)
 
 ## Example
 

content/en/docs/concepts/development_model/vehicle_app_sdk/_index.md

@@ -17,7 +17,7 @@ The _Vehicle App_ SDK consists of the following building blocks:
 
 - **[Vehicle Model Ontology](#vehicle-model-ontology):** The SDK provides a set of model base classes for the creation of vehicle models.
 
-- **[Middleware integration](#middleware-integration):** Vehicle Models can contain gRPC stubs to communicate with _Vehicle Services_. gRPC communication is integrated with the [Dapr](https://dapr.io) middleware for service discovery and [OpenTelemetry](https://opentelemetry.io) logging and tracing.
+- **[Middleware integration](#middleware-integration):** Vehicle Models can contain gRPC stubs to communicate with _Vehicle Services_. gRPC communication is integrated natively.
 
 - **[Fluent query & rule construction](#fluent-query--rule-construction):** Based on a concrete Vehicle Model, the SDK is able to generate queries and rules against the KUKSA Data Broker to access the real values of the data points that are defined in the vehicle model.
 
@@ -303,10 +303,6 @@ private:
 {{< /tab >}}
 {{< /tabpane >}}
 
-### Service discovery
-
-The underlying gRPC channel is provided and managed by the `Service` base class of the SDK. It is also responsible for routing the method invocation to the service through the Dapr middleware. As a result, a `dapr-app-id` has to be assigned to every `Service`, so that Dapr can discover the corresponding _Vehicle Services_. This `dapr-app-id` has to be specified as an environment variable named `<service_name>_DAPR_APP_ID`.
-
 ## Fluent query & rule construction
 
 A set of query methods like `get()`, `where()`, `join()` etc. are provided through the `Model` and `DataPoint` base classes. These functions make it possible to construct SQL-like queries and subscriptions in a fluent language, which are then transmitted through the gRPC interface to the KUKSA Data Broker.
@@ -434,7 +430,7 @@ void onSeatPositionChanged(const DataPointMap_t datapoints) {
 
 ## Publish & subscribe messaging
 
-The SDK supports publishing messages to a MQTT broker and subscribing to topics of a MQTT broker. By leveraging the Dapr pub/sub building block for this purpose, the low-level MQTT communication is abstracted away from the _Vehicle App_ developer. Especially the physical address and port of the MQTT broker is no longer configured in the _Vehicle App_ itself, but rather is part of the Dapr configuration, which is outside of the _Vehicle App_.
+The SDK supports publishing messages to a MQTT broker and subscribing to topics of a MQTT broker. Using the Velocitas SDK, the low-level MQTT communication is abstracted away from the _Vehicle App_ developer. Especially the physical address and port of the MQTT broker is no longer configured in the _Vehicle App_ itself, but rather is set as an environment variable, which is outside of the _Vehicle App_.
 
 ### Publish MQTT Messages
 
@@ -474,22 +470,6 @@ subscribeToTopic("seatadjuster/setPosition/request")->onItem([this](auto&& item)
 {{< /tab >}}
 {{< /tabpane >}}
 
-Under the hood, the _Vehicle App_ creates a gRPC endpoint on port `50008`, which is exposed to the Dapr middleware. The Dapr middleware will then subscribe to the MQTT broker and forward the messages to the _Vehicle App_.
-
-To change the app port, set it in the `main()` method of the app:
-
-{{< tabpane langEqualsHeader=true >}}
-{{< tab "Python" >}}
-from sdv import conf
-
-async def main():
-    conf.DAPR_APP_PORT = <your port>
-{{< /tab >}}
-{{< tab "C++" >}}
-// C++ does not use Dapr for Pub/Sub messaging at this point
-{{< /tab >}}
-{{< /tabpane >}}
-
 ## Vehicle App abstraction
 
 _Vehicle Apps_ are inherited from the `VehicleApp` base class. This enables the _Vehicle App_ to use the Publish & Subscribe messaging and to connect to the KUKSA Data Broker.

content/en/docs/concepts/lifecycle_management/packages/usage.md

@@ -17,7 +17,7 @@ Currently, the packages provided by the _Velocitas_ team are the following:
 {{<table "table table-bordered">}}
 | name | description |
 |:--------|:---------------|
-|[devenv-runtimes](https://github.com/eclipse-velocitas/devenv-runtimes)| Containing scripts and configuration for [Local](/docs/tutorials/vehicle_app_runtime/local_runtime/) and [Kubernetes](/docs/tutorials/vehicle_app_runtime/kubernetes_runtime/) Runtime Services |
+|[devenv-runtimes](https://github.com/eclipse-velocitas/devenv-runtimes)| Containing scripts and configuration for [Local](/docs/tutorials/vehicle_app_runtime/local_runtime/) and [Kanto](/docs/tutorials/vehicle_app_runtime/kanto_runtime/) Runtime Services |
 |[devenv-devcontainer-setup](https://github.com/eclipse-velocitas/devenv-devcontainer-setup)| Basic configuration for the devcontainer, like proxy configuration, post create scripts, entry points for the lifecycle management. |
 |[devenv-github-workflows](https://github.com/eclipse-velocitas/devenv-github-workflows)| Containing github workflow files used by velocitas repositories |
 |[devenv-github-templates](https://github.com/eclipse-velocitas/devenv-github-templates)| Containing github templates used by velocitas repositories |

content/en/docs/tutorials/quickstart/quickstart.md

@@ -125,7 +125,7 @@ You can find more information about the _Vehicle App_ development in the [respec
 
 The runtime services (like _KUKSA Data Broker_ or _Vehicle Services_) are required to develop _Vehicle Apps_ and run integration tests.
 
-Currently, the supported options to run these services is either [locally](/docs/tutorials/vehicle_app_runtime/local_runtime), in a [Kubernetes (K3D) cluster](/docs/tutorials/vehicle_app_runtime/kubernetes_runtime) or via the [Kanto runtime](/docs/tutorials/vehicle_app_runtime/kanto_runtime).
+Currently, the supported options to run these services is either [locally](/docs/tutorials/vehicle_app_runtime/local_runtime) or via the [Kanto runtime](/docs/tutorials/vehicle_app_runtime/kanto_runtime).
 
 {{< tabpane text=true >}}
    {{% tab header="Local Runtime" %}}
@@ -154,36 +154,8 @@ To stop the runtime simply press `Ctrl + C`.
 {{% /pageinfo %}}
 
 {{% /tab %}}
-{{% tab header="K3D Runtime" %}}
 
-A VS Code task called `K3D Runtime - Up` is available to start all necessary services in the correct order.
-
-1. Press <kbd>F1</kbd>
-2. Select command `Tasks: Run Task`
-3. Select `K3D Runtime - Up`
-
-You should see the task `K3D Runtime - Up` being executed on a separate VS Code terminal with the following content:
-
-```bash
-$ velocitas exec runtime-k3d up
-
-Hint: Log files can be found in your workspace's logs directory
-> Checking K3D registry... created.
-> Creating cluster with proxy configuration.
-> Checking K3D cluster... created.
-> Checking zipkin deployment... deployed.
-> Checking dapr... initialized.
-✅ Configuring controlplane for k3d...
-> Deploying runtime... installed.
-✅ Starting k3d runtime...
-```
-
-{{% pageinfo color="primary" %}}
-   You need to perform the task `K3D Runtime - Down` to properly stop all runtime activities.
-{{% /pageinfo %}}
-
-{{% /tab %}}
-   {{% tab header="Kanto Runtime" %}}
+{{% tab header="Kanto Runtime" %}}
 
 A VS Code task called `Kanto Runtime - Up` is available to start all necessary services in the correct order.
 

content/en/docs/tutorials/vehicle_app_deployment/_index.md

@@ -5,3 +5,5 @@ weight: 60
 description: >
   Learn how to deploy the _Vehicle App_ to currently supported infrastructure targets.
 ---
+
+See the [Kanto container configuration](https://eclipse.dev/kanto/docs/references/containers/container-config/) for details how to write Kanto deployment files.