Skip to content

Commit

Permalink
Language revision
Browse files Browse the repository at this point in the history
  • Loading branch information
Dmitri Popov committed Jan 30, 2025
1 parent d956cfa commit 041c8fb
Showing 1 changed file with 20 additions and 20 deletions.
40 changes: 20 additions & 20 deletions trento/xml/trento-requirements.xml
Original file line number Diff line number Diff line change
Expand Up @@ -13,16 +13,16 @@
&t.agent;s. </para>
<section xml:id="sec-trento-server-requirements">
<title>&t.server; requirements</title>
<para> Running all the &t.server; components requires a minimum of 4&nbsp;GB of RAM,
two CPU cores and 64&nbsp;GB of storage.
When using K3s, such storage should be provided under <filename>/var/lib/rancher/k3s</filename>.

This comment has been minimized.

Copy link
@abravosuse

abravosuse Jan 30, 2025

Collaborator

Cool

<para> Running all the &t.server; components requires a minimum of
4&nbsp;GB of RAM, two CPU cores and 64&nbsp;GB of storage. When using K3s,
such storage should be provided under
<filename>/var/lib/rancher/k3s</filename>.
</para>
<para>
Trento is powered by event driven technology. Registered events are stored in a &postgresql; database with a default retention
period of 10 days. For each host registered with Trento, you need to allocate at least 1.5GB of space in the &postgresql; database.
&trento; is based on the event-driven architecture. Registered events are stored in a &postgresql; database with a default retention

This comment has been minimized.

Copy link
@abravosuse

abravosuse Jan 30, 2025

Collaborator

To be sure, not sure what the right expression is: event-driven technology vs event-driven architecture. I've always used the former, probably wrongly.

Also, not sure about that "the" before "event-driven architecture". We are referring to something generic: event-driven technology/architecture. Not a particular one.

period of 10 days. For each host registered with &trento;, you need to allocate at least 1.5GB of space in the &postgresql; database.
</para>
<para> &t.server; supports different deployment scenarios: &k8s;, systemd and containerized. A &k8s; based deployment of &t.server; is meant to be
cloud native and OS agnostic. It can be done on the following services: </para>
<para> &t.server; supports different deployment scenarios: &k8s;, systemd, and containers. A &k8s;-based deployment of &t.server; is cloud-native and OS-agnostic. It can be performed on the following services: </para>

This comment has been minimized.

Copy link
@abravosuse

abravosuse Jan 31, 2025

Collaborator

A Kubernetes deployment is also container based. That's why "Kubernetes, systemd and containers" might be redundant. "containerized" speaks better, I think, for the scenario where containers are deployed on a container runtime (like docker).

<itemizedlist>
<listitem>
<para>RKE1 (&rancher.k8s.engine; version 1)</para>
Expand All @@ -37,33 +37,33 @@
<para>any other CNCF-certified &k8s; running on x86_64 architecture</para>
</listitem>
</itemizedlist>
<para> A proper, production ready &k8s; based deployment of &t.server; requires &k8s;
knowledge. The Helm chart is meant to be used by customers lacking such knowledge
or who want to get started quickly. However, Helm chart delivers a basic deployment of the &t.server; with all the components running
on a single node of the cluster.</para>
<para> A production-ready &k8s;-based deployment of &t.server; requires
&k8s; knowledge. The Helm chart is intended to be used by customers without
in-house &k8s; expertise, or as a way to try &trento; with a minimum of
effort. However, Helm chart delivers a basic deployment of the &t.server;

This comment has been minimized.

Copy link
@abravosuse

abravosuse Jan 31, 2025

Collaborator

I would rephrase the last sentence as follows:

However, the Helm chart as-is delivers a basic deployment of the Trento Server...

with all the components running on a single node of the cluster.</para>
</section>
<section xml:id="sec-trento-agent-requirements">
<title>&t.agent; requirements</title>
<para> The resource footprint of the &t.agent; is designed to not
impact the performance of the host it runs on. </para>
<para> The &t.agent; component needs to interact with several
low-level system components that are part of the &sles4sap; distribution. </para>
<para> Trento requires unique machine identifiers (ids) on the hosts to be registered. Therefore, if any host in your environment is built as a clone of another one,
ensure that you change the machine identifier as part of the cloning process before starting the &t.agent; on it. </para>
<para> Similarly, Trento requires unique authkeys on the clusters to be registered.</para>
<para>The hosts must have unique machine identifiers (ids) in order to be registered in Trento. This means that if a host in your environment is built as a clone of another one,
make sure to change the machine's identifier as part of the cloning process before starting the &t.agent; on it. </para>
<para> Similarly, the clusters must have unique authkeys on the clusters in order to be registered in &trento;.</para>

