diff --git a/REBRANDING-PLAN.md b/REBRANDING-PLAN.md index 1673f69..629e52d 100644 --- a/REBRANDING-PLAN.md +++ b/REBRANDING-PLAN.md @@ -319,9 +319,9 @@ Directory: `docs/overview/design/arch-decision-records/` | ------------------------------------------------------------ | --------------------------- | | `https://github.com/NASA-AMMOS/aerie` | Update to new repo or keep? | | `https://github.com/NASA-AMMOS/aerie-docs` | Update to new repo | -| `https://github.com/NASA-AMMOS/aerie-ui` | Update to new repo | -| `https://github.com/NASA-AMMOS/aerie-mission-model-template` | Update to new repo | -| `https://github.com/NASA-AMMOS/aerie-gateway` | Update to new repo | +| `https://github.com/NASA-AMMOS/plandev-ui` | Update to new repo | +| `https://github.com/NASA-AMMOS/plandev-mission-model-template` | Update to new repo | +| `https://github.com/NASA-AMMOS/plandev-gateway` | Update to new repo | ### 8.2 Email Addresses @@ -340,7 +340,7 @@ Directory: `docs/overview/design/arch-decision-records/` | Current | New | | ------------------------------------------ | --- | -| `https://nasa-ammos.github.io/aerie-docs/` | TBD | +| `https://nasa-ammos.github.io/plandev-docs/` | TBD | --- diff --git a/docs/api/examples/external-events.mdx b/docs/api/examples/external-events.mdx index bb0d904..34f95fc 100644 --- a/docs/api/examples/external-events.mdx +++ b/docs/api/examples/external-events.mdx @@ -3,11 +3,11 @@ Refer to [External Events](../../../planning/external-events/introduction) for more information on External Events & Sources. ## API Gateway -External Events & their respective External Sources utilize routes located on [`aerie-gateway`](https://github.com/NASA-AMMOS/aerie-gateway) to perform data validation and upon success, an upload through Hasura/GQL. +External Events & their respective External Sources utilize routes located on [`plandev-gateway`](https://github.com/NASA-AMMOS/plandev-gateway) to perform data validation and upon success, an upload through Hasura/GQL. ### Creating External Source & Event Types -To upload schemas for External Sources and Events, users should POST to the `/uploadExternalSourceEventTypes` route in `aerie-gateway`. +To upload schemas for External Sources and Events, users should POST to the `/uploadExternalSourceEventTypes` route in `plandev-gateway`. The body of the request should be a JSON object with this structure: @@ -51,7 +51,7 @@ This endpoint expects data provided in [`multipart/form-data` format](https://ww -When uploading through PlanDev's UI, the External Source & it's contained External Events are packaged together in a single `JSON` file which adheres to the meta-schema defined [here](https://github.com/NASA-AMMOS/aerie-gateway/blob/develop/src/schemas/external-event-validation-schemata.ts). A `derivation_group_name` can be passed in as an argument with the request which will override any value for `derivation_group_name` in the External Source. This argument can be ignored if there is a value for `derivation_group_name` in the External Source. +When uploading through PlanDev's UI, the External Source & it's contained External Events are packaged together in a single `JSON` file which adheres to the meta-schema defined [here](https://github.com/NASA-AMMOS/plandev-gateway/blob/develop/src/schemas/external-event-validation-schemata.ts). A `derivation_group_name` can be passed in as an argument with the request which will override any value for `derivation_group_name` in the External Source. This argument can be ignored if there is a value for `derivation_group_name` in the External Source. :::info Note diff --git a/docs/command-expansion/sequences.mdx b/docs/command-expansion/sequences.mdx index 36fb28c..d605923 100644 --- a/docs/command-expansion/sequences.mdx +++ b/docs/command-expansion/sequences.mdx @@ -36,7 +36,7 @@ We are exploring several options to mitigate the rework. ::: -This page will pick up after the third step. +This page will pick up after the third step. To create a filter, select the following: @@ -45,7 +45,7 @@ To create a filter, select the following:
Figure 2: Sequence Filter Creation
-name it, and then select all relevant options to narrow down the set of simulated activities that you would like to associate with the sequence you will be creating. +name it, and then select all relevant options to narrow down the set of simulated activities that you would like to associate with the sequence you will be creating.
PlanDev UI - Sequence Filter Options @@ -83,6 +83,6 @@ PlanDev recommends automating the seqID declaration and seqID-activity associati ## Command Sorting -As of PlanDev [v1.5.0](https://github.com/NASA-AMMOS/aerie/releases/tag/v1.5.0), during expansion if more than one activity targets a single sequence then the commands are sorted time-ascending if all commands use either absolute or relative time tags, and the first command for each activity uses an absolute time tag. Otherwise none of the commands are sorted. If the commands are sorted then all time tags are converted to absolute time. +As of PlanDev [v1.5.0](https://github.com/NASA-AMMOS/plandev/releases/tag/v1.5.0), during expansion if more than one activity targets a single sequence then the commands are sorted time-ascending if all commands use either absolute or relative time tags, and the first command for each activity uses an absolute time tag. Otherwise none of the commands are sorted. If the commands are sorted then all time tags are converted to absolute time. Additionally a `timeSorted` boolean property has been added to the expanded sequence `metadata` indicating if the commands have been sorted (true for sorted, false otherwise). diff --git a/docs/deployment/advanced-authentication.mdx b/docs/deployment/advanced-authentication.mdx index 83088d3..5a6a21b 100644 --- a/docs/deployment/advanced-authentication.mdx +++ b/docs/deployment/advanced-authentication.mdx @@ -14,7 +14,7 @@ To learn how to programmatically authenticate with PlanDev to get a token, see t ## Service Environment Variables -The default PlanDev [docker-compose.yml](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/docker-compose.yml) file requires certain environment variables to be set to enable authentication. This section outlines the variable definitions and the services that require them for authentication. +The default PlanDev [docker-compose.yml](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/docker-compose.yml) file requires certain environment variables to be set to enable authentication. This section outlines the variable definitions and the services that require them for authentication. ### AUTH_GROUP_ROLE_MAPPINGS - Description: Optional JSON object that maps LDAP groups to allowed PlanDev roles. diff --git a/docs/deployment/advanced-database-migrations-OLD.mdx b/docs/deployment/advanced-database-migrations-OLD.mdx index 80ef4ea..93229f7 100644 --- a/docs/deployment/advanced-database-migrations-OLD.mdx +++ b/docs/deployment/advanced-database-migrations-OLD.mdx @@ -5,18 +5,18 @@ For PlanDev deployments AFTER to v3.3.0, please reference [this page](../advance for accurate information as to how the migration script works. ::: -To aid in migrating between database versions we provide a Python script called [aerie_db_migration.py](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/aerie_db_migration). In order to run it, the following software is required: +To aid in migrating between database versions we provide a Python script called [aerie_db_migration.py](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/aerie_db_migration). In order to run it, the following software is required: - [Python 3.9](https://www.python.org/downloads/) or later - [Hasura CLI 2.35.1](https://hasura.io/docs/latest/hasura-cli/install-hasura-cli/) or later -Additional Python package requirements can be installed by running the following command in the [deployment](https://github.com/NASA-AMMOS/aerie/tree/develop/deployment) directory: +Additional Python package requirements can be installed by running the following command in the [deployment](https://github.com/NASA-AMMOS/plandev/tree/develop/deployment) directory: ```sh python -m pip install -r requirements.txt ``` -Once the prerequisite software has been installed, the script can be executed by running the following command from inside the PlanDev [deployment](https://github.com/NASA-AMMOS/aerie/tree/develop/deployment) directory: +Once the prerequisite software has been installed, the script can be executed by running the following command from inside the PlanDev [deployment](https://github.com/NASA-AMMOS/plandev/tree/develop/deployment) directory: ```sh python aerie_db_migration.py diff --git a/docs/deployment/advanced-database-migrations.mdx b/docs/deployment/advanced-database-migrations.mdx index 08526a4..4621308 100644 --- a/docs/deployment/advanced-database-migrations.mdx +++ b/docs/deployment/advanced-database-migrations.mdx @@ -5,18 +5,18 @@ For PlanDev deployments PRIOR to v3.3.0, please reference [this page](../advance for accurate information as to how the migration script works. ::: -To aid in migrating between database versions we provide a Python script called [aerie_db_migration.py](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/aerie_db_migration). In order to run it, the following software is required: +To aid in migrating between database versions we provide a Python script called [aerie_db_migration.py](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/aerie_db_migration). In order to run it, the following software is required: - [Python 3.9](https://www.python.org/downloads/) or later - [Hasura CLI 2.35.1](https://hasura.io/docs/latest/hasura-cli/install-hasura-cli/) or later -Additional Python package requirements can be installed by running the following command in the [deployment](https://github.com/NASA-AMMOS/aerie/tree/develop/deployment) directory: +Additional Python package requirements can be installed by running the following command in the [deployment](https://github.com/NASA-AMMOS/plandev/tree/develop/deployment) directory: ```sh python -m pip install -r requirements.txt ``` -Once the prerequisite software has been installed, the script can be executed by running the following command from inside the PlanDev [deployment](https://github.com/NASA-AMMOS/aerie/tree/develop/deployment) directory: +Once the prerequisite software has been installed, the script can be executed by running the following command from inside the PlanDev [deployment](https://github.com/NASA-AMMOS/plandev/tree/develop/deployment) directory: ```sh python aerie_db_migration.py diff --git a/docs/deployment/advanced-kubernetes.mdx b/docs/deployment/advanced-kubernetes.mdx index bb302f8..a1dd75c 100644 --- a/docs/deployment/advanced-kubernetes.mdx +++ b/docs/deployment/advanced-kubernetes.mdx @@ -92,7 +92,7 @@ kubectl set image deployment/aerie-ui-deployment aerie-ui=ghcr.io/nasa-ammos/aer ## Within PlanDev context -PlanDev is provided as a set of container images, which makes it a perfect match for a Kubernetes deployment. Manifests for PlanDev on Kubernetes are provided in the [PlanDev repo](https://github.com/NASA-AMMOS/aerie/tree/develop/deployment/kubernetes). These manifests create `Deployments` for each of the PlanDev services, e.g. `aerie-merlin`, `hasura`, etc. with one replica of each `Pod`. An existing Kubernetes cluster will be needed. See one of the following sections for instructions on spinning up a cluster varying environments. +PlanDev is provided as a set of container images, which makes it a perfect match for a Kubernetes deployment. Manifests for PlanDev on Kubernetes are provided in the [PlanDev repo](https://github.com/NASA-AMMOS/plandev/tree/develop/deployment/kubernetes). These manifests create `Deployments` for each of the PlanDev services, e.g. `aerie-merlin`, `hasura`, etc. with one replica of each `Pod`. An existing Kubernetes cluster will be needed. See one of the following sections for instructions on spinning up a cluster varying environments. ## Local Kubernetes deployment diff --git a/docs/deployment/advanced-permissions.mdx b/docs/deployment/advanced-permissions.mdx index 60aab37..bc33e0a 100644 --- a/docs/deployment/advanced-permissions.mdx +++ b/docs/deployment/advanced-permissions.mdx @@ -18,7 +18,7 @@ it is strongly recommended to give your role *at least* the same permissions as ### Adding the Role to Hasura -In order to interact with the PlanDev system, a role must first be provided access via the [Hasura Metadata](https://github.com/NASA-AMMOS/aerie/tree/develop/deployment/hasura/metadata). +In order to interact with the PlanDev system, a role must first be provided access via the [Hasura Metadata](https://github.com/NASA-AMMOS/plandev/tree/develop/deployment/hasura/metadata). There are three parts of the Hasura Metadata that a role needs to be added to: Functions, Actions, and individual tables. The Hasura Metadata can be found in `hasura/metadata`. @@ -362,7 +362,7 @@ By default, users will use the `user` role and have access to the `user` and `vi To configure this, use the `ALLOWED_ROLES` and `DEFAULT_ROLE` environment variables. **Note: `DEFAULT_ROLE` _must_ be an entry in `ALLOWED_ROLES`.** -For more information, see the [Environment Variables document](https://github.com/NASA-AMMOS/aerie-gateway/blob/develop/docs/ENVIRONMENT.md) in the Gateway. +For more information, see the [Environment Variables document](https://github.com/NASA-AMMOS/plandev-gateway/blob/develop/docs/ENVIRONMENT.md) in the Gateway. :::info When Authentication is Disabled [If authentication is disabled](../advanced-authentication/), then the following changes apply: diff --git a/docs/deployment/advanced-ui-custom-base-path.md b/docs/deployment/advanced-ui-custom-base-path.md index 37da307..d7fbee1 100644 --- a/docs/deployment/advanced-ui-custom-base-path.md +++ b/docs/deployment/advanced-ui-custom-base-path.md @@ -4,21 +4,21 @@ This document lists the instructions for building an aerie-ui Docker image with ### Building -1. Clone the [aerie-ui](https://github.com/NASA-AMMOS/aerie-ui) and install dependencies. Note that [Node LTS](https://nodejs.org/) is required (currently 18.13.0). +1. Clone the [aerie-ui](https://github.com/NASA-AMMOS/plandev-ui) and install dependencies. Note that [Node LTS](https://nodejs.org/) is required (currently 18.13.0). ```sh - git clone https://github.com/NASA-AMMOS/aerie-ui.git + git clone https://github.com/NASA-AMMOS/plandev-ui.git cd aerie-ui npm install ``` - When you clone aerie-ui the default branch is [develop](https://github.com/NASA-AMMOS/aerie-ui/tree/develop). If you want to build an image from a [specific release](https://github.com/NASA-AMMOS/aerie-ui/releases) you have to checkout the proper tag. For example to checkout [v1.0.0](https://github.com/NASA-AMMOS/aerie-ui/releases/tag/v1.0.0) do: + When you clone aerie-ui the default branch is [develop](https://github.com/NASA-AMMOS/plandev-ui/tree/develop). If you want to build an image from a [specific release](https://github.com/NASA-AMMOS/plandev-ui/releases) you have to checkout the proper tag. For example to checkout [v1.0.0](https://github.com/NASA-AMMOS/plandev-ui/releases/tag/v1.0.0) do: ```sh git checkout tags/v1.0.0 -b v1.0.0 ``` -2. Update [svelte.config.js](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/svelte.config.js) with the [base path](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/svelte.config.js#L9) you want to use. Note that a leading `/` is required. So for example a valid base path is `/aerie`. +2. Update [svelte.config.js](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/svelte.config.js) with the [base path](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/svelte.config.js#L9) you want to use. Note that a leading `/` is required. So for example a valid base path is `/aerie`. 3. Build the aerie-ui. @@ -32,7 +32,7 @@ This document lists the instructions for building an aerie-ui Docker image with docker build -t aerie-ui . ``` -5. Use the newly built image as part of your normal [PlanDev Docker deployment](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/docker-compose.yml#L132). +5. Use the newly built image as part of your normal [PlanDev Docker deployment](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/docker-compose.yml#L132). ### Cleaning @@ -52,8 +52,8 @@ docker rmi aerie-ui ### References -1. [aerie-ui Developer.md](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/docs/DEVELOPER.md) -1. [aerie-ui Deployment.md](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/docs/DEPLOYMENT.md) +1. [aerie-ui Developer.md](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/docs/DEVELOPER.md) +1. [aerie-ui Deployment.md](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/docs/DEPLOYMENT.md) ### Svelte Kit Issues diff --git a/docs/deployment/introduction.md b/docs/deployment/introduction.md index e243c5d..f944650 100644 --- a/docs/deployment/introduction.md +++ b/docs/deployment/introduction.md @@ -4,19 +4,19 @@ There are a few different ways to deploy PlanDev: - To get PlanDev running **quickly** on your computer, see the [fast track instructions](/introduction/#fast-track) for minimal setup. - If you plan to deploy PlanDev in a shared **production environment**, read this entire page and then see the [production deployment guide](/deployment/production-deployment). -- If you are a **developer** and you want to run PlanDev locally & make changes to PlanDev core code, read this page and then head to the [developer guide](https://github.com/NASA-AMMOS/aerie/blob/develop/docs/DEVELOPER.md) in the repository for local setup instructions. +- If you are a **developer** and you want to run PlanDev locally & make changes to PlanDev core code, read this page and then head to the [developer guide](https://github.com/NASA-AMMOS/plandev/blob/develop/docs/DEVELOPER.md) in the repository for local setup instructions. The rest of this document goes into more depth about the PlanDev system and how it should be deployed, regardless of environment. ## PlanDev Releases -PlanDev releases are published on the [Github Releases page](https://github.com/NASA-AMMOS/aerie/releases), and each release has a `Deployment.zip` artifact attached. This folder contains everything necessary to deploy a version of PlanDev - namely the **`docker-compose.yml`** and **`.env`** files, detailed below. These files are provided _as a starting point_ and should be modified to suit your needs. +PlanDev releases are published on the [Github Releases page](https://github.com/NASA-AMMOS/plandev/releases), and each release has a `Deployment.zip` artifact attached. This folder contains everything necessary to deploy a version of PlanDev - namely the **`docker-compose.yml`** and **`.env`** files, detailed below. These files are provided _as a starting point_ and should be modified to suit your needs. ## Environment Variables -Each PlanDev service is configured with environment variables, some of which are **required** to run. They are expected to be set in a `.env` file in the folder you're running PlanDev from. The version of this file provided in `Deployment.zip` is an empty template that must be filled in with service usernames and passwords of your choosing. See [this .env.template file](https://github.com/NASA-AMMOS/aerie-mission-model-template/blob/main/.env.template) for a completed example. +Each PlanDev service is configured with environment variables, some of which are **required** to run. They are expected to be set in a `.env` file in the folder you're running PlanDev from. The version of this file provided in `Deployment.zip` is an empty template that must be filled in with service usernames and passwords of your choosing. See [this .env.template file](https://github.com/NASA-AMMOS/plandev-mission-model-template/blob/main/.env.template) for a completed example. -A description of allowed variables is found in the [Environment Variable Documentation](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/Environment.md) - it's recommended to read through these & determine which are relevant to your situation. +A description of allowed variables is found in the [Environment Variable Documentation](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/Environment.md) - it's recommended to read through these & determine which are relevant to your situation. Of note, the `aerie-merlin`, `aerie_merlin_worker`, `aerie-scheduler`, and `aerie-scheduler-worker` containers can be provided additional JVM arguments - for example, allocated heap size - as environment variables. Desired JVM flags should be added to the `JAVA_OPTS` environment variable for the container being configured. @@ -87,7 +87,7 @@ Defect reports should be sent to: `plandev-support@googlegroups.com`. For chat-b [gateway]: https://github.com/orgs/NASA-AMMOS/packages/container/package/aerie-gateway [hasura]: https://github.com/orgs/NASA-AMMOS/packages/container/package/aerie-hasura [merlin]: https://github.com/orgs/NASA-AMMOS/packages/container/package/aerie-merlin -[merlin-worker]: https://github.com/NASA-AMMOS/aerie/pkgs/container/aerie-merlin-worker +[merlin-worker]: https://github.com/NASA-AMMOS/plandev/pkgs/container/aerie-merlin-worker [postgres]: https://github.com/orgs/NASA-AMMOS/packages/container/package/aerie-postgres [scheduler]: https://github.com/orgs/NASA-AMMOS/packages/container/package/aerie-scheduler [scheduler-worker]: https://github.com/orgs/NASA-AMMOS/packages/container/package/aerie-scheduler-worker diff --git a/docs/deployment/production-deployment.md b/docs/deployment/production-deployment.md index e1b47f2..bce40e0 100644 --- a/docs/deployment/production-deployment.md +++ b/docs/deployment/production-deployment.md @@ -24,13 +24,13 @@ This checklist outlines a set of steps for running a minimal production PlanDev 1. Ensure you have **Docker Engine and Docker Compose installed** on your server. We recommend following the official [Engine install guide](https://docs.docker.com/engine/install/) and [Compose install guide](https://docs.docker.com/compose/install/#scenario-two-install-the-docker-compose-plugin) for your platform, as simply running eg. `yum install docker` may install Podman instead of Docker on some platforms. 2. Ensure your server has the necessary **network ports exposed** for PlanDev services - namely, ports **80, 8080, and 9000**, unless you plan to modify these default ports in the docker-compose file. Port rules are usually configured via your server's firewall settings. See [PlanDev services & images](/deployment/introduction/#aerie-services--images) for details on services and their port assignments. If you are running on an AWS EC2 instance, you may need to set rules for the instance's *security group* to allow these ports to send & receive TCP traffic. -3. Copy the `Deployment.zip` file from an [PlanDev release](https://github.com/NASA-AMMOS/aerie/releases) to your server and extract it, for example: +3. Copy the `Deployment.zip` file from an [PlanDev release](https://github.com/NASA-AMMOS/plandev/releases) to your server and extract it, for example: ``` - curl -sLO https://github.com/NASA-AMMOS/aerie/releases/download/v3.1.1/Deployment.zip + curl -sLO https://github.com/NASA-AMMOS/plandev/releases/download/v3.1.1/Deployment.zip unzip Deployment.zip tar -xf deployment.tar ``` -4. Modify the `.env` file to fill in the required variables - see [Environment Variables](/deployment/introduction/#environment-variables). Importantly, all services need usernames and passwords set, and Hasura needs a secret key - see eg. [this completed example](https://github.com/NASA-AMMOS/aerie-mission-model-template/blob/main/.env.template). +4. Modify the `.env` file to fill in the required variables - see [Environment Variables](/deployment/introduction/#environment-variables). Importantly, all services need usernames and passwords set, and Hasura needs a secret key - see eg. [this completed example](https://github.com/NASA-AMMOS/plandev-mission-model-template/blob/main/.env.template). 5. Modify the [`docker-compose.yml` file](/deployment/introduction/#docker-composeyml) for your specific environment. - A useful pattern is to **[merge Compose files](https://docs.docker.com/compose/how-tos/multiple-compose-files/merge/)** when running PlanDev, to keep your custom compose file changes separate from the original file provided by the deployment, rather than modifying the original. You can create a file called eg. `docker-compose.prod.yml` which contains *only* the overriding changes you want to make to the original file. Then, when running your services, you can pass them both to Compose [with the `-f` flag](https://docs.docker.com/compose/how-tos/multiple-compose-files/merge/). - If you are using [CAM/SSO authentication adapters](/deployment/advanced-authentication/) and/or [a reverse proxy](/deployment/advanced-reverse-proxy/), review their docs to determine the Compose file modifications they require. @@ -68,7 +68,7 @@ It may be useful sometimes to just backup the state of your Postgres database us ### Upgrading your PlanDev Environment PlanDev releases new versions roughly every two weeks, and eventually you may want to upgrade your environment to a new version. If you want to preserve your environment's data from the previous version, you should take care to upgrade and migrate your data forward in a safe way: -* Carefully read the [changelogs on the Releases page](https://github.com/NASA-AMMOS/aerie/releases) and the [upgrade guides](https://nasa-ammos.github.io/plandev-docs/upgrade-guides/3-1-1-to-3-2-0/) for all versions between your old version and the one you're upgrading to, and keep note of any breaking changes. +* Carefully read the [changelogs on the Releases page](https://github.com/NASA-AMMOS/plandev/releases) and the [upgrade guides](https://nasa-ammos.github.io/plandev-docs/upgrade-guides/3-1-1-to-3-2-0/) for all versions between your old version and the one you're upgrading to, and keep note of any breaking changes. * Perform a backup of your database and/or Docker volumes before upgrading. * To perform the upgrade: - Stop your docker containers with `docker compose down` diff --git a/docs/deployment/upgrade-process.md b/docs/deployment/upgrade-process.md index d8f6d1d..a7f25eb 100644 --- a/docs/deployment/upgrade-process.md +++ b/docs/deployment/upgrade-process.md @@ -1,6 +1,6 @@ # Upgrade Process -This document describes how to upgrade your PlanDev deployment when a new version is released. New releases are released periodically and can be found on our [Github Releases page](https://github.com/NASA-AMMOS/aerie/releases). We recommend staying up to date with new releases as much as is practical. +This document describes how to upgrade your PlanDev deployment when a new version is released. New releases are released periodically and can be found on our [Github Releases page](https://github.com/NASA-AMMOS/plandev/releases). We recommend staying up to date with new releases as much as is practical. ## Backups @@ -13,7 +13,7 @@ Before upgrading, determine the version you are upgrading *from* and *to*. Go to Once you're prepared, follow these instructions to upgrade: -1. Find your desired release on our [Github Releases page](https://github.com/NASA-AMMOS/aerie/releases). Go to the **Assets** section, under the release notes, and download the attached **Deployment.zip** file. +1. Find your desired release on our [Github Releases page](https://github.com/NASA-AMMOS/plandev/releases). Go to the **Assets** section, under the release notes, and download the attached **Deployment.zip** file. 2. Extract the file to a location on the server where you're deploying PlanDev (or on your local machine for a local deployment). 3. Compare the contents of the new deployment directory to your existing deployment directory, and copy to the new directory any custom changes you have made to your deployment - for example, changes made while following our [Production Deployment Guide](/plandev-docs/deployment/production-deployment/#production-deployment-guide), any customizations to your `docker-compose` file, and the environment variables in `.env`. If you made a `docker-compose.prod.yml` file for your deployment, this should be copied as well. 4. Apply any necessary changes to your code or configuration that were outlined in the upgrade guides you read, to account for any breaking changes in the PlanDev API since the last version. diff --git a/docs/introduction.md b/docs/introduction.md index 3be31e2..544d477 100644 --- a/docs/introduction.md +++ b/docs/introduction.md @@ -11,7 +11,7 @@ Some of the main features of PlanDev include: - An EDSL for defining and executing activity command expansions - An EDSL for defining sequences, and a fully-featured browser-based sequence editor - A GraphQL API so you can easily build tools on top of PlanDev -- A web-based [client application](https://github.com/NASA-AMMOS/aerie-ui) +- A web-based [client application](https://github.com/NASA-AMMOS/plandev-ui) As a multi-tenant system, PlanDev allows multiple distributed users to [collaborate](https://nasa-ammos.github.io/plandev-docs/planning/collaboration/introduction/) in real-time on a single plan or concurrently work on multiple plans for multiple missions. Additionally, PlanDev's [service based architecture](https://nasa-ammos.github.io/plandev-docs/overview/software-design-document/#plandev-system-design) allows for efficient system deployment and scalability on the cloud. @@ -24,13 +24,13 @@ Understand PlanDev in **5 minutes** by trying it out! 1. If you're running macOS, Linux, or another Unix-like OS you can use following two commands in your terminal to download the [Docker Compose](https://docs.docker.com/compose/) file and `.env` file: ```sh - curl https://raw.githubusercontent.com/NASA-AMMOS/aerie-mission-model-template/main/docker-compose.yml --output docker-compose.yml - curl https://raw.githubusercontent.com/NASA-AMMOS/aerie-mission-model-template/refs/heads/main/.env.template --output .env + curl https://raw.githubusercontent.com/NASA-AMMOS/plandev-mission-model-template/main/docker-compose.yml --output docker-compose.yml + curl https://raw.githubusercontent.com/NASA-AMMOS/plandev-mission-model-template/refs/heads/main/.env.template --output .env ``` - If you're running a different OS and do not have [curl](https://curl.se/) available you can [download the docker-compose.yml here](https://raw.githubusercontent.com/NASA-AMMOS/aerie-mission-model-template/main/docker-compose.yml) and [the .env file here](https://raw.githubusercontent.com/NASA-AMMOS/aerie-mission-model-template/refs/heads/main/.env.template) (rename to `.env`). + If you're running a different OS and do not have [curl](https://curl.se/) available you can [download the docker-compose.yml here](https://raw.githubusercontent.com/NASA-AMMOS/plandev-mission-model-template/main/docker-compose.yml) and [the .env file here](https://raw.githubusercontent.com/NASA-AMMOS/plandev-mission-model-template/refs/heads/main/.env.template) (rename to `.env`). - Note that this compose file starts the [latest](https://github.com/NASA-AMMOS/aerie/releases/latest) version of PlanDev. The PlanDev version can be specified by changing the `DOCKER_TAG` variable in the `.env` file to any valid PlanDev release. + Note that this compose file starts the [latest](https://github.com/NASA-AMMOS/plandev/releases/latest) version of PlanDev. The PlanDev version can be specified by changing the `DOCKER_TAG` variable in the `.env` file to any valid PlanDev release. 1. To start the PlanDev services you can use the following command in the same directory as the `docker-compose.yml` file from the previous step: @@ -38,7 +38,7 @@ Understand PlanDev in **5 minutes** by trying it out! docker compose up ``` -1. Visit [http://localhost/](http://localhost/) to view the [PlanDev UI](https://github.com/NASA-AMMOS/aerie-ui). +1. Visit [http://localhost/](http://localhost/) to view the [PlanDev UI](https://github.com/NASA-AMMOS/plandev-ui). Note that the fast track deployment is not configured to connect to an authentication and authorization provider, therefore any credentials are accepted. @@ -46,4 +46,4 @@ Understand PlanDev in **5 minutes** by trying it out! ## Cleanup -PlanDev is an actively developed application suite with interdepenencies between the server, the web ui, and the database schema. New capabilities may require ensuring that all parts of the application are on the same version. Breaking changes are stated in the release notes. If the above fast track instructions worked previously, but are now seeing an inconsistent schema consult the [developer docs](https://github.com/NASA-AMMOS/aerie/blob/develop/docs/DEVELOPER.md) for instructions on clearing container images. For long running hosts see [Production Deployment](https://nasa-ammos.github.io/plandev-docs/deployment/production-deployment/) for an overview of the data migration process. +PlanDev is an actively developed application suite with interdepenencies between the server, the web ui, and the database schema. New capabilities may require ensuring that all parts of the application are on the same version. Breaking changes are stated in the release notes. If the above fast track instructions worked previously, but are now seeing an inconsistent schema consult the [developer docs](https://github.com/NASA-AMMOS/plandev/blob/develop/docs/DEVELOPER.md) for instructions on clearing container images. For long running hosts see [Production Deployment](https://nasa-ammos.github.io/plandev-docs/deployment/production-deployment/) for an overview of the data migration process. diff --git a/docs/mission-modeling/activity-mappers.mdx b/docs/mission-modeling/activity-mappers.mdx index 4355479..db6737e 100644 --- a/docs/mission-modeling/activity-mappers.mdx +++ b/docs/mission-modeling/activity-mappers.mdx @@ -16,7 +16,7 @@ The `ActivityMapper` interface is shown below: language="java" showLineNumbers title="PlanDev Merlin Framework - ActivityMapper.java " - url="https://raw.githubusercontent.com/NASA-AMMOS/aerie/develop/merlin-framework/src/main/java/gov/nasa/jpl/aerie/merlin/framework/ActivityMapper.java" + url="https://raw.githubusercontent.com/NASA-AMMOS/plandev/develop/merlin-framework/src/main/java/gov/nasa/jpl/aerie/merlin/framework/ActivityMapper.java" > The first thing to notice is that the interface takes a type parameter (here called `Instance`). When implementing the `ActivityMapper` interface, an activity mapper must supply the `ActivityType` being mapped. With that in mind, each of the methods shown must be implemented as such: @@ -29,11 +29,11 @@ The first thing to notice is that the interface takes a type parameter (here cal - `getValidationFailures(Instance activity)` provides a list of reasons a constructed activity is invalid, if any. Note that validation failures are different from instantiation errors. Validation failures occur when a constructed activity instance's parameters are outside acceptable range. -The `getParameters()` method returns a `Map`. In this map should be a key for every parameter, with a `ValueSchema` describing the structure of that parameter. See our [Value Schema documentation](https://github.com/NASA-AMMOS/aerie/wiki/Value-Schemas#value-schemas-from-code) for more information on creating value schemas. +The `getParameters()` method returns a `Map`. In this map should be a key for every parameter, with a `ValueSchema` describing the structure of that parameter. See our [Value Schema documentation](https://github.com/NASA-AMMOS/plandev/wiki/Value-Schemas#value-schemas-from-code) for more information on creating value schemas. ## Generated Activity Mappers -In most cases, you will likely want to let Merlin generate activity mappers for you. Thankfully, this is the done automatically when running the Merlin Annotation Processor. When compiling your code with the Merlin annotation processor, the processor will produce an activity mapper for each activity type. This is made possible by the use of the `@WithMappers()` annotations in your [package-info.java](https://github.com/NASA-AMMOS/aerie/wiki/Developing-a-Mission-Model#package-infojava). Each java-file specified by these annotations is parsed to determine what types of values can be mapped. As long as there is a mapper for each activity parameter type used in the model, the annotation processor should have no issues creating activity mappers. +In most cases, you will likely want to let Merlin generate activity mappers for you. Thankfully, this is the done automatically when running the Merlin Annotation Processor. When compiling your code with the Merlin annotation processor, the processor will produce an activity mapper for each activity type. This is made possible by the use of the `@WithMappers()` annotations in your [package-info.java](https://github.com/NASA-AMMOS/plandev/wiki/Developing-a-Mission-Model#package-infojava). Each java-file specified by these annotations is parsed to determine what types of values can be mapped. As long as there is a mapper for each activity parameter type used in the model, the annotation processor should have no issues creating activity mappers. ## Value Mappers @@ -106,11 +106,11 @@ public class Vector3DValueMapper implements ValueMapper { Notice there are just 3 methods to implement for a `ValueMapper`. The first is `getValueSchema()`, which should return a `ValueSchema` -describing the structure of the value being mapped (see [here](https://github.com/NASA-AMMOS/aerie/wiki/Value-Schemas) for more info) +describing the structure of the value being mapped (see [here](https://github.com/NASA-AMMOS/plandev/wiki/Value-Schemas) for more info) -The next two methods are inverses of each other: `deserializeValue()` and `serializeValue()`. It is the job of `deserializeValue()` to take a `SerializedValue` and map it, if possible, into the mapper's supported value. Meanwhile, `serializeValue()` takes an instance of the mapper's supported value and turns it into a [`SerializedValue`](https://github.com/NASA-AMMOS/aerie/wiki/Activity-Mappers#what-is-a-serializedvalue). +The next two methods are inverses of each other: `deserializeValue()` and `serializeValue()`. It is the job of `deserializeValue()` to take a `SerializedValue` and map it, if possible, into the mapper's supported value. Meanwhile, `serializeValue()` takes an instance of the mapper's supported value and turns it into a [`SerializedValue`](https://github.com/NASA-AMMOS/plandev/wiki/Activity-Mappers#what-is-a-serializedvalue). -There are plenty of examples of value mappers over in the [contrib module](https://github.com/NASA-AMMOS/aerie/tree/develop/contrib/src/main/java/gov/nasa/jpl/aerie/contrib/serialization/mappers). +There are plenty of examples of value mappers over in the [contrib module](https://github.com/NASA-AMMOS/plandev/tree/develop/contrib/src/main/java/gov/nasa/jpl/aerie/contrib/serialization/mappers). ### AutoValueMapper.Record diff --git a/docs/mission-modeling/activity-types/introduction.mdx b/docs/mission-modeling/activity-types/introduction.mdx index a739427..e8643d0 100644 --- a/docs/mission-modeling/activity-types/introduction.mdx +++ b/docs/mission-modeling/activity-types/introduction.mdx @@ -12,7 +12,7 @@ For example, here is a simple activity type from the examples in the template mi language="java" showLineNumbers title="PlanDev Mission Model Template - CollectData.java" - url="https://raw.githubusercontent.com/NASA-AMMOS/aerie-mission-model-template/main/missionmodel/examples/CollectData.java" + url="https://raw.githubusercontent.com/NASA-AMMOS/plandev-mission-model-template/main/missionmodel/examples/CollectData.java" > PlanDev automatically generates parameter serialization boilerplate for every activity type defined in the mission model's [package-info.java](../introduction.mdx#the-package-infojava-file). diff --git a/docs/mission-modeling/advanced-incons.mdx b/docs/mission-modeling/advanced-incons.mdx index 8bec1cf..483e719 100644 --- a/docs/mission-modeling/advanced-incons.mdx +++ b/docs/mission-modeling/advanced-incons.mdx @@ -1,7 +1,7 @@ # Advanced - Incons It is possible to initialize the internal state of your model via an initial conditions (incons) file. -This page will go over one way to do so, using a simplified version of [the Banananation model](https://github.com/NASA-AMMOS/aerie/tree/develop/examples/banananation) as a reference. +This page will go over one way to do so, using a simplified version of [the Banananation model](https://github.com/NASA-AMMOS/plandev/tree/develop/examples/banananation) as a reference. Note that a different implementation may suit your model better. ## Configuration diff --git a/docs/mission-modeling/configuration.md b/docs/mission-modeling/configuration.md index afb89d5..729c355 100644 --- a/docs/mission-modeling/configuration.md +++ b/docs/mission-modeling/configuration.md @@ -6,7 +6,7 @@ A **mission model configuration** enables mission modelers to set initial missio To use a mission model configuration the `@WithConfiguration` annotation must be used within the mission model's [package-info.java](./introduction.mdx#the-package-infojava-file) to register the configuration with PlanDev. -For example, the PlanDev mission model template [package-info.java](https://github.com/NASA-AMMOS/aerie-mission-model-template/blob/main/src/main/java/missionmodel/package-info.java) makes use of this annotation: +For example, the PlanDev mission model template [package-info.java](https://github.com/NASA-AMMOS/plandev-mission-model-template/blob/main/src/main/java/missionmodel/package-info.java) makes use of this annotation: ```java @MissionModel(model = Mission.class) @@ -17,7 +17,7 @@ import gov.nasa.jpl.aerie.merlin.framework.annotations.MissionModel; import gov.nasa.jpl.aerie.merlin.framework.annotations.MissionModel.WithConfiguration; ``` -In this example `Configuration` is the class class containing all mission model configuration data. When the `@WithConfiguration` annotation is used, the model – defined within the `@MissionModel` annotation – must accept the configuration as the last constructor parameter. See [Mission.java](https://github.com/NASA-AMMOS/aerie-mission-model-template/blob/main/src/main/java/missionmodel/Mission.java): +In this example `Configuration` is the class class containing all mission model configuration data. When the `@WithConfiguration` annotation is used, the model – defined within the `@MissionModel` annotation – must accept the configuration as the last constructor parameter. See [Mission.java](https://github.com/NASA-AMMOS/plandev-mission-model-template/blob/main/src/main/java/missionmodel/Mission.java): ```java public Mission(final Registrar registrar, final Configuration config) { @@ -59,12 +59,12 @@ public record Configuration(Path initialDataPath) { } ``` -See the PlanDev [mission model examples directory](https://github.com/NASA-AMMOS/aerie/tree/develop/examples) for a demonstration of each possible style of configuration definitions: +See the PlanDev [mission model examples directory](https://github.com/NASA-AMMOS/plandev/tree/develop/examples) for a demonstration of each possible style of configuration definitions: -1. [foo-missionmodel](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/foo-missionmodel/src/main/java/gov/nasa/jpl/aerie/foomissionmodel/Configuration.java) - Uses standard `@Parameter` configuration annotations -1. [banananation](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/Configuration.java) - Uses the `@Template` annotation to define a default Configuration object (shown above) -1. [config-with-defaults](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/config-with-defaults/src/main/java/gov/nasa/jpl/aerie/configwithdefaults/Configuration.java) - Uses `@WithDefaults` to define a default for each parameter -1. [config-without-defaults](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/config-without-defaults/src/main/java/gov/nasa/jpl/aerie/configwithoutdefaults/Configuration.java) - Defined with no default arguments, requires all arguments to be supplied by the planner +1. [foo-missionmodel](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/foo-missionmodel/src/main/java/gov/nasa/jpl/aerie/foomissionmodel/Configuration.java) - Uses standard `@Parameter` configuration annotations +1. [banananation](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/Configuration.java) - Uses the `@Template` annotation to define a default Configuration object (shown above) +1. [config-with-defaults](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/config-with-defaults/src/main/java/gov/nasa/jpl/aerie/configwithdefaults/Configuration.java) - Uses `@WithDefaults` to define a default for each parameter +1. [config-without-defaults](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/config-without-defaults/src/main/java/gov/nasa/jpl/aerie/configwithoutdefaults/Configuration.java) - Defined with no default arguments, requires all arguments to be supplied by the planner The mission model may use a configuration to set initial values of resources, for example: diff --git a/docs/mission-modeling/introduction.mdx b/docs/mission-modeling/introduction.mdx index f4e128d..b8b3078 100644 --- a/docs/mission-modeling/introduction.mdx +++ b/docs/mission-modeling/introduction.mdx @@ -7,7 +7,7 @@ In PlanDev, a mission model serves activity planning needs in two ways. First, i ## Creating a Mission Model If you want to learn how to develop a mission model, head to our [mission modeling tutorial](../../tutorials/mission-modeling/introduction/), -or check out our [GitHub template mission model repository](https://github.com/NASA-AMMOS/aerie-mission-model-template) for an empty template. +or check out our [GitHub template mission model repository](https://github.com/NASA-AMMOS/plandev-mission-model-template) for an empty template. You will need a public [GitHub.com](https://github.com/) account to download the PlanDev Maven packages. If you do not want to develop a mission model and just want to try an example, you can download the [missionmodel.jar](https://github.com/NASA-AMMOS/aerie-modeling-tutorial/blob/main/missionmodel.jar) from the [PlanDev modeling tutorial repository](https://github.com/NASA-AMMOS/aerie-modeling-tutorial). @@ -21,12 +21,12 @@ A mission model must contain a [package-info.java](https://www.baeldung.com/java language="java" showLineNumbers title="PlanDev Mission Model Template - package-info.java" - url="https://raw.githubusercontent.com/NASA-AMMOS/aerie-mission-model-template/main/missionmodel/src/main/java/missionmodel/package-info.java" + url="https://raw.githubusercontent.com/NASA-AMMOS/plandev-mission-model-template/main/missionmodel/src/main/java/missionmodel/package-info.java" > This `package-info.java` identifies the top-level class representing the mission model, and registers activity types that may interact with the mission model. PlanDev processes these annotations at compile-time, generating a set of boilerplate classes which take care of interacting with the PlanDev system. -The `@WithMappers` annotation informs the annotation processor of a set of serialization rules for activity parameters of various types; the [BasicValueMappers](https://github.com/NASA-AMMOS/aerie/blob/develop/contrib/src/main/java/gov/nasa/jpl/aerie/contrib/serialization/rulesets/BasicValueMappers.java) ruleset covers most primitive Java types. Mission modelers may also create their own rulesets, specifying rules for mapping custom value types. +The `@WithMappers` annotation informs the annotation processor of a set of serialization rules for activity parameters of various types; the [BasicValueMappers](https://github.com/NASA-AMMOS/plandev/blob/develop/contrib/src/main/java/gov/nasa/jpl/aerie/contrib/serialization/rulesets/BasicValueMappers.java) ruleset covers most primitive Java types. Mission modelers may also create their own rulesets, specifying rules for mapping custom value types. If multiple mapper classes are included via the `@WithMappers` annotations, and multiple mappers declare a mapping rule to the same data type, the rule found in the earlier declared mapper will take precedence. ## The Mission Model class @@ -39,7 +39,7 @@ The top-level model is received by activities, however, so it must make accessib language="java" showLineNumbers title="PlanDev Mission Model Template - Mission.java" - url="https://raw.githubusercontent.com/NASA-AMMOS/aerie-mission-model-template/main/missionmodel/src/main/java/missionmodel/Mission.java" + url="https://raw.githubusercontent.com/NASA-AMMOS/plandev-mission-model-template/main/missionmodel/src/main/java/missionmodel/Mission.java" > Mission resources are declared using `Registrar#discrete` or `Registrar#real` functions. diff --git a/docs/mission-modeling/parameters.md b/docs/mission-modeling/parameters.md index efa9c36..4ea49aa 100644 --- a/docs/mission-modeling/parameters.md +++ b/docs/mission-modeling/parameters.md @@ -47,7 +47,7 @@ This approach is great for defining a simple record type parent class without de ### See Also -PlanDev's [config-without-defaults](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/config-without-defaults/src/main/java/gov/nasa/jpl/aerie/configwithoutdefaults/Configuration.java) example mission model makes use of this succinct style for declaring mission model configuration parameters. See the [Java documentation on Record classes](https://docs.oracle.com/en/java/javase/19/language/records.html) for more detailed information about the language feature. +PlanDev's [config-without-defaults](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/config-without-defaults/src/main/java/gov/nasa/jpl/aerie/configwithoutdefaults/Configuration.java) example mission model makes use of this succinct style for declaring mission model configuration parameters. See the [Java documentation on Record classes](https://docs.oracle.com/en/java/javase/19/language/records.html) for more detailed information about the language feature. ## Export Parameter @@ -87,7 +87,7 @@ Some mission modelers may prefer the explicitness provided by individual `@Param ### See Also -PlanDev's [foo-missionmodel](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/foo-missionmodel/src/main/java/gov/nasa/jpl/aerie/foomissionmodel/Configuration.java) example mission model makes use of this style when declaring mission model configuration parameters. +PlanDev's [foo-missionmodel](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/foo-missionmodel/src/main/java/gov/nasa/jpl/aerie/foomissionmodel/Configuration.java) example mission model makes use of this style when declaring mission model configuration parameters. ## Export Template @@ -118,7 +118,7 @@ Use `@Template` when every member variable for a parent class should be an expor ### See Also -PlanDev's [banananation](https://github.com/NASA-AMMOS/aerie/tree/develop/examples/banananation) example mission model uses this style within the [GrowBananaActivity](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/activities/GrowBananaActivity.java) and [ThrowBananaActivity](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/activities/ThrowBananaActivity.java). +PlanDev's [banananation](https://github.com/NASA-AMMOS/plandev/tree/develop/examples/banananation) example mission model uses this style within the [GrowBananaActivity](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/activities/GrowBananaActivity.java) and [ThrowBananaActivity](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/activities/ThrowBananaActivity.java). ## Export With Defaults @@ -150,4 +150,4 @@ Use `@WithDefaults` when every member variable for a parent class should be an e ### See Also -PlanDev's [config-with-defaults](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/config-with-defaults/src/main/java/gov/nasa/jpl/aerie/configwithdefaults/Configuration.java) example mission model makes use of this style within its mission model configuration. The [banananation](https://github.com/NASA-AMMOS/aerie/tree/develop/examples/banananation) example mission model uses this style in the [BakeBananaBreadActivity](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/activities/BakeBananaBreadActivity.java). +PlanDev's [config-with-defaults](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/config-with-defaults/src/main/java/gov/nasa/jpl/aerie/configwithdefaults/Configuration.java) example mission model makes use of this style within its mission model configuration. The [banananation](https://github.com/NASA-AMMOS/plandev/tree/develop/examples/banananation) example mission model uses this style in the [BakeBananaBreadActivity](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/activities/BakeBananaBreadActivity.java). diff --git a/docs/mission-modeling/resources-and-models.md b/docs/mission-modeling/resources-and-models.md index d00506d..ed00dba 100644 --- a/docs/mission-modeling/resources-and-models.md +++ b/docs/mission-modeling/resources-and-models.md @@ -12,7 +12,7 @@ Defining a resource is as simple as constructing a model of the appropriate type ## Derived Resources -A derived resource is constructed from an existing resource given a mapping transformation. For example, the [Imager class](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/foo-missionmodel/src/main/java/gov/nasa/jpl/aerie/foomissionmodel/models/Imager.java) sample model defines an "imaging in progress" resource with: +A derived resource is constructed from an existing resource given a mapping transformation. For example, the [Imager class](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/foo-missionmodel/src/main/java/gov/nasa/jpl/aerie/foomissionmodel/models/Imager.java) sample model defines an "imaging in progress" resource with: ```java this.imagingInProgress = this.imagerMode.map($ -> $ != ImagerMode.OFF); @@ -30,7 +30,7 @@ var sumResource = instrumentA.volume.resource.plus(instrumentB.volume.resource); A sampled resource allows for a new resource to be constructed from arbitrarily many existing resources/values and to be sampled once per second. This differs from a derived resource which provides a continuous mapping transformation from a single existing resource. -For example, the [Mission class](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/foo-missionmodel/src/main/java/gov/nasa/jpl/aerie/foomissionmodel/Mission.java) sample model defines a "battery state of charge" resource with: +For example, the [Mission class](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/foo-missionmodel/src/main/java/gov/nasa/jpl/aerie/foomissionmodel/Mission.java) sample model defines a "battery state of charge" resource with: ```java this.batterySoC = new SampledResource<>(() -> this.source.volume.get() - this.sink.volume.get()); @@ -44,4 +44,4 @@ Often, the semantics of the pre-existing models are not exactly what you need in A custom model is a regular Java class, extending the Model class generated for your mission model by Merlin (or the base class provided by the framework, if it’s mission-agnostic). It may implement any helper methods you’d like, and may contain any sub-models that contribute to its purpose. The only restriction is that it must not contain any mutable state of its own - all mutable state must be held by one of the basic models, or one of the internal state-management entities they use, known as "cells". -The `contrib` package is a rich source of example models. See [the repository](https://github.com/NASA-AMMOS/aerie/tree/develop/contrib/src/main/java/gov/nasa/jpl/aerie/contrib/models) for more details. +The `contrib` package is a rich source of example models. See [the repository](https://github.com/NASA-AMMOS/plandev/tree/develop/contrib/src/main/java/gov/nasa/jpl/aerie/contrib/models) for more details. diff --git a/docs/overview/design/software-design-document.mdx b/docs/overview/design/software-design-document.mdx index ce3e429..ec34d04 100644 --- a/docs/overview/design/software-design-document.mdx +++ b/docs/overview/design/software-design-document.mdx @@ -101,7 +101,7 @@ passing reactive system can exist whether the components are in the same process, in separate processes, or even separate infrastructure. For example the -[merlin-worker](https://github.com/NASA-AMMOS/aerie/tree/develop/merlin-worker) +[merlin-worker](https://github.com/NASA-AMMOS/plandev/tree/develop/merlin-worker) is a part of the Merlin bounded context. Much of PlanDev has been designed with the [DDD principle of bounded contexts](https://martinfowler.com/bliki/BoundedContext.html). Among diff --git a/docs/planning/create-plan-and-simulate.mdx b/docs/planning/create-plan-and-simulate.mdx index 8add9d9..1485db7 100644 --- a/docs/planning/create-plan-and-simulate.mdx +++ b/docs/planning/create-plan-and-simulate.mdx @@ -3,7 +3,7 @@ import firstSimulation from './assets/first-simulation.mp4'; # Create Plan and Simulate -Here we describe how to create a new plan and simulate it using the [PlanDev UI](https://github.com/NASA-AMMOS/aerie-ui). +Here we describe how to create a new plan and simulate it using the [PlanDev UI](https://github.com/NASA-AMMOS/plandev-ui). This document assumes you already uploaded a model. If you still need to upload a model, first follow the [instructions for uploading a model](../upload-mission-model) and then come back here. ## Instructions diff --git a/docs/planning/external-events/external-events-attributes.md b/docs/planning/external-events/external-events-attributes.md index fa7b4c9..f36610a 100644 --- a/docs/planning/external-events/external-events-attributes.md +++ b/docs/planning/external-events/external-events-attributes.md @@ -160,4 +160,4 @@ A complete file looks like the following: } ``` -Note that this structure provides the full expressiveness of JSON Schema syntax, allowing users to define attributes as simple primitives or complex nested structures. The full meta-schema used to validate schema files can be found [here](https://github.com/NASA-AMMOS/aerie-gateway/blob/develop/src/schemas/external-event-validation-schemata.ts). \ No newline at end of file +Note that this structure provides the full expressiveness of JSON Schema syntax, allowing users to define attributes as simple primitives or complex nested structures. The full meta-schema used to validate schema files can be found [here](https://github.com/NASA-AMMOS/plandev-gateway/blob/develop/src/schemas/external-event-validation-schemata.ts). diff --git a/docs/planning/external-events/introduction.mdx b/docs/planning/external-events/introduction.mdx index 153e42e..b23f25b 100644 --- a/docs/planning/external-events/introduction.mdx +++ b/docs/planning/external-events/introduction.mdx @@ -79,7 +79,7 @@ Currently, External Events are *not* accessible to the procedural constraints en ### External Sources **External Sources** represent a collection of External Events. When we upload External Events, we can only do so by uploading them in an External Source. -These sources are defined using [JSON Schema](https://json-schema.org/) format with a [meta-schema](https://github.com/NASA-AMMOS/aerie-gateway/blob/develop/src/schemas/external-event-validation-schemata.ts) enforced to ensure certain fields such as `key` and `start_time` are present and in the correct format. +These sources are defined using [JSON Schema](https://json-schema.org/) format with a [meta-schema](https://github.com/NASA-AMMOS/plandev-gateway/blob/develop/src/schemas/external-event-validation-schemata.ts) enforced to ensure certain fields such as `key` and `start_time` are present and in the correct format. #### Schema diff --git a/docs/planning/plan-import-export.mdx b/docs/planning/plan-import-export.mdx index 907c2d9..5f0ffc3 100644 --- a/docs/planning/plan-import-export.mdx +++ b/docs/planning/plan-import-export.mdx @@ -16,7 +16,7 @@ Note that the following data is not included in plan files: The format of these files is described by this Typescript type in the PlanDev repository: -https://github.com/NASA-AMMOS/aerie-gateway/pull/97/files#diff-aadcd2e92cdf1b17122b6fc65396f3e5603e14064d730a020b231cd30134704e +https://github.com/NASA-AMMOS/plandev-gateway/pull/97/files#diff-aadcd2e92cdf1b17122b6fc65396f3e5603e14064d730a020b231cd30134704e Future releases of PlanDev will include a JSON schema fully describing the format. diff --git a/docs/planning/plugins/introduction.mdx b/docs/planning/plugins/introduction.mdx index 8ea52fe..dbfaf38 100644 --- a/docs/planning/plugins/introduction.mdx +++ b/docs/planning/plugins/introduction.mdx @@ -1,6 +1,6 @@ # Advanced - UI Plugins -The PlanDev UI provides an client-side API for customizing various aspects of the UI. This customization is accomplished by supplying the UI with specifically named javascript files in the `static/resources` directory of the application and enabling the plugins using runtime environment variables. These plugins are run in the PlanDev UI browser context. The relevant portions of the API specification can be found on specific plugin pages below or for the entire specification please reference the PlanDev UI [plugin.ts](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/src/types/plugin.ts) type file. Plugins may also load additional supporting files from the `static/resources` directory or from external sources. Please note that additional resource requests to `static/resources/*` should be referenced as `/resources/*` given the client side routing setup. +The PlanDev UI provides an client-side API for customizing various aspects of the UI. This customization is accomplished by supplying the UI with specifically named javascript files in the `static/resources` directory of the application and enabling the plugins using runtime environment variables. These plugins are run in the PlanDev UI browser context. The relevant portions of the API specification can be found on specific plugin pages below or for the entire specification please reference the PlanDev UI [plugin.ts](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/src/types/plugin.ts) type file. Plugins may also load additional supporting files from the `static/resources` directory or from external sources. Please note that additional resource requests to `static/resources/*` should be referenced as `/resources/*` given the client side routing setup. Plugins must export an asynchronous function named `getPlugin` that returns a subset of the Plugin API. diff --git a/docs/planning/plugins/time.mdx b/docs/planning/plugins/time.mdx index 790a35d..7793d4b 100644 --- a/docs/planning/plugins/time.mdx +++ b/docs/planning/plugins/time.mdx @@ -46,7 +46,7 @@ The Time Plugin is responsible for gracefully failing when exceptions are encoun ## Example Plugins -Below is a basic example that sets the additional time formats to a single format that displays the current UTC year. For additional plugin examples, please refer to the [aerie-ui-plugin-examples](https://github.com/NASA-AMMOS/aerie-ui-plugin-examples) repository. +Below is a basic example that sets the additional time formats to a single format that displays the current UTC year. For additional plugin examples, please refer to the [aerie-ui-plugin-examples](https://github.com/NASA-AMMOS/plandev-ui-plugin-examples) repository. ```javascript // Time plugin example (time-plugin.js) diff --git a/docs/planning/timeline-editing.mdx b/docs/planning/timeline-editing.mdx index bb597be..56b2611 100644 --- a/docs/planning/timeline-editing.mdx +++ b/docs/planning/timeline-editing.mdx @@ -10,7 +10,7 @@ import timelineLineLayerEditingDemo from './assets/timeline-line-layer-editing.m # Timeline Editing -Here we describe how to edit the timeline using the [PlanDev UI](https://github.com/NASA-AMMOS/aerie-ui). For more details on the full timeline definition please refer to the [UI Views](./ui-views.md#timeline) documentation. +Here we describe how to edit the timeline using the [PlanDev UI](https://github.com/NASA-AMMOS/plandev-ui). For more details on the full timeline definition please refer to the [UI Views](./ui-views.md#timeline) documentation. ## Edit Timeline Properties diff --git a/docs/planning/ui-views.md b/docs/planning/ui-views.md index 3b72c41..9c61691 100644 --- a/docs/planning/ui-views.md +++ b/docs/planning/ui-views.md @@ -2,7 +2,7 @@ Users can create custom planning views for different sub-systems (e.g. science, engineering, thermal, etc.), where only data (e.g. activities and resources) for those sub-systems are visualized. This is done through custom JSON configuration files (or directly via the UI). The format of a UI View is the subject of this document. -See the [UI view JSON schema specification](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/src/schemas/ui-view-schema.json) for the complete set of view object properties and types. +See the [UI view JSON schema specification](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/src/schemas/ui-view-schema.json) for the complete set of view object properties and types. ## View Schema diff --git a/docs/planning/upload-mission-model.mdx b/docs/planning/upload-mission-model.mdx index 7229262..b9275e2 100644 --- a/docs/planning/upload-mission-model.mdx +++ b/docs/planning/upload-mission-model.mdx @@ -2,7 +2,7 @@ import uploadMissionModel from './assets/upload-mission-model.mp4'; # Upload Mission Model -Here we describe how to upload a mission model to PlanDev using the [PlanDev UI](https://github.com/NASA-AMMOS/aerie-ui). +Here we describe how to upload a mission model to PlanDev using the [PlanDev UI](https://github.com/NASA-AMMOS/plandev-ui). This document assumes you already have the PlanDev services running somewhere (either locally or remotely). To get the PlanDev services running locally first follow the [fast track instructions](../../introduction#fast-track) and then come back here. diff --git a/docs/scheduling-and-constraints/declarative/scheduling/temporal-subset.mdx b/docs/scheduling-and-constraints/declarative/scheduling/temporal-subset.mdx index b8ffbdf..6db7ed6 100644 --- a/docs/scheduling-and-constraints/declarative/scheduling/temporal-subset.mdx +++ b/docs/scheduling-and-constraints/declarative/scheduling/temporal-subset.mdx @@ -3,7 +3,7 @@ Sometimes, it may be desirable to limit the action of the scheduler to a certain time range. This can be accomplished using [Global Conditions](../global-conditions). -First, you’ll need to define a numeric resource in your mission model that represents time - for example, you could use a [Clock](https://github.com/NASA-AMMOS/aerie/blob/develop/contrib/src/main/java/gov/nasa/jpl/aerie/contrib/models/Clock.java). +First, you’ll need to define a numeric resource in your mission model that represents time - for example, you could use a [Clock](https://github.com/NASA-AMMOS/plandev/blob/develop/contrib/src/main/java/gov/nasa/jpl/aerie/contrib/models/Clock.java). ```java Mission(Registrar registrar, Instant planStart) { diff --git a/docs/scheduling-and-constraints/procedural/getting-started.mdx b/docs/scheduling-and-constraints/procedural/getting-started.mdx index 379c2c1..c6ea453 100644 --- a/docs/scheduling-and-constraints/procedural/getting-started.mdx +++ b/docs/scheduling-and-constraints/procedural/getting-started.mdx @@ -2,13 +2,13 @@ ## Create a project from the template -We have created a template repository for your mission model, scheduling procedures, and constraint procedures [here](https://github.com/NASA-AMMOS/aerie-mission-model-template). +We have created a template repository for your mission model, scheduling procedures, and constraint procedures [here](https://github.com/NASA-AMMOS/plandev-mission-model-template). If you don't already have a mission model project, you can just copy that template and follow the instructions. If you do, you can follow these steps to add a place for your procedures: 1. Move your mission model code into a gradle subproject if it isn't already. 2. Create a `scheduling` and `constraints` subproject. -3. Copy the `build.gradle` from the `scheduling` and `constraints` subprojects of the [mission model template repo](https://github.com/NASA-AMMOS/aerie-mission-model-template). +3. Copy the `build.gradle` from the `scheduling` and `constraints` subprojects of the [mission model template repo](https://github.com/NASA-AMMOS/plandev-mission-model-template). 4. You can now create procedures in a java package in your respective subprojects, as long as the package path ends in `procedures`. (i.e. `src/main/java/myorg/mymission/procedures`) @@ -27,4 +27,4 @@ See some examples in the mission model template repo, or see [the scheduling pag ## Creating a Constraint -See some examples in the [mission model template repo](https://github.com/NASA-AMMOS/aerie-mission-model-template), the PlanDev [mission model tutorial](https://github.com/NASA-AMMOS/aerie-modeling-tutorial), or see the procedural [constraints page](../constraints/introduction) of the docs. +See some examples in the [mission model template repo](https://github.com/NASA-AMMOS/plandev-mission-model-template), the PlanDev [mission model tutorial](https://github.com/NASA-AMMOS/aerie-modeling-tutorial), or see the procedural [constraints page](../constraints/introduction) of the docs. diff --git a/docs/sequencing/actions.mdx b/docs/sequencing/actions.mdx index d91191e..012b6e6 100644 --- a/docs/sequencing/actions.mdx +++ b/docs/sequencing/actions.mdx @@ -43,12 +43,12 @@ Now we're ready to run the action for the first time - click the purple "Run" bu opens a modal dialog with a form for entering **parameters** for this run. Like settings, parameters are options defined by the action - but unlike settings, they are required to be provided by the user on each run, rather than saved and persisted for all future runs. In this modal, for the parameter called "urlPath", enter -`repos/NASA-AMMOS/aerie`. The example action appends the "urlPath" to the base "externalUrl" entered in settings +`repos/NASA-AMMOS/plandev`. The example action appends the "urlPath" to the base "externalUrl" entered in settings to form a complete URL to request. Finally, click the "Run" button in the dialog window to start the run. This will take you to the **action run detail page** for this run, which will show information about the status of this particular run. After a few seconds, you should either see a green "success" status with results (showing information -about the `aerie` repo from the Github API), or a red "failure" status. If you see a failure, check to make sure your +about the `plandev` repo from the Github API), or a red "failure" status. If you see a failure, check to make sure your settings and parameters were set correctly. Finally, you can go back to the main Actions page for your workspace, which should show your just-completed run in the diff --git a/docs/sequencing/adaptation.mdx b/docs/sequencing/adaptation.mdx index ee35d04..5486d7d 100644 --- a/docs/sequencing/adaptation.mdx +++ b/docs/sequencing/adaptation.mdx @@ -2,7 +2,7 @@ The sequence editor supports uploading a custom sequence adaptation through the Dictionaries page. This custom adaptation can overwrite various features inside of the editor including linting and autocomplete. -The adaptation type is defined in [Sequencing](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/src/types/sequencing.ts#L70) and [Extension Points](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/src/utilities/sequence-editor/extension-points.ts) +The adaptation type is defined in [Sequencing](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/src/types/sequencing.ts#L70) and [Extension Points](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/src/utilities/sequence-editor/extension-points.ts) ```ts export interface ISequenceAdaptation { diff --git a/docs/tutorials/mission-modeling/first-build.mdx b/docs/tutorials/mission-modeling/first-build.mdx index 7857dc7..ac6b108 100644 --- a/docs/tutorials/mission-modeling/first-build.mdx +++ b/docs/tutorials/mission-modeling/first-build.mdx @@ -5,8 +5,8 @@ Mission models require a couple of standard items for PlanDev to process the mod 1. A [`package-info.java`](https://nasa-ammos.github.io/plandev-docs/mission-modeling/introduction/#the-package-infojava-file) file containing a reference to the top-level mission model class, annotations referencing any activities defined in the model, an annotation referencing a configuration class that can expose configuration parameters that can be varied prior to simulation, and import statements to the PlanDev modeling framework to bridge the framework to the model. 2. The top-level [mission model class](https://ammos.nasa.gov/plandev-docs/mission-modeling/introduction/#the-mission-model-class) that defines or delegates the behavior of the system being described in the model. Any quantity or state that you would like to track over the course of the simulation - which we define as a [**Resource**](https://ammos.nasa.gov/plandev-docs/mission-modeling/resources-and-models/) - should be declared and defined in this class or its delegates. The name of the top-level mission class can be anything as long as it matches the reference in `package-info.java`. -Fortunately, to save you some trouble, we've created a [mission model template repository](https://github.com/NASA-AMMOS/aerie-mission-model-template) that already has these items included for you along with a gradle build setup that takes care of including the right PlanDev dependencies to get your mission model `.jar` file built hassle-free. In this repository, if you take a look in [`missionmodel/src/main/java/missionmodel`](https://github.com/NASA-AMMOS/aerie-mission-model-template/tree/main/missionmodel/src/main/java/missionmodel), you'll see the `package-info.java` file along with the top-level `Mission` and `Configuration` classes already defined for you. +Fortunately, to save you some trouble, we've created a [mission model template repository](https://github.com/NASA-AMMOS/plandev-mission-model-template) that already has these items included for you along with a gradle build setup that takes care of including the right PlanDev dependencies to get your mission model `.jar` file built hassle-free. In this repository, if you take a look in [`missionmodel/src/main/java/missionmodel`](https://github.com/NASA-AMMOS/plandev-mission-model-template/tree/main/missionmodel/src/main/java/missionmodel), you'll see the `package-info.java` file along with the top-level `Mission` and `Configuration` classes already defined for you. -On the main page for the [mission model template repository](https://github.com/NASA-AMMOS/aerie-mission-model-template), click the "Use this template" button on the top right of the page and select "Create a new repository" to create a new repository for your SSR model. Clone your new repository and follow the instructions in the [`README.md`](https://github.com/NASA-AMMOS/aerie-mission-model-template/blob/main/README.md) to setup your environment and test out building a mission model `.jar` from the model. You'll find the `.jar` you built within a `build/libs` directory generated as part of the gradle build. +On the main page for the [mission model template repository](https://github.com/NASA-AMMOS/plandev-mission-model-template), click the "Use this template" button on the top right of the page and select "Create a new repository" to create a new repository for your SSR model. Clone your new repository and follow the instructions in the [`README.md`](https://github.com/NASA-AMMOS/plandev-mission-model-template/blob/main/README.md) to setup your environment and test out building a mission model `.jar` from the model. You'll find the `.jar` you built within a `build/libs` directory generated as part of the gradle build. At this point, we could pull up the PlanDev UI and load the `.jar` file into PlanDev as a model, but there is nothing really interesting in the model yet. So before we bring our model into PlanDev, let's give it some content. diff --git a/docs/tutorials/mission-modeling/mission-modeling.mdx b/docs/tutorials/mission-modeling/mission-modeling.mdx index 1b19bdf..75ad5ad 100644 --- a/docs/tutorials/mission-modeling/mission-modeling.mdx +++ b/docs/tutorials/mission-modeling/mission-modeling.mdx @@ -21,9 +21,9 @@ Mission models require a couple of standard items for PlanDev to process the mod 1. A [`package-info.java`](https://nasa-ammos.github.io/plandev-docs/mission-modeling/introduction/#the-package-infojava-file) file containing a reference to the top-level mission model class, annotations referencing any activities defined in the model, an annotation referencing a configuration class that can expose configuration parameters that can be varied prior to simulation, and import statements to the PlanDev modeling framework to bridge the framework to the model. 2. The top-level [mission model class](https://ammos.nasa.gov/plandev-docs/mission-modeling/introduction/#the-mission-model-class) that defines or delegates the behavior of the system being described in the model. Any quantity or state that you would like to track over the course of the simulation - which we define as a [**Resource**](https://ammos.nasa.gov/plandev-docs/mission-modeling/resources-and-models/) - should be declared and defined in this class or its delegates. The name of the top-level mission class can be anything as long as it matches the reference in `package-info.java`. -Fortunately, to save you some trouble, we've created a [mission model template repository](https://github.com/NASA-AMMOS/aerie-mission-model-template) that already has these items included for you along with a gradle build setup that takes care of including the right PlanDev dependencies to get your mission model `.jar` file built hassle-free. In this repository, if you take a look in [`src/main/java/missionmodel`](https://github.com/NASA-AMMOS/aerie-mission-model-template/tree/main/src/main/java/missionmodel), you'll see the `package-info.java` file along with the top-level `Mission` and `Configuration` classes already defined for you. +Fortunately, to save you some trouble, we've created a [mission model template repository](https://github.com/NASA-AMMOS/plandev-mission-model-template) that already has these items included for you along with a gradle build setup that takes care of including the right PlanDev dependencies to get your mission model `.jar` file built hassle-free. In this repository, if you take a look in [`src/main/java/missionmodel`](https://github.com/NASA-AMMOS/plandev-mission-model-template/tree/main/src/main/java/missionmodel), you'll see the `package-info.java` file along with the top-level `Mission` and `Configuration` classes already defined for you. -On the main page for the [mission model template repository](https://github.com/NASA-AMMOS/aerie-mission-model-template), click the "Use this template" button on the top right of the page and select "Create a new repository" to create a new repository for your SSR model. Clone your new repository and follow the instructions in the [`README.md`](https://github.com/NASA-AMMOS/aerie-mission-model-template/blob/main/README.md) to setup your environment and test out building a mission model `.jar` from the model. You'll find the `.jar` you built within a `build/libs` directory generated as part of the gradle build. +On the main page for the [mission model template repository](https://github.com/NASA-AMMOS/plandev-mission-model-template), click the "Use this template" button on the top right of the page and select "Create a new repository" to create a new repository for your SSR model. Clone your new repository and follow the instructions in the [`README.md`](https://github.com/NASA-AMMOS/plandev-mission-model-template/blob/main/README.md) to setup your environment and test out building a mission model `.jar` from the model. You'll find the `.jar` you built within a `build/libs` directory generated as part of the gradle build. At this point, we could pull up the PlanDev UI and load the `.jar` file into PlanDev as a model, but there is nothing really interesting in the model yet. So before we bring our model into PlanDev, let's give it some content. diff --git a/docs/upgrade-guides/0-13-2-to-1-0-0.md b/docs/upgrade-guides/0-13-2-to-1-0-0.md index 1010c4b..a034cda 100644 --- a/docs/upgrade-guides/0-13-2-to-1-0-0.md +++ b/docs/upgrade-guides/0-13-2-to-1-0-0.md @@ -2,7 +2,7 @@ This document describes the upgrade instructions from `0.13.2` to `1.0.0`. -### Activity Directive New Primary Key ([#380](https://github.com/NASA-AMMOS/aerie/pull/380)) +### Activity Directive New Primary Key ([#380](https://github.com/NASA-AMMOS/plandev/pull/380)) Before this change an `activity_directive` was just uniquely identified by `id` across different plans. Now an `activity_directive` is uniquely identified with both an `id` and a `plan_id`. @@ -18,7 +18,7 @@ mutation UpdateActivityDirective($id: Int!, $plan_id: Int!, $activityDirectiveSe } ``` -### Improved Test Ergonomics ([#382](https://github.com/NASA-AMMOS/aerie/pull/382)) +### Improved Test Ergonomics ([#382](https://github.com/NASA-AMMOS/plandev/pull/382)) Previously if a unit test needed to spawn activities it would need a lot of boilerplate. Now unit tests that spawn activities are no different from other unit tests that use the `MerlinExtension`. To update your existing tests you need to do the following: @@ -28,9 +28,9 @@ Previously if a unit test needed to spawn activities it would need a lot of boil It is also recommended to use the `@ExtendWith(MerlinExtension.class)` annotation instead of the `@RegisterExtension` static method. -Please reference [this diff](https://github.com/NASA-AMMOS/aerie/commit/de36ac4983dbc830b3691077439758fdd0491eee#diff-d2f70599d51fd583111cde71d52820ccaec50abc4d13ae62c30e5ae10b97d8b9) which makes these updates to one of our example mission models. +Please reference [this diff](https://github.com/NASA-AMMOS/plandev/commit/de36ac4983dbc830b3691077439758fdd0491eee#diff-d2f70599d51fd583111cde71d52820ccaec50abc4d13ae62c30e5ae10b97d8b9) which makes these updates to one of our example mission models. -### Move 'TaskFactory' from Framework to Protocol ([#382](https://github.com/NASA-AMMOS/aerie/pull/382)) +### Move 'TaskFactory' from Framework to Protocol ([#382](https://github.com/NASA-AMMOS/plandev/pull/382)) So the simulation can manage task creation the `TaskFactory` has been moved to the Merlin protocol. @@ -46,11 +46,11 @@ Need to change to: gov.nasa.jpl.aerie.merlin.protocol.model.TaskFactory ``` -### Remove 'RootModel' ([#382](https://github.com/NASA-AMMOS/aerie/pull/382)) +### Remove 'RootModel' ([#382](https://github.com/NASA-AMMOS/plandev/pull/382)) Previously a mission model needed to be wrapped in a `RootModel` prior to simulation. Because task creation has been moved to the simulation engine, the `RootModel` is no longer necessary. -### Update Constraint Boolean Operator Names ([#407](https://github.com/NASA-AMMOS/aerie/pull/407)) +### Update Constraint Boolean Operator Names ([#407](https://github.com/NASA-AMMOS/plandev/pull/407)) The constraints DSL has renamed some boolean operators to be more clear. You should rename the following: @@ -74,11 +74,11 @@ export default (): Constraint => { }; ``` -### Global Scheduling Conditions Mutex ([#410](https://github.com/NASA-AMMOS/aerie/pull/410)) +### Global Scheduling Conditions Mutex ([#410](https://github.com/NASA-AMMOS/plandev/pull/410)) -Previously the scheduler would avoid placing activities of the same type overlapping each other. Now by default the scheduler is allowed to place overlapping activities of the same type. If you want mutual exclusion you need to use a global scheduling condition. Please see our [documentation on global scheduling conditions](https://nasa-ammos.github.io/aerie/develop/user-guide/ui-api-guide/scheduling/scheduling-conditions.html#authoring-scheduling-global-conditions) for more detailed instructions. +Previously the scheduler would avoid placing activities of the same type overlapping each other. Now by default the scheduler is allowed to place overlapping activities of the same type. If you want mutual exclusion you need to use a global scheduling condition. Please see our [documentation on global scheduling conditions](https://nasa-ammos.github.io/plandev/develop/user-guide/ui-api-guide/scheduling/scheduling-conditions.html#authoring-scheduling-global-conditions) for more detailed instructions. -### Rename "condition" table to "constraint" ([#419](https://github.com/NASA-AMMOS/aerie/pull/419)) +### Rename "condition" table to "constraint" ([#419](https://github.com/NASA-AMMOS/plandev/pull/419)) The "condition" table has been renamed to "constraint" to avoid confusion with global scheduling conditions. Any API queries or mutations that used "condition" before will need to be updated. For example the following query uses the new "constraint" name: @@ -96,7 +96,7 @@ query GetConstraints { } ``` -### SimulationResults Java Class No Longer Provides 'resourceSamples' Field ([#423](https://github.com/NASA-AMMOS/aerie/pull/423)) +### SimulationResults Java Class No Longer Provides 'resourceSamples' Field ([#423](https://github.com/NASA-AMMOS/plandev/pull/423)) Prior to this change, the `resourceSamples` field was derived from `realProfiles` and `discreteProfiles` via the `takeSample`s method - upon calling the `SimulationResults` constructor, `takeSamples` would be called eagerly. In typical usage, `resourceSamples` is unused - the simulation results are written to the database using the `realProfiles` and `discreteProfiles` directly. The only time it is used (outside of testing) is via the explicit `resourceSamples` Hasura action. @@ -145,10 +145,10 @@ static Map>> takeSamples(Simulation } ``` -### Rename 'command-expansion-server' to 'sequencing-server' ([#439](https://github.com/NASA-AMMOS/aerie/pull/439)) +### Rename 'command-expansion-server' to 'sequencing-server' ([#439](https://github.com/NASA-AMMOS/plandev/pull/439)) -To better align with the domain of Aerie sequencing features (command expansion, sequence authoring, command dictionary management, etc.) the `aerie-commanding` image was renamed to `aerie-sequencing`. Any downstream deployment configuration that was using `aerie-commanding` needs to be updated to reference the new [aerie-sequencing image](https://github.com/NASA-AMMOS/aerie/pkgs/container/aerie-sequencing). You can reference the updated deployment [docker-compose.yml](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/docker-compose.yml#L102) for a detailed example. +To better align with the domain of Aerie sequencing features (command expansion, sequence authoring, command dictionary management, etc.) the `aerie-commanding` image was renamed to `aerie-sequencing`. Any downstream deployment configuration that was using `aerie-commanding` needs to be updated to reference the new [aerie-sequencing image](https://github.com/NASA-AMMOS/plandev/pkgs/container/aerie-sequencing). You can reference the updated deployment [docker-compose.yml](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/docker-compose.yml#L102) for a detailed example. -### Add Scheduler Workers ([#406](https://github.com/NASA-AMMOS/aerie/pull/406)) +### Add Scheduler Workers ([#406](https://github.com/NASA-AMMOS/plandev/pull/406)) -A scheduler worker has been added that allows for running multiple concurrent scheduling jobs. You need to make sure any downstream deployment configurations now use at least one [aerie-scheduler-worker image](https://github.com/NASA-AMMOS/aerie/pkgs/container/aerie-scheduler-worker). You can reference the updated deployment [docker-compose.yml](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/docker-compose.yml#L81) for a detailed example. Also please read the updated [Aerie Scheduler](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/Environment.md#aerie-scheduler) and [Aerie Scheduler Worker](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/Environment.md#aerie-scheduler-worker) environment variables to make sure your deployment is up-to-date. +A scheduler worker has been added that allows for running multiple concurrent scheduling jobs. You need to make sure any downstream deployment configurations now use at least one [aerie-scheduler-worker image](https://github.com/NASA-AMMOS/plandev/pkgs/container/aerie-scheduler-worker). You can reference the updated deployment [docker-compose.yml](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/docker-compose.yml#L81) for a detailed example. Also please read the updated [Aerie Scheduler](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/Environment.md#aerie-scheduler) and [Aerie Scheduler Worker](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/Environment.md#aerie-scheduler-worker) environment variables to make sure your deployment is up-to-date. diff --git a/docs/upgrade-guides/1-0-0-to-1-0-1.md b/docs/upgrade-guides/1-0-0-to-1-0-1.md index 9a3879e..6301ebf 100644 --- a/docs/upgrade-guides/1-0-0-to-1-0-1.md +++ b/docs/upgrade-guides/1-0-0-to-1-0-1.md @@ -2,6 +2,6 @@ This document describes the upgrade instructions from `1.0.0` to `1.0.1`. -### Use a Record Instead of a Pair for Profile Segments ([#434](https://github.com/NASA-AMMOS/aerie/pull/434)) +### Use a Record Instead of a Pair for Profile Segments ([#434](https://github.com/NASA-AMMOS/plandev/pull/434)) -Java clients of `SimulationResults` will need to be updated to use `ProfileSegment::extent` and `ProfileSegment::dynamics` instead of `Pair::getLeft` and `Pair::getRight`. Please see the changes in [the PR](https://github.com/NASA-AMMOS/aerie/pull/434/files) for examples. +Java clients of `SimulationResults` will need to be updated to use `ProfileSegment::extent` and `ProfileSegment::dynamics` instead of `Pair::getLeft` and `Pair::getRight`. Please see the changes in [the PR](https://github.com/NASA-AMMOS/plandev/pull/434/files) for examples. diff --git a/docs/upgrade-guides/1-0-1-to-1-0-2.md b/docs/upgrade-guides/1-0-1-to-1-0-2.md index d1cbad9..e654cba 100644 --- a/docs/upgrade-guides/1-0-1-to-1-0-2.md +++ b/docs/upgrade-guides/1-0-1-to-1-0-2.md @@ -4,7 +4,7 @@ This document describes the upgrade instructions from `1.0.1` to `1.0.2`. ## Sequence Argument Passing -To support repeat arguments in commands ([#617](https://github.com/NASA-AMMOS/aerie/pull/617)) all existing sequence EDSLs (authored sequences and expansion rules) will need to be updated to use the pass-by-name argument style for commands. Pass-by-position is no longer supported because it does not allow for use of repeat arguments without major changes. For example old expansion rules could use the following pass-by-position command argument format: +To support repeat arguments in commands ([#617](https://github.com/NASA-AMMOS/plandev/pull/617)) all existing sequence EDSLs (authored sequences and expansion rules) will need to be updated to use the pass-by-name argument style for commands. Pass-by-position is no longer supported because it does not allow for use of repeat arguments without major changes. For example old expansion rules could use the following pass-by-position command argument format: ```ts /** diff --git a/docs/upgrade-guides/1-1-0-to-1-2-0.md b/docs/upgrade-guides/1-1-0-to-1-2-0.md index d040a28..3670dac 100644 --- a/docs/upgrade-guides/1-1-0-to-1-2-0.md +++ b/docs/upgrade-guides/1-1-0-to-1-2-0.md @@ -2,7 +2,7 @@ This document describes the upgrade instructions from `1.1.0` to `1.2.0`. -## UI View Schema Grid Update ([#387](https://github.com/NASA-AMMOS/aerie-ui/pull/387)) +## UI View Schema Grid Update ([#387](https://github.com/NASA-AMMOS/plandev-ui/pull/387)) The UI view schema has replaced the `layout` property with a much simpler `grid` property. The `grid` property fully specifies the panel grids on the UI plan page. To update just delete the old `layout` object and add the `grid` object to your existing views or view generation scripts. Here is the diff: @@ -70,10 +70,10 @@ Here is a good default `grid` JSON for easy copy-paste: } ``` -## JSON (de)serialization of SerializedValue Refactor ([#577](https://github.com/NASA-AMMOS/aerie/pull/577)) +## JSON (de)serialization of SerializedValue Refactor ([#577](https://github.com/NASA-AMMOS/plandev/pull/577)) Any implementations of the `SerializedValue.Visitor` interface will need to replace their `onReal(double)` and `onInt(long)` methods with the new `onNumeric(BigDecimal)` method. -## Seq JSON Version Bump ([#683](https://github.com/NASA-AMMOS/aerie/pull/683)) +## Seq JSON Version Bump ([#683](https://github.com/NASA-AMMOS/plandev/pull/683)) The Aerie sequence editor now supports [seq-json-schema](https://github.com/NASA-AMMOS/seq-json-schema) version `1.0.16`. This should be mostly transparent if you've been keeping up with the schema versions, but we are noting it here for completeness. diff --git a/docs/upgrade-guides/1-11-0-to-1-12-0.md b/docs/upgrade-guides/1-11-0-to-1-12-0.md index bf6bbfb..6fd7db9 100644 --- a/docs/upgrade-guides/1-11-0-to-1-12-0.md +++ b/docs/upgrade-guides/1-11-0-to-1-12-0.md @@ -4,4 +4,4 @@ This document describes the upgrade instructions from `1.11.0` to `1.12.0`. ## Plan Snapshot Table Changes -The `plan_snapshot` table columns have been updated. This should not be a problem for most users unless you are querying for plan snapshots directly. You can see the [latest database schema here](https://github.com/NASA-AMMOS/aerie/blob/v1.12.0/merlin-server/sql/merlin/tables/plan_snapshot.sql) to determine how to change your queries. +The `plan_snapshot` table columns have been updated. This should not be a problem for most users unless you are querying for plan snapshots directly. You can see the [latest database schema here](https://github.com/NASA-AMMOS/plandev/blob/v1.12.0/merlin-server/sql/merlin/tables/plan_snapshot.sql) to determine how to change your queries. diff --git a/docs/upgrade-guides/1-2-0-to-1-3-0.md b/docs/upgrade-guides/1-2-0-to-1-3-0.md index ffb7fac..c4f1fc3 100644 --- a/docs/upgrade-guides/1-2-0-to-1-3-0.md +++ b/docs/upgrade-guides/1-2-0-to-1-3-0.md @@ -2,7 +2,7 @@ This document describes the upgrade instructions from `1.2.0` to `1.3.0`. -## Remove Nested Seq JSON GraphQL Querying ([#716](https://github.com/NASA-AMMOS/aerie/pull/716)) +## Remove Nested Seq JSON GraphQL Querying ([#716](https://github.com/NASA-AMMOS/plandev/pull/716)) To query the Aerie GraphQL API for Seq JSON we provide the following four queries: diff --git a/docs/upgrade-guides/1-3-0-to-1-4-0.md b/docs/upgrade-guides/1-3-0-to-1-4-0.md index 650a463..3de0063 100644 --- a/docs/upgrade-guides/1-3-0-to-1-4-0.md +++ b/docs/upgrade-guides/1-3-0-to-1-4-0.md @@ -2,7 +2,7 @@ This document describes the upgrade instructions from `1.3.0` to `1.4.0`. -## Temporal Subset Simulation ([#725](https://github.com/NASA-AMMOS/aerie/pull/725)) +## Temporal Subset Simulation ([#725](https://github.com/NASA-AMMOS/plandev/pull/725)) ### Update `SimulationDriver.simulate` @@ -69,13 +69,13 @@ public final class SimulationResults { ### Plan Simulation Configuration -Previously when creating a plan using the API you had to create a separate [simulation](https://github.com/NASA-AMMOS/aerie/blob/v1.4.0/merlin-server/sql/merlin/tables/simulation.sql) and associate it with the plan. You no longer need to do this. Now when you create a plan a simulation is automatically created and properly associated. +Previously when creating a plan using the API you had to create a separate [simulation](https://github.com/NASA-AMMOS/plandev/blob/v1.4.0/merlin-server/sql/merlin/tables/simulation.sql) and associate it with the plan. You no longer need to do this. Now when you create a plan a simulation is automatically created and properly associated. ### Plan Simulation Bounds -The [simulation](https://github.com/NASA-AMMOS/aerie/blob/v1.4.0/merlin-server/sql/merlin/tables/simulation.sql#L9) now includes a `simulation_start_time` and `simulation_end_time` to denote the time range to be simulated. Plans need to set these fields in their associated simulation before simulating. The UI will handle this automatically, but clients updating to this new paradigm need to take this into account. Please see [these docs](https://nasa-ammos.github.io/aerie-docs/api/examples/simulation/#update-a-simulation-configuration) on how to set a simulation start time and end time via the API. +The [simulation](https://github.com/NASA-AMMOS/plandev/blob/v1.4.0/merlin-server/sql/merlin/tables/simulation.sql#L9) now includes a `simulation_start_time` and `simulation_end_time` to denote the time range to be simulated. Plans need to set these fields in their associated simulation before simulating. The UI will handle this automatically, but clients updating to this new paradigm need to take this into account. Please see [these docs](https://nasa-ammos.github.io/plandev-docs/api/examples/simulation/#update-a-simulation-configuration) on how to set a simulation start time and end time via the API. -## UI View Activity Table ([#406](https://github.com/NASA-AMMOS/aerie-ui/pull/406)) +## UI View Activity Table ([#406](https://github.com/NASA-AMMOS/plandev-ui/pull/406)) To help when analyzing the two different types of activities in Aerie, the UI now shows activity directives and simulated activities (spans) separately. The requires updating UI views by replacing the former `activityTables` property with two new properties: `activityDirectivesTable` and `activitySpansTable`. Additionally any default `grid` property using the former `ActivityTablePanel` needs to be updated to `ActivityDirectivesTablePanel`. diff --git a/docs/upgrade-guides/1-6-0-to-1-7-0.md b/docs/upgrade-guides/1-6-0-to-1-7-0.md index 647ddfa..39622e2 100644 --- a/docs/upgrade-guides/1-6-0-to-1-7-0.md +++ b/docs/upgrade-guides/1-6-0-to-1-7-0.md @@ -2,19 +2,19 @@ This document describes the upgrade instructions from `1.6.0` to `1.7.0`. -## Hasura Authorization Enabled by Default ([#848](https://github.com/NASA-AMMOS/aerie/issues/848)) +## Hasura Authorization Enabled by Default ([#848](https://github.com/NASA-AMMOS/plandev/issues/848)) Authorization is now enabled by default for our Hasura API server. This requires additional environment variables to be provided when deploying Aerie. Additionally you must now pass an `authorization` header when making requests to Hasura. -- Deploying Aerie now requires setting additional secret environment variables. Please see our new [document on deploying with authentication](https://nasa-ammos.github.io/aerie-docs/deployment/advanced-authentication/) for details on what variables to set and where. -- Any tools that make API requests to Hasura need to be updated to get a token from the gateway, and pass it in an `authorization` header. Instructions for how to do this can be found in our [API documentation](https://nasa-ammos.github.io/aerie-docs/api/introduction/#authentication). -- When running migrations, the `admin-secret` property now needs to be included in Hasura’s `config.yaml`. See the [example](https://github.com/NASA-AMMOS/aerie/blob/481127baabb22babc143ec6a537f815e796fe884/deployment/hasura/config.yaml#L8) in the Aerie deployment directory. +- Deploying Aerie now requires setting additional secret environment variables. Please see our new [document on deploying with authentication](https://nasa-ammos.github.io/plandev-docs/deployment/advanced-authentication/) for details on what variables to set and where. +- Any tools that make API requests to Hasura need to be updated to get a token from the gateway, and pass it in an `authorization` header. Instructions for how to do this can be found in our [API documentation](https://nasa-ammos.github.io/plandev-docs/api/introduction/#authentication). +- When running migrations, the `admin-secret` property now needs to be included in Hasura’s `config.yaml`. See the [example](https://github.com/NASA-AMMOS/plandev/blob/481127baabb22babc143ec6a537f815e796fe884/deployment/hasura/config.yaml#L8) in the Aerie deployment directory. ## New GraphQL Playground -Since Hasura now requires authorization, the Hasura Console is not accessible for non-admin users. To keep the Aerie API accessible we provide a new GraphQL playground in the gateway. Instructions for how to use it can be found in our [API documentation](https://nasa-ammos.github.io/aerie-docs/api/introduction/#playground). +Since Hasura now requires authorization, the Hasura Console is not accessible for non-admin users. To keep the Aerie API accessible we provide a new GraphQL playground in the gateway. Instructions for how to use it can be found in our [API documentation](https://nasa-ammos.github.io/plandev-docs/api/introduction/#playground). -## 'Summary' Field Removed from Constraints ([#880](https://github.com/NASA-AMMOS/aerie/pull/880)) +## 'Summary' Field Removed from Constraints ([#880](https://github.com/NASA-AMMOS/plandev/pull/880)) The `summary` field has been removed from the constraint table. Any API queries that used that field need to be updated to remove it. For example, here is a query for a constraint with the `summary` field removed: diff --git a/docs/upgrade-guides/1-8-0-to-1-9-0.md b/docs/upgrade-guides/1-8-0-to-1-9-0.md index 326a94a..e04d19e 100644 --- a/docs/upgrade-guides/1-8-0-to-1-9-0.md +++ b/docs/upgrade-guides/1-8-0-to-1-9-0.md @@ -2,7 +2,7 @@ This document describes the upgrade instructions from `1.8.0` to `1.9.0`. -## Tags Table ([#959](https://github.com/NASA-AMMOS/aerie/pull/959)) +## Tags Table ([#959](https://github.com/NASA-AMMOS/plandev/pull/959)) There is a new `tags` table that is a global store for all tags in Aerie. Previously tags only existed on the `activity_directive` table directly. Any API call that queries for old `activity_directive.tags` needs to be updated to conform to the new API. @@ -26,4 +26,4 @@ There is a new `tags` table that is a global store for all tags in Aerie. Previo Notice the new nested structure. This is required because `tags` is now a separate table, and we need to join behind the scenes to get the tags associated with the `activity_directive`. -To create tags via the API, you now need to write to the `tags` table. See the `insert_tags` query in our GraphQL schema. An example can be found in the [UI repo](https://github.com/NASA-AMMOS/aerie-ui/blob/e84cc96ce43d7b7bb019586907979f23b5dc1c98/src/utilities/gql.ts#L234). +To create tags via the API, you now need to write to the `tags` table. See the `insert_tags` query in our GraphQL schema. An example can be found in the [UI repo](https://github.com/NASA-AMMOS/plandev-ui/blob/e84cc96ce43d7b7bb019586907979f23b5dc1c98/src/utilities/gql.ts#L234). diff --git a/docs/upgrade-guides/2-1-0-to-2-2-0.md b/docs/upgrade-guides/2-1-0-to-2-2-0.md index de5540d..ef2834e 100644 --- a/docs/upgrade-guides/2-1-0-to-2-2-0.md +++ b/docs/upgrade-guides/2-1-0-to-2-2-0.md @@ -4,4 +4,4 @@ This document describes the upgrade instructions from `2.1.0` to `2.2.0`. ## PUBLIC_AERIE_FILE_STORE_PREFIX environment variable -Aerie UI now provides an environment variable to specify a naming convention for simulation configuration files that are uploaded. UI environment variables are docuemented in [ENVIRONMENT.md](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/docs/ENVIRONMENT.md). +Aerie UI now provides an environment variable to specify a naming convention for simulation configuration files that are uploaded. UI environment variables are docuemented in [ENVIRONMENT.md](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/docs/ENVIRONMENT.md). diff --git a/docs/upgrade-guides/2-13-0-to-2-14-0.md b/docs/upgrade-guides/2-13-0-to-2-14-0.md index 59dfeac..3ca53e8 100644 --- a/docs/upgrade-guides/2-13-0-to-2-14-0.md +++ b/docs/upgrade-guides/2-13-0-to-2-14-0.md @@ -4,16 +4,16 @@ No special instructions are **necessary** to upgrade to `v2.14.0`. The following ## In-Memory Checkpoint Simulation -Aerie 2.14.0 includes an experimental [In-Memory Checkpoint Simulation](https://github.com/NASA-AMMOS/aerie/pull/1323) feature which is intended to improve the performance of the **scheduler** by setting "simulation checkpoints" from which the simulation engine can restart, rather than always re-running the entire simulation. This improved performance comes at the cost of memory usage, which may be quite significant for larger models/plans, so it is disabled by default. If you don't want to use this feature, no changes to your deployment or models are necessary. +Aerie 2.14.0 includes an experimental [In-Memory Checkpoint Simulation](https://github.com/NASA-AMMOS/plandev/pull/1323) feature which is intended to improve the performance of the **scheduler** by setting "simulation checkpoints" from which the simulation engine can restart, rather than always re-running the entire simulation. This improved performance comes at the cost of memory usage, which may be quite significant for larger models/plans, so it is disabled by default. If you don't want to use this feature, no changes to your deployment or models are necessary. **To use this feature in your Aerie deployment, you must:** 1. Modify the `MAX_NB_CACHED_SIMULATION_ENGINES` environment variable for the Aerie Scheduler Worker to be larger than `1`. The higher this value is, the more checkpoints may be set, resulting in increased performance at the cost of higher memory usage. If the number is too high, you may encounter out-of-memory errors on larger models and plans. -2. Implement a `duplicate()` method on any custom tasks that are used by your model. The `duplicate()` method is called when a checkpoint is created, and should return a duplicate/"deep copy" of the task, which can be stepped independently of the original task. This is required because the checkpoint creates a duplicate copy of the entire simulation engine, including its tasks. For more information, see the [documentation for this method](https://github.com/NASA-AMMOS/aerie/blob/2b8a5945fdb51c724768d55abc84ea9cab86338c/merlin-sdk/src/main/java/gov/nasa/jpl/aerie/merlin/protocol/model/Task.java#L37). +2. Implement a `duplicate()` method on any custom tasks that are used by your model. The `duplicate()` method is called when a checkpoint is created, and should return a duplicate/"deep copy" of the task, which can be stepped independently of the original task. This is required because the checkpoint creates a duplicate copy of the entire simulation engine, including its tasks. For more information, see the [documentation for this method](https://github.com/NASA-AMMOS/plandev/blob/2b8a5945fdb51c724768d55abc84ea9cab86338c/merlin-sdk/src/main/java/gov/nasa/jpl/aerie/merlin/protocol/model/Task.java#L37). -An example implementation of a `duplicate()` method on a task can be found in Aerie's `ReplayingTask` class, [located here](https://github.com/NASA-AMMOS/aerie/blob/develop/merlin-framework/src/main/java/gov/nasa/jpl/aerie/merlin/framework/ReplayingTask.java#L75). +An example implementation of a `duplicate()` method on a task can be found in Aerie's `ReplayingTask` class, [located here](https://github.com/NASA-AMMOS/plandev/blob/develop/merlin-framework/src/main/java/gov/nasa/jpl/aerie/merlin/framework/ReplayingTask.java#L75). ## Configuring Sequence Expansion Workers -[PR #1476](https://github.com/NASA-AMMOS/aerie/pull/1476) exposes a new environment variable in the sequencing server that can be used to limit the maximum number of workers the server uses for sequence expansion. This is set to a default value of `8` if not provided, but can be increased to improve performance of sequence expansion at the cost of additional memory usage. +[PR #1476](https://github.com/NASA-AMMOS/plandev/pull/1476) exposes a new environment variable in the sequencing server that can be used to limit the maximum number of workers the server uses for sequence expansion. This is set to a default value of `8` if not provided, but can be increased to improve performance of sequence expansion at the cost of additional memory usage. diff --git a/docs/upgrade-guides/2-15-0-to-2-16-0.md b/docs/upgrade-guides/2-15-0-to-2-16-0.md index 8d80a0b..c4b1f89 100644 --- a/docs/upgrade-guides/2-15-0-to-2-16-0.md +++ b/docs/upgrade-guides/2-15-0-to-2-16-0.md @@ -15,6 +15,6 @@ Two changes were made to the names of environment variables used by Aerie contai Aerie 2.16.0 introduces a change to the way simulation results are written to the database - they are now streamed to the database throughout the simulation instead of at the end. This should improve peak memory usage for large plans/mission models without impacting simulation running time, but please let us know if you see any significant performance regressions. -Aerie plans can now be exported to and imported from files, see [Plan Import/Export](https://nasa-ammos.github.io/aerie-docs/planning/plan-import-export/) for details. +Aerie plans can now be exported to and imported from files, see [Plan Import/Export](https://nasa-ammos.github.io/plandev-docs/planning/plan-import-export/) for details. -Aerie deployments can now provide a Time Plugin to support other time systems such as LMST or SCLK. See [Advanced - UI Plugins](https://nasa-ammos.github.io/aerie-docs/planning/plugins/introduction/) and [Time Plugin](https://nasa-ammos.github.io/aerie-docs/planning/plugins/time/) pages for details. +Aerie deployments can now provide a Time Plugin to support other time systems such as LMST or SCLK. See [Advanced - UI Plugins](https://nasa-ammos.github.io/plandev-docs/planning/plugins/introduction/) and [Time Plugin](https://nasa-ammos.github.io/plandev-docs/planning/plugins/time/) pages for details. diff --git a/docs/upgrade-guides/2-17-0-to-2-18-0.md b/docs/upgrade-guides/2-17-0-to-2-18-0.md index 9055058..903b5b5 100644 --- a/docs/upgrade-guides/2-17-0-to-2-18-0.md +++ b/docs/upgrade-guides/2-17-0-to-2-18-0.md @@ -17,4 +17,4 @@ This change may impact users who are using the following API actions: You will be impacted **only** if you are using a query variable for the `missionModelId` argument of these actions. If so, update your usage by changing the type of that query variable from `ID!` to `Int!`. -You can see an example of this type of change in [this aerie-ui pull request](https://github.com/NASA-AMMOS/aerie-ui/pull/1427/files) for reference. +You can see an example of this type of change in [this aerie-ui pull request](https://github.com/NASA-AMMOS/plandev-ui/pull/1427/files) for reference. diff --git a/docs/upgrade-guides/2-18-0-to-2-19-0.md b/docs/upgrade-guides/2-18-0-to-2-19-0.md index c63511c..19c1034 100644 --- a/docs/upgrade-guides/2-18-0-to-2-19-0.md +++ b/docs/upgrade-guides/2-18-0-to-2-19-0.md @@ -3,9 +3,9 @@ This document describes the upgrade instructions from `2.18.0` to `2.19.0`. ## Procedural Scheduling -Aerie `2.19.0` includes our Procedural Scheduling feature, which is a new way to write scheduling goals in Java. The documentation has been updated and reorganized to describe this new feature, see [Scheduling & Constraints](https://nasa-ammos.github.io/aerie-docs/scheduling-and-constraints/introduction/) for more details. +Aerie `2.19.0` includes our Procedural Scheduling feature, which is a new way to write scheduling goals in Java. The documentation has been updated and reorganized to describe this new feature, see [Scheduling & Constraints](https://nasa-ammos.github.io/plandev-docs/scheduling-and-constraints/introduction/) for more details. -This is an early-release feature which may see some significant changes in future releases as we refine the idea - please feel free to submit feedback via [Github issues](https://github.com/NASA-AMMOS/aerie/issues) or our [#nasa-ammos-aerie-users Slack channel](https://jpl.slack.com/archives/C0163E42UBF) if you have questions or issues. +This is an early-release feature which may see some significant changes in future releases as we refine the idea - please feel free to submit feedback via [Github issues](https://github.com/NASA-AMMOS/plandev/issues) or our [#nasa-ammos-aerie-users Slack channel](https://jpl.slack.com/archives/C0163E42UBF) if you have questions or issues. ## DB Migrations Two new database migrations have been added to support Procedural Scheduling. If you are upgrading from a past version and want to preserve your data, follow the instructions in the diff --git a/docs/upgrade-guides/2-2-0-to-2-3-0.md b/docs/upgrade-guides/2-2-0-to-2-3-0.md index 00af603..bddf4b2 100644 --- a/docs/upgrade-guides/2-2-0-to-2-3-0.md +++ b/docs/upgrade-guides/2-2-0-to-2-3-0.md @@ -4,4 +4,4 @@ This document describes the upgrade instructions from `2.2.0` to `2.3.0`. ## PUBLIC_AUTH_SSO_ENABLED environment variable -Aerie UI now provides an environment variable to specify the SSO (single sign on) gateway. UI environment variables are documented in [ENVIRONMENT.md](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/docs/ENVIRONMENT.md). +Aerie UI now provides an environment variable to specify the SSO (single sign on) gateway. UI environment variables are documented in [ENVIRONMENT.md](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/docs/ENVIRONMENT.md). diff --git a/docs/upgrade-guides/2-21-0-to-3-0-0.md b/docs/upgrade-guides/2-21-0-to-3-0-0.md index dfd40b0..dfbe08b 100644 --- a/docs/upgrade-guides/2-21-0-to-3-0-0.md +++ b/docs/upgrade-guides/2-21-0-to-3-0-0.md @@ -2,5 +2,5 @@ No special instructions are necessary to upgrade to `v3.0.0`. -Aerie `v3.0.0` includes a new feature to support uploading and visualizing External Events, see the [External Events](https://nasa-ammos.github.io/aerie-docs/planning/external-events/introduction) docs page for more information. +Aerie `v3.0.0` includes a new feature to support uploading and visualizing External Events, see the [External Events](https://nasa-ammos.github.io/plandev-docs/planning/external-events/introduction) docs page for more information. diff --git a/docs/upgrade-guides/2-4-0-to-2-5-0.md b/docs/upgrade-guides/2-4-0-to-2-5-0.md index 96a1ae2..34e363f 100644 --- a/docs/upgrade-guides/2-4-0-to-2-5-0.md +++ b/docs/upgrade-guides/2-4-0-to-2-5-0.md @@ -2,7 +2,7 @@ This document describes the upgrade instructions from `2.4.0` to `2.5.0`. -## Mapping LDAP groups to Aerie roles for deployments using CAM SSO ([#1279](https://github.com/NASA-AMMOS/aerie/issues/1279)) +## Mapping LDAP groups to Aerie roles for deployments using CAM SSO ([#1279](https://github.com/NASA-AMMOS/plandev/issues/1279)) -The DEFAULT_ROLE environment variable in aerie-gateway is now a list of strings, previously only a single value was allowed. See here for more details https://nasa-ammos.github.io/aerie-docs/deployment/advanced-sso/#setting-default_roles +The DEFAULT_ROLE environment variable in aerie-gateway is now a list of strings, previously only a single value was allowed. See here for more details https://nasa-ammos.github.io/plandev-docs/deployment/advanced-sso/#setting-default_roles diff --git a/docs/upgrade-guides/2-5-0-to-2-6-0.md b/docs/upgrade-guides/2-5-0-to-2-6-0.md index cbac534..cb21fa3 100644 --- a/docs/upgrade-guides/2-5-0-to-2-6-0.md +++ b/docs/upgrade-guides/2-5-0-to-2-6-0.md @@ -3,16 +3,16 @@ This document describes the upgrade instructions from `2.5.0` to `2.6.0`. # 2.6.0 NOT RECOMMENDED -NOTE that a migration-related bug was discovered in version `2.6.0` after release. If you have not yet upgraded to `2.6.0`, you can skip this version and upgrade directly to `2.6.2` or later. If you are already using `2.6.0`, you should upgrade to `2.6.2` or later as soon as possible to avoid potential issues. More details can be found in [this Github issue](https://github.com/NASA-AMMOS/aerie/pull/1374). +NOTE that a migration-related bug was discovered in version `2.6.0` after release. If you have not yet upgraded to `2.6.0`, you can skip this version and upgrade directly to `2.6.2` or later. If you are already using `2.6.0`, you should upgrade to `2.6.2` or later as soon as possible to avoid potential issues. More details can be found in [this Github issue](https://github.com/NASA-AMMOS/plandev/pull/1374). # Changes to scheduling goals and conditions To support shared & versioned scheduling goals and conditions, several changes were made to their behavior and database structure. The goals and conditions tables have each been split into two tables, a metadata table and a definitions table. Goals and conditions may now be associated with multiple plans via plan specifications, and may be marked "public" or "private" to control their visibility to other users. The database structure for **model specifications** for conditions and goals has been added. A model specification is a recommended set of goals/conditions and their versions for all plans using the model. In a future release, **plan scheduling specs** will be prepopulated from the model specs, but this is not yet supported. -For more details about these changes, see [PR #1315](https://github.com/NASA-AMMOS/aerie/pull/1315) +For more details about these changes, see [PR #1315](https://github.com/NASA-AMMOS/plandev/pull/1315) -## `scheduling_specifications` relationship changed to `scheduling_specification` ([#1355](https://github.com/NASA-AMMOS/aerie/pull/1355)) +## `scheduling_specifications` relationship changed to `scheduling_specification` ([#1355](https://github.com/NASA-AMMOS/plandev/pull/1355)) The relationship of **plan** to **scheduling spec** was changed from an array relationship to an object relationship, and the relationship name was changed from `scheduling_specifications` to `scheduling_specification` (singular). Aerie API users using this relationship should update to the new name & type. diff --git a/docs/upgrade-guides/2-6-0-to-2-6-1.md b/docs/upgrade-guides/2-6-0-to-2-6-1.md index b9fde25..5bc606e 100644 --- a/docs/upgrade-guides/2-6-0-to-2-6-1.md +++ b/docs/upgrade-guides/2-6-0-to-2-6-1.md @@ -3,4 +3,4 @@ This document describes the upgrade instructions from `2.6.0` to `2.6.1`. # 2.6.1 NOT RECOMMENDED -NOTE that a bug was discovered in version `2.6.1` after release. If you have not yet upgraded to `2.6.1`, you can skip this version and upgrade directly to `2.6.2` or later. If you are already using `2.6.1`, you should upgrade to `2.6.2` or later as soon as possible to avoid potential issues. More details can be found in [this Github issue](https://github.com/NASA-AMMOS/aerie/pull/1401). +NOTE that a bug was discovered in version `2.6.1` after release. If you have not yet upgraded to `2.6.1`, you can skip this version and upgrade directly to `2.6.2` or later. If you are already using `2.6.1`, you should upgrade to `2.6.2` or later as soon as possible to avoid potential issues. More details can be found in [this Github issue](https://github.com/NASA-AMMOS/plandev/pull/1401). diff --git a/docs/upgrade-guides/2-6-2-to-2-7-0.md b/docs/upgrade-guides/2-6-2-to-2-7-0.md index e12694d..cc66447 100644 --- a/docs/upgrade-guides/2-6-2-to-2-7-0.md +++ b/docs/upgrade-guides/2-6-2-to-2-7-0.md @@ -3,7 +3,7 @@ This document describes the upgrade instructions from `2.6.2` to `2.7.0`. # 2.7.0 NOT RECOMMENDED -NOTE that a bug was discovered in version `2.7.0` after release. If you have not yet upgraded to `2.7.0`, you can skip this version and upgrade directly to `2.7.1` or later. If you are already using `2.7.0`, you should upgrade to `2.7.1` or later as soon as possible to avoid potential issues. More details can be found in [this Github issue](https://github.com/NASA-AMMOS/aerie/pull/1401). +NOTE that a bug was discovered in version `2.7.0` after release. If you have not yet upgraded to `2.7.0`, you can skip this version and upgrade directly to `2.7.1` or later. If you are already using `2.7.0`, you should upgrade to `2.7.1` or later as soon as possible to avoid potential issues. More details can be found in [this Github issue](https://github.com/NASA-AMMOS/plandev/pull/1401). ## Dependency changes -Some changes were made to Aerie UI dependencies. If you are running `aerie-ui` locally and have issues running the application or tests after this upgrade, try following the ["Cleaning" procedure in the Developer Guide](https://github.com/NASA-AMMOS/aerie-ui/blob/develop/docs/DEVELOPER.md#cleaning), then run `npm run build` to create a fresh build. +Some changes were made to Aerie UI dependencies. If you are running `aerie-ui` locally and have issues running the application or tests after this upgrade, try following the ["Cleaning" procedure in the Developer Guide](https://github.com/NASA-AMMOS/plandev-ui/blob/develop/docs/DEVELOPER.md#cleaning), then run `npm run build` to create a fresh build. diff --git a/docs/upgrade-guides/2-7-0-to-2-7-1.md b/docs/upgrade-guides/2-7-0-to-2-7-1.md index 8b1e7fc..f275cab 100644 --- a/docs/upgrade-guides/2-7-0-to-2-7-1.md +++ b/docs/upgrade-guides/2-7-0-to-2-7-1.md @@ -3,4 +3,4 @@ This document describes the upgrade instructions from `2.7.0` to `2.7.1`. ## Patch release -This is a patch release to fix a known issue in `2.7.0`. If you are using `2.7.0`, you should upgrade to this version or later to avoid potential issues with data migration. No additional changes are necessary. More information about this issue can be found [here](https://github.com/NASA-AMMOS/aerie/pull/1374). +This is a patch release to fix a known issue in `2.7.0`. If you are using `2.7.0`, you should upgrade to this version or later to avoid potential issues with data migration. No additional changes are necessary. More information about this issue can be found [here](https://github.com/NASA-AMMOS/plandev/pull/1374). diff --git a/docs/upgrade-guides/3-0-0-to-3-1-0.md b/docs/upgrade-guides/3-0-0-to-3-1-0.md index 3edbcfb..2ccddeb 100644 --- a/docs/upgrade-guides/3-0-0-to-3-1-0.md +++ b/docs/upgrade-guides/3-0-0-to-3-1-0.md @@ -2,5 +2,5 @@ * **NOTE**: An issue with database migrations was discovered in Aerie `v3.1.0` and fixed in `v3.1.1`. Please use `v3.1.1` instead of `v3.1.0` to avoid issues with migrations. -The **Procedural Scheduling API** has one breaking change in Aerie `v3.1.0`: the functionality of `filterLongerThan` and `filterShorterThan` methods have been **inverted** to be more consistent with other `filter` methods. `filterLongerThan(duration)` will now *include* all events longer than `duration`, not *remove* them. See [aerie-ui#1587](https://github.com/NASA-AMMOS/aerie/pull/1587) for details. If you are using these functions in your code, you should invert them as needed to achieve the same functionality in `v3.1.0`. +The **Procedural Scheduling API** has one breaking change in Aerie `v3.1.0`: the functionality of `filterLongerThan` and `filterShorterThan` methods have been **inverted** to be more consistent with other `filter` methods. `filterLongerThan(duration)` will now *include* all events longer than `duration`, not *remove* them. See [aerie-ui#1587](https://github.com/NASA-AMMOS/plandev/pull/1587) for details. If you are using these functions in your code, you should invert them as needed to achieve the same functionality in `v3.1.0`. diff --git a/docs/upgrade-guides/3-2-0-to-3-3-0.md b/docs/upgrade-guides/3-2-0-to-3-3-0.md index 16b559b..e94342b 100644 --- a/docs/upgrade-guides/3-2-0-to-3-3-0.md +++ b/docs/upgrade-guides/3-2-0-to-3-3-0.md @@ -2,7 +2,7 @@ ## Updated migration script -The behavior of the [Aerie database migration script](https://nasa-ammos.github.io/aerie-docs/deployment/advanced-database-migrations/) has been [improved to be more user-friendly](https://github.com/NASA-AMMOS/aerie/pull/1617) and report more information. Along with this, the syntax used to invoke the script has changed slightly, and now requires a subcommand, eg. `aerie_db_migration.py migrate ...`. [See this docs page for more details](https://nasa-ammos.github.io/aerie-docs/deployment/advanced-database-migrations/). The instructions for running the OLD version of the script [have been preserved here](https://nasa-ammos.github.io/aerie-docs/deployment/advanced-database-migrations-OLD/) - in case you ever need to downgrade your Aerie deployment to a version <3.3.0, you will need to use the old version of the migration script. +The behavior of the [Aerie database migration script](https://nasa-ammos.github.io/plandev-docs/deployment/advanced-database-migrations/) has been [improved to be more user-friendly](https://github.com/NASA-AMMOS/plandev/pull/1617) and report more information. Along with this, the syntax used to invoke the script has changed slightly, and now requires a subcommand, eg. `aerie_db_migration.py migrate ...`. [See this docs page for more details](https://nasa-ammos.github.io/plandev-docs/deployment/advanced-database-migrations/). The instructions for running the OLD version of the script [have been preserved here](https://nasa-ammos.github.io/plandev-docs/deployment/advanced-database-migrations-OLD/) - in case you ever need to downgrade your Aerie deployment to a version <3.3.0, you will need to use the old version of the migration script. diff --git a/docs/upgrade-guides/3-3-1-to-3-4-0.md b/docs/upgrade-guides/3-3-1-to-3-4-0.md index 8f57288..62be0b7 100644 --- a/docs/upgrade-guides/3-3-1-to-3-4-0.md +++ b/docs/upgrade-guides/3-3-1-to-3-4-0.md @@ -18,26 +18,26 @@ If you encounter this, add the following line to your `build.gradle` in the `dep ``` testRuntimeOnly 'org.junit.platform:junit-platform-launcher' ``` -See [the mission model template](https://github.com/NASA-AMMOS/aerie-mission-model-template/blob/8bc56fe9f47b2494ab655855fe7d7ef8fca6e1ae/missionmodel/build.gradle) for example and [this Github issue](https://github.com/junit-team/junit5/issues/4374#issuecomment-2704880447) for more info. +See [the mission model template](https://github.com/NASA-AMMOS/plandev-mission-model-template/blob/8bc56fe9f47b2494ab655855fe7d7ef8fca6e1ae/missionmodel/build.gradle) for example and [this Github issue](https://github.com/junit-team/junit5/issues/4374#issuecomment-2704880447) for more info. -A new [Upgrade Process guide](https://nasa-ammos.github.io/aerie-docs/deployment/upgrade-process/) was recently added to our documentation, please refer to that document for general upgrade instructions. +A new [Upgrade Process guide](https://nasa-ammos.github.io/plandev-docs/deployment/upgrade-process/) was recently added to our documentation, please refer to that document for general upgrade instructions. ## Database migrations -Aerie v3.4.0 adds two new database migrations, please be sure to [run the database migration script when upgrading](https://nasa-ammos.github.io/aerie-docs/deployment/advanced-database-migrations/) if you want to preserve your data in Aerie v3.4.0. +Aerie v3.4.0 adds two new database migrations, please be sure to [run the database migration script when upgrading](https://nasa-ammos.github.io/plandev-docs/deployment/advanced-database-migrations/) if you want to preserve your data in Aerie v3.4.0. ## Interface changes Some changes have been made to the API and database structure for constraint definitions and constraint runs, to support Procedural Constraints. The `constraint_run` table has been split into three tables: `constraint_run`, `constraint_request`, and `constraint_result`. The `constraint_definition` table has been updated to support JARs, and constraint specification tables have been updated to support invocations, arguments and priority. The Hasura action for running constraints now accepts an optional boolean `force` flag - if set to `true`, the Action will skip loading results from the cache - and its response body now includes the generated request id. -For full details about these changes, see the Pull Request [Procedural Constraints Action/Database Support #1596](https://github.com/NASA-AMMOS/aerie/pull/1596) +For full details about these changes, see the Pull Request [Procedural Constraints Action/Database Support #1596](https://github.com/NASA-AMMOS/plandev/pull/1596) ## New Features This release adds some significant new experimental features to Aerie - check out our docs for more details: -* Aerie now supports [Procedural Constraints](https://nasa-ammos.github.io/aerie-docs/scheduling-and-constraints/procedural/constraints/introduction/), Java-based user-defined constraints which may leverage the same libraries used by [Procedural Scheduling](https://nasa-ammos.github.io/aerie-docs/scheduling-and-constraints/procedural/scheduling/introduction/) as an alternative to our [declarative/EDSL constraints feature](https://nasa-ammos.github.io/aerie-docs/scheduling-and-constraints/declarative/constraints/introduction/) -* [Aerie Actions](https://nasa-ammos.github.io/aerie-docs/sequencing/actions/) have been added to our Phoenix sequencing app - these are a powerful new tool allowing users to define custom tasks in Javascript that operate on the sequences in their workspace, to do things like translation, compilation or static checking. -* [Sequence Templates](https://nasa-ammos.github.io/aerie-docs/command-expansion/template-expansion/introduction/) are now supported as a way for users to expand activities in a plan into commands/sequences, as an alternative to our existing Typescript EDSL expansion rules. +* Aerie now supports [Procedural Constraints](https://nasa-ammos.github.io/plandev-docs/scheduling-and-constraints/procedural/constraints/introduction/), Java-based user-defined constraints which may leverage the same libraries used by [Procedural Scheduling](https://nasa-ammos.github.io/plandev-docs/scheduling-and-constraints/procedural/scheduling/introduction/) as an alternative to our [declarative/EDSL constraints feature](https://nasa-ammos.github.io/plandev-docs/scheduling-and-constraints/declarative/constraints/introduction/) +* [Aerie Actions](https://nasa-ammos.github.io/plandev-docs/sequencing/actions/) have been added to our Phoenix sequencing app - these are a powerful new tool allowing users to define custom tasks in Javascript that operate on the sequences in their workspace, to do things like translation, compilation or static checking. +* [Sequence Templates](https://nasa-ammos.github.io/plandev-docs/command-expansion/template-expansion/introduction/) are now supported as a way for users to expand activities in a plan into commands/sequences, as an alternative to our existing Typescript EDSL expansion rules. diff --git a/docs/upgrade-guides/3-5-1-to-3-6-0.md b/docs/upgrade-guides/3-5-1-to-3-6-0.md index 3b7bb3e..be8ad64 100644 --- a/docs/upgrade-guides/3-5-1-to-3-6-0.md +++ b/docs/upgrade-guides/3-5-1-to-3-6-0.md @@ -55,5 +55,5 @@ If this occurs, the safest move is to *remove* your `workspace_file_store` docke ## Aerie Actions :::caution - As discussed [elsewhere in the docs](https://nasa-ammos.github.io/aerie-docs/sequencing/actions/), Aerie Actions are included in this release as an experimental feature. Aerie **intentionally defaults** to only allowing users with the `aerie_admin` role to upload actions, and you **should not change this setting**. Actions should be authored and reviewed by trusted users only, as a **malicious action** could get access to other parts of the Aerie database besides the workspace within which it is run. + As discussed [elsewhere in the docs](https://nasa-ammos.github.io/plandev-docs/sequencing/actions/), Aerie Actions are included in this release as an experimental feature. Aerie **intentionally defaults** to only allowing users with the `aerie_admin` role to upload actions, and you **should not change this setting**. Actions should be authored and reviewed by trusted users only, as a **malicious action** could get access to other parts of the Aerie database besides the workspace within which it is run. ::: diff --git a/docs/upgrade-guides/3-6-0-to-3-7-0.md b/docs/upgrade-guides/3-6-0-to-3-7-0.md index da34433..eb8594f 100644 --- a/docs/upgrade-guides/3-6-0-to-3-7-0.md +++ b/docs/upgrade-guides/3-6-0-to-3-7-0.md @@ -20,6 +20,6 @@ Multiple DB migrations were added in this release. If you are upgrading from a p ## Descriptions for Activities, Parameters and Resource Types -This release adds support for annotating the Activities, Activity Parameters and Resources in your mission model with user-readable descriptions. For Activities and Parameters, you can precede their declaration with an annotation like `@Description("My description")`, and for resources you can pass an additional description argument to the registrar. See [`BakeBananaBreadActivity.java`](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/activities/BakeBananaBreadActivity.java#L15) and [`Mission.java`](https://github.com/NASA-AMMOS/aerie/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/Mission.java) in the example model for examples. +This release adds support for annotating the Activities, Activity Parameters and Resources in your mission model with user-readable descriptions. For Activities and Parameters, you can precede their declaration with an annotation like `@Description("My description")`, and for resources you can pass an additional description argument to the registrar. See [`BakeBananaBreadActivity.java`](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/activities/BakeBananaBreadActivity.java#L15) and [`Mission.java`](https://github.com/NASA-AMMOS/plandev/blob/develop/examples/banananation/src/main/java/gov/nasa/jpl/aerie/banananation/Mission.java) in the example model for examples. These descriptions will be visible in the UI, and stored in the Aerie database (in the `metadata` column for parameters/resources, and in a new column called `description` for activities) for retrieval via the API. diff --git a/docs/upgrade-guides/3-7-0-to-3-7-1.md b/docs/upgrade-guides/3-7-0-to-3-7-1.md index 22c41bb..c25b583 100644 --- a/docs/upgrade-guides/3-7-0-to-3-7-1.md +++ b/docs/upgrade-guides/3-7-0-to-3-7-1.md @@ -28,11 +28,11 @@ Aerie 3.7.0 added the ability to define secret-type parameters on Actions, and p environment: PUBLIC_ACTION_CLIENT_URL: http://YOUR_HOST_NAME:27186 ``` -See [this docker-compose file](https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/docker-compose.yml#L191) for an example. +See [this docker-compose file](https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/docker-compose.yml#L191) for an example. ### `tables.yaml` file If you are managing **custom Hasura metadata `.yaml` files** for your deployment (instead of using the ones included in our `Deployment.zip`), you will need to make sure the file `hasura/metadata/databases/tables/tables.yaml` contains the following `include` statement: ```yaml - "!include ui/file_extension_content_type.yaml" ``` -See [this file for an example](https://github.com/NASA-AMMOS/aerie/blob/5352ddbac2408af649f5608cef7c05909835452a/deployment/hasura/metadata/databases/tables/tables.yaml#L191). +See [this file for an example](https://github.com/NASA-AMMOS/plandev/blob/5352ddbac2408af649f5608cef7c05909835452a/deployment/hasura/metadata/databases/tables/tables.yaml#L191). diff --git a/docs/upgrade-guides/3-7-1-to-3-8-0.md b/docs/upgrade-guides/3-7-1-to-3-8-0.md index b7230b8..8686651 100644 --- a/docs/upgrade-guides/3-7-1-to-3-8-0.md +++ b/docs/upgrade-guides/3-7-1-to-3-8-0.md @@ -11,11 +11,11 @@ There are a few changes to our `docker-compose.yml` file for the `aerie_action` * Under the `aerie_action` container, in the `environment` section, you can remove the `HASURA_GRAPHQL_ADMIN_SECRET` variable as it is no longer needed * Under the `aerie_workspace` container, add `HASURA_GRAPHQL_URL: http://hasura:8080/v1/graphql` (or your equivalent, if running on a different url/port) -See this file in the `aerie` repo for a full example: https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/docker-compose.yml +See this file in the `aerie` repo for a full example: https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/docker-compose.yml ### Hasura metadata yaml file changes -If you maintain your own versions of Hasura metadata files for granular control of permissions (rare), you may need to update them to contain the latest values for Workspaces. [This PR is a good reference](https://github.com/NASA-AMMOS/aerie/pull/1757/files#diff-def18dd27c7d2c9dfe61a27ba55973f94e8354160d817a99c7ef0ad4c0682e7a) demonstrating the changes to the `yaml` files in `deployment/hasura/metadata` +If you maintain your own versions of Hasura metadata files for granular control of permissions (rare), you may need to update them to contain the latest values for Workspaces. [This PR is a good reference](https://github.com/NASA-AMMOS/plandev/pull/1757/files#diff-def18dd27c7d2c9dfe61a27ba55973f94e8354160d817a99c7ef0ad4c0682e7a) demonstrating the changes to the `yaml` files in `deployment/hasura/metadata` # DB Migrations diff --git a/docs/upgrade-guides/3-8-1-to-4-0-0.md b/docs/upgrade-guides/3-8-1-to-4-0-0.md index a147ff9..55e0a6d 100644 --- a/docs/upgrade-guides/3-8-1-to-4-0-0.md +++ b/docs/upgrade-guides/3-8-1-to-4-0-0.md @@ -22,6 +22,6 @@ PlanDev v4.0.0 is a "major release" in name only, and does n**ot require any mig This release contains a few changes to the default **sorting order** of items in lists. These are not usually breaking changes, but may be unexpected if your process relies on the existing ordering. -* On the Models page, models are now listed in reverse ID order, ie. most recent first. ([#1364](https://github.com/NASA-AMMOS/aerie-ui/issues/1364)) -* For [procedural scheduling goals and constraints](https://nasa-ammos.github.io/plandev-docs/scheduling-and-constraints/procedural/introduction/), their parameters now appear in the order they are written in the procedural code. ([#1738](https://github.com/NASA-AMMOS/aerie/pull/1738)) -* Command expansion rules in the "New Expansion Set" table are now sorted by rule ID. ([#1823](https://github.com/NASA-AMMOS/aerie-ui/issues/1823)) +* On the Models page, models are now listed in reverse ID order, ie. most recent first. ([#1364](https://github.com/NASA-AMMOS/plandev-ui/issues/1364)) +* For [procedural scheduling goals and constraints](https://nasa-ammos.github.io/plandev-docs/scheduling-and-constraints/procedural/introduction/), their parameters now appear in the order they are written in the procedural code. ([#1738](https://github.com/NASA-AMMOS/plandev/pull/1738)) +* Command expansion rules in the "New Expansion Set" table are now sorted by rule ID. ([#1823](https://github.com/NASA-AMMOS/plandev-ui/issues/1823)) diff --git a/docusaurus.config.js b/docusaurus.config.js index 1328f73..1603da9 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -99,7 +99,7 @@ const config = { // value: 'Archived versions', // }, // { - // href: 'https://nasa-ammos.github.io/aerie-docs/1.0.0', + // href: 'https://nasa-ammos.github.io/plandev-docs/1.0.0', // label: '1.0.0', // }, // ], @@ -109,7 +109,7 @@ const config = { { 'aria-label': 'GitHub repository', className: 'header-github-link', - href: 'https://github.com/NASA-AMMOS/aerie', + href: 'https://github.com/NASA-AMMOS/plandev', position: 'right', }, ], diff --git a/sidebars.js b/sidebars.js index e15be76..3a63c84 100644 --- a/sidebars.js +++ b/sidebars.js @@ -144,7 +144,7 @@ const sidebars = { { label: 'Environment Variables', type: 'link', - href: 'https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/Environment.md', + href: 'https://github.com/NASA-AMMOS/plandev/blob/develop/deployment/Environment.md', }, 'deployment/advanced-ui-custom-base-path', 'deployment/advanced-kubernetes', @@ -336,7 +336,7 @@ const sidebars = { { label: 'EDSL Docs', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/constraints-edsl-api/', + href: 'https://nasa-ammos.github.io/plandev/constraints-edsl-api/', }, ], }, @@ -355,7 +355,7 @@ const sidebars = { { label: 'EDSL Docs', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/scheduling-edsl-api/modules/Scheduling_eDSL.html', + href: 'https://nasa-ammos.github.io/plandev/scheduling-edsl-api/modules/Scheduling_eDSL.html', }, ], }, @@ -421,92 +421,92 @@ const sidebars = { { label: 'Constraints eDSL Backend', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/constraints/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/constraints/', }, { label: 'Contrib', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/contrib/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/contrib/', }, { label: 'Examples - Banananation', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/examples/banananation/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/examples/banananation/', }, { label: 'Examples - Config With Defaults', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/examples/config-with-defaults/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/examples/config-with-defaults/', }, { label: 'Examples - Config Without Defaults', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/examples/config-without-defaults/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/examples/config-without-defaults/', }, { label: 'Examples - Foo Mission Model', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/examples/foo-missionmodel/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/examples/foo-missionmodel/', }, { label: 'Merlin Driver', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/merlin-driver/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/merlin-driver/', }, { label: 'Merlin Framework', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/merlin-framework/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/merlin-framework/', }, { label: 'Merlin Framework JUnit', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/merlin-framework-junit/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/merlin-framework-junit/', }, { label: 'Merlin Framework Processor', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/merlin-framework-processor/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/merlin-framework-processor/', }, { label: 'Merlin SDK', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/merlin-sdk/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/merlin-sdk/', }, { label: 'Merlin Server', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/merlin-server/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/merlin-server/', }, { label: 'Merlin Worker', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/merlin-worker/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/merlin-worker/', }, { label: 'Parsing Utilities', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/parsing-utilities/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/parsing-utilities/', }, { label: 'Procedural APIs', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/procedural-apis', + href: 'https://nasa-ammos.github.io/plandev/procedural-apis', }, { label: 'Scheduler Driver', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/scheduler-driver/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/scheduler-driver/', }, { label: 'Scheduler Server', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/scheduler-server/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/scheduler-server/', }, { label: 'Scheduler Worker', type: 'link', - href: 'https://nasa-ammos.github.io/aerie/javadoc/scheduler-worker/', + href: 'https://nasa-ammos.github.io/plandev/javadoc/scheduler-worker/', }, ], }, diff --git a/src/components/HomepageCards/index.js b/src/components/HomepageCards/index.js index 43abe33..b3515ca 100644 --- a/src/components/HomepageCards/index.js +++ b/src/components/HomepageCards/index.js @@ -136,7 +136,7 @@ const LearnMoreList = [ Img: require('@site/static/img/cards/plandev-learn-github.png').default, ImgDark: require('@site/static/img/cards/plandev-learn-github-dark.png').default, size: 'col--4', - link: 'https://github.com/NASA-AMMOS/aerie', + link: 'https://github.com/NASA-AMMOS/plandev', linkTitle: 'PlanDev on Github', description: ( <>Post a question in GitHub discussions, or contribute back and help make PlanDev even better than it is today. diff --git a/src/components/HomepageFooter/index.js b/src/components/HomepageFooter/index.js index 98f14c6..87555eb 100644 --- a/src/components/HomepageFooter/index.js +++ b/src/components/HomepageFooter/index.js @@ -19,7 +19,7 @@ const links = [ { category: 'Resources', label: 'Github', - href: 'https://github.com/NASA-AMMOS/aerie', + href: 'https://github.com/NASA-AMMOS/plandev', type: 'link', }, {