This is an automated email from the ASF dual-hosted git repository.
nvollmar pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-pekko-management.git
The following commit(s) were added to refs/heads/main by this push:
new 778ee60 Adapts documentation for Pekko (#35)
778ee60 is described below
commit 778ee60ef963e4e8f53e4483d9ae2af829c45b20
Author: Nicolas Vollmar <[email protected]>
AuthorDate: Thu Mar 2 14:32:32 2023 +0100
Adapts documentation for Pekko (#35)
* Adapts documentation for Pekko
* Adds references for Akka migration guide and sample projects
---
docs/release-train-issue-template.md | 68 ---------------
docs/src/main/paradox/bootstrap/details.md | 8 +-
docs/src/main/paradox/bootstrap/index.md | 40 ++++-----
docs/src/main/paradox/bootstrap/istio.md | 12 +--
docs/src/main/paradox/bootstrap/kubernetes-api.md | 6 +-
docs/src/main/paradox/bootstrap/kubernetes.md | 4 +-
docs/src/main/paradox/bootstrap/local-config.md | 4 +-
docs/src/main/paradox/bootstrap/recipes.md | 36 ++++----
docs/src/main/paradox/cluster-http-management.md | 24 +++---
docs/src/main/paradox/cluster-jmx-management.md | 2 +-
docs/src/main/paradox/discovery/aws.md | 30 +++----
docs/src/main/paradox/discovery/consul.md | 6 +-
docs/src/main/paradox/discovery/index.md | 8 +-
docs/src/main/paradox/discovery/kubernetes.md | 10 +--
docs/src/main/paradox/discovery/marathon.md | 10 +--
docs/src/main/paradox/healthchecks.md | 2 +-
docs/src/main/paradox/index.md | 27 +++---
.../paradox/kubernetes-deployment/deploying.md | 8 +-
.../kubernetes-deployment/forming-a-cluster.md | 32 +++----
.../main/paradox/kubernetes-deployment/index.md | 4 +-
.../preparing-for-production.md | 2 +-
docs/src/main/paradox/kubernetes-lease.md | 10 +--
docs/src/main/paradox/loglevels/log4j2.md | 22 ++---
docs/src/main/paradox/loglevels/logback.md | 22 ++---
docs/src/main/paradox/migration.md | 98 +---------------------
.../{akka-management.md => pekko-management.md} | 28 +++----
integration-test/aws-api-ec2/README.md | 4 +-
integration-test/aws-api-ecs/README.md | 2 +-
.../pekko/cluster/bootstrap/demo/DemoApp.java | 8 +-
.../apache/pekko/cluster/bootstrap/DemoApp.scala | 8 +-
integration-test/marathon-api-docker/README.md | 2 +-
integration-test/marathon-api/README.md | 2 +-
.../org/apache/pekko/management/CodeExamples.java | 4 +-
.../PekkoManagementHttpEndpointSpec.scala | 4 +-
34 files changed, 197 insertions(+), 360 deletions(-)
diff --git a/docs/release-train-issue-template.md
b/docs/release-train-issue-template.md
deleted file mode 100644
index 4e7ebfe..0000000
--- a/docs/release-train-issue-template.md
+++ /dev/null
@@ -1,68 +0,0 @@
-Release Akka Management $VERSION$
-
-<!--
-# Release Train Issue Template for Akka Management
-
-(Liberally copied and adopted from Scala itself
https://github.com/scala/scala-dev/blob/b11cd2e4a4431de7867db6b39362bea8fa6650e7/notes/releases/template.md)
-
-For every release, make a copy of this file named after the release, and
expand the variables.
-Ideally replacing variables could become a script you can run on your local
machine.
-
-Variables to be expanded in this template:
-- $VERSION$=???
--->
-
-### before the release
-
-- [ ] Check that open PRs and issues assigned to the milestone are reasonable
-- [ ] Create a new milestone for the [next
version](https://github.com/akka/akka-management/milestones)
-- [ ] Check [closed issues without a
milestone](https://github.com/akka/akka-management/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aclosed%20no%3Amilestone)
and either assign them the 'upcoming' release milestone or `invalid/not
release-bound`
-
-### Preparing release notes in the documentation / announcement
-
-- For non-patch releases:
- - [ ] Create a news item draft PR on
[akka.github.com](https://github.com/akka/akka.github.com), based on the [draft
release](https://github.com/akka/akka-management/releases) and
[`sbt-authors`](https://github.com/2m/authors) (eg. `./scripts/authors.scala
v1.0.9 HEAD`).
-- [ ] Move all [unclosed
issues](https://github.com/akka/akka-management/issues?q=is%3Aopen+is%3Aissue+milestone%3A$VERSION$)
for this milestone to the next milestone
-- [ ] Close the [$VERSION$
milestone](https://github.com/akka/akka-management/milestones?direction=asc&sort=due_date)
-
-### Cutting the release
-
-- [ ] Wait until the build for the `main` branch finished on GH Actions after
the last merge
-- [ ] `git tag -a v$VERSION$ -m "Release version $VERSION$"; git push --tags`
-- [ ] Check that GitHub Actions release build has executed successfully (it
should publish artifacts to Sonatype and documentation to Gustav)
-
-### Check availability
-
-- [ ] Check [API](https://doc.akka.io/api/akka-management/$VERSION$/)
documentation
-- [ ] Check [reference](https://doc.akka.io/docs/akka-management/$VERSION$/)
documentation
-- [ ] Check the release on [Maven
central](https://repo1.maven.org/maven2/com/lightbend/akka/management/akka-management_2.12/$VERSION$/)
-
-### When everything is on maven central
-
- - `ssh [email protected]`
- - [ ] update the `current` links on `repo.akka.io` to point to the latest
version
- ```
- ln -nsf $VERSION$ www/docs/akka-management/current
- ln -nsf $VERSION$ www/api/akka-management/current
- ```
- - [ ] check changes and commit the new version to the local git repository
- ```
- cd ~/www
- git add docs/akka-management/ api/akka-management/
- git commit -m "Akka Management $VERSION$"
- ```
-
-### Announcements
-
-- [ ] Update the [draft
release](https://github.com/akka/akka-management/releases), either with the
content from the news item, or by revising and adding the
[`sbt-authors`](https://github.com/2m/authors) (eg. `./scripts/authors.scala
v1.0.9 HEAD`) to the generated text. Attach to the tag created earlier, and
publish.
-- [ ] For non-patch releases: Merge draft news item for
[akka.io](https://github.com/akka/akka.github.com)
-- For non-patch releases or for a particularly interesting patch release:
- - [ ] Send a release notification to [Lightbend
discuss](https://discuss.akka.io)
- - [ ] Tweet using the akkateam account (or ask someone to) about the new
release
- - [ ] Announce on [Gitter akka/akka](https://gitter.im/akka/akka)
- - [ ] Announce internally
-
-### Afterwards
-
-- [ ] Update version for [Lightbend Supported
Modules](https://developer.lightbend.com/docs/lightbend-platform/introduction/getting-help/build-dependencies.html#_akka_management)
in [private
project](https://github.com/lightbend/lightbend-technology-intro-doc/blob/master/docs/modules/getting-help/examples/build.sbt#L156)
-- Close this issue
diff --git a/docs/src/main/paradox/bootstrap/details.md
b/docs/src/main/paradox/bootstrap/details.md
index d67dbec..1e3cf28 100644
--- a/docs/src/main/paradox/bootstrap/details.md
+++ b/docs/src/main/paradox/bootstrap/details.md
@@ -3,7 +3,7 @@
Below is a description of the bootstrap process in more detail.
All configuration properties references below are in the
`pekko.management.cluster.bootstrap` section.
-- Each node discovers its "neighbours" using Akka Discovery
+- Each node discovers its "neighbours" using Pekko Discovery
- Some initial negotiation between the nodes must take place to safely
form a new cluster when there is no
existing cluster.
- The node starts to probe the Contact Points of the discovered nodes (which
are HTTP endpoints, exposed via
@@ -39,17 +39,17 @@ presented here is very close to it. Please note that the
often used claim of usi
seed-nodes also is not 100% safe (sic!), since races could occur between the
node having discovered a node from the strongly
consistent store and attempting the join operation.
-Akka bootstrap's solution is prone to very few and rather rare races. Built-in
protection against the race cases exists
+Pekko bootstrap's solution is prone to very few and rather rare races.
Built-in protection against the race cases exists
in the form of the stable timeout, which means that if any changes are being
observed in discovery, the decision making
is delayed until the observation is stable again. This prevents initiating
joining while discovery is still inconsistent.
Note also that the bootstrap process does NOT rely on full consistency of the
discovery mechanism when adding new nodes
to an existing cluster. This is very desirable, since this situation usually
occurs when dynamically scaling up due to
-increased load on your service, and some services may indeed not be fully
consistent then. However, the Akka Cluster
+increased load on your service, and some services may indeed not be fully
consistent then. However, the Pekko Cluster
membership protocol IS strongly consistent, and it is the source of truth with
regards what the cluster is consisting of,
and no external system can have more reliable information about this (since it
could be outdated). This is why the
Contact Point probing mechanism exists, and even if discovery would only
return *partial* or even *different set of nodes
-for each lookup* the probing would allow the node still to join all the right
nodes, thanks to how Akka Cluster's membership
+for each lookup* the probing would allow the node still to join all the right
nodes, thanks to how Pekko Cluster's membership
and gossip protocols work. Summing up, the bootstrap mechanism works well for
adding nodes to the system, even under load,
even if the DNS system is not completely consistent.
diff --git a/docs/src/main/paradox/bootstrap/index.md
b/docs/src/main/paradox/bootstrap/index.md
index c09338c..3de1cee 100644
--- a/docs/src/main/paradox/bootstrap/index.md
+++ b/docs/src/main/paradox/bootstrap/index.md
@@ -8,19 +8,19 @@
@@@
-Akka Cluster Bootstrap helps forming (or joining to) a cluster by using
@ref:[Akka Discovery](../discovery/index.md)
+Pekko Cluster Bootstrap helps forming (or joining to) a cluster by using
@ref:[Pekko Discovery](../discovery/index.md)
to discover peer nodes. It is an alternative to configuring static
`seed-nodes` in dynamic deployment environments
such as on Kubernetes or AWS.
-It builds on the flexibility of Akka Discovery, leveraging a range of
discovery mechanisms depending on the
+It builds on the flexibility of Pekko Discovery, leveraging a range of
discovery mechanisms depending on the
environment you want to run your cluster in.
## Prerequisites
Bootstrap depends on:
- * @ref:[Akka Discovery](../discovery/index.md) to discover other members of
the cluster
- * @ref:[Pekko Management](../akka-management.md) to host HTTP endpoints used
during the bootstrap process
+ * @ref:[Pekko Discovery](../discovery/index.md) to discover other members of
the cluster
+ * @ref:[Pekko Management](../pekko-management.md) to host HTTP endpoints used
during the bootstrap process
A discovery mechanism needs to be chosen. A good default choice is DNS.
@@ -40,17 +40,17 @@ and bootstrap extensions:
value=$pekko.version$
symbol1=PekkoManagementVersion
value1=$project.version$
- group=com.lightbend.akka.management
- artifact=akka-management-cluster-bootstrap_$scala.binary.version$
+ group=org.apache.pekko
+ artifact=pekko-management-cluster-bootstrap_$scala.binary.version$
version=PekkoManagementVersion
group2=org.apache.pekko
artifact2=pekko-discovery_$scala.binary.version$
version2=PekkoVersion
}
-Akka Cluster Bootstrap can be used with Akka $pekko.version$ or later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+Pekko Cluster Bootstrap can be used with Pekko $pekko.version$ or later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
@@ -67,12 +67,12 @@ a later version than $pekko.version$ can be used.
@@@ note
`pekko-discovery` is already a transitive dependency of
`pekko-management-cluster-bootstrap` but it can
-be good to define it explicitly in the build of the application to align the
Akka versions with other
-dependencies from the application. The version must be the same across all
Akka modules, e.g.
+be good to define it explicitly in the build of the application to align the
Pekko versions with other
+dependencies from the application. The version must be the same across all
Pekko modules, e.g.
`pekko-actor`, `pekko-discovery` and `pekko-cluster` must be of the same
version.
-The minimum supported Akka version is $pekko.version$. Use the same Akka
version for `pekko-discovery`
-as for other Akka dependencies in the application. Latest patch version of
Akka is recommended and
+The minimum supported Pekko version is $pekko.version$. Use the same Pekko
version for `pekko-discovery`
+as for other Pekko dependencies in the application. Latest patch version of
Pekko is recommended and
a later version than $pekko.version$ can be used.
@@@
@@ -105,11 +105,11 @@ a good idea to act on such a failure, for example by
logging an error and termin
Ensure that `seed-nodes` is not present in configuration and that either
autoloading through config or `start()` is called on every node.
-The following configuration is required, more details for each and additional
configuration can be found in
[reference.conf](https://github.com/akka/akka-management/blob/master/cluster-bootstrap/src/main/resources/reference.conf):
+The following configuration is required, more details for each and additional
configuration can be found in
[reference.conf](https://github.com/apache/incubator-pekko-management/blob/master/cluster-bootstrap/src/main/resources/reference.conf):
* `pekko.management.cluster.bootstrap.contact-point-discovery.service-name`: a
unique name in the deployment environment for this cluster
instance which is used to lookup peers in service discovery. If unset, it
will be derived from the `ActorSystem` name.
-*
`pekko.management.cluster.bootstrap.contact-point-discovery.discovery-method`:
the intended service discovery mechanism (from what choices Akka Discovery
provides).
+*
`pekko.management.cluster.bootstrap.contact-point-discovery.discovery-method`:
the intended service discovery mechanism (from what choices Pekko Discovery
provides).
If unset, falls back to the system-wide default from
`pekko.discovery.method`.
@@ -130,7 +130,7 @@ See @ref[full bootstrap process and advanced
configuration](details.md) for more
## Joining Mechanism Precedence
-As Akka Cluster allows nodes to join to a cluster using multiple different
methods, the precedence of each method
+As Pekko Cluster allows nodes to join to a cluster using multiple different
methods, the precedence of each method
is strictly defined and is as follows:
- If `pekko.cluster.seed-nodes` (in your `application.conf`) are non-empty,
those nodes will be joined, and bootstrap
@@ -171,7 +171,7 @@ the initial joining, even in face of an flaky discovery
mechanism!
### Recommended Configuration
-When using the bootstrap module, there are some underlying Akka Cluster
settings that should be specified to ensure
+When using the bootstrap module, there are some underlying Pekko Cluster
settings that should be specified to ensure
that your deployment is robust.
Since the target environments for this module are dynamic, that is, instances
can come and go, failure needs to be
@@ -185,7 +185,7 @@ and the operation will (presumably) eventually succeed.
You'll want to specify t
#### Graceful shutdown
-Akka Cluster can handle hard failures using a downing provider such as
Lightbend's split brain resolver discussed below.
+Pekko Cluster can handle hard failures using a downing provider such as
Lightbend's split brain resolver discussed below.
However this should not be relied upon for regular rolling redeploys. Features
such as `ClusterSingleton`s and `ClusterSharding`
can safely restart actors on new nodes far quicker when it is certain that a
node has shutdown rather than crashed.
@@ -197,12 +197,12 @@ Upon receiving a `SIGTERM` Coordinated Shutdown will:
* Perform a `Cluster(system).leave` on itself
* The status of the member will be changed to Exiting while allowing any
shards to be shutdown gracefully and
- `ClusterSingleton`s to be migrated if this was the oldest node. Finally the
node is removed from the Akka Cluster membership.
+ `ClusterSingleton`s to be migrated if this was the oldest node. Finally the
node is removed from the Pekko Cluster membership.
#### Number of nodes to redeploy at once
-Akka bootstrap requires a `stable-period` where service discovery returns a
stable set of contact points. When doing rolling
+Pekko bootstrap requires a `stable-period` where service discovery returns a
stable set of contact points. When doing rolling
updates it is best to wait for a node (or group of nodes) to finish joining
the cluster before adding and removing other nodes.
#### Cluster Singletons
diff --git a/docs/src/main/paradox/bootstrap/istio.md
b/docs/src/main/paradox/bootstrap/istio.md
index 0f4f214..ba95983 100644
--- a/docs/src/main/paradox/bootstrap/istio.md
+++ b/docs/src/main/paradox/bootstrap/istio.md
@@ -1,16 +1,16 @@
# Istio
-[Istio](https://istio.io/) is a service mesh that handles many of the concerns
of service to service communication for you, such as routing, load balancing,
authentication, authorization, and observability. In certain use cases, it can
complement an Akka cluster well. Typically, Akka cluster communication is used
for multiple nodes of the same service to communicate with each other, to
achieve things such as sharding, replication and peer to peer communication,
while a service mesh might [...]
+[Istio](https://istio.io/) is a service mesh that handles many of the concerns
of service to service communication for you, such as routing, load balancing,
authentication, authorization, and observability. In certain use cases, it can
complement an Pekko cluster well. Typically, Pekko cluster communication is
used for multiple nodes of the same service to communicate with each other, to
achieve things such as sharding, replication and peer to peer communication,
while a service mesh mig [...]
-To bootstrap an Akka cluster in Istio, Istio must be configured to allow Akka
cluster communication to bypass the Istio sidecar proxy. Istio's routing design
is made such that services don't need to be aware of each others location, they
just communicate with the proxy, and the mesh figures out how to route and
secure the communication. However, Akka cluster communication is fundamentally
location aware, in order to, for example, route messages to sharded actors.
Hence a service mesh is [...]
+To bootstrap a Pekko cluster in Istio, Istio must be configured to allow Pekko
cluster communication to bypass the Istio sidecar proxy. Istio's routing design
is made such that services don't need to be aware of each others location, they
just communicate with the proxy, and the mesh figures out how to route and
secure the communication. However, Pekko cluster communication is fundamentally
location aware, in order to, for example, route messages to sharded actors.
Hence a service mesh i [...]
-It is important to be aware that since Istio's proxy is bypassed, the Akka
cluster communication will not be secured by Istio using TLS. If you wish to
secure your cluster communication, you will need to configure [Akka remoting
with
mTLS](https://doc.akka.io/docs/akka/current/remoting-artery.html#remote-security)
yourself.
+It is important to be aware that since Istio's proxy is bypassed, the Pekko
cluster communication will not be secured by Istio using TLS. If you wish to
secure your cluster communication, you will need to configure [Akka remoting
with
mTLS](https://doc.akka.io/docs/akka/current/remoting-artery.html#remote-security)
yourself.
-Booting an Akka cluster in Istio requires a minimum Istio version of 1.2.0, as
it requires the outbound port exclusions feature that was added in there. It
also requires using the @ref[Kubernetes API](kubernetes-api.md) contact point
discovery method to be used. The instructions below are for the additional
configuration necessary to ensure an Akka cluster can be bootstrapped in Istio.
+Booting a Pekko cluster in Istio requires a minimum Istio version of 1.2.0, as
it requires the outbound port exclusions feature that was added in there. It
also requires using the @ref[Kubernetes API](kubernetes-api.md) contact point
discovery method to be used. The instructions below are for the additional
configuration necessary to ensure an Akka cluster can be bootstrapped in Istio.
## Allowing outbound communication
-By default, Istio redirects all outbound communication to its proxy. To
prevent it from doing this for Akka cluster communication, both the remoting
and management ports need to be excluded from redirection. This can be done
using the `traffic.sidecar.istio.io/excludeOutboundPorts` annotation in the
deployment pod template. If your remoting port is 2552, and management port is
8558, this can be done like so:
+By default, Istio redirects all outbound communication to its proxy. To
prevent it from doing this for Pekko cluster communication, both the remoting
and management ports need to be excluded from redirection. This can be done
using the `traffic.sidecar.istio.io/excludeOutboundPorts` annotation in the
deployment pod template. If your remoting port is 2552, and management port is
8558, this can be done like so:
```yaml
annotations:
@@ -32,7 +32,7 @@ If you offer any other services on other ports, they can be
added as a comma sep
## Example
-Here is an example deployment spec for an Akka cluster deployed to Istio,
which uses the explicit include inbound ports annotation to ensure that
incoming remoting and management traffic isn't redirected through the proxy:
+Here is an example deployment spec for an Pekko cluster deployed to Istio,
which uses the explicit include inbound ports annotation to ensure that
incoming remoting and management traffic isn't redirected through the proxy:
```yaml
apiVersion: apps/v1
diff --git a/docs/src/main/paradox/bootstrap/kubernetes-api.md
b/docs/src/main/paradox/bootstrap/kubernetes-api.md
index 22c48f7..e7b6151 100644
--- a/docs/src/main/paradox/bootstrap/kubernetes-api.md
+++ b/docs/src/main/paradox/bootstrap/kubernetes-api.md
@@ -1,12 +1,12 @@
# Kubernetes API
-The Kubernetes API can be used to discover peers and form an Akka Cluster. The
`kubernetes-api`
+The Kubernetes API can be used to discover peers and form a Pekko Cluster. The
`kubernetes-api`
mechanism queries the Kubernetes API server to find pods with a given label. A
Kubernetes service isn't required
for the cluster bootstrap but may be used for external access to the
application.
The following Kubernetes resources are created:
-* Deployment: For creating the Akka pods
+* Deployment: For creating the Pekko pods
* Role and RoleBinding to give the pods access to the API server
An example deployment (used for integration testing):
@@ -22,7 +22,7 @@ The User name includes the namespace, this will need updated
for your namespace.
The following configuration is required:
* Set
`pekko.management.cluster.bootstrap.contact-point-discovery.discovery-method`
to `kubernetes-api`
-* Set `pekko.discovery.kubernetes-api.pod-label-selector` to a label selector
that will match the Akka pods e.g. `app=%s`
+* Set `pekko.discovery.kubernetes-api.pod-label-selector` to a label selector
that will match the Pekko pods e.g. `app=%s`
@@snip
[pekko-cluster.yml](/integration-test/kubernetes-api/src/main/resources/application.conf)
{ #discovery-config }
diff --git a/docs/src/main/paradox/bootstrap/kubernetes.md
b/docs/src/main/paradox/bootstrap/kubernetes.md
index 965e6c5..eaa8f50 100644
--- a/docs/src/main/paradox/bootstrap/kubernetes.md
+++ b/docs/src/main/paradox/bootstrap/kubernetes.md
@@ -11,7 +11,7 @@ The project shows how to:
### Internal headless service for bootstrap
-For Akka Cluster / Management use a headless service. This allows the solution
to not be coupled to k8s as well
+For Pekko Cluster / Management use a headless service. This allows the
solution to not be coupled to k8s as well
as there is no use case for load balancing across management/remoting ports.
Set endpoints to be published before readiness checks pass as these endpoints
are required to bootstrap the Cluster
and make the application ready.
@@ -29,7 +29,7 @@ Then to configure your application:
@@snip
[application.conf](/integration-test/kubernetes-dns/src/main/resources/application.conf)
{ #management }
-The same configuration will work for any environment that has an SRV record
for your Akka Clustered application.
+The same configuration will work for any environment that has an SRV record
for your Pekko Clustered application.
For more details on how to configure the Kubernetes deployment see
@ref:[recipes](recipes.md).
diff --git a/docs/src/main/paradox/bootstrap/local-config.md
b/docs/src/main/paradox/bootstrap/local-config.md
index d0d9c2f..b9ca0f4 100644
--- a/docs/src/main/paradox/bootstrap/local-config.md
+++ b/docs/src/main/paradox/bootstrap/local-config.md
@@ -6,7 +6,7 @@ Cluster Bootstrap process run locally within an IDE or from the
command line.
To use `config` service discovery set the following configuration:
*
`pekko.management.cluster.bootstrap.contact-point-discovery.discovery-method`
to `config`
-* `pekko.discovery.config.services.[cluster-name]` to the endpoinds of the
Akka nodes
+* `pekko.discovery.config.services.[cluster-name]` to the endpoinds of the
Pekko nodes
For example:
@@ -14,7 +14,7 @@ For example:
This configuration will return three endpoints for a service called
`local-cluster`.
-Akka bootstrap is then configured to lookup `local-cluster` in the `config`:
+Pekko bootstrap is then configured to lookup `local-cluster` in the `config`:
@@snip
[application.conf](/integration-test/local/src/main/resources/application.conf)
{ #bootstrap }
diff --git a/docs/src/main/paradox/bootstrap/recipes.md
b/docs/src/main/paradox/bootstrap/recipes.md
index 3899d0e..c3b878c 100644
--- a/docs/src/main/paradox/bootstrap/recipes.md
+++ b/docs/src/main/paradox/bootstrap/recipes.md
@@ -1,31 +1,27 @@
# Bootstrap environments
-A set of integration tests projects can be found in [integration-test folder
of the Pekko Management
project](https://github.com/akka/akka-management/tree/master/integration-test).
+A set of integration tests projects can be found in [integration-test folder
of the Pekko Management
project](https://github.com/apache/incubator-pekko-management/tree/master/integration-test).
These test various Pekko management features together in various environments
such as Kubernetes.
-The following samples exist as standalone projects:
+The following samples exist as standalone projects for Akka as a starting
point and can be easily adapted to Pekko:
-* [Akka Cluster bootstrap using the Kubernetes API with
Java/Maven](https://github.com/akka/pekko-sample-cluster-kubernetes-java)
-* [Akka Cluster bootstrap using DNS in
Kubernetes](https://github.com/akka/pekko-sample-cluster-kubernetes-dns-java)
+* [Akka Cluster bootstrap using the Kubernetes API with
Java/Maven](https://github.com/akka/akka-sample-cluster-kubernetes-java)
+* [Akka Cluster bootstrap using DNS in
Kubernetes](https://github.com/akka/akka-sample-cluster-kubernetes-dns-java)
## Local
To run Bootstrap locally without any dependencies such as DNS or Kubernetes
see the @ref[`local` example](local-config.md)
-## Running Akka Cluster in Kubernetes
+## Running Pekko Cluster in Kubernetes
-The goal of bootstrap is to support running Akka Cluster in Kubernetes as if
it is a stateless application.
+The goal of bootstrap is to support running Pekko Cluster in Kubernetes as if
it is a stateless application.
The part bootstrap solves is creating the initial cluster and handling scaling
and re-deploys gracefully.
The recommended approach is to:
* Use a Deployment for creating the pods
* Use either the Kubernetes API or DNS for contact point discovery (details
below)
-* Optionally use a service or ingress for any for traffic coming from outside
of the Akka Cluster e.g. gRPC and HTTP
-
-### Example project
-
-To get started, it might be helpful to have a look at the [Akka Cluster on
Kubernetes](https://developer.lightbend.com/start/?group=akka&project=pekko-sample-cluster-kubernetes-java)
example project.
+* Optionally use a service or ingress for any for traffic coming from outside
of the Pekko Cluster e.g. gRPC and HTTP
### Kubernetes Deployment
@@ -58,20 +54,20 @@ Note that the `app` is the same for both services as they
both refer to the same
### Health checks
`pekko-management` includes a HTTP route for readiness and liveness checks.
-`pekko-management-cluster-http` includes readiness check for the Akka Cluster
membership. To use it
+`pekko-management-cluster-http` includes readiness check for the Pekko Cluster
membership. To use it
add the following dependency:
@@dependency[sbt,Gradle,Maven] {
symbol1=PekkoManagementVersion
value1=$project.version$
- group=com.lightbend.akka.management
- artifact=akka-management-cluster-http_$scala.binary.version$
+ group=org.apache.pekko
+ artifact=pekko-management-cluster-http_$scala.binary.version$
version=PekkoManagementVersion
}
-Akka Cluster HTTP Management can be used with Akka $pekko.version$ or later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+Pekko Cluster HTTP Management can be used with Pekko $pekko.version$ or later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
@@ -105,14 +101,14 @@ on additional resources required and how they work:
* @ref[Kubernetes using `kubernetes-api` discovery](kubernetes-api.md)
* @ref[Kubernetes using `pekko-dns` discovery](kubernetes.md)
-Kubernetes-api is the more battle tested mechanism, DNS was added in Akka
2.5.15 and Pekko Management 0.18.
+Kubernetes-api is the more battle tested mechanism, DNS was added in Pekko
2.5.15 and Pekko Management 0.18.
DNS has the benefit that it is agnostic of Kubernetes so does not require pods
be able to communicate with the API
server. However it requires a headless service that supports the
`publishNotReadyAddresses` feature. If your Kubernetes setup
does not support `publishNotReadyAddresses` yet then use the `kubernetes-api`
discovery mechanism.
### Running in Istio
-For considerations and configuration necessary for bootstrapping an Akka
cluster in Istio, see @ref[Bootstrapping an Akka cluster in Istio](istio.md).
+For considerations and configuration necessary for bootstrapping a Pekko
cluster in Istio, see @ref[Bootstrapping an Pekko cluster in Istio](istio.md).
### Running the Kubernetes demos
@@ -147,7 +143,7 @@ $ sbt shell
You can run multiple different Pekko Bootstrap-based applications in the same
namespace,
alongside any other containers that belong to the same logical application.
-The resources in `kubernetes/pekko-cluster.yml` are configured to run in the
`akka-bootstrap-demo-ns` namespace.
+The resources in `kubernetes/pekko-cluster.yml` are configured to run in the
`pekko-bootstrap-demo-ns` namespace.
Change that to the namespace you want to deploy to. If you do not have a
namespace to run your application in yet,
create it:
diff --git a/docs/src/main/paradox/cluster-http-management.md
b/docs/src/main/paradox/cluster-http-management.md
index 68cd8ca..7ff95bf 100644
--- a/docs/src/main/paradox/cluster-http-management.md
+++ b/docs/src/main/paradox/cluster-http-management.md
@@ -13,23 +13,23 @@ The operations exposed are comparable to the Command Line
Management tool or the
## Dependencies
-The Akka Cluster HTTP Management is a separate jar file.
-Make sure to include it along with the core akka-management library in your
project:
+The Pekko Cluster HTTP Management is a separate jar file.
+Make sure to include it along with the core pekko-management library in your
project:
@@dependency[sbt,Gradle,Maven] {
symbol1=PekkoManagementVersion
value1="$project.version$"
- group=com.lightbend.akka.management
- artifact=akka-management_$scala.binary.version$
+ group=org.apache.pekko
+ artifact=pekko-management_$scala.binary.version$
version=PekkoManagementVersion
- group2=com.lightbend.akka.management
- artifact2=akka-management-cluster-http_$scala.binary.version$
+ group2=org.apache.pekko
+ artifact2=pekko-management-cluster-http_$scala.binary.version$
version2=PekkoManagementVersion
}
-Akka Cluster HTTP Management can be used with Akka $pekko.version$ or later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+Pekko Cluster HTTP Management can be used with Apache Pekko $pekko.version$ or
later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
@@ -45,7 +45,7 @@ a later version than $pekko.version$ can be used.
## Running
-To make sure the Akka Cluster HTTP Management is running, register it with
Pekko Management:
+To make sure the Pekko Cluster HTTP Management is running, register it with
Pekko Management:
Scala
: @@snip
[CompileOnlySpec.scala](/management-cluster-http/src/test/scala/doc/org/apache/pekko/cluster/http/management/CompileOnlySpec.scala)
{ #loading }
@@ -109,7 +109,7 @@ Example request:
Example response:
HTTP/1.1 200 OK
- Server: akka-http/10.2.2
+ Server: pekko-http/1.0.0
Date: Mon, 11 Jan 2021 21:02:37 GMT
Transfer-Encoding: chunked
Content-Type: text/event-stream
@@ -239,7 +239,7 @@ Example response:
## Hosting the routes in an existing Pekko HTTP server
-Starting `AkkaMangement` starts a Pekko HTTP server and hosts the Cluster HTTP
Routes. The routes can also be added
+Starting `PekkoMangement` starts a Pekko HTTP server and hosts the Cluster
HTTP Routes. The routes can also be added
to an existing Pekko HTTP server. To access all the routes:
Scala
diff --git a/docs/src/main/paradox/cluster-jmx-management.md
b/docs/src/main/paradox/cluster-jmx-management.md
index 6487301..76b406f 100644
--- a/docs/src/main/paradox/cluster-jmx-management.md
+++ b/docs/src/main/paradox/cluster-jmx-management.md
@@ -1,4 +1,4 @@
# Built-in JMX Management
-Akka has built-in JMX beans which you can use to manage the cluster, read more
about them in the Akka
+Pekko has built-in JMX beans which you can use to manage the cluster, read
more about them in the Pekko
documentation: @extref:[Cluster Usage:
JMX](pekko:cluster-usage.html#cluster-jmx)
diff --git a/docs/src/main/paradox/discovery/aws.md
b/docs/src/main/paradox/discovery/aws.md
index 5284338..817ea40 100644
--- a/docs/src/main/paradox/discovery/aws.md
+++ b/docs/src/main/paradox/discovery/aws.md
@@ -31,7 +31,7 @@ instead.
You can use tags to simply mark the instances that belong to the same cluster.
Use a tag that
has "service" as the key and set the value equal to the name of your service
(same value as
`pekko.management.cluster.bootstrap.contact-point-discovery.service-name`
-defined in `application.conf`, if you're using this module for bootstrapping
your Akka cluster).
+defined in `application.conf`, if you're using this module for bootstrapping
your Pekko cluster).
Screenshot of two tagged EC2 instances:
@@ -57,9 +57,9 @@ This is a separate JAR file:
version=PekkoManagementVersion
}
-`pekko-discovery-aws-api` can be used with Akka $pekko.version$ or later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+`pekko-discovery-aws-api` can be used with Pekko $pekko.version$ or later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
@@ -105,20 +105,20 @@ character. For example:
}
```
-* By default, this module is configured for clusters with one Akka node per
EC2 instance: it
+* By default, this module is configured for clusters with one Pekko node per
EC2 instance: it
separates cluster members solely by their EC2 IP address. However, we can
change the default configuration to indicate multiple ports per discovered EC2
IP, and achieve
-a setup with multiple Akka nodes (i.e. multiple JVMs) per EC2 instance.
+a setup with multiple Pekko nodes (i.e. multiple JVMs) per EC2 instance.
```
pekko {
discovery {
aws-api-ec2-tag-based {
- ports = [8557, 8558, 8559] # 3 Akka nodes per EC2 instance
+ ports = [8557, 8558, 8559] # 3 Pekko nodes per EC2 instance
# note that the above need to be the ports associated with the
*Pekko Management* extension
}
}
}
```
- Note: this comes with the limitation that each EC2 instance has to have
the same number of Akka nodes.
+ Note: this comes with the limitation that each EC2 instance has to have
the same number of Pekko nodes.
* You can change the default tag key from "service" to something else. This
can be done via `application.conf`, by
setting `pekko.discovery.aws-api-ec2-tag-based.tag-key` to something else.
@@ -129,11 +129,11 @@ setting `pekko.discovery.aws-api-ec2-tag-based.tag-key`
to something else.
* If your service is running in a docker container, you will need to configure
Pekko Management with separate
IPs for binding and discovery. This is because Pekko Management needs to
_bind_ to the internal docker IP,
but will _discover_ the "host" IP (the EC2 private IP) on the AWS API. See
@ref:[Basic
- Configuration](../akka-management.md) on how to separate the bind IP from
the discovery IP.
+ Configuration](../pekko-management.md) on how to separate the bind IP from
the discovery IP.
Demo:
-* A working demo app is available in the
[integration-test](https://github.com/akka/akka-management/tree/master/integration-test/aws-api-ec2)
+* A working demo app is available in the
[integration-test](https://github.com/apache/incubator-pekko-management/tree/master/integration-test/aws-api-ec2)
folder.
@@ -142,7 +142,7 @@ folder.
If you're using ECS with
[awsvpc](https://aws.amazon.com/blogs/compute/introducing-cloud-native-networking-for-ecs-containers/)
mode networking, you can have all task instances of a given ECS service
discover
-each other. If you're using this module for bootstrapping your Akka cluster
that
+each other. If you're using this module for bootstrapping your Pekko cluster
that
you'll do so by setting the value of
`pekko.management.cluster.bootstrap.contact-point-discovery.service-name` to
that of the
ECS service itself.
@@ -262,8 +262,8 @@ Notes:
rules have to be set. See the docs for
[Task Networking with the `awsvpc` Network
Mode](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html).
-* akka-remote by default sets `pekko.remote.netty.tcp.hostname` to the result
of
- `InetAddress.getLocalHost.getHostAddress`, and akka-management does the same
+* pekko-remote by default sets `pekko.remote.netty.tcp.hostname` to the result
of
+ `InetAddress.getLocalHost.getHostAddress`, and pekko-management does the same
for `pekko.management.http.hostname`. However,
`InetAddress.getLocalHost.getHostAddress` throws an exception when running in
awsvpc mode (because the container name cannot be resolved), so you will need
@@ -276,7 +276,7 @@ Notes:
* Because ECS service discovery is only able to discover IP addresses (not
ports
too) you'll need to set
`pekko.management.cluster.bootstrap.contact-point.fallback-port = 8558`,
where
- 8558 is whatever port you choose to bind akka-management to.
+ 8558 is whatever port you choose to bind pekko-management to.
* You can set additional filters to only discover nodes with specific tag
values in
your application.conf file, in the `pekko.discovery.aws-api-ecs-async.tags`
key.
@@ -302,7 +302,7 @@ Notes:
Demo:
* A working demo app is available in the
-
[integration-test](https://github.com/akka/akka-management/tree/master/integration-test/aws-api-ecs)
+
[integration-test](https://github.com/apache/incubator-pekko-management/tree/master/integration-test/aws-api-ecs)
folder. It includes CloudFormation templates with minimal permissions w.r.t
to
IAM policies and security group ingress, and so is a good starting point for
any deployment that integrates the
diff --git a/docs/src/main/paradox/discovery/consul.md
b/docs/src/main/paradox/discovery/consul.md
index 2113b84..3d68125 100644
--- a/docs/src/main/paradox/discovery/consul.md
+++ b/docs/src/main/paradox/discovery/consul.md
@@ -24,9 +24,9 @@ If you are using Consul to do the service discovery this
would allow you to base
version=PekkoManagementVersion
}
-`pekko-discovery-consul` can be used with Akka $pekko.version$ or later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+`pekko-discovery-consul` can be used with Pekko $pekko.version$ or later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
diff --git a/docs/src/main/paradox/discovery/index.md
b/docs/src/main/paradox/discovery/index.md
index 7d0e813..d350452 100644
--- a/docs/src/main/paradox/discovery/index.md
+++ b/docs/src/main/paradox/discovery/index.md
@@ -1,8 +1,8 @@
# Apache Pekko Discovery Methods
-As of version `1.0.0` of Pekko Management @extref:[Akka
Discovery](pekko:discovery/index.html)
-has become a core Akka module. Older versions of Service Discovery from Pekko
Management are not compatible with the
-Akka Discovery module in Akka.
+As of version `1.0.0` of Pekko Management @extref:[Pekko
Discovery](pekko:discovery/index.html)
+has become a core Pekko module. Older versions of Service Discovery from Pekko
Management are not compatible with the
+Pekko Discovery module in Pekko.
Pekko Management contains methods for:
@@ -11,7 +11,7 @@ Pekko Management contains methods for:
* @ref[Marathon](marathon.md)
* @ref[AWS](aws.md)
-The @ref[Kubernetes](kubernetes.md) and @extref:[Akka Discovery
DNS](pekko:discovery/index.html#discovery-method-dns)
+The @ref[Kubernetes](kubernetes.md) and @extref:[Pekko Discovery
DNS](pekko:discovery/index.html#discovery-method-dns)
methods are known to be well used and tested. The others are community
contributions that are not tested as
part of the build and release process.
diff --git a/docs/src/main/paradox/discovery/kubernetes.md
b/docs/src/main/paradox/discovery/kubernetes.md
index bf71565..9d73151 100644
--- a/docs/src/main/paradox/discovery/kubernetes.md
+++ b/docs/src/main/paradox/discovery/kubernetes.md
@@ -20,9 +20,9 @@ First, add the dependency on the component:
version=PekkoManagementVersion
}
-`pekko-discovery-kubernetes-api` can be used with Akka $pekko.version$ or
later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+`pekko-discovery-kubernetes-api` can be used with Pekko $pekko.version$ or
later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
@@ -37,7 +37,7 @@ a later version than $pekko.version$ can be used.
}
As described above, it is uncommon to use the Kubernetes API discovery
-mechanism as your default discovery mechanism. When using it with Akka Cluster
+mechanism as your default discovery mechanism. When using it with Pekko Cluster
Bootstrap, it is sufficient to configure it as described
@ref[here](../bootstrap/kubernetes-api.md).
Otherwise, to load it manually, use `loadServiceDiscovery` on the `Discovery`
extension:
@@ -96,7 +96,7 @@ spec:
image: example/image:1.0.0
imagePullPolicy: IfNotPresent
ports:
- # akka remoting
+ # pekko remoting
- name: remoting
containerPort: 2552
protocol: TCP
diff --git a/docs/src/main/paradox/discovery/marathon.md
b/docs/src/main/paradox/discovery/marathon.md
index 76ca4f0..2865cb3 100644
--- a/docs/src/main/paradox/discovery/marathon.md
+++ b/docs/src/main/paradox/discovery/marathon.md
@@ -33,9 +33,9 @@ This is a separate JAR file:
version=PekkoManagementVersion
}
-`pekko-discovery-marathon-api` can be used with Akka $pekko.version$ or later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+`pekko-discovery-marathon-api` can be used with Pekko $pekko.version$ or later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
@@ -61,14 +61,14 @@ And in your `marathon.json`:
```
{
...
- "cmd": "path-to-your-app -Dpekko.remote.netty.tcp.hostname=$HOST
-Dpekko.remote.netty.tcp.port=$PORT_AKKAREMOTE
-Dpekko.management.http.hostname=$HOST
-Dpekko.management.http.port=$PORT_AKKAMGMTHTTP",
+ "cmd": "path-to-your-app -Dpekko.remote.netty.tcp.hostname=$HOST
-Dpekko.remote.netty.tcp.port=$PORT_PEKKOREMOTE
-Dpekko.management.http.hostname=$HOST
-Dpekko.management.http.port=$PORT_AKKAMGMTHTTP",
"labels": {
"ACTOR_SYSTEM_NAME": "my-system"
},
"portDefinitions": [
- { "port": 0, "name": "akkaremote" },
+ { "port": 0, "name": "pekkoremote" },
{ "port": 0, "name": "pekkomgmthttp" }
]
...
diff --git a/docs/src/main/paradox/healthchecks.md
b/docs/src/main/paradox/healthchecks.md
index bfa645e..5e5f117 100644
--- a/docs/src/main/paradox/healthchecks.md
+++ b/docs/src/main/paradox/healthchecks.md
@@ -23,7 +23,7 @@ A health check must extend
@scala[`Function0[Future[Boolean]]`]@java[`Supplier[C
with a single argument of type `ActorSystem.` A general type is used rather
than a specific interface so that modules such as `pekko-cluster` can
provide health checks without depending on Pekko management.
-Having access to the `ActorSystem` allows loading of any external resource via
an Akka extension e.g. `Cluster` or a database connection. Health checks
+Having access to the `ActorSystem` allows loading of any external resource via
a Pekko extension e.g. `Cluster` or a database connection. Health checks
return a @scala[`Future`]@java[`CompletionStage`] so that an asynchronous
action can be taken.
Scala
diff --git a/docs/src/main/paradox/index.md b/docs/src/main/paradox/index.md
index 0d7aaa0..24142d0 100644
--- a/docs/src/main/paradox/index.md
+++ b/docs/src/main/paradox/index.md
@@ -1,38 +1,37 @@
# Apache Pekko Management
-Pekko Management is a suite of tools for operating Akka Clusters.
-The current version may only be used with Akka 2.6.
+Pekko Management is a suite of tools for operating Pekko Clusters.
## Overview
Pekko Management consists of multiple modules:
- * @ref[akka-management](akka-management.md) is the base module that provides
an extensible HTTP management endpoint for Pekko management tools as well a
@ref[pluggable health check mechanism](healthchecks.md).
- * @ref[pekko-cluster-bootstrap](bootstrap/index.md) helps bootstrapping an
Akka cluster using @extref:[Akka Discovery](pekko:discovery/index.html).
- * @ref[akka-management-cluster-http](cluster-http-management.md) is a module
that provides HTTP endpoints for introspecting and managing Akka clusters.
+ * @ref[pekko-management](pekko-management.md) is the base module that
provides an extensible HTTP management endpoint for Pekko management tools as
well a @ref[pluggable health check mechanism](healthchecks.md).
+ * @ref[pekko-cluster-bootstrap](bootstrap/index.md) helps bootstrapping a
Pekko cluster using @extref:[Pekko Discovery](pekko:discovery/index.html).
+ * @ref[pekko-management-cluster-http](cluster-http-management.md) is a module
that provides HTTP endpoints for introspecting and managing Pekko clusters.
* @ref[kubernetes-lease](kubernetes-lease.md) a lease backed by Kubernetes
API server.
- As well as @extref:[Akka Discovery](pekko:discovery/index.html) methods for:
+ As well as @extref:[Pekko Discovery](pekko:discovery/index.html) methods for:
* @ref[Kubernetes API](discovery/kubernetes.md)
* @ref[Consul](discovery/consul.md)
* @ref[Marathon API](discovery/marathon.md)
* @ref[AWS](discovery/aws.md)
-Various parts of Pekko management can be used together for deploying Akka
Cluster applications to Kubernetes.
+Various parts of Pekko management can be used together for deploying Pekko
Cluster applications to Kubernetes.
- * @ref[Deploying Akka Cluster to Kubernetes](kubernetes-deployment/index.md)
+ * @ref[Deploying Pekko Cluster to Kubernetes](kubernetes-deployment/index.md)
@@@ index
- [Deploy guide for Kubernetes](kubernetes-deployment/index.md)
- - [Pekko Management](akka-management.md)
+ - [Pekko Management](pekko-management.md)
- [Migrating from older versions](migration.md)
- [Health Checks](healthchecks.md)
- - [Akka Cluster Bootstrap](bootstrap/index.md)
- - [Akka Discovery Methods](discovery/index.md)
- - [Akka Cluster Management (HTTP)](cluster-http-management.md)
- - [Akka Cluster Management (JMX)](cluster-jmx-management.md)
+ - [Pekko Cluster Bootstrap](bootstrap/index.md)
+ - [Pekko Discovery Methods](discovery/index.md)
+ - [Pekko Cluster Management (HTTP)](cluster-http-management.md)
+ - [Pekko Cluster Management (JMX)](cluster-jmx-management.md)
- [Dynamic Log Levels](loglevels/index.md)
- - [Akka Coordination Lease for Kubernetes](kubernetes-lease.md)
+ - [Pekko Coordination Lease for Kubernetes](kubernetes-lease.md)
@@@
diff --git a/docs/src/main/paradox/kubernetes-deployment/deploying.md
b/docs/src/main/paradox/kubernetes-deployment/deploying.md
index 259fdda..e8317c1 100644
--- a/docs/src/main/paradox/kubernetes-deployment/deploying.md
+++ b/docs/src/main/paradox/kubernetes-deployment/deploying.md
@@ -13,7 +13,7 @@ Having configured a DeploymentSpec, Role, and RoleBinding
they can be created wi
kubectl apply -f kubernetes/pekko-cluster.yaml
```
-Where akka `kubernetes/pekko-cluster.yaml` is location of the Kubernetes
resources files in the samples.
+Where Pekko `kubernetes/pekko-cluster.yaml` is location of the Kubernetes
resources files in the samples.
@@@note
If you haven't been creating the files as you go for the guide, but rather are
relying on the existing
@@ -100,7 +100,7 @@ An explanation of these messages is as follows.
1. These are init messages, showing that remoting has started on port 25520.
The IP address should be the pods IP address from which other pods can access
it, while the port number should match the configured remoting number,
defaulting to 25520.
2. Init messages for Pekko management, once again, the IP address should be
the pods IP address, while the port number should be the port number you've
configured for Pekko management to use, defaulting to 8558.
Pekko management is also hosting the readiness and liveness checks.
-3. Now the cluster bootstrap process is starting. The service name should
match your Akka system name or configured service name in cluster bootstrap,
and the port should match your configured port name. In this guide we kept
these as the default values.
+3. Now the cluster bootstrap process is starting. The service name should
match your Pekko system name or configured service name in cluster bootstrap,
and the port should match your configured port name. In this guide we kept
these as the default values.
This and subsequent messages will be repeated many times as cluster
bootstrap polls Kubernetes and the other pods to determine what pods have been
started, and whether and where a cluster has been formed.
4. This is the disocvery process. The bootstarp coordinator uses the
Kubernetes discovery mechanism. The label selector should be one that will
return your pods, and the namespace should match your applications namespace.
The namespace is picked up automatically.
5. Here the Kubernetes API has returned three services, including ourselves.
@@ -109,7 +109,7 @@ An explanation of these messages is as follows.
Following these messages, you may still see some messages warning that
messages can't be routed, it still may take some time for cluster singletons
and other cluster features to decide which pod to start up on, but before long,
the logs should go quiet as the cluster is started up.
-The logs above show those of a pod that wasn't the pod to start the cluster.
As mentioned earlier, the default strategy that Akka Cluster Bootstrap uses
when it starts and finds that there is no existing cluster is to get the pod
with the lowest IP address to start the cluster. In the example above, that pod
has an IP address of `172.17.0.6`,
+The logs above show those of a pod that wasn't the pod to start the cluster.
As mentioned earlier, the default strategy that Pekko Cluster Bootstrap uses
when it starts and finds that there is no existing cluster is to get the pod
with the lowest IP address to start the cluster. In the example above, that pod
has an IP address of `172.17.0.6`,
and ends up joining a pod with IP `172.17.0.5` as it has a lower IP.
If you look in the logs of that pod, you'll see a message like this:
@@ -150,7 +150,7 @@ for 'hello world':
kubectl expose deployment appka --type=LoadBalancer --name=appka-service
-You can inspect the Akka Cluster membership status with the [Cluster HTTP
Management](https://doc.akka.io/docs/akka-management/current/cluster-http-management.html).
+You can inspect the Pekko Cluster membership status with the [Cluster HTTP
Management](https://doc.akka.io/docs/akka-management/current/cluster-http-management.html).
curl http://127.0.0.1:8558/cluster/members/
diff --git a/docs/src/main/paradox/kubernetes-deployment/forming-a-cluster.md
b/docs/src/main/paradox/kubernetes-deployment/forming-a-cluster.md
index 5cae478..464e4b9 100644
--- a/docs/src/main/paradox/kubernetes-deployment/forming-a-cluster.md
+++ b/docs/src/main/paradox/kubernetes-deployment/forming-a-cluster.md
@@ -1,50 +1,50 @@
-# Forming an Akka Cluster
+# Forming an Pekko Cluster
-Services that use Akka Cluster have additional requirements over stateless
applications.
+Services that use Pekko Cluster have additional requirements over stateless
applications.
To form a cluster, each pod needs to know which other pods have been deployed
as part of that service,
-so that they can connect to each other. Akka provides a Cluster Bootstrap
library that allows Akka applications in Kubernetes to
+so that they can connect to each other. Pekko provides a Cluster Bootstrap
library that allows Pekko applications in Kubernetes to
discover this automatically using the Kubernetes API. The process is roughly
as follows:
1. When the application starts, the application polls the Kubernetes API to
find what pods are deployed,
until a configured minimum number of pods have been discovered.
-2. It then attempts to connect to those pods, using Akka's HTTP management
interface, and queries whether any of those pods have already formed a cluster.
+2. It then attempts to connect to those pods, using Pekko's HTTP management
interface, and queries whether any of those pods have already formed a cluster.
3. If a cluster has already been formed, then the application will join the
cluster.
4. If a cluster has not yet been formed on any of the pods, a deterministic
function is used to decide which pod will initiate the cluster -
this function ensures that all pods that are currently going through this
process will decide on the same pod.
5. The pod that is decided to start the cluster forms a cluster with itself.
6. The remaining pods poll that pod until it reports that it has formed a
cluster, they then join it.
-For a much more detailed description of this process, see the [Akka Cluster
Bootstrap
documentation](https://developer.lightbend.com/docs/akka-management/current/bootstrap/details.html).
+For a much more detailed description of this process, see the [Pekko Cluster
Bootstrap
documentation](https://developer.lightbend.com/docs/akka-management/current/bootstrap/details.html).
## Bootstrap and Management dependencies
Add the following dependencies to your application:
* Pekko Management Cluster HTTP: This provides HTTP management endpoints as
well as a @ref[cluster health
check](../cluster-http-management.md#health-checks)
-* @ref[Akka Discovery Kubernetes](../discovery/kubernetes.md): This provides a
discovery mechanism that queries the Kubernetes API
+* @ref[Pekko Discovery Kubernetes](../discovery/kubernetes.md): This provides
a discovery mechanism that queries the Kubernetes API
* @ref[Pekko Bootstrap](../bootstrap/index.md): This bootstraps the cluster
from nodes discovered via the Kubernetes API
@@dependency[sbt,Gradle,Maven] {
symbol1=PekkoManagementVersion
value1=$project.version$
- group=com.lightbend.akka.management
- artifact=akka-management-cluster-http_$scala.binary.version$
+ group=org.apache.pekko
+ artifact=pekko-management-cluster-http_$scala.binary.version$
version=PekkoManagementVersion
- group2=com.lightbend.akka.management
- artifact2=akka-management-cluster-bootstrap_$scala.binary.version$
+ group2=org.apache.pekko
+ artifact2=pekko-management-cluster-bootstrap_$scala.binary.version$
version2=PekkoManagementVersion
- group3="com.lightbend.pekko.discovery"
+ group3="org.apache.pekko"
artifact3="pekko-discovery-kubernetes-api_$scala.binary.version$"
version3=PekkoManagementVersion
}
## Configuring Cluster Bootstrap
-There are three components that need to be configured: Akka Cluster, Pekko
Management HTTP, and Akka Cluster Bootstrap.
+There are three components that need to be configured: Pekko Cluster, Pekko
Management HTTP, and Pekko Cluster Bootstrap.
### Apache Pekko Cluster
-Set three things for Akka Cluster:
+Set three things for Pekko Cluster:
* Set the actor provider to `cluster`.
* Shutdown if cluster formation doesn't work. This will cause Kubernetes to
re-create the pod.
@@ -69,7 +69,7 @@ The default configuration for Pekko management HTTP is
suitable for use in Kuber
### Apache Pekko Cluster Bootstrap
To configure Cluster Bootstrap, we need to tell it which discovery method will
be used to discover the other nodes in the cluster.
-This uses Akka Discovery to find nodes, however, the discovery method and
configuration used in Cluster Bootstrap will often be different
+This uses Pekko Discovery to find nodes, however, the discovery method and
configuration used in Cluster Bootstrap will often be different
to the method used for looking up other services. The reason for this is that
during Cluster Bootstrap, we are interested in discovering
nodes even when they aren't ready to handle requests yet, for example, because
they too are trying to form a cluster. If we were to use a
method such as DNS to lookup other services, the Kubernetes DNS server, by
default, will only return services that are ready to serve requests,
@@ -89,7 +89,7 @@ pekko.management {
}
```
-You can optionally specify a `service-name` otherwise the name of the
AkkaSystem is used that matches your label in the deployment spec.
+You can optionally specify a `service-name` otherwise the name of the
PekkoSystem is used that matches your label in the deployment spec.
## Starting
@@ -106,7 +106,7 @@ Java
## Role-Based Access Control
By default, pods are unable to use the Kubernetes API because they are not
authenticated to do so.
-In order to allow the applications pods to form an Akka Cluster using the
Kubernetes API, we need to define some Role-Based Access Control (RBAC) roles
and bindings.
+In order to allow the applications pods to form an Pekko Cluster using the
Kubernetes API, we need to define some Role-Based Access Control (RBAC) roles
and bindings.
RBAC allows the configuration of access control using two key concepts, roles,
and role bindings. A role is a set of permissions to access something
in the Kubernetes API. For example, a `pod-reader` role may have permission to
perform the `list`, `get` and `watch` operations on the `pods` resource in a
particular namespace, by default the same namespace that the role is configured
in. In fact, that's exactly what we are going to configure, as this is the
permission that our pods need. Here's the spec for the `pod-reader` role to be
added in `kubernetes/pekko-cluster.yaml`:
diff --git a/docs/src/main/paradox/kubernetes-deployment/index.md
b/docs/src/main/paradox/kubernetes-deployment/index.md
index 6bb0bb6..447bf1c 100644
--- a/docs/src/main/paradox/kubernetes-deployment/index.md
+++ b/docs/src/main/paradox/kubernetes-deployment/index.md
@@ -1,10 +1,10 @@
-# Deploying Akka Cluster to Kubernetes
+# Deploying Pekko Cluster to Kubernetes
[Akka Cloud
Platform](https://developer.lightbend.com/docs/akka-platform-guide/deployment/index.html)
is the easiest way to deploy an Akka Cluster application to Amazon Elastic
Kubernetes Service (EKS) or Google Kubernetes Engine (GKE).
Alternatively, you can deploy to Kubernetes according to this guide, but that
requires more expertise of Kubernetes.
-For this guide we will be using the Akka Cluster in Kubernetes sample.
+For this guide we will be using the Pekko Cluster in Kubernetes sample.
It is available for both:
*
[Java](https://developer.lightbend.com/start/?group=akka&project=pekko-sample-cluster-kubernetes-java)
diff --git
a/docs/src/main/paradox/kubernetes-deployment/preparing-for-production.md
b/docs/src/main/paradox/kubernetes-deployment/preparing-for-production.md
index c9435df..a406d99 100644
--- a/docs/src/main/paradox/kubernetes-deployment/preparing-for-production.md
+++ b/docs/src/main/paradox/kubernetes-deployment/preparing-for-production.md
@@ -3,7 +3,7 @@
In preparation for production, we need to do two main things:
1. Write a Kubernetes deployment spec
-1. Configure our Akka cluster application
+1. Configure our Pekko cluster application
The final configuration file and deployment spec are in the sample application.
In this guide we will show snippets. Locations of the samples:
diff --git a/docs/src/main/paradox/kubernetes-lease.md
b/docs/src/main/paradox/kubernetes-lease.md
index a848396..c28d6e4 100644
--- a/docs/src/main/paradox/kubernetes-lease.md
+++ b/docs/src/main/paradox/kubernetes-lease.md
@@ -7,7 +7,7 @@ The API, configuration and behavior may change based on
feedback from initial us
@@@
-This module is an implementation of an [Akka Coordination
Lease](https://doc.akka.io/docs/akka/current/coordination.html#lease) backed
+This module is an implementation of a [Pekko Coordination
Lease](https://pekko.apache.org/docs/pekko/current/coordination.html#lease)
backed
by a [Custom Resource Definition
(CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
in Kubernetes.
Resources in Kubernetes offer [concurrency control and
consistency](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
that have been used to build a distributed lease/lock.
@@ -23,8 +23,8 @@ and its backing `etcd` cluster can also be subject to failure
and network issues
### Lease Instances
-* With @extref[Split Brain Resolver](pekko:split-brain-resolver.html#lease)
there will be one lease per Akka Cluster
-* With multiple Akka Clusters using SBRs in the same namespace, e.g. multiple
Lagom
+* With @extref[Split Brain Resolver](pekko:split-brain-resolver.html#lease)
there will be one lease per Pekko Cluster
+* With multiple Pekko Clusters using SBRs in the same namespace, e.g. multiple
Lagom
applications, you must ensure different `ActorSystem` names because they all
need a separate lease.
* With Cluster Sharding and Cluster Singleton there will be more leases
- For @extref:[Cluster
Singleton](pekko:typed/cluster-singleton.html#lease) there will be one per
singleton.
@@ -37,7 +37,7 @@ applications, you must ensure different `ActorSystem` names
because they all nee
@@dependency[sbt,Maven,Gradle] {
symbol1=PekkoManagementVersion
value1=$project.version$
- group="com.lightbend.akka.management"
+ group="org.apache.pekko"
artifact="pekko-lease-kubernetes_$scala.binary.version$"
version=PekkoManagementVersion
}
@@ -89,7 +89,7 @@ roleRef:
This defines a `Role` that is allowed to `get`, `create` and `update` lease
objects and a `RoleBinding`
that gives the default service user this role in `<YOUR NAMESPACE>`.
-Future versions may also require `delete` access for cleaning up old
resources. Current uses within Akka
+Future versions may also require `delete` access for cleaning up old
resources. Current uses within Pekko
only create a single lease so cleanup is not an issue.
To avoid giving an application the access to create new leases an empty lease
can be created in the same namespace as the application with:
diff --git a/docs/src/main/paradox/loglevels/log4j2.md
b/docs/src/main/paradox/loglevels/log4j2.md
index 1081b57..6376f22 100644
--- a/docs/src/main/paradox/loglevels/log4j2.md
+++ b/docs/src/main/paradox/loglevels/log4j2.md
@@ -6,22 +6,22 @@ Dynamic Log Levels for Log4j2 hooks into Pekko Management and
provides a route w
@@project-info{ projectId="management-loglevels-log4j2" }
-Requires @ref:[Pekko Management](../akka-management.md) and that the
application uses [Log4j2](https://logging.apache.org/log4j/2.x/) as logging
backend.
+Requires @ref:[Pekko Management](../pekko-management.md) and that the
application uses [Log4j2](https://logging.apache.org/log4j/2.x/) as logging
backend.
@@dependency[sbt,Gradle,Maven] {
symbol1=PekkoManagementVersion
value1=$project.version$
- group=com.lightbend.akka.management
- artifact=akka-management-loglevels-log4j2_$scala.binary.version$
+ group=org.apache.pekko
+ artifact=pekko-management-loglevels-log4j2_$scala.binary.version$
version=PekkoManagementVersion
- group2=com.lightbend.akka.management
- artifact2=akka-management_$scala.binary.version$
+ group2=org.apache.pekko
+ artifact2=pekko-management_$scala.binary.version$
version2=PekkoManagementVersion
}
-Pekko Management and `pekko-management-loglevels-log4j2` can be used with Akka
$pekko.version$ or later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+Pekko Management and `pekko-management-loglevels-log4j2` can be used with
Pekko $pekko.version$ or later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
@@ -59,15 +59,15 @@ For example using curl:
curl -X PUT
"http://127.0.0.1:8558/loglevel/log4j2?logger=com.example.MyActor&level=DEBUG";
```
-#### Classic and Internal Akka Logger Level
+#### Classic and Internal Pekko Logger Level
-Internal Akka actors and classic Akka does logging through the built in API
there is an [additional level of
filtering](https://doc.akka.io/docs/akka/current/logging.html#slf4j) using the
+Internal Pekko actors and classic Pekko does logging through the built in API
there is an [additional level of
filtering](https://doc.akka.io/docs/akka/current/logging.html#slf4j) using the
`pekko.loglevel` setting. If you have not set `pekko.loglevel` to `DEBUG`
(recommended) log entries from the classic logging API may never reach the
logger backend at all.
The current level configured with `pekko.loglevel` can be inspected with a GET
request to `loglevel/pekko`.
If management `read-only` is set to `false` PUT requests to
`loglevel/pekko?level=[level name]` will dynamically change that.
-Note that the allowed level for Akka Classic logging is a subset of the
loglevels supported by SLF4j, valid values are `OFF`, `DEBUG`, `INFO`,
`WARNING` and `ERROR`.
+Note that the allowed level for Pekko Classic logging is a subset of the
loglevels supported by SLF4j, valid values are `OFF`, `DEBUG`, `INFO`,
`WARNING` and `ERROR`.
For example using curl:
diff --git a/docs/src/main/paradox/loglevels/logback.md
b/docs/src/main/paradox/loglevels/logback.md
index a3fcb2a..22bffee 100644
--- a/docs/src/main/paradox/loglevels/logback.md
+++ b/docs/src/main/paradox/loglevels/logback.md
@@ -6,22 +6,22 @@ Dynamic Log Levels for Logback hooks into Pekko Management
and provides a route
@@project-info{ projectId="management-loglevels-logback" }
-Requires @ref:[Pekko Management](../akka-management.md) and that the
application uses [Logback](http://logback.qos.ch) as logging backend.
+Requires @ref:[Pekko Management](../pekko-management.md) and that the
application uses [Logback](http://logback.qos.ch) as logging backend.
@@dependency[sbt,Gradle,Maven] {
symbol1=PekkoManagementVersion
value1=$project.version$
- group=com.lightbend.akka.management
- artifact=akka-management-loglevels-logback_$scala.binary.version$
+ group=org.apache.pekko
+ artifact=pekko-management-loglevels-logback_$scala.binary.version$
version=PekkoManagementVersion
- group2=com.lightbend.akka.management
- artifact2=akka-management_$scala.binary.version$
+ group2=org.apache.pekko
+ artifact2=pekko-management_$scala.binary.version$
version2=PekkoManagementVersion
}
-Pekko Management and `pekko-management-loglevels-logback` can be used with
Akka $pekko.version$ or later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+Pekko Management and `pekko-management-loglevels-logback` can be used with
Pekko $pekko.version$ or later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
@@ -59,15 +59,15 @@ For example using curl:
curl -X PUT
"http://127.0.0.1:8558/loglevel/logback?logger=com.example.MyActor&level=DEBUG";
```
-#### Classic and Internal Akka Logger Level
+#### Classic and Internal Pekko Logger Level
-Internal Akka actors and classic Akka does logging through the built in API
there is an [additional level of
filtering](https://doc.akka.io/docs/akka/current/logging.html#slf4j) using the
+Internal Pekko actors and classic Pekko does logging through the built in API
there is an [additional level of
filtering](https://doc.akka.io/docs/akka/current/logging.html#slf4j) using the
`pekko.loglevel` setting. If you have not set `pekko.loglevel` to `DEBUG`
(recommended) log entries from the classic logging API may never reach the
logger backend at all.
The current level configured with `pekko.loglevel` can be inspected with a GET
request to `loglevel/pekko`.
If management `read-only` is set to `false` PUT requests to
`loglevel/pekko?level=[level name]` will dynamically change that.
-Note that the allowed level for Akka Classic logging is a subset of the
loglevels supported by SLF4j, valid values are `OFF`, `DEBUG`, `INFO`,
`WARNING` and `ERROR`.
+Note that the allowed level for Pekko Classic logging is a subset of the
loglevels supported by SLF4j, valid values are `OFF`, `DEBUG`, `INFO`,
`WARNING` and `ERROR`.
For example using curl:
diff --git a/docs/src/main/paradox/migration.md
b/docs/src/main/paradox/migration.md
index 8f29e34..91d1a9e 100644
--- a/docs/src/main/paradox/migration.md
+++ b/docs/src/main/paradox/migration.md
@@ -3,101 +3,11 @@
## 1.0
Version requirements:
+* Pekko 1.0 later
+* Pekko HTTP 1.0 or later
-* Akka 2.5.19 or later
-* Pekko HTTP 10.1.7 or later
-
-### Source changes
-
-* `PekkoManagement` moved to package
`org.apache.pekko.management.scaladsl.PekkoManagement`, if using from Java use
`org.apache.pekko.management.javadsl.PekkoManagement`
-* If implementing custom ManagementRouteProvider the package changed to
`org.apache.pekko.management.scaladsl.ManagementRouteProvider`/`org.apache.pekko.management.javadsl.ManagementRouteProvider`
-* `PekkoManagement.start` and `PekkoManagement.routes` may throw
IllegalArgumentException instead of returning Try
-* Auth and HTTPS has changed by using overloaded methods of
`PekkoManagement.start` and `PekkoManagement.routes`, see the @ref[docs for
more details](akka-management.md#enabling-basic-authentication)
-
-### Configuration changes
-
-* `org.apache.pekko.management.cluster.http.healthcheck.ready-states` moved to
`org.apache.pekko.management.cluster.health-check.ready-states`
-* `org.apache.pekko.management.cluster.bootstrap.form-new-cluster` renamed to
`org.apache.pekko.management.cluster.bootstrap.new-cluster-enabled`
-
-#### route-providers
-
-`org.apache.pekko.management.cluster.route-providers` changed from being a
list of fully qualified class names to
-a configuration object `org.apache.pekko.management.cluster.routes` with named
route providers. The reason for the
-change was to be able to exclude a route provider that was included by a
library (from reference.conf) by
-using `""` or `null` as the FQCN of the named entry, for example:
-
-```
-pekko.management.http.routes {
- health-checks = ""
-}
-```
-
-By default the `org.apache.pekko.management.HealthCheckRoutes` is enabled.
-
-### Apache Pekko Discovery
-
-For Pekko Management version 1.0 Service Discovery as well as the config, DNS
and aggregate discovery methods
-were made core Akka module. The following steps are required when upgrading to
1.0 of Pekko Management.
-
-Remove dependencies for:
-
-@@dependency[sbt,Gradle,Maven] {
- group="com.lightbend.pekko.discovery"
- artifact="pekko-discovery"
- version="old_akka_management_version"
- group2="com.lightbend.pekko.discovery"
- artifact2="pekko-discovery-dns"
- version2="old_akka_management_version"
- group3="com.lightbend.pekko.discovery"
- artifact3="pekko-discovery-config"
- version3="old_akka_management_version"
- group4="com.lightbend.pekko.discovery"
- artifact4="pekko-discovery-aggregate"
- version4="old_akka_management_version"
-}
-
-If using Cluster Bootstrap the new dependency will be brought in automatically.
-If using Service Discovery directly add the following dependency:
-
-@@dependency[sbt,Gradle,Maven] {
- group="org.apache.pekko"
- artifact="pekko-discovery"
- version="latest_akka_version"
-}
-
-Setting the service discovery method now has to be the unqualified name e.g
`kubernetes-api` rather than `pekko.discovery.kubernets-api`.
-If using a custom discovery method the configuration for the discovery method
must live under `pekko.discovery`.
-
-For bootstrap it is recommended to set the service discovery method via
`org.apache.pekko.management.cluster.bootstrap.contact-point-discovery.discovery-method`
-rather then overriding the global service discovery mechanism with
`pekko.discovery.method`
-
-### DNS
-
-If using DNS service discovery it is no longer required to override the global
Akka DNS resolver. Remove `akka.io.dns.resolver = async-dns` from your
configuration
-to avoid setting the `async-dns` as the global DNS resolver as it still lacks
some features. The DNS discovery mechanism now uses an isolated resolver
internally
-to support SRV records.
-
-### Kubernetes
-
-Kubernetes service discovery now automatically picks up the namespace at
runtime. If previously hard coded or an environment variable used this can be
removed
-from configuration and the deployment.
-
-Unless used for something other than service discovery / bootstrap the
following can be removed from your deployment
-
-```
-- name: NAMESPACE
- valueFrom:
- fieldRef:
- fieldPath: metadata.namespace
-```
-
-If `pod-namespace` is set remove from your configuration as it will be
automatically picked up from the
`/var/run/secrets/kubernetes.io/serviceaccount/namespace` file
-that is mounted to each Kubernetes container. The namespace can be overridden
with `pod-namespace` if this isn't the desired behavior.
-
-### Cluster HTTP
-
-The `cluster-http` module now only exposes read only routes by default. To
enable destructive operations such as downing members
-set `pekko.management.http.route-providers-read-only` to `false.
+When migrating from Akka Management it is recommended to first upgrade to Akka
2.6.20 / Akka Management 1.1.4 before switching to Pekko/Pekko Management.
+Please refer to the [Akka Management migration
guide](https://doc.akka.io/docs/akka-management/current/migration.html).
diff --git a/docs/src/main/paradox/akka-management.md
b/docs/src/main/paradox/pekko-management.md
similarity index 91%
rename from docs/src/main/paradox/akka-management.md
rename to docs/src/main/paradox/pekko-management.md
index edb8aca..e75c759 100644
--- a/docs/src/main/paradox/akka-management.md
+++ b/docs/src/main/paradox/pekko-management.md
@@ -1,6 +1,6 @@
# Apache Pekko Management
-Pekko Management is the core module of the management utilities which provides
a central HTTP endpoint for Akka
+Pekko Management is the core module of the management utilities which provides
a central HTTP endpoint for Pekko
management extensions.
## Project Info
@@ -17,7 +17,7 @@ actually want to use (and load) in their project.
@@dependency[sbt,Gradle,Maven] {
symbol1=PekkoManagementVersion
value1="$project.version$"
- group="com.lightbend.akka.management"
+ group="org.apache.pekko"
artifact="pekko-management_$scala.binary.version$"
version=PekkoManagementVersion
}
@@ -26,9 +26,9 @@ And in addition to that, include all of the dependencies for
the features you'd
like `pekko-management-bootstrap` etc. Refer to each extensions documentation
page to learn about how
to configure and use it.
-Pekko Management can be used with Akka $pekko.version$ or later.
-You have to override the following Akka dependencies by defining them
explicitly in your build and
-define the Akka version to the one that you are using. Latest patch version of
Akka is recommended and
+Pekko Management can be used with Apache Pekko $pekko.version$ or later.
+You have to override the following Pekko dependencies by defining them
explicitly in your build and
+define the Pekko version to the one that you are using. Latest patch version
of Pekko is recommended and
a later version than $pekko.version$ can be used.
@@dependency[sbt,Gradle,Maven] {
@@ -44,10 +44,10 @@ a later version than $pekko.version$ can be used.
Remember that Pekko Management does not start automatically and the routes
will only be exposed once you trigger:
Scala
-:
@@snip[DemoApp.scala](/integration-test/kubernetes-api/src/main/scala/org/apache/pekko/cluster/bootstrap/DemoApp.scala){
#start-akka-management }
+:
@@snip[DemoApp.scala](/integration-test/kubernetes-api/src/main/scala/org/apache/pekko/cluster/bootstrap/DemoApp.scala){
#start-pekko-management }
Java
-:
@@snip[DemoApp.java](/integration-test/kubernetes-api-java/src/main/java/org/apache/pekko/cluster/bootstrap/demo/DemoApp.java){
#start-akka-management }
+:
@@snip[DemoApp.java](/integration-test/kubernetes-api-java/src/main/java/org/apache/pekko/cluster/bootstrap/demo/DemoApp.java){
#start-pekko-management }
This allows users to prepare anything further before exposing routes for
the bootstrap joining process and other purposes.
@@ -65,8 +65,8 @@ You can configure hostname and port to use for the HTTP
Cluster management by ov
Note that the default value for hostname is
`InetAddress.getLocalHost.getHostAddress`, which may or may not evaluate to
`127.0.0.1`.
-When running Akka nodes behind NATs or inside docker containers in bridge mode,
-it is necessary to set different hostname and port number to bind for the HTTP
Server for Http Cluster Management:
+When running Pekko nodes behind NATs or inside docker containers in bridge
mode,
+it is necessary to set different hostname and port number to bind for the HTTP
Server for HTTP Cluster Management:
application.conf
: ```hocon
@@ -88,7 +88,7 @@ application.conf
```
In this example, with this configuration, then the Pekko Management routes
will will be exposed at under the `/myClusterName/...`,
-base path. For example, when using Akka Cluster Management routes the members
information would then be available under
+base path. For example, when using Pekko Cluster Management routes the members
information would then be available under
`/myClusterName/shards/{name}` etc.
## Read only routes
@@ -113,10 +113,10 @@ publicly.
The non-secured usage of the module is as follows:
Scala
-:
@@snip[DemoApp.scala](/integration-test/kubernetes-api/src/main/scala/org/apache/pekko/cluster/bootstrap/DemoApp.scala){
#start-akka-management }
+:
@@snip[DemoApp.scala](/integration-test/kubernetes-api/src/main/scala/org/apache/pekko/cluster/bootstrap/DemoApp.scala){
#start-pekko-management }
Java
-:
@@snip[DemoApp.java](/integration-test/kubernetes-api-java/src/main/java/org/apache/pekko/cluster/bootstrap/demo/DemoApp.java){
#start-akka-management }
+:
@@snip[DemoApp.java](/integration-test/kubernetes-api-java/src/main/java/org/apache/pekko/cluster/bootstrap/demo/DemoApp.java){
#start-pekko-management }
### Enabling TLS/SSL (HTTPS) for Cluster HTTP Management
@@ -124,10 +124,10 @@ To enable SSL you need to provide an `SSLContext`. You
can find more information
@extref:[Server HTTPS
Support](pekko-http:server-side/server-https-support.html).
Scala
-:
@@snip[PekkoManagementHttpEndpointSpec.scala](/management/src/test/scala/org/apache/pekko/management/PekkoManagementHttpEndpointSpec.scala){
#start-akka-management-with-https-context }
+:
@@snip[PekkoManagementHttpEndpointSpec.scala](/management/src/test/scala/org/apache/pekko/management/PekkoManagementHttpEndpointSpec.scala){
#start-pekko-management-with-https-context }
Java
-:
@@snip[CodeExamples.java](/management/src/test/java/org/apache/pekko/management/CodeExamples.java){
#start-akka-management-with-https-context }
+:
@@snip[CodeExamples.java](/management/src/test/java/org/apache/pekko/management/CodeExamples.java){
#start-pekko-management-with-https-context }
You can also refer to
[PekkoManagementHttpEndpointSpec](https://github.com/akka/akka-management/blob/119ad1871c3907c2ca528720361b8ccb20234c55/management/src/test/scala/org/apache/pekko/management/PekkoManagementHttpEndpointSpec.scala#L124-L148)
where a full example configuring the HTTPS context is shown.
diff --git a/integration-test/aws-api-ec2/README.md
b/integration-test/aws-api-ec2/README.md
index f9fb1e1..9063300 100644
--- a/integration-test/aws-api-ec2/README.md
+++ b/integration-test/aws-api-ec2/README.md
@@ -1,4 +1,4 @@
-Your Akka Cluster on Vanilla EC2 using Tag Based Discovery
+Your Pekko Cluster on Vanilla EC2 using Tag Based Discovery
==========================================================
Note: these steps can be easily automated via CloudFormation or
@@ -39,7 +39,7 @@ launched in Step 1. See screenshot below to see how to do
this.
Step 4: Create Security Group
-----------------------------
-Since we want to run an an Akka cluster on these instances, they have to be
able to talk to each other: the TCP ports we
+Since we want to run a Pekko cluster on these instances, they have to be able
to talk to each other: the TCP ports we
care about are 2552 and 8558. However, we don't want to open these ports to
the whole wide world. In the Amazon Cloud,
instances can *privately* communicate with each other if they are part of the
same security group *and* if the proper inbound
rules are set.
diff --git a/integration-test/aws-api-ecs/README.md
b/integration-test/aws-api-ecs/README.md
index 2d86c41..b97c2c3 100644
--- a/integration-test/aws-api-ecs/README.md
+++ b/integration-test/aws-api-ecs/README.md
@@ -1,4 +1,4 @@
-# Your Akka Cluster on ECS
+# Your Pekko Cluster on ECS
**Note:**
diff --git
a/integration-test/kubernetes-api-java/src/main/java/org/apache/pekko/cluster/bootstrap/demo/DemoApp.java
b/integration-test/kubernetes-api-java/src/main/java/org/apache/pekko/cluster/bootstrap/demo/DemoApp.java
index 85d607b..93f00d5 100644
---
a/integration-test/kubernetes-api-java/src/main/java/org/apache/pekko/cluster/bootstrap/demo/DemoApp.java
+++
b/integration-test/kubernetes-api-java/src/main/java/org/apache/pekko/cluster/bootstrap/demo/DemoApp.java
@@ -20,10 +20,10 @@ import org.apache.pekko.cluster.ClusterEvent;
import org.apache.pekko.http.javadsl.ConnectHttp;
import org.apache.pekko.http.javadsl.Http;
import org.apache.pekko.http.javadsl.server.AllDirectives;
-//#start-akka-management
+//#start-pekko-management
import org.apache.pekko.management.javadsl.PekkoManagement;
-//#start-akka-management
+//#start-pekko-management
import org.apache.pekko.management.cluster.bootstrap.ClusterBootstrap;
import org.apache.pekko.stream.Materializer;
@@ -37,9 +37,9 @@ public class DemoApp extends AllDirectives {
system.log().info("Started [" + system + "], cluster.selfAddress = " +
cluster.selfAddress() + ")");
- //#start-akka-management
+ //#start-pekko-management
PekkoManagement.get(system).start();
- //#start-akka-management
+ //#start-pekko-management
ClusterBootstrap.get(system).start();
cluster
diff --git
a/integration-test/kubernetes-api/src/main/scala/org/apache/pekko/cluster/bootstrap/DemoApp.scala
b/integration-test/kubernetes-api/src/main/scala/org/apache/pekko/cluster/bootstrap/DemoApp.scala
index 7e5b4d0..c537789 100644
---
a/integration-test/kubernetes-api/src/main/scala/org/apache/pekko/cluster/bootstrap/DemoApp.scala
+++
b/integration-test/kubernetes-api/src/main/scala/org/apache/pekko/cluster/bootstrap/DemoApp.scala
@@ -21,9 +21,9 @@ import pekko.http.scaladsl.Http
import pekko.http.scaladsl.model._
import pekko.http.scaladsl.server.Directives._
import pekko.management.cluster.bootstrap.ClusterBootstrap
-//#start-akka-management
+//#start-pekko-management
import org.apache.pekko.management.scaladsl.PekkoManagement
-//#start-akka-management
+//#start-pekko-management
object DemoApp extends App {
@@ -34,9 +34,9 @@ object DemoApp extends App {
log.info(s"Started [$system], cluster.selfAddress = ${cluster.selfAddress}")
- // #start-akka-management
+ // #start-pekko-management
PekkoManagement(system).start()
- // #start-akka-management
+ // #start-pekko-management
ClusterBootstrap(system).start()
cluster.subscribe(
diff --git a/integration-test/marathon-api-docker/README.md
b/integration-test/marathon-api-docker/README.md
index 8efbee8..dd632dc 100644
--- a/integration-test/marathon-api-docker/README.md
+++ b/integration-test/marathon-api-docker/README.md
@@ -4,7 +4,7 @@ Marathon API Docker lookup example
This example demonstrates Marathon API discovery mechanism when an application
runs inside a docker container in
network bridge mode with automatic host port allocation.
-Marathon API discovery mechanism uses Marathon API to find other application
instances (contact points) to form Akka cluster.
+Marathon API discovery mechanism uses Marathon API to find other application
instances (contact points) to form a Pekko cluster.
In order to identify contact points it uses a label assigned to the
application in the application description and
a port name to identify Pekko HTTP management port:
diff --git a/integration-test/marathon-api/README.md
b/integration-test/marathon-api/README.md
index 81fa611..4493aeb 100644
--- a/integration-test/marathon-api/README.md
+++ b/integration-test/marathon-api/README.md
@@ -1,4 +1,4 @@
-Your Akka Cluster on DC/OS
+Your Pekko Cluster on DC/OS
==========================
Prerequisites
diff --git
a/management/src/test/java/org/apache/pekko/management/CodeExamples.java
b/management/src/test/java/org/apache/pekko/management/CodeExamples.java
index a9c2b45..4b7c0f0 100644
--- a/management/src/test/java/org/apache/pekko/management/CodeExamples.java
+++ b/management/src/test/java/org/apache/pekko/management/CodeExamples.java
@@ -31,12 +31,12 @@ public class CodeExamples {
public void start() {
SSLContext sslContext = null;
- //#start-akka-management-with-https-context
+ //#start-pekko-management-with-https-context
PekkoManagement management = PekkoManagement.get(system);
HttpsConnectionContext https = ConnectionContext.https(sslContext);
management.start(settings -> settings.withHttpsConnectionContext(https));
- //#start-akka-management-with-https-context
+ //#start-pekko-management-with-https-context
}
public void basicAuth() {
diff --git
a/management/src/test/scala/org/apache/pekko/management/PekkoManagementHttpEndpointSpec.scala
b/management/src/test/scala/org/apache/pekko/management/PekkoManagementHttpEndpointSpec.scala
index 506dc2e..2a31bf7 100644
---
a/management/src/test/scala/org/apache/pekko/management/PekkoManagementHttpEndpointSpec.scala
+++
b/management/src/test/scala/org/apache/pekko/management/PekkoManagementHttpEndpointSpec.scala
@@ -186,13 +186,13 @@ class PekkoManagementHttpEndpointSpec extends
AnyWordSpecLike with Matchers {
engine
})
- // #start-akka-management-with-https-context
+ // #start-pekko-management-with-https-context
val management = PekkoManagement(system)
val httpsServer: HttpsConnectionContext =
ConnectionContext.httpsServer(sslContext)
val started =
management.start(_.withHttpsConnectionContext(httpsServer))
- // #start-akka-management-with-https-context
+ // #start-pekko-management-with-https-context
Await.result(started, 10.seconds)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