This comment has been minimized.

Copy link
@abravosuse

abravosuse Jan 31, 2025

Collaborator

"This means that if a host in your environment is built as a clone of another one, make sure to change..." > sounds strange > "This means that if a host in your environment is built as a clone of another one, you must change..."

"Similarly, the clusters must have unique authkeys on the clusters in order to be registered in &trento;" > redundancy > "Similarly, the clusters must have unique authkeys in order to be registered in &trento;"

</section>
<section xml:id="sec-trento-network-requirements">
<title>Network requirements</title>
<itemizedlist>
<listitem>
<para>
<remark>toms 2021-12-06: do we have UDP here too?</remark>
From any &t.agent; host, the Web component of the &t.server; must be reachable via HTTP (port TCP/80) or via HTTPS (port TCP/443) if SSL is enabled.
The Web component of the &t.server; must be reachable from any &t.agent; host via HTTP (port TCP/80) or via HTTPS (port TCP/443) if SSL is enabled.

This comment has been minimized.

Copy link
@abravosuse

abravosuse Jan 31, 2025

Collaborator

OK

</para>
</listitem>
<listitem>
<para>
From any &t.agent; host, the checks engine component of the &t.server;, called Wanda, must be reachable via Advanced Message Queuing Protocol or AMQP (port TCP/5672).
The checks engine component of the &t.server; must be reachable from any &t.agent; host via Advanced Message Queuing Protocol or AMQP (port TCP/5672).

This comment has been minimized.

Copy link
@abravosuse

abravosuse Jan 31, 2025

Collaborator

"The checks engine component of the &t.server; must be reachable from any &t.agent; host via Advanced Message Queuing Protocol or AMQP (port TCP/5672)." > given that the artifacts in SUSE registry and SLES for SAP repos use wanda as a name, I think it's important to remind the user that such is the name of the checks engine > "The checks engine component of the &t.server;, called wanda, must be reachable from any &t.agent; host via Advanced Message Queuing Protocol or AMQP (port TCP/5672)."

</para>
</listitem>
<listitem>
Expand All @@ -72,7 +72,7 @@
</para>
</listitem>
<listitem>
<para>The &sap; Basis administrator needs access to the Web component of the &t.server; via HTTP (port TCP/80) or via HTTPS (port TCP/443) if SSL is enabled. </para>
<para>The &sap; Basis administrator must access to the Web component of the &t.server; via HTTP (port TCP/80) or via HTTPS (port TCP/443) if SSL is enabled. </para>

This comment has been minimized.

Copy link
@abravosuse

abravosuse Jan 31, 2025

Collaborator

OK

</listitem>
</itemizedlist>
</section>
Expand All @@ -82,8 +82,8 @@
<listitem>
<formalpara>
<title>&t.server;</title>
<para>Access to &suse; public registry for the deployment of &t.server; containers, if we choose a &k8s; based deployment.
A registered &sles4sap; 15 (SP3 or higher) distribution, if we choose a systemd deployment. Both in the case of a containerized deployment.</para>
<para>For a &k8s;-based deployment, you must have access to &suse; public registry for the deployment of &t.server; containers.
For a systemd deployment, you must have a registered &sles4sap; 15 (SP3 or higher) distribution. The same applies to a containerized deployment.</para>

This comment has been minimized.

Copy link
@abravosuse

abravosuse Jan 31, 2025

Collaborator

"The same applies to a containerized deployment" > I don't think this is clear enough. If you choose a containerized deployment, upstream components will be deployed as containers from SUSE public registry but 3rd party components will be deployed as systemd services from SLES for SAP repos. Therefore you both things: access to SUSE public registry and a registered distro of SLES for SAP 15.

</formalpara>
</listitem>
<listitem>
Expand Down

1 comment on commit 041c8fb

@EMaksy
Copy link
Collaborator

@EMaksy EMaksy commented on 041c8fb Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great changes, nothing to add on it. Thanks Dima.
Also the section size is great, easy to follow :)

Please sign in to comment.