Skip to main content

0.13.2 to 1.0.0

This document describes the upgrade instructions from 0.13.2 to 1.0.0.

Activity Directive New Primary Key (#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.
Any API call that queries or mutates an activity_directive now needs to include both an id and plan_id.

For example see this update to an activity_directive mutation. Notice we include both the id and plan_id in the primary key columns field (pk_columns) to uniquely identify the activity.

mutation UpdateActivityDirective($id: Int!, $plan_id: Int!, $activityDirectiveSetInput: activity_directive_set_input!) {
  update_activity_directive_by_pk(pk_columns: { id: $id, plan_id: $plan_id }, _set: $activityDirectiveSetInput) {
    id
  }
}

Improved Test Ergonomics (#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:

  1. The constructor of the unit test class should take a single Registrar parameter, rather than the MerlinTestContext
  2. Previous uses of ctx.registrar() can use this registrar argument instead
  3. Previous uses of ctx.use() can safely be deleted - they are no longer necessary

It is also recommended to use the @ExtendWith(MerlinExtension.class) annotation instead of the @RegisterExtension static method.

Please reference this diff which makes these updates to one of our example mission models.

Move 'TaskFactory' from Framework to Protocol (#382)​

So the simulation can manage task creation the TaskFactory has been moved to the Merlin protocol.

Any reference to:

gov.nasa.jpl.aerie.merlin.framework.Context.TaskFactory

Need to change to:

gov.nasa.jpl.aerie.merlin.protocol.model.TaskFactory

Remove 'RootModel' (#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)​

The constraints DSL has renamed some boolean operators to be more clear. You should rename the following:

  1. All -> And
  2. Any -> Or
  3. Invert -> Not

For example the following constraint uses the new operators:

export default (): Constraint => {
  return Windows.Not( // Used to be '.Invert'
    Windows.Or( // Used to be '.Any'
      Discrete.Resource('/resource/A').equal('OPEN'),
      Windows.And( // Used to be '.All'
        Discrete.Resource('/resource/B').equal('FALSE'),
        Discrete.Resource('/resource/C').equal('FALSE'),
      ),
    ),
  );
};

Global Scheduling Conditions Mutex (#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 for more detailed instructions.

Rename "condition" table to "constraint" (#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:

query GetConstraints {
  constraint { # Used to be 'condition'
    definition
    description
    id
    model_id
    name
    plan_id
    summary
  }
}

SimulationResults Java Class No Longer Provides 'resourceSamples' Field (#423)​

Prior to this change, the resourceSamples field was derived from realProfiles and discreteProfiles via the takeSamples 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.

Any test code that refers to resourceSamples will need to get that information from realProfiles and discreteProfiles instead. You can use the following "drop in" method if you still want to use resourceSamples in your Java code:

static Map<String, List<Pair<Duration, SerializedValue>>> takeSamples(SimulationResults simulationResults) {
    final var samples = new HashMap<String, List<Pair<Duration, SerializedValue>>>();

    simulationResults.realProfiles.forEach((name, p) -> {
        var elapsed = Duration.ZERO;
        var profile = p.getRight();

        final var timeline = new ArrayList<Pair<Duration, SerializedValue>>();
        for (final var piece : profile) {
            final var extent = piece.getLeft();
            final var dynamics = piece.getRight();

            timeline.add(Pair.of(elapsed, SerializedValue.of(
                dynamics.initial)));
            elapsed = elapsed.plus(extent);
            timeline.add(Pair.of(elapsed, SerializedValue.of(
                dynamics.initial + dynamics.rate * extent.ratioOver(Duration.SECONDS))));
        }

        samples.put(name, timeline);
    });
    simulationResults.discreteProfiles.forEach((name, p) -> {
        var elapsed = Duration.ZERO;
        var profile = p.getRight();

        final var timeline = new ArrayList<Pair<Duration, SerializedValue>>();
        for (final var piece : profile) {
            final var extent = piece.getLeft();
            final var value = piece.getRight();

            timeline.add(Pair.of(elapsed, value));
            elapsed = elapsed.plus(extent);
            timeline.add(Pair.of(elapsed, value));
        }

        samples.put(name, timeline);
    });

    return samples;
}

Rename 'command-expansion-server' to 'sequencing-server' (#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. You can reference the updated deployment docker-compose.yml for a detailed example.

Add Scheduler Workers (#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. You can reference the updated deployment docker-compose.yml for a detailed example. Also please read the updated Aerie Scheduler and Aerie Scheduler Worker environment variables to make sure your deployment is up-to-date.