diff --git a/ambari-agent/src/main/python/ambari_agent/alerts/port_alert.py b/ambari-agent/src/main/python/ambari_agent/alerts/port_alert.py
index acf37467d39..59e40134c83 100644
--- a/ambari-agent/src/main/python/ambari_agent/alerts/port_alert.py
+++ b/ambari-agent/src/main/python/ambari_agent/alerts/port_alert.py
@@ -154,8 +154,8 @@ def _collect(self):
start_time = time.time()
s.connect((host, port))
if self.socket_command is not None:
- s.sendall(self.socket_command)
- data = s.recv(1024)
+ s.sendall(self.socket_command.encode())
+ data = s.recv(1024).decode()
if self.socket_command_response is not None and data != self.socket_command_response:
raise Exception("Expected response {0}, Actual response {1}".format(
self.socket_command_response, data))
diff --git a/ambari-agent/src/test/python/ambari_agent/TestPortAlert.py b/ambari-agent/src/test/python/ambari_agent/TestPortAlert.py
index 0a47f3b8a5c..845a8cf2777 100644
--- a/ambari-agent/src/test/python/ambari_agent/TestPortAlert.py
+++ b/ambari-agent/src/test/python/ambari_agent/TestPortAlert.py
@@ -393,7 +393,7 @@ def test_collect_zookeeper(self, time, socket):
alert.set_cluster(cluster, cluster_id, host)
alert.configuration_builder = MagicMock()
s = socket()
- s.recv.return_value = "imok"
+ s.recv.return_value = "imok".encode()
def collector_side_effect(clus, data):
self.assertEqual(data['name'], alert_meta['name'])
@@ -451,7 +451,7 @@ def test_collect_zookeeper_warning(self, time, socket):
alert.set_cluster(cluster, cluster_id, host)
alert.configuration_builder = MagicMock()
s = socket()
- s.recv.return_value = "imok"
+ s.recv.return_value = "imok".encode()
def collector_side_effect(clus, data):
self.assertEqual(data['name'], alert_meta['name'])
@@ -510,7 +510,7 @@ def test_collect_zookeeper_connectionTimeout(self, time, socket):
alert.configuration_builder = MagicMock()
s = socket()
- s.recv.return_value = "imok"
+ s.recv.return_value = "imok".encode()
def collector_side_effect(clus, data):
self.assertEqual(data['name'], alert_meta['name'])
diff --git a/ambari-server/docs/api/v1/alert-dispatching.md b/ambari-server/docs/api/v1/alert-dispatching.md
index 8326e5ee053..90a9499e507 100644
--- a/ambari-server/docs/api/v1/alert-dispatching.md
+++ b/ambari-server/docs/api/v1/alert-dispatching.md
@@ -37,7 +37,7 @@ Any number of targets can be associated with an alert group (a grouping of defin
There is also a `global` alert target which can be used as a way to produce notifications for any alert defined in Ambari. These `global` targets are never associated with any groups; they apply to all groups and all definitions.
##### Notices
-Once an alert has changed state, Ambari will determine if there are any targets that should receive a notification of the state change. These notifications, or notices, are created with an initial status of `PENDING` and will transition either to `DELIVERED` or `FAILED` once the proper dispatcher has attemped to process the notice. Dispatchers can attempt to aggregate any `PENDING` notices into a single outbound notification.
+Once an alert has changed state, Ambari will determine if there are any targets that should receive a notification of the state change. These notifications, or notices, are created with an initial status of `PENDING` and will transition either to `DELIVERED` or `FAILED` once the proper dispatcher has attempted to process the notice. Dispatchers can attempt to aggregate any `PENDING` notices into a single outbound notification.
### API Summary
diff --git a/ambari-server/docs/api/v1/index.md b/ambari-server/docs/api/v1/index.md
index e8abcb633b2..4bdbcff23d2 100644
--- a/ambari-server/docs/api/v1/index.md
+++ b/ambari-server/docs/api/v1/index.md
@@ -176,7 +176,7 @@ Delete the cluster named 'c1'.
### Asynchronous Response
-The managment APIs can return a response code of 202 which indicates that the request has been accepted. The body of the response contains the ID and href of the request resource that was created to carry out the instruction.
+The management APIs can return a response code of 202 which indicates that the request has been accepted. The body of the response contains the ID and href of the request resource that was created to carry out the instruction.
202 Accepted
{
diff --git a/ambari-server/docs/configuration/index.md b/ambari-server/docs/configuration/index.md
index 7a1b7184f65..01c61d8caa3 100644
--- a/ambari-server/docs/configuration/index.md
+++ b/ambari-server/docs/configuration/index.md
@@ -234,7 +234,7 @@ The following are the properties which can be used to configure Ambari.
| server.metrics.retrieval-service.thread.priority | The priority of threads used by the service which retrieves JMX and REST metrics directly from their respective endpoints. |`5` |
| server.metrics.retrieval-service.threadpool.size.core | The core number of threads used to retrieve JMX and REST metrics directly from their respective endpoints. |`4` |
| server.metrics.retrieval-service.threadpool.size.max | The maximum number of threads used to retrieve JMX and REST metrics directly from their respective endpoints. |`8` |
-| server.metrics.retrieval-service.threadpool.worker.size | The number of queued requests allowed for JMX and REST metrics before discarding old requests which have not been fullfilled. |`80` |
+| server.metrics.retrieval-service.threadpool.worker.size | The number of queued requests allowed for JMX and REST metrics before discarding old requests which have not been fulfilled. |`80` |
| server.operations.retry-attempts | The number of retry attempts for failed API and blueprint operations. |`0` |
| server.os_family | The operating system family for all hosts in the cluster. This is used when bootstrapping agents and when enabling Kerberos.
The following are examples of valid values: