[Rename] missed kibana references in project (#37) (#183)

Signed-off-by: Bishoy Boktor <[email protected]>

packages/README.md

@@ -1,6 +1,6 @@
-# Kibana-related packages
+# OpenSearch Dashboards-related packages
 
-This folder contains packages that are intended for use in Kibana and Kibana
+This folder contains packages that are intended for use in OpenSearch Dashboards and OpenSearch Dashboards
 plugins.
 
 tl;dr:
@@ -15,19 +15,19 @@ We no longer publish these packages to the npm registry. Now, instead of
 specifying a version when including these packages, we rely on yarn workspaces,
 which sets up a symlink to the package.
 
-For example if you want to use the `@osd/i18n` package in Kibana itself, you
+For example if you want to use the `@osd/i18n` package in OpenSearch Dashboards itself, you
 can specify the dependency like this:
 
 ```
 "@osd/i18n": "1.0.0"
 ```
 
-However, if you want to use this from a Kibana plugin, you need to use a `link:`
-dependency and account for the relative location of the Kibana repo, so it would
+However, if you want to use this from a OpenSearch Dashboards plugin, you need to use a `link:`
+dependency and account for the relative location of the OpenSearch Dashboards repo, so it would
 instead be:
 
 ```
-"@osd/i18n": "link:../../kibana/packages/osd-i18n"
+"@osd/i18n": "link:../../opensearch-dashboards/packages/osd-i18n"
 ```
 
 How all of this works is described in more detail in the
@@ -49,18 +49,18 @@ Currently there are two patterns used to test packages, one using Mocha and one
 ### 1. Mocha
 Today a package can follow the pattern of having a `__tests__` directory in each source code directory of a package which contains the tests for that module. These are usually run by Mocha.
 
-If a package's tests should be run with Mocha, you'll have to opt-in to run them by appending the package's test file pattern(s) to Kibana's `src/dev/mocha/run_mocha_cli.js` file. These will then be run by the unit test runner.
+If a package's tests should be run with Mocha, you'll have to opt-in to run them by appending the package's test file pattern(s) to OpenSearch Dashboards's `src/dev/mocha/run_mocha_cli.js` file. These will then be run by the unit test runner.
 
 * `yarn test` or `yarn grunt test` runs all unit tests.
 * `node scripts/mocha` runs all Mocha tests.
 
 ### 2. Jest
 A package can also follow the pattern of having `.test.js` files as siblings of the source code files, and these run by Jest.
 
-A package using the `.test.js` naming convention will have those tests automatically picked up by Jest and run by the unit test runner, currently mapped to the Kibana `test` script in the root `package.json`.
+A package using the `.test.js` naming convention will have those tests automatically picked up by Jest and run by the unit test runner, currently mapped to the OpenSearch Dashboards `test` script in the root `package.json`.
 
 * `yarn test` or `yarn grunt test` runs all unit tests.
-* `node scripts/jest` runs all Jest tests in Kibana.
+* `node scripts/jest` runs all Jest tests in OpenSearch Dashboards.
 
 ----
 Each package can also specify its own `test` script in the package's `package.json`, for cases where you'd prefer to run the tests from the local package directory.

packages/kbn-release-notes/package.json

@@ -3,7 +3,7 @@
   "version": "1.0.0",
   "license": "Apache-2.0",
   "main": "target/index.js",
-  "kibana": {
+  "opensearchDashboards": {
     "devOnly": true
   },
   "scripts": {

packages/kbn-release-notes/src/formats/asciidoc.ts

@@ -73,7 +73,7 @@ export class AsciidocFormat extends Format {
         for (const pr of prsInArea) {
           const fixes = pr.fixes.length ? `[Fixes ${pr.fixes.join(', ')}] ` : '';
           const strippedTitle = pr.title.replace(/^\s*\[[^\]]+\]\s*/, '');
-          yield `* ${fixes}${strippedTitle} {kibana-pull}${pr.number}[#${pr.number}]\n`;
+          yield `* ${fixes}${strippedTitle} {opensearch-dashboards-pull}${pr.number}[#${pr.number}]\n`;
           if (pr.note) {
             yield `  - ${pr.note}\n`;
           }

packages/osd-test/src/failed_tests_reporter/issue_metadata.test.ts

@@ -26,23 +26,23 @@ const HAS_METADATA = dedent`
 
   some text
 
-  <!-- kibanaCiData = {"failed-test": {"foo": "bar"}} -->
+  <!-- opensearchDashboardsCiData = {"failed-test": {"foo": "bar"}} -->
 `;
 
 const HAS_SOME_OTHER_METADATA = dedent`
   # my issue
 
   some text
 
-  <!-- kibanaCiData = {"some-other": {"foo": "bar"}} -->
+  <!-- opensearchDashboardsCiData = {"some-other": {"foo": "bar"}} -->
 `;
 
 const INVALID_METADATA = dedent`
   # my issue
 
   some text
 
-  <!-- kibanaCiData = {"failed-test" -->
+  <!-- opensearchDashboardsCiData = {"failed-test" -->
 `;
 
 const MISSING_METADATA = dedent`
@@ -88,7 +88,7 @@ describe('updateIssueMetadata', () => {
 
       some text
 
-      <!-- kibanaCiData = {\\"failed-test\\":{\\"foo\\":\\"bar\\",\\"box\\":\\"baz\\"}} -->"
+      <!-- opensearchDashboardsCiData = {\\"failed-test\\":{\\"foo\\":\\"bar\\",\\"box\\":\\"baz\\"}} -->"
     `);
   });
 
@@ -102,7 +102,7 @@ describe('updateIssueMetadata', () => {
 
       some text
 
-      <!-- kibanaCiData = {\\"failed-test\\":{\\"box\\":\\"baz\\"}} -->"
+      <!-- opensearchDashboardsCiData = {\\"failed-test\\":{\\"box\\":\\"baz\\"}} -->"
     `);
 
     expect(
@@ -114,7 +114,7 @@ describe('updateIssueMetadata', () => {
 
       some text
 
-      <!-- kibanaCiData = {\\"some-other\\":{\\"foo\\":\\"bar\\"},\\"failed-test\\":{\\"box\\":\\"baz\\"}} -->"
+      <!-- opensearchDashboardsCiData = {\\"some-other\\":{\\"foo\\":\\"bar\\"},\\"failed-test\\":{\\"box\\":\\"baz\\"}} -->"
     `);
   });
 
