Skip to content

Commit e4d16e0

Browse files
shainaraskasshainaraskas
authored
Version docs (#478)
1 parent 7d28b29 commit e4d16e0

File tree

4 files changed

+423
-1
lines changed

4 files changed

+423
-1
lines changed

‎docs/docset.yml‎

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -20,10 +20,15 @@ external_hosts:
2020
- commonmark.org
2121
- github.io
2222
- github.com
23+
- elastic.dev
2324
exclude:
2425
- '_*.md'
2526
subs:
2627
a-global-variable: "This was defined in docset.yml"
28+
stack: Elastic Stack
29+
serverless-short: Serverless
30+
ece: "Elastic Cloud Enterprise"
31+
eck: "Elastic Cloud on Kubernetes"
2732
toc:
2833
- file: index.md
2934
- hidden: developer-notes.md
@@ -92,6 +97,10 @@ toc:
9297
- file: tabs.md
9398
- file: tagged_regions.md
9499
- file: titles.md
100+
- folder: versions
101+
children:
102+
- file: index.md
103+
- file: content-patterns.md
95104
# nested TOCs are only allowed from docset.yml
96105
# to prevent them from being nested deeply arbitrarily
97106
- toc: development
@@ -112,4 +121,4 @@ toc:
112121
- file: bar.md
113122
- folder: baz
114123
children:
115-
- file: qux.md
124+
- file: qux.md

‎docs/versions/_snippets/content-patterns-list.md‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
| Approach | Use case |
2+
| --- | --- |
3+
| [Page-level `applies` tags](/versions/content-patterns.md#page-level-applies-tags) | Provide signals that a page applies to the reader. |
4+
| [Section/heading-level `applies` tags](/versions/content-patterns.md#sectionheading-level-applies-tags) | Provide signals about a section’s scope so a user can choose to read or skip it as needed. |
5+
| [Tabs](/versions/content-patterns.md#tabs) | Provide two sets of procedures when one or more steps in a process differs between contexts or versions. |
6+
| [Callouts](/versions/content-patterns.md#callouts) | Draw attention to happy differences and basic clarifications. |
7+
| [Prose](/versions/content-patterns.md#prose) | Provide clarifying or secondary information, explain differences with a "why". |
8+
| [Sibling pages](/versions/content-patterns.md#sibling-pages) | When the information is too complex to be addressed with only the other content patterns. See specific examples in the sibling pages section. |
9+
10+
% | [List item suffixes](/versions/content-patterns.md#list-item-suffixes) | Identify features in a **list of features** that are exclusive to a specific context, or that were introduced in a specific version. |
11+
% | [Sibling bullets](/versions/content-patterns.md#sibling-bullets) | List differing requirements, limits, and other simple, mirrored facts. |

‎docs/versions/content-patterns.md‎

Lines changed: 290 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,290 @@
1+
---
2+
navigation_title: "Content patterns"
3+
---
4+
5+
# Version content patterns
6+
7+
Depending on what you're trying to communicate, you can use the following patterns to represent version and deployment type differences in your docs.
8+
9+
Choose from:
10+
11+
:::{include} _snippets/content-patterns-list.md
12+
:::
13+
14+
## Page-level `applies` tags
15+
16+
*see [`applies`](/syntax/applies.md)*
17+
18+
**Use case:** Provide signals that a page applies to the reader
19+
20+
**Number to use:** Minimum to add clarity. See [basic concepts and principles](/versions/index.md#basic-concepts-and-principles).
21+
22+
**Approach:**
23+
24+
Add tags for all **versioning facets** relevant to the page.
25+
26+
See [Versions and lifecycle states](/versions/index.md#versions-and-lifecycle-states) to learn when to specify versions in these tags.
27+
28+
### Examples
29+
30+
[Manage your Cloud organization](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/deploy-manage/cloud-organization)
31+
32+
## Section/heading-level `applies` tags
33+
34+
:::{applies}
35+
:ece: all
36+
:hosted: all
37+
:eck: all
38+
:stack: all
39+
:::
40+
41+
*see [`applies`](/syntax/applies.md#sections)*
42+
43+
**Use case:** Provide signals about a section’s scope so a user can choose to read or skip it as needed
44+
45+
**Number to use:** Minimum to add clarity. See [basic concepts and principles](/versions/index.md#basic-concepts-and-principles).
46+
47+
**When to use:** When the section-level scope differs from the page-level scope
48+
49+
**Example**
50+
See above
51+
52+
% ## List item suffixes
53+
%
54+
% **Use case:** When features in a **list of features** are exclusive to a specific context, or were introduced in a specific version
55+
%
56+
% **Number to use:** Three max. If the number of tags is longer than that, consider:
57+
%
58+
% * Breaking up the list by facet
59+
% * Using labels that don't have version / lifecycle information and deferring that information to the page or section for the feature
60+
%
61+
% **Approach:**
62+
%
63+
% Append the information to the bullet item in bolded square brackets `**[]**`. Add all information within a single set of square brackets. The brackets should appear after any final punctuation. Consider using words like `only` to help people to understand that this information indicates the applicability of a feature.
64+
%
65+
% ### Examples
66+
%
67+
% Spaces let you organize your content and users according to your needs.
68+
%
69+
% ::::{tab-set}
70+
% :group: one-two
71+
%
72+
% :::{tab-item} One
73+
% :sync: one
74+
%
75+
% * Each space has its own saved objects.
76+
% * Users can only access the spaces that they have been granted access to. This access is based on user roles, and a given role can have different permissions per space.
77+
% * Each space has its own navigation. **[{{stack}} v9 only]**
78+
%
79+
% :::
80+
% :::{tab-item} Two
81+
% :sync: two
82+
%
83+
%
84+
% * Learn about internal users, which are responsible for the operations that take place inside an Elasticsearch cluster
85+
% * Learn about service accounts, which are used for integration with external services that connect to Elasticsearch
86+
% * Learn about the services used for token-based authentication
87+
% * Learn about the services used by orchestrators **[Elastic Cloud Hosted, {{ece}}, {{eck}}]**
88+
% * Learn about user lookup technologies
89+
% * Manage the user cache
90+
%
91+
% :::
92+
% ::::
93+
94+
95+
## Tabs
96+
97+
**Use case:** When one or more steps in a process differs, put the steps into tabs - one for each process.
98+
99+
**Number to use:** Max 4 or 5 (in a deployment type / versioning context - might be different for other situations)
100+
101+
Try to minimize the number of tabs where you can - try to work around small differences by rewording or adding context in prose or in `note` style admonitions. Check out the [prose](#prose) guidelines.
102+
103+
Try not to include information surrounding a procedure in the tabs. Make the tab content as small as possible apart from the procedure itself.
104+
105+
Consider breaking up procedures into sets of procedures if only one section differs between contexts.
106+
107+
:::{tip}
108+
For consistency, use [substitutions](/syntax/substitutions.md) for the tab labels.
109+
:::
110+
111+
### Examples
112+
113+
To create a space:
114+
115+
:::::{tab-set}
116+
:group: serverless-stack
117+
118+
::::{tab-item} {{serverless-short}}
119+
:sync: serverless
120+
121+
1. Click **Create space** or select the space you want to edit.
122+
2. Provide:
123+
124+
* A meaningful name and description for the space.
125+
* A URL identifier. The URL identifier is a short text string that becomes part of the Kibana URL. Kibana suggests a URL identifier based on the name of your space, but you can customize the identifier to your liking. You cannot change the space identifier later.
126+
127+
3. Customize the avatar of the space to your liking.
128+
4. Save the space.
129+
::::
130+
131+
::::{tab-item} {{stack}} v9
132+
:sync: stack
133+
134+
1. Select **Create space** and provide a name, description, and URL identifier.
135+
The URL identifier is a short text string that becomes part of the Kibana URL when you are inside that space. Kibana suggests a URL identifier based on the name of your space, but you can customize the identifier to your liking. You cannot change the space identifier once you create the space.
136+
137+
2. Select a **Solution view**. This setting controls the navigation that all users of the space will get:
138+
* **Search**: A light navigation menu focused on analytics and Search use cases. Features specific to Observability and Security are hidden.
139+
* **Observability**: A light navigation menu focused on analytics and Observability use cases. Features specific to Search and Security are hidden.
140+
* **Security**: A light navigation menu focused on analytics and Security use cases. Features specific to Observability and Search are hidden.
141+
* **Classic**: All features from all solutions are visible by default using the classic, multilayered navigation menus. You can customize which features are visible individually.
142+
143+
3. If you selected the **Classic** solution view, you can customize the **Feature visibility** as you need it to be for that space.
144+
145+
:::{note}
146+
Even when disabled in this menu, some Management features can remain visible to some users depending on their privileges. Additionally, controlling feature visibility is not a security feature. To secure access to specific features on a per-user basis, you must configure Kibana Security.
147+
:::
148+
4. Customize the avatar of the space to your liking.
149+
5. Save your new space by selecting **Create space**.
150+
::::
151+
152+
:::::
153+
154+
You can edit all of the space settings you just defined at any time, except for the URL identifier.
155+
156+
% ## Sibling bullets
157+
%
158+
% **Use case:** Requirements, limits, other simple, mirrored facts.
159+
%
160+
% **Number to use:** Ideal is one per option (e.g. one per deployment type). You might consider nested bullets in limited cases.
161+
%
162+
% ### Examples
163+
%
164+
% ::::{tab-set}
165+
% :group: one-two
166+
%
167+
% :::{tab-item} One
168+
% :sync: one
169+
%
170+
% #### Required permissions
171+
%
172+
% * **{{serverless-short}}**: `Admin` or equivalent
173+
% * **{{stack}} v9**: `kibana_admin` or equivalent
174+
%
175+
% :::
176+
% :::{tab-item} Two
177+
% :sync: two
178+
%
179+
% #### Create a space
180+
%
181+
% The maximum number of spaces that you can have differs by [what do we call this]:
182+
%
183+
% * **{{serverless-short}}**: Maximum of 100 spaces.
184+
% * **{{stack}} v9**: Controlled by the `xpack.spaces.maxSpaces` setting. Default is 1000.
185+
% :::
186+
% ::::
187+
188+
## Callouts
189+
190+
**Use case:** Happy differences, clarifications
191+
192+
Some sections don’t apply to contexts like serverless, because we manage the headache for you. Help people to feel like they’re not getting shortchanged with a callout.
193+
194+
If there’s a terminology change or other minor change (especially where x equates with y), consider handling as a note for simplicity.
195+
196+
### Examples
197+
198+
* *In **Manage TLS certificates** section*:
199+
200+
:::{tip}
201+
Elastic Cloud manages TLS certificates for you.
202+
:::
203+
204+
* *In a **Spaces** overview*:
205+
206+
:::{note}
207+
In {{stack}} 9.0.0 and earlier, **Spaces** are referred to as **Places**.
208+
209+
## Prose
210+
211+
**Use case**: Clarifying or secondary information, differences with a "why"
212+
213+
**When to use:**
214+
* Cases where the information isn’t wildly important, but nice to know, or to add basic terminology change info to overviews
215+
* Comparative overviews
216+
* Differences that are small enough or not significant enough to warrant an admonition or tabs or separate sections with frontmatter.
217+
218+
In some cases, you might want to add a paragraph specific to one version or another in prose to clarify behavior or terminology.
219+
220+
In cases where there are significant differences between contexts, close explanation of the differences helps people to understand how something works, or why something behaves the way it does. Compare and contrast differences in paragraphs when the explanation helps people to use our features effectively.
221+
222+
% You also might do this to compare approaches between deployment types, when [sibling bullets](#sibling-bullets) aren't enough.
223+
224+
### Examples
225+
226+
* In {{stack}} 9.1.0 and earlier, **Spaces** were referred to as **Places**.
227+
228+
::::{tab-set}
229+
:group: one-two-three
230+
231+
:::{tab-item} One
232+
:sync: one
233+
234+
The way that TLS certificates are managed depends on your deployment type:
235+
236+
In self-managed Elasticsearch, you manage both of these certificates yourself.
237+
238+
In {{eck}}, you can manage certificates for the HTTP layer. Certificates for the transport layer are managed by ECK and can’t be changed. However, you can set your own certificate authority, customize certificate contents, and provide your own certificate generation tools using transport settings.
239+
240+
In {{ece}}, you can use one or more proxy certificates to secure the HTTP layer. These certificates are managed at the ECE installation level. Transport-level encryption is managed by ECE and certificates can’t be changed.
241+
:::
242+
243+
:::{tab-item} Two
244+
:sync: two
245+
If you're managing a {{stack}} v9 deployment, then you can also assign roles and define permissions for a space from the **Permissions** tab of the space settings.
246+
:::
247+
248+
:::{tab-item} Three
249+
:sync: three
250+
251+
**Managed security in Elastic Cloud**
252+
253+
Elastic Cloud has built-in security. For example, HTTPS communications between Elastic Cloud and the internet, as well as inter-node communications, are secured automatically, and cluster data is encrypted at rest.
254+
255+
You can augment Elastic Cloud security features in the following ways:
256+
257+
* Configure traffic filtering to prevent unauthorized access to your deployments.
258+
* Encrypt your deployment with a customer-managed encryption key.
259+
* Secure your settings with the Elasticsearch keystore.
260+
* Allow or deny Cloud IP ranges using Elastic Cloud static IPs.
261+
262+
[Learn more about security measures in Elastic Cloud](https://www.elastic.co/cloud/security).
263+
264+
:::
265+
::::
266+
267+
## Sibling pages
268+
269+
**Use case:**
270+
271+
* Processes that have significant differences **across multiple procedures**
272+
* Chained procedures where not all of the procedures are needed for all contexts / where the flow across procedures is muddied when versioning context is added
273+
* Very complex pages that are already heavily using tabs and other tools we use for versioning differences, making it hard to add another “layer” of content
274+
* Beta to GA transitions? Hide the beta doc and leave it linked to the GA doc, which will presumably be more stable?
275+
276+
**Number to use:** As few as possible. Consider leveraging other ways of communicating versioning differences to reduce the number of sibling pages.
277+
278+
**When to use:**
279+
280+
When version differences are just too large to be handled with any of our other tools. Try to avoid creating sibling pages when you can.
281+
282+
% Down the line, if we need to, we could easily convert version-sensitive sibling pages into “picker” pages
283+
284+
### Examples
285+
286+
[Cloud Hosted deployment billing dimensions](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/deploy-manage/cloud-organization/billing/cloud-hosted-deployment-billing-dimensions.html)
287+
288+
and its sibling
289+
290+
[{{serverless-short}} project billing dimensions](https://docs-v3-preview.elastic.dev/elastic/docs-content/tree/main/deploy-manage/cloud-organization/billing/serverless-project-billing-dimensions.html)

0 commit comments

Comments
 (0)