ChangeLog won't be any useful before the first release.
Save us time, save the world useless computation, remove the CI steps.
They'll be added back as soon as they are necessary.
Configured Nginx to set caching headers for static assets by adding
a location block to match common static file extensions and set
an expiration time of 30 days.
It should result in faster loading times, reduced bandwidth usage,
and a more efficient and responsive user experience.
Wdyt @manuhabitela?
Configured Nginx to serve index.html for all requests, allowing
the client-side router (Wouter) to manage the routing.
Added a try_files directive to attempt to serve static files first,
falling back to index.html if the requested file is not found.
Added an error_page directive to handle 404 errors by internally
redirecting to index.html without modifying the URL path.
Wouter should make the rest.
It seems appropriate that backend owns the responsability of knowing any
information/configurations of the LiveKit server. Then, it shares those
with the frontend.
Please see my previous commit to understand why environment variables are
not appropriate for deployment in several remove environments.
As of today, the LiveKit server URL is the only configuration exposed
dynamically to the frontend. Thus, it doesn't justify adding a new route
to the API, responsible for exposing configurations (e.g. /configuration).
As the frontend needs to call the backend when it wants to initiate a new
webconference room, let's pass the server URL when retrieving the room's token.
It is relevant, to get both the room location and the keys to open the room in
the same call.
I prefered to be pragmatic, if the need appears any soon, I would refactor
these parts.
Discussed IRL with @manuhabitela. In developpement, we build locally the
Docker image. Thus, we can pass values to the frontend before the npm build
command was called.
Environment variables are great for configuration, and work perfectly in dev
mode, building Docker image on the fly.
However, in other environment (e.g. staging, pre-prod, prod) we'll pull a common
Docker image published in a remote registry. All cited environments should use
the same Docker image to make tests/deployment reproducible between envs.
As the Docker image is not rebuilt on the fly, we cannot easily configure
customized environment variables for each environment.
The API base URL would have a different value for each environment, and would
require a different environment variable.
Inspired by Impress works, if no environment variable is passed for the API URL,
the window origin will be used, and then the API path will be appended.
Frontend and backend are always deployed on the same URL, usually frontend
is at the '/' route, and backend at the '/api/vXX/' route.
If any configuration are required for each remote environment, they would be
retrieved from the API at runtime.
Voila! Don't hesitate to challenge this commit.
@manuhabitela configured panda css to manage project styling.
Panda codegen generates a new folder, 'styled-system' which was not
ingored by Eslint, resulting in ~40 Eslint errors.
Adapted Eslint configurations to ignore this path.
Values for staging, pre-prod, prod environments were adapted to read
the newly introduced LiveKit secrets.
The extra/template/secrets.yaml should be moved to a proper location.
Uncommenting the line left the original commented line in place,
which was misleading because the comment indicated to comment
the next line, which was already commented.
Fixed!
I have updated the staging, pre-prod and production environments.
Done:
- Remove silenced security checks, as SECURE_PROXY_SSL_HEADER is set in prod.
- Rename "impress" to "meet"
- Rename "docs" to "meet"
- Remove unused values (webrtc, ingressWS)
I haven't yet received the definitive DNS configuration from Florian or Olivier.
The hosts meet.numerique.gouv.fr and all meet-*.beta.numerique.gouv.fr are
only hypothetical at this point.
panda needs to generate types to work. We used to generate those after
deps install but it's not that necessary, since we generate them before
running the dev env, and before building the prod build.
This fixes the `npm ci` error in the frontend docker build
the idea is to use react aria, panda-css, react query and wouter as a
base, in addition to livekit react components
this is still mostly wip but it's usable:
- homepage shows a login link to create a room
- before joining a room you are asked to configure your audio/video/user
name
- note that if you directly go to a a conference url it creates it even
if you are not logged in… very secured!
Done:
- Rename all occurrences of "impress" to "meet".
- Update Agent Connect secrets credentials for the dev environment.
- Add new development secrets for LiveKit.
- Remove Minio from the dev stack (no cold storage required).
- Add LiveKit chart to the stack.
- Remove templates and values related to the WebSocket server.
The integration of LiveKit was inspired by an example from the "numerique-gouve/infrastructure" repo.
However, a notable issue persists with LiveKit's default chart: we are unable to override
the namespace, resulting in all LiveKit components running in the default namespace.
thx to @rouja for his help.
The start-kind.sh script was read-only after copying the repository, preventing it from running
the "build-k8s-cluster" make command. Updated permissions to chmod 755.
Configured the frontend to use environment variables (prefixed with "VITE_") for frontend
port and host configuration, which will be overridden in the Helm chart values
to ensure correct values are used in different environments.
Helm requires the frontend port to be 8081 and use the public host,
not the default "localhost" value.
Renamed docker/files/usr/local/etc/gunicorn/impress.py to .../meet.py to match the updated
backend source filenames. This resolves the issue where the Dockerfile was attempting
to copy a non-existent file, causing the build to fail.
Configured the frontend to use environment variables (prefixed with "VITE_") for API
and LiveKit server URLs, which will be overridden in the Helm chart values
to ensure correct URLs are used in different environments.
Inspired by the Docker images from numerique-gouv/people and numerique-gouv/impress
(see commit 1a3b396 in the "people" repository).
Due to the lack of a certified cold storage solution (e.g., S3) for serving static files,
we've containerized the frontend as a temporary deployment solution.
Vite.js static output is served using an Nginx reverse proxy.
I am not quite sure of this commit, please @manuhabitela could you review how I exposed
the static build from vite in my Nginx server? and do the appriopriate fix if necessary.
Resolved minor TypeScript errors in the Proof of Concept (PoC)
that were causing the "npm run build" command to fail.
These fixes were necessary to prepare the frontend for
containerization with Docker.
ASAP, a CI step will prevent these kind of errors.
@rouja secrets management relies on a central repository, which manages
all numerique-gouv secrets.
I have created a new subfolder in its "numerique-gouv/secret" repository
to store all update key/credentials related to the Meet project.
I have updated all references of "Impress" to "Meet" in the tsclient.
Also, I forgot to rename the repository link in the mail package.json,
my bad, it's fixed.
I have created two new repositories on DockerHub, one for the currently
existing backend image, and one for the future frontend image.
I searched-replaced all occurences of "lasuite/impress-frontend" or "lasuite/impress-backend".
One image won't exist anymore, "impress-y-webrtc-signaling", I have
removed the steps building and pushing its image to the DockerHub account.
Performed a minor cleanup:
The CI related to the frontend has been removed temporarily.
It will be reinstated once the frontend development is initiated by @manuhabitela.
A redundant issue template has been removed. Existing templates in
the "ISSUE_TEMPLATE" folder remain in place.
I have updated all references of "Impress" to "Meet".
Migrations were manually updated and not regenerated. Never-mind,
they all will be squashed before the first release.
I have also searched for reference to "Magnify", and replaced them
by "Meet".
While updating the backend sources, I have also fixed other parts of
the project, namely:
- Compose file
- Github documentation and CI
- Makefile commands
I have renamed the Github project's name, from "Impress" to "Meet".
Updated the pyproject urls section, which provides essential metadata
about the project. This updates ensure all links point to the right
github repository.
I have updated all references of "Impress" to "Meet".
Few environment variables were updated, keycloak was including
the realm's name as a base URL for API endpoints.
Update frontend to be the root folder of the frontend sources,
instead of nesting them in a folder named as the application.
We only work on a single frontend app as of today, nesting
sources doesn't add any value, even though the initial organization
was more extensible.
Introduce a utility function to issue a basic LiveKit access token with the minimal
required video grants for videoconferencing.
/!\ This function is naive, and doesn’t handle properly all cases. It’s under construction.
Testing was conducted using the LiveKit connection test tool https://livekit.io/connection-test,
which allows users to input the address of their local LiveKit server and an access token.
** Upcoming improvements? **
- Unit tests should be added.
- User display name should be their full name instead of their email address.
- Anonymous users should be allowed to provide a full name when requesting access to the room.
- Video grants should be adapted based on the room configuration and the user's role.
These improvements will be addressed in future commits.
Nevertheless, with this draft, we should be able to address various situations, including
public rooms, permanent rooms, temporary rooms, logged-in users, and anonymous users.
When starting the LiveKit server using the '--dev' option, the server uses
defaults secret/key pair according to the documentation.
Make sure the Django settings and de facto the environment variable match
these defaults.
Please have a look at the documentation page here:
https://docs.livekit.io/home/self-hosting/local/
LiveKit offers various React components as building blocks to build any
video or audio conference tools.
It also requires to install a LiveKit client, as the users will connect
to the LiveKit server once the backend have issued an Access Token,
directly from their web browsers.
Add livekit-api dependencies. According to the documentation, this Python
package is required while issuing Access Token for a LiveKit server, to
the users.
Introduce CRUD API endpoints for the Rooms and ResourceAccess models.
The code follows the Magnify logic, with the exception that token generation
has been removed and replaced by a TODO item with a mocked value.
Proper integration of LiveKit will be added in future commits.
With the removal of group logic, some complex query sets can be simplified.
Previously, we checked for both direct and indirect access to a room.
Indirect access meant a room was shared with a group, and the user was a
member of that group. I haven’t simplified those query set, as I preferred
isolate changes in dedicated commits.
Additionally, all previous tests are still passing, although tests related
to groups have been removed.
I picked few models from Magnify to build our MVP:
- Resource:
A generic model representing any type of resource. Though currently used only by Room,
it encapsulates a meaningful business logic as an abstract model.
- Room:
The primary object we manipulate, representing a meeting room with access
and permission controls.
- ResourceAccess
Ensures relevant users have the appropriate permissions for a given room.
** What’s different from Magnify ? **
Removed group logic; it will be added later. For now, we rely on the user model's
property to get its groups via desk.
Removed any logic or method related to Jitsi or LiveKit. These servers will be integrated
in the upcomming commits.
Focus on Room-related models to maintain a minimal and functional product (KISS principle)
until we achieve product-market fit (PMF).
Creating simple public and private, permanent and temporary rooms
is sufficient for building our MVP.
The Meeting model in Magnify, which supports recurrence, should be handled by
the collaborative calendar instead.
Adapted the unit test to use Pytest, and linted all the sources using Ruff linter.
(Migrations will be squashed before releasing the MVP)
Based on @mathisbarthere's PR on openfun/Magnify migration to LiveKit.
These configurations might need to be updated.
Please refer to the documentation: https://docs.livekit.io/home/self-hosting/local/
The 'livekit-server --dev' will start a LiveKit in development mode,
the instance will use the following API key/secret pair:
API Key: devkey
API secret: secret
By default LiveKit's signal server binds to `127.0.0.1:7880`, adding the
option `--bind 0.0.0.0 allow other devices on your network to access the
server.
Quick and dirty code to initiate a login or logout flow based on
user's click.
The code is copied/pasted from several sources of Impress. It's dirty,
and meant to be refactored.
It asserts the login and logout are still functional while introducing
new features in the project.
