| Age | Commit message (Collapse) | Author |
|---|
|
This change fixes the Dockerfile for the OpenDC web server by also
providing the custom Auth0 configuration values during build time of the
image. These settings cannot be changed during runtime, so we need to
declare them in the Dockerfile.
|
|
This change fixes the Docker deployment of the OpenDC web UI. There have
been several updates to the build process of the web UI, which have not
taken into account the Docker deployment process. This change addresses
these discrepancies.
|
|
This change updates the Quarkus-based web server to use Flyway for
migrating between schema versions. This enables us to evolve the schema
and denote it in SQL.
|
|
This change updates the Quarkus configuration of the OpenDC web server
to serve as a fully standalone distribution that is capable of serving
the web UI, web API, and experiment runner. Such an approach vastly
simplifies local deployments.
For Docker deployments, we create a custom Quarkus profile that uses
PostgreSQL and disables the web UI.
|
|
This change updates the web server configuration to reduce the logging
output produced by simulation runs.
|
|
This change updates the Quarkus extension for the OpenDC runner to avoid
the REST layer if possible, by providing an implementation of `JobManager`
that directly communicates with the `JobService`. This means the runner
does not have to traverse the authentication layer.
|
|
This change introduces a new interface `JobManager` that is responsible
for communicating with the backend about the available jobs and updating
their status when the runner is simulating a job. This manager can be
injected into the `OpenDCRunner` class and allows users to provide
different sources for the jobs, not only the current REST API.
|
|
This change updates the runner configuration to support specifying the
parallelism as zero to let the runtime decide the appropriate number of
threads based on the available CPU cores on the machine.
|
|
This change fixes an issue with the OpenDC web runner where it would
report NaN values for some of the metrics due to the topology being
empty. This in turn causes issues in the frontend.
|
|
This change updates the web runner implementation to gracefully exit the
current thread when interrupted.
|
|
This change updates the OpenDC web runner implementation to use the
correct context ClassLoader for simulation jobs running inside a
ForkJoinPool. By default, the ForkJoinPool will use the system class
loader which does not have access to the services needed by the web
runner.
|
|
This change updates the Quarkus extension to register all the available
trace formats that are on the class path during processing time.
Without this change, the OpenDC web runner is unable to load any of the
available trace formats via Quarkus.
|
|
This change updates the simulator dependencies to the latest available
version where possible.
|
|
This change adds a distribution that contains the OpenDC web server
implementation based on Quarkus. This distribution should be used by
advanced users that whish to deploy a custom OpenDC instance.
|
|
This change adds a Quarkus extension that hosts the OpenDC web runner
for a (potentially local) OpenDC API instance. This functionality
enables a simplified developer experience by allowing users to spawn the
complete OpenDC stack with a single command.
|
|
This change updates the OpenDC web UI Quarkus extension to live
completely in the `opendc-web` directory, as opposed to adding another
level of nesting. This also allows us to properly name the artifacts of
the Quarkus extension modules.
|
|
This change splits the command line interface from the OpenDC web runner
into a separate configuration. We plan to re-use the runner code for a Quarkus
extension that integrates the runner in development mode.
|
|
This change updates the `OpenDCClient` and `OpenDCRunnerClient` to
support connecting to an API that is not protected by authorization.
This is useful in a local development context where authorization is
explicitly disabled.
|
|
|
|
This change updates the dependencies of the Next.js-based web UI to
their latest available versions where possible.
|
|
This change fixes an issue where the library for hotkeys that we
previously used does not (yet) support React 18. Instead, we switch to a
simpler solution based on React Hooks which is compatible with React 18.
|
|
This change updates the build configuration in order to ensure that
Node.js is downloaded onto the build system. This drops an explicit
dependency on a system installation of Node.js and allows us to ensure
that the project is built against the correct Node.js version.
|
|
This change updates the Dockerfile for the web runner to reduce the
number of build steps necessary to build the web runner. Previously, the
build would also include/build the web API which is not used in the
image.
|
|
This change removes the OpenTelemetry integration from the OpenDC
Compute modules. Previously, we chose to integrate OpenTelemetry to
provide a unified way to report metrics to the users.
Although this worked as expected, the overhead of the OpenTelemetry when
collecting metrics during simulation was considerable and lacked more
optimization opportunities (other than providing a separate API
implementation). Furthermore, since we were tied to OpenTelemetry's SDK
implementation, we experienced issues with throttling and registering
multiple instruments.
We will instead use another approach, where we expose the core metrics
in OpenDC via specialized interfaces (see the commits before) such that
access is fast and can be done without having to interface with
OpenTelemetry. In addition, we will provide an adapter to that is able
to forward these metrics to OpenTelemetry implementations, so we can
still integrate with the wider ecosystem.
|
|
This change introduces a `ComputeMetricReader` class that can be used as
a replacement for the `CoroutineMetricReader` class when reading metrics
from the Compute service. This implementation operates directly on a
`ComputeService` instance, providing better performance.
|
|
This change updates the Gradle build configuration of the project to
publish the different type of modules (e.g., opendc-compute,
opendc-simulator) into their own groups.
|
|
This change updates the Gradle build configuration to ensure that all
library modules (that will be published) use testing and are included in
coverage reports. This should ensure the public modules remain well
tested.
|
|
This change updates the compute support library to load the VM
interference model via the OpenDC trace library, which provides a
generic interface for reading interference models associated with
workload traces.
|
|
This change contains a rewrite of the OpenDC web runner implementation,
which now supports terminating simulations when exceeding a deadline, as
well as executing multiple simulation jobs at the same time.
Furthermore, we have extracted the runner from the command line
interface, so that we can offer this functionality as a library in the
future.
|
|
This change moves most of the Quarkus build configuration into buildSrc
so it can possibly be re-used for other modules.
|
|
This change fixes an issue where the results of the Quarkus tests where
not included in the aggregated JaCoCo test report, due to it not using
the official Gradle JaCoCo plugin.
This change defines a new configuration that exposes the execution data
generated by Quarkus to the aggregation plugin.
|
|
This change updates the web API to use Quarkus 2.8.1.Final. This release
fixes an issue we had with local extensions failing to build due to some
build directories missing.
|
|
This change updates the Node package manager used by the OpenDC web UI
build from Yarn to NPM, which is included by default in the Node
distributions that are used by node-gradle.
|
|
This change removes the use of lint-staged from the project. These steps
should be managed by the Gradle build logic, while we keep the Next.js
build logic as minimal as possible.
|
|
This change updates the ESLint dependencies to operate correctly in
Windows environments.
|
|
This change updates the web UI and API to support unauthenticated user
access. Such functionality is helpful when there is just a single user
that wants to try OpenDC.
|
|
This chnage add a workaround for the issues that appear when building
the Quarkus application due to it accessing the build files of the other
local modules.
|
|
This change adds support for serving the web UI of OpenDC while in the
development mode of the API server.
|
|
This change adds a new Quarkus extension that is able to serve the
OpenDC web interface via the Quarkus deployment of OpenDC.
|
|
This change updates the build process to build a static WebJar out of
the OpenDC web UI module. This allows us to embed the UI inside the
development distribution of OpenDC for other users to readily deploy it.
|
|
This change adds support for building the OpenDC web interface project
that uses Next.js using Gradle. This enables a single build pipeline
using Gradle.
|
|
|
|
This change updates the web interface to use next-global-css instead of
next-transpile-modules. This approach is more efficient since it does
not require transpilation of the dependencies.
|
|
This change removes the use of next/image from the project. Although it
is recommended by the Next.js project to use this component, it is not
compatible currently with static export.
|
|
This change updates the build script to fix the aggregation step for the
JaCoCo coverage reports that are submitted to Codecov. Previously, not
all modules were properly included in the report.
|
|
This change updates the Docker deployment configuration for the new web
API implemented in Kotlin. The new API migrates to Postgres.
Furthermore, with this change, we move the Dockerfiles to their
corresponding module.
|
|
This change updates the web interface in React to be compatible with the
new API written in Kotlin. Several changes have been made in the new API
to ensure consistency.
|
|
This change updates the web runner implementation to use the new API
client introduced in the previous commit.
|
|
This change implements a simple client for the OpenDC REST API into a
separate module. This allows other users to use this module as well.
|
|
This change adds support for dynamically selecting the appropriate JSON
type for the current database. For Postgres, this will be the JSONB
type, while for H2 this is either the BLOB or JSON type.
|