@@ -128,7 +128,7 @@ describe('updateIssueMetadata', () => {
 
       some text
 
-      <!-- kibanaCiData = {\\"failed-test\\":{\\"box\\":\\"baz\\"}} -->"
+      <!-- opensearchDashboardsCiData = {\\"failed-test\\":{\\"box\\":\\"baz\\"}} -->"
     `);
   });
 });

packages/osd-test/src/failed_tests_reporter/report_failure.test.ts

@@ -53,7 +53,7 @@ describe('createFailureIssue()', () => {
 
       First failure: [Jenkins Build](https://build-url)
 
-      <!-- kibanaCiData = {\\"failed-test\\":{\\"test.class\\":\\"some.classname\\",\\"test.name\\":\\"test name\\",\\"test.failCount\\":1}} -->",
+      <!-- opensearchDashboardsCiData = {\\"failed-test\\":{\\"test.class\\":\\"some.classname\\",\\"test.name\\":\\"test name\\",\\"test.failCount\\":1}} -->",
             Array [
               "failed-test",
             ],
@@ -82,7 +82,7 @@ describe('updateFailureIssue()', () => {
         body: dedent`
           # existing issue body
 
-          <!-- kibanaCiData = {"failed-test":{"test.failCount":10}} -->"
+          <!-- opensearchDashboardsCiData = {"failed-test":{"test.failCount":10}} -->"
         `,
       },
       api
@@ -95,7 +95,7 @@ describe('updateFailureIssue()', () => {
             1234,
             "# existing issue body
 
-      <!-- kibanaCiData = {\\"failed-test\\":{\\"test.failCount\\":11}} -->\\"",
+      <!-- opensearchDashboardsCiData = {\\"failed-test\\":{\\"test.failCount\\":11}} -->\\"",
           ],
         ],
         "results": Array [

rfcs/text/0002_encrypted_attributes.md

@@ -1,6 +1,6 @@
 - Start Date: 2019-03-22
 - RFC PR: [#33740](https://github.com/elastic/kibana/pull/33740)
-- Kibana Issue: (leave this empty)
+- OpenSearch Dashboards Issue: (leave this empty)
 
 # Summary
 
@@ -41,7 +41,7 @@ const savedObject = await server.savedObjects
 
 ```
 
-Use dedicated method to retrieve saved object with decrypted attributes on behalf of Kibana internal user:
+Use dedicated method to retrieve saved object with decrypted attributes on behalf of OpenSearch Dashboards internal user:
 
 ```typescript
 const savedObject = await server.plugins.encrypted_saved_objects.getDecryptedAsInternalUser(
@@ -151,7 +151,7 @@ const savedObject = await server.plugins.encrypted_saved_objects.getDecryptedAsI
 ```
 
 As can be seen from the method name, the request to retrieve saved object and decrypt its attributes is performed on
-behalf of the internal Kibana user and hence isn't supposed to be called within user request context.
+behalf of the internal OpenSearch Dashboards user and hence isn't supposed to be called within user request context.
 
 **Note:** the fact that saved object with encrypted attributes is created using standard Saved Objects API within a 
 particular user and space context, but retrieved out of any context makes it unclear how consumers are supposed to 
@@ -165,9 +165,9 @@ Saved object attributes are encrypted using [@elastic/node-crypto](https://githu
 take a look at the source code of this library to know how encryption is performed exactly, what algorithm and encryption 
 parameters are used, but in short it's AES Encryption with AES-256-GCM that uses random initialization vector and salt.
 
-As with encryption key for Kibana's session cookie, master encryption key used by `encrypted_saved_objects` plugin can be
-defined as a configuration value (`xpack.encryptedSavedObjects.encryptionKey`) via `kibana.yml`, but it's **highly 
-recommended** to define this key in the [Kibana Keystore](https://www.elastic.co/guide/en/kibana/current/secure-settings.html)
+As with encryption key for OpenSearch Dashboards's session cookie, master encryption key used by `encrypted_saved_objects` plugin can be
+defined as a configuration value (`xpack.encryptedSavedObjects.encryptionKey`) via `opensearch_dashboards.yml`, but it's **highly 
+recommended** to define this key in the [OpenSearch Dashboards Keystore](https://www.elastic.co/guide/en/kibana/current/secure-settings.html)
 instead. The master key should be cryptographically safe and be equal or greater than 32 bytes.
 
 To prevent certain vectors of attacks where raw content of encrypted attributes of one saved object is copied to another
@@ -190,7 +190,7 @@ into AAD (e.g some user defined content associated with the email action or aler
 ## Audit
 
 Encrypted attributes will most likely contain sensitive information and any attempt to access these should be properly
-logged to allow any further audit procedures. The following events will be logged with Kibana audit log functionality:
+logged to allow any further audit procedures. The following events will be logged with OpenSearch Dashboards audit log functionality:
 
 * Successful attempt to encrypt attributes (incl. saved object ID, type and attributes names)
 * Failed attempt to encrypt attribute (incl. saved object ID, type and attribute name)
@@ -223,7 +223,7 @@ handler.
 # Out of scope
 
 * Encryption key rotation mechanism, either regular or emergency
-* Mechanism that would detect and warn when Kibana does not use keystore to store encryption key
+* Mechanism that would detect and warn when OpenSearch Dashboards does not use keystore to store encryption key
 
 # Alternatives
 

rfcs/text/0004_application_service_mounting.md

@@ -1,6 +1,6 @@
 - Start Date: 2019-05-10
 - RFC PR: (leave this empty)
-- Kibana Issue: (leave this empty)
+- OpenSearch Dashboards Issue: (leave this empty)
 
 # Summary
 
@@ -181,20 +181,20 @@ Plugins can also register additional context attributes via the
 
 ## Routing
 
-The ApplicationService will serve as the global frontend router for Kibana,
-enabling Kibana to be a 100% single page application. However, the router will
+The ApplicationService will serve as the global frontend router for OpenSearch Dashboards,
+enabling OpenSearch Dashboards to be a 100% single page application. However, the router will
 only manage top-level routes. Applications themselves will need to implement
 their own routing as subroutes of the top-level route.
 
 An example:
 - "MyApp" is registered with `id: 'my-app'`
-- User navigates from mykibana.com/app/home to mykibana.com/app/my-app
+- User navigates from myopensearchDashboards.com/app/home to myopensearchDashboards.com/app/my-app
 - ApplicationService sees the root app has changed and mounts the new
   application:
   - Calls the `Unmount` function returned my "Home"'s `mount`
   - Calls the `mount` function registered by "MyApp"
 - MyApp's internal router takes over rest of routing. Redirects to initial
-  "overview" page: mykibana.com/app/my-app/overview
+  "overview" page: myopensearchDashboards.com/app/my-app/overview
 
 When setting up a router, your application should only handle the part of the
 URL following the `params.appBasePath` provided when you application is mounted.
@@ -215,7 +215,7 @@ starting a full-page refresh rather than a mounting cycle.
 
 Here is a complete example that demonstrates rendering a React application with
 a full-featured router and code-splitting. Note that using React or any other
-3rd party tools featured here is not required to build a Kibana Application.
+3rd party tools featured here is not required to build a OpenSearch Dashboards Application.
 
 ```tsx
 // my_plugin/public/application.tsx
@@ -234,10 +234,10 @@ const MyApp = ({ basename }) => (
   // Setup router's basename from the basename provided from MountContext
   <BrowserRouter basename={basename}>
 
-    {/* mykibana.com/app/my-app/ */}
+    {/* myopensearchDashboards.com/app/my-app/ */}
     <Route path="/" exact component={HomePage} />
 
-    {/* mykibana.com/app/my-app/dashboard/42 */}
+    {/* myopensearchDashboards.com/app/my-app/dashboard/42 */}
     <Route
       path="/dashboard/:id"
       render={({ match }) => <LazyDashboard dashboardId={match.params.id} />}
@@ -287,7 +287,7 @@ have a bundle for.
 
 - Implementing this will be significant work and requires migrating legacy code
   from `ui/chrome`
-- Making Kibana a single page application may lead to problems if applications
+- Making OpenSearch Dashboards a single page application may lead to problems if applications
   do not clean themselves up properly when unmounted
 - Application `mount` functions will have access to *setup* via the closure. We
   may want to lock down these APIs from being used after *setup* to encourage
@@ -313,14 +313,14 @@ over to the new platform.
 
 # How we teach this
 
-Introducing this service makes applications a first-class feature of the Kibana
+Introducing this service makes applications a first-class feature of the OpenSearch Dashboards
 platform. Right now, plugins manage their own routes and can export "navlinks"
 that get rendered in the navigation UI, however there is a not a self-contained
 concept like an application to encapsulate these related responsibilities. It
 will need to be emphasized that plugins can register zero, one, or multiple
 applications.
 
-Most new and existing Kibana developers will need to understand how the
+Most new and existing OpenSearch Dashboards developers will need to understand how the
 ApplicationService works and how multiple apps run in a single page application.
 This should be accomplished through thorough documentation in the
 ApplicationService's API implementation as well as in general plugin development

rfcs/text/0012_encryption_key_rotation.md

@@ -8,7 +8,7 @@ This RFC proposes a way of the encryption key (`xpack.encryptedSavedObjects.encr
 
 # Basic example
 
-When administrators decide to rotate encryption key they will have to generate a new one and move the old key(s) to the `keyRotation` section in the `kibana.yml`:
+When administrators decide to rotate encryption key they will have to generate a new one and move the old key(s) to the `keyRotation` section in the `opensearch_dashboards.yml`:
 
 ```yaml
 xpack.encryptedSavedObjects:
@@ -31,7 +31,7 @@ Today when encryption key changes we can no longer decrypt Saved Objects attribu
 
 * If consumers explicitly request decryption via  `getDecryptedAsInternalUser()` we abort operation and throw exception.
 * If consumers fetch Saved Objects with encrypted attributes that should be automatically decrypted (the ones with `dangerouslyExposeValue: true` marker) via standard Saved Objects APIs we don't abort operation, but rather strip all encrypted attributes from the response and record decryption error in the `error` Saved Object field.
-* If Kibana tries to migrate encrypted Saved Objects at the start up time we abort operation and throw exception. 
+* If OpenSearch Dashboards tries to migrate encrypted Saved Objects at the start up time we abort operation and throw exception. 
 
 In both of these cases we throw or record error with the specific type to allow consumers to gracefully handle this scenario and either drop Saved Objects with unrecoverable encrypted attributes or facilitate the process of re-entering and re-encryption of the new values.
 
@@ -49,7 +49,7 @@ In this scenario a new encryption key (primary encryption key) will be generated
 
 The old old decryption-only keys should be eventually disposed and users should have a way to make sure all existing Saved Objects are re-encrypted with the new primary encryption key.
 
-__NOTE:__ users can get into a state when different Saved Objects are encrypted with different encryption keys even if they didn't intend to rotate the encryption key. We anticipate that it can happen during initial Elastic Stack HA setup, when by mistake or intentionally different Kibana instances were using different encryption keys. Key rotation mechanism can help to fix this issue without a data loss.
+__NOTE:__ users can get into a state when different Saved Objects are encrypted with different encryption keys even if they didn't intend to rotate the encryption key. We anticipate that it can happen during initial Elastic Stack HA setup, when by mistake or intentionally different OpenSearch Dashboards instances were using different encryption keys. Key rotation mechanism can help to fix this issue without a data loss.
 
 # Detailed design
 
@@ -72,9 +72,9 @@ Technically just having `decryptionOnlyKeys` would be enough to cover the majori
 
 We'd like to make this process as simple as possible while meeting the following requirements:
 
-* It should not be required to restart Kibana to perform this type of migration since Saved Objects encrypted with the another encryption key can theoretically appear at any point in time.
+* It should not be required to restart OpenSearch Dashboards to perform this type of migration since Saved Objects encrypted with the another encryption key can theoretically appear at any point in time.
 * It should be possible to integrate this operation into other operational flows our users may have and any user-friendly key management UIs we may introduce in this future.
-* Any possible failures that may happen during this operation shouldn't make Kibana nonfunctional.
+* Any possible failures that may happen during this operation shouldn't make OpenSearch Dashboards nonfunctional.
 * Ordinary users should not be able to trigger this migration since it may consume a considerable amount of computing resources.
 
 We think that the best option we have right now is a dedicated API endpoint that would trigger this migration:
@@ -93,7 +93,7 @@ As for any other encryption or decryption operation we'll record relevant bits i
 
 # Benefits
 
-* The concept of decryption-only keys is easy to grasp and allows Kibana to function even if it has a mix of Saved Objects encrypted with different encryption keys.
+* The concept of decryption-only keys is easy to grasp and allows OpenSearch Dashboards to function even if it has a mix of Saved Objects encrypted with different encryption keys.
 * Support of the key rotation out of the box decreases the chances of the data loss and makes `EncryptedSavedObjects` story more secure and approachable overall.
 
 # Drawbacks
@@ -103,7 +103,7 @@ As for any other encryption or decryption operation we'll record relevant bits i
 
 # Alternatives
 
-We cannot think of any better alternative for `decryptionOnlyKeys` at the moment, but instead of API endpoint for the batch re-encryption we could potentially use another `kibana.yml` config option. For example `keyRotation.mode: onWrite | onStart | both`, but it feels a bit hacky and cannot be really integrated with anything else.
+We cannot think of any better alternative for `decryptionOnlyKeys` at the moment, but instead of API endpoint for the batch re-encryption we could potentially use another `opensearch_dashboards.yml` config option. For example `keyRotation.mode: onWrite | onStart | both`, but it feels a bit hacky and cannot be really integrated with anything else.
 
 # Adoption strategy
 

src/core/public/application/utils/relative_to_absolute.ts

@@ -24,7 +24,7 @@
  *
  * @example
  * ```ts
- * // current url: `https://kibana:8000/base-path/app/my-app`
+ * // current url: `https://opensearch-dashboards:8000/base-path/app/my-app`
  * relativeToAbsolute('/base-path/app/another-app') => `https://opensearch-dashboards:8000/base-path/app/another-app`
  * ```
  */