aura issueshttps://gitlab.servus.at/aura/aura/-/issues2021-11-16T22:47:44+01:00https://gitlab.servus.at/aura/aura/-/issues/45[EPIC] Advanced CLI - Research & implement a CLI Framework2021-11-16T22:47:44+01:00David Trattnig[EPIC] Advanced CLI - Research & implement a CLI FrameworkCurrently there is some rudimentary functionality in the `run.sh` scripts.
Provide an advanced CLI system for
- development
- debugging and testing
- deployment, tech ops / sys ops
- release management
to manage Aura components.
...Currently there is some rudimentary functionality in the `run.sh` scripts.
Provide an advanced CLI system for
- development
- debugging and testing
- deployment, tech ops / sys ops
- release management
to manage Aura components.
## Possible Frameworks
- oclif (https://oclif.io/)
- Click (https://click.palletsprojects.com/en/3.x/)
- Click Alternatives (https://python.libhunt.com/click-alternatives)
- Collection of Awesome CLI Frameworks (https://github.com/shadawck/awesome-cli-frameworks)
- Comparison of some CLI Frameworks (https://www.nexmo.com/legacy-blog/2020/06/12/comparing-cli-building-libraries)1.1https://gitlab.servus.at/aura/aura/-/issues/46[EPIC] Accessibility2023-07-13T21:31:03+02:00David Trattnig[EPIC] AccessibilityFor example ARIA implementation, screen reader ready etc.For example ARIA implementation, screen reader ready etc.1.0-beta1https://gitlab.servus.at/aura/aura/-/issues/47[EPIC] Approaches to sync the excact playout time2023-07-17T12:07:03+02:00David Trattnig[EPIC] Approaches to sync the excact playout timeFor example to display in the Dashboard or the Studio Clock (in contrast to the browser time of these apps).
Research if it's possible to provide a Time API via Playout Engine.For example to display in the Dashboard or the Studio Clock (in contrast to the browser time of these apps).
Research if it's possible to provide a Time API via Playout Engine.1.1https://gitlab.servus.at/aura/aura/-/issues/48[EPIC] Embed Studio Clock into Dashboard2023-06-27T13:12:51+02:00David Trattnig[EPIC] Embed Studio Clock into DashboardWhile the basic integration is easy, there needs to be a time sync approach in place to allow displaying the correct time difference (playout time vs. browser time) and displaying timeslots accordingly.While the basic integration is easy, there needs to be a time sync approach in place to allow displaying the correct time difference (playout time vs. browser time) and displaying timeslots accordingly.1.2https://gitlab.servus.at/aura/aura/-/issues/49[EPIC] AURA Dashboard as a Progressive Web App2023-04-27T11:34:24+02:00David Trattnig[EPIC] AURA Dashboard as a Progressive Web AppDashboard can be installed as a PWA on mobile devices.
Blocked by https://gitlab.servus.at/aura/dashboard/-/issues/159+Dashboard can be installed as a PWA on mobile devices.
Blocked by https://gitlab.servus.at/aura/dashboard/-/issues/159+Aura 2.0https://gitlab.servus.at/aura/aura/-/issues/57[EPIC] AURA CLI2023-04-25T16:17:39+02:00David Trattnig[EPIC] AURA CLIImprove and implement a command line interface providing targets for building, running dev and prod servers, testing and more (native and Docker).
## Specification
* Where possible, specification and documentation shall be provided bef...Improve and implement a command line interface providing targets for building, running dev and prod servers, testing and more (native and Docker).
## Specification
* Where possible, specification and documentation shall be provided before implementation: https://gitlab.servus.at/aura/meta/-/blob/master/docs/administration/cli.md
* Not all projects have an existing `run.sh` script already. If it is not existing yet, create such file. If it is missing some simple targets (e.g. to start the dev or prod server) add them. Check out `run.sh` of Engine & Engine-Core to get an idea of an complete, but basic target set.
* **Discuss**: Should parts of the script be extracted to some `Makefile` which is called by the run script? Does it make sense to replace the run.sh by `make` completely (feedback from @Oyla).
* **Discuss**: Does it make sense to improve the existing run.sh at all, or does it make more sense to implement a more advanced CLI (see #45) [or replace it with Earthly now, to cover `Makefile`, `Dockerfile` and Bash Scripts altogether](https://earthly.dev/).
## Best Practices for CLI development
* Check out the [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html) for inspirations on writing better scripts e.g. Let's replace `run.sh` with `run` executable?
* Keep it simple stupid (KISS) - *we want to encapsulate, not re-create the complexity of lengthy `docker run ...` commands*
* Try to keep the glue-code and configurations D.R.Y.
* Re-use targets as much as possible, even across projects + inside & outside of a Docker container, CI pipeline etc.
Example: Project specific Docker targets are called from the host using [`make docker.run`](https://gitlab.servus.at/aura/engine/-/blob/main/Makefile), but inside the starting docker container, the CLI command is re-used in its "native version". The [`make run`](https://gitlab.servus.at/aura/engine/-/blob/main/Makefile) target is called from within the Dockerfile again (https://gitlab.servus.at/aura/engine/-/blob/master/Dockerfile).
## TODO
- [x] Establish `Makefile` targets for dealing with repo-specific tasks
- #59 Provide a simple META CLI for maintaining Docker & Docker Compose. Integrate with an concept for dealing with App config files and Environment variables with Docker1.2https://gitlab.servus.at/aura/aura/-/issues/59[EPIC] META CLI for Docker & Docker Compose Maintenance2023-04-25T16:17:46+02:00David Trattnig[EPIC] META CLI for Docker & Docker Compose Maintenance
- Provide a simple META CLI for deploying & maintaining Docker & Docker Compose images. It should be located in the `meta` repository.
- Elegantly integrate with app config files and environment variables with Docker. Hence such concept...
- Provide a simple META CLI for deploying & maintaining Docker & Docker Compose images. It should be located in the `meta` repository.
- Elegantly integrate with app config files and environment variables with Docker. Hence such concept needs to be available beforehand.
- Flexible argument parsing.
- Check if knowledge or code from the existing "Aura Web" Docker Compose POC can be re-used (see https://gitlab.servus.at/aura/aura-web).
## Specification
Specification and documentation shall be provided before implementation: https://gitlab.servus.at/aura/meta/-/blob/master/docs/development/cli.md
## TODO
The required CLI features are two-fold:
### 1. SysOps Commands
- It shall work independent from other repositories. The ready-build images shall be drawn from dockerhub.com.
- Simple approach (*one-liner*) to run a single docker container, for example `$meta ./run.sh docker:steering`. Details on settings need to be documented here: https://gitlab.servus.at/aura/meta/-/blob/master/docs/administration/install-docker.md and here
- Simple approach (*one-liner*) to run the two Docker Compose "Aura Web" and "Aura Playout". Needs to be documented here: https://gitlab.servus.at/aura/meta/-/blob/master/docs/administration/install-docker-compose.md
### 2. Release Management Commands
- Simple commands to tag, push, release a defined software version
- Synchronization of versions in code/configs (for example npm packages), git tags and dockerhub tags
- Optional: Integration with Gitlab Milestones, Version pages and CI/CD
**OPTIONAL TASK:** #45 \[EPIC \] Advanced CLI - Replace the existing `run.sh` scripts with some proven CLI Framework1.2https://gitlab.servus.at/aura/aura/-/issues/74Update Component Diagram2024-03-21T18:34:48+01:00David TrattnigUpdate Component DiagramXML for draw.io provided by @ingo: [STRG_Schema5.xml](/uploads/51992d204794da0f6078069b0f108eaf/STRG_Schema5.xml)
![STRG_Schema5](/uploads/09fdeb489dfaa81b967a938489cec1a7/STRG_Schema5.png)XML for draw.io provided by @ingo: [STRG_Schema5.xml](/uploads/51992d204794da0f6078069b0f108eaf/STRG_Schema5.xml)
![STRG_Schema5](/uploads/09fdeb489dfaa81b967a938489cec1a7/STRG_Schema5.png)1.0-alpha7David TrattnigDavid Trattnighttps://gitlab.servus.at/aura/aura/-/issues/77[EPIC] Role and Permission Management2023-11-06T17:03:33+01:00David Trattnig[EPIC] Role and Permission ManagementThis ticket is a collection of all role and permissions settings to be implemented at some point:
## Sub Tickets
- #156+
- #157+This ticket is a collection of all role and permissions settings to be implemented at some point:
## Sub Tickets
- #156+
- #157+1.1https://gitlab.servus.at/aura/aura/-/issues/78Provide a Contributor License Agreement2022-08-08T13:10:31+02:00David TrattnigProvide a Contributor License Agreement@equinox suggested https://contributoragreements.org/ca-cla-chooser/@equinox suggested https://contributoragreements.org/ca-cla-chooser/1.0-beta1https://gitlab.servus.at/aura/aura/-/issues/80[EPIC] Simplify, combined versioning of app and git tag (e.g. bump2version)2024-03-21T18:34:23+01:00David Trattnig[EPIC] Simplify, combined versioning of app and git tag (e.g. bump2version)The release workflow currently requires two areas where a version needs to be updated (https://gitlab.servus.at/aura/meta/-/blob/master/docs/development/dev-releases.md):
- in the application version file (e.g. package.json)
- in form o...The release workflow currently requires two areas where a version needs to be updated (https://gitlab.servus.at/aura/meta/-/blob/master/docs/development/dev-releases.md):
- in the application version file (e.g. package.json)
- in form of a git tag
This should be combined. As @sumpfralle suggested we could use [Bump2Version](https://pypi.org/project/bump2version/)
Such feature should be implemented for all components and the full software suite (meta repo).
## Related questions to be solved
How should we handle "in development versioning".
One idea is to add a "-dev" suffix to a version in development1.0-alpha7https://gitlab.servus.at/aura/aura/-/issues/83Dashboard Clock doesn't quite work behind the reverse proxy2022-12-05T12:38:10+01:00EorlBruderDashboard Clock doesn't quite work behind the reverse proxyIn 8e1b9c22737eafa82e86074ac1da12683f1d39f3 I've added the possibility of optionally including the dashboard clock in the reverse proxy.
## Setup
The relevant components (dashboard, dashboard-clock and engine-api) are set-up as follow...In 8e1b9c22737eafa82e86074ac1da12683f1d39f3 I've added the possibility of optionally including the dashboard clock in the reverse proxy.
## Setup
The relevant components (dashboard, dashboard-clock and engine-api) are set-up as follows:
- The dashboard-clock image contains a very simple nginx, deploying the files for dashboard-clock under port 5001. The bind-address can be configured, so this can bind to a private network if dashboard-clock shouldn't be world-readable
- Engine-API will bind to a private network. Only the two public endpoints (`trackservice` and `trackservice/current`) will be world-readable via the reverse proxy (this is not implemented yet).
- The dashboard image contains a nginx-server which deploys dashboard and acts as a reverse-proxy for some further services (e.g. steering, tank). With a special env-variable set (INCLUDE_CLOCK, defaults to false) it will also act as a reverse proxy for dashboard-clock, thus making it world-readable (under $hostname/clock).
Dashboard-clock will fetch info from Engine-API via its `clock`-endpoint. Because dashboard-clock is working completly client-side, the clock-endpoint needs to be reachable from the browser with which you're looking at the dashboard-clock.
## Expected behavior
Now when I set INCLUDE_CLOCK to true, I'd expect dashboard-clock to be fully working from $hostname/clock. This means it should send requests to engine-apis `clock`-endpoint and display the results.
## Actual behavior
Now we run into multiple problems.
### Engine-API is in a private network
Since engine-api is in a private network and the `clock`-endpoint doesn't get exposed, it simply won't be reachable from the client accessing `/clock` (except if that client is in the same private network)
### Engine-API doesn't do https
If dashboard is configured to use https (which it does by default) or is in general accessed by https (which it should do in production), we'll even run in problems when engine-api is reachable from the accessing client. Engine-API doesn't do https and the `/clock` endpoint isn't included in the reverse proxy.
Thus, when opening dashboard-clock, we'll be making request from an https site (dashboard-clock) to a http resource (the API), which will result in `Blocked loading mixed active content “http://$hostname:8008/api/v1/clock"`-errors. This is sensible behavior.
## Possible Mitigations
Generally this won't happen if engine-api is reachable from the client and dashboard is configured to http-only. Of course this is not really a safe configuration. In addition I'd argue, that for this you could just not bother with the proxy and access the clock from $hostname:5001.
Basically the only way for this to work reliably is to also make the `/clock`-endpoint public. This could be an optional configuration, tied to the `INCLUDE_CLOCK` variable and would be quite easily implementable.
Should the mitigation above not be desired, I'd recommend to just roll back the `INCLUDE_CLOCK`-option. (Which affects this repository and the dashboard-repository).
Since this only affects a small edge-case for an optional setting I'd not prioritize it. I mainly aimed to document the current state, so no one trips over this option.1.1https://gitlab.servus.at/aura/aura/-/issues/86[EPIC] Provide a search server to index data in Steering2023-07-13T12:15:35+02:00David Trattnig[EPIC] Provide a search server to index data in SteeringProposal:
* As part of the `steering` repo or as a new `steering-search` repo
* Based on [Apache Solr](https://solr.apache.org) and [Haystack](https://django-haystack.readthedocs.io/en/master/)
* Provide ability to integrate with other ...Proposal:
* As part of the `steering` repo or as a new `steering-search` repo
* Based on [Apache Solr](https://solr.apache.org) and [Haystack](https://django-haystack.readthedocs.io/en/master/)
* Provide ability to integrate with other search backends (e.g. Drupal)
Final details to be clarified.1.1https://gitlab.servus.at/aura/aura/-/issues/97[EPIC] [AEP01] Recording, cutting and rescheduling of episodes2024-03-09T11:17:03+01:00David Trattnig[EPIC] [AEP01] Recording, cutting and rescheduling of episodesSpecification: [AEP01](https://gitlab.servus.at/aura/meta/-/wikis/AEP01-Aufnahmen-und-Wiederholungen)
## Tasks
- [x] https://gitlab.servus.at/aura/aura/-/issues/9+
- [x] https://gitlab.servus.at/aura/aura/-/issues/88+
- [x] https://git...Specification: [AEP01](https://gitlab.servus.at/aura/meta/-/wikis/AEP01-Aufnahmen-und-Wiederholungen)
## Tasks
- [x] https://gitlab.servus.at/aura/aura/-/issues/9+
- [x] https://gitlab.servus.at/aura/aura/-/issues/88+
- [x] https://gitlab.servus.at/aura/aura/-/issues/84+
- [x] https://gitlab.servus.at/aura/aura/-/issues/28+
- [ ] tbc: Provide service architecture to integrate recordings into Tank1.0-alpha7https://gitlab.servus.at/aura/aura/-/issues/98[EPIC] Prometheus monitoring compatibility2024-03-13T13:54:55+01:00David Trattnig[EPIC] Prometheus monitoring compatibility"As a system administrator I want services to be seamlessly integrated to Prometheus monitoring, to monitor service quality and availability".
Therefore services need to provide "metrics" API endpoints."As a system administrator I want services to be seamlessly integrated to Prometheus monitoring, to monitor service quality and availability".
Therefore services need to provide "metrics" API endpoints.1.1https://gitlab.servus.at/aura/aura/-/issues/101Use buildkit instead of privileged Docker in Docker (DinD) building2023-12-04T14:30:14+01:00David TrattnigUse buildkit instead of privileged Docker in Docker (DinD) building[Buildkit](https://docs.docker.com/develop/develop-images/build_enhancements/) was suggested as a faster alternative to [Kaniko](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html).[Buildkit](https://docs.docker.com/develop/develop-images/build_enhancements/) was suggested as a faster alternative to [Kaniko](https://docs.gitlab.com/ee/ci/docker/using_kaniko.html).1.1Kay EffenbergerKay Effenbergerhttps://gitlab.servus.at/aura/aura/-/issues/103Docs (Developer Guide): Technical documentation on overall OpenID implementation2022-07-07T13:58:46+02:00David TrattnigDocs (Developer Guide): Technical documentation on overall OpenID implementationDocument:
- General OIDC implementation approach
- Steering, Tank and Dashboard specifics
Also compare and update relevant parts in https://docs.aura.radio/en/latest/developer/misc/oidc-client-config.htmlDocument:
- General OIDC implementation approach
- Steering, Tank and Dashboard specifics
Also compare and update relevant parts in https://docs.aura.radio/en/latest/developer/misc/oidc-client-config.html1.1https://gitlab.servus.at/aura/aura/-/issues/106Document how to start individual Docker containers2023-03-01T15:18:48+01:00David TrattnigDocument how to start individual Docker containersDocumentation on how following Containers are started with Docker-only (`RUN` commands):
- Engine
- Engine Core
- Engine Recorder
- Dashboard Clock
This solves the [partially open sub-task]() of #23+Documentation on how following Containers are started with Docker-only (`RUN` commands):
- Engine
- Engine Core
- Engine Recorder
- Dashboard Clock
This solves the [partially open sub-task]() of #23+1.0-beta1David TrattnigDavid Trattnighttps://gitlab.servus.at/aura/aura/-/issues/107Migrate feature documentation from individual repos to docs.aura.radio2024-03-21T18:32:30+01:00David TrattnigMigrate feature documentation from individual repos to docs.aura.radioIndividual repos should be kept simple stupid, holding essential information to kick-start developer usage.
https://docs.aura.radio is the place to hold all documentation guides. So let's migrate relevant information.Individual repos should be kept simple stupid, holding essential information to kick-start developer usage.
https://docs.aura.radio is the place to hold all documentation guides. So let's migrate relevant information.1.0-alpha6David TrattnigDavid Trattnighttps://gitlab.servus.at/aura/aura/-/issues/110[EPIC] Coding Conventions: Setup pre-commit and add configuration2023-11-07T13:31:46+01:00David Trattnig[EPIC] Coding Conventions: Setup pre-commit and add configurationFor all repositories:
- [ ] Steering: steering#87 and https://gitlab.servus.at/aura/steering/-/issues/176
- [ ] Tank: https://gitlab.servus.at/aura/tank/-/issues/63+
- [x] Dashboard
- [x] Engine: engine#114+
- [x] Engine Core: https://g...For all repositories:
- [ ] Steering: steering#87 and https://gitlab.servus.at/aura/steering/-/issues/176
- [ ] Tank: https://gitlab.servus.at/aura/tank/-/issues/63+
- [x] Dashboard
- [x] Engine: engine#114+
- [x] Engine Core: https://gitlab.servus.at/aura/engine-core/-/issues/52+
- [x] Engine API
- [ ] Engine Recorder: engine-recorder#37+1.0-beta1