Both engines now diff the stored/live index schema against the schema generated from code when the service starts. A shared recursive classifier in the mapping package is the single oracle: - equal: start normally. - additive (new fields without any indexed data): applied in place. OpenSearch gets a PUT _mapping with the full code properties, bleve persists the code mapping into the index (SetInternal + reopen) so the new fields are properly typed immediately and later startups classify equal. A startup warning lists the new fields because documents indexed before the upgrade lack them until re-indexed. - breaking (changed definitions or analyzers, removed or renamed fields, or new fields that already contain data of unknown form): refuse to start with an error describing the rebuild procedure (delete the index, start, run "opencloud search index --all-spaces") and the OC_EXCLUDE_RUN_SERVICES=search escape hatch. PUT _mapping is deliberately only the apply mechanism, never the judge: its merge semantics cannot see removals or renames and it accepts in-place updatable param changes with an ack. bleve additionally checks idx.Fields() so previously dynamically indexed data (which leaves no schema trace in bleve) is caught, matching by exact name and by path prefix. While at it: the OpenSearch startup check runs with a real, minute-bounded context instead of context.TODO(), bleve indexes are opened with a 5s bolt_timeout so a second process fails fast instead of hanging on the file lock, and the reversed errors.Is arguments in bleve.NewIndex were fixed. https://github.com/opencloud-eu/opencloud/issues/3092
Server Backend
Tip
For general information about OpenCloud and how to install please visit OpenCloud on Github and OpenCloud GmbH.
This is the main repository of the OpenCloud server. It contains the golang codebase for the backend services.
Getting Involved
The OpenCloud server is released under Apache 2.0. The project is thrilled to receive contributions in all forms. Start hacking now, there are many ways to get involved such as:
- Reporting issues or bugs
- Requesting features
- Writing documentation
- Writing code or extend our tests
- Reviewing code
- Helping others in the community
Every contribution is meaningful and appreciated! Please refer to our Contribution Guidelines if you want to get started.
Build OpenCloud
To build the backend, follow these instructions:
Generate the assets needed by e.g., the web UI and the builtin IDP
make generate
Then compile the opencloud binary
make -C opencloud build
That will produce the binary opencloud/bin/opencloud. It can be started as a local test instance right away with a two step command:
opencloud/bin/opencloud init && opencloud/bin/opencloud server
This creates a server configuration (by default in $HOME/.opencloud) and starts the server.
For more setup- and installation options consult the Development Documentation.
Technology
Important information for contributors about the technology in use.
Authentication
The OpenCloud backend authenticates users via OpenID Connect using either an external IdP like Keycloak or the embedded LibreGraph Connect identity provider.
Database
The OpenCloud backend does not use a database. It stores all data in the filesystem. By default, the root directory of the backend is $HOME/.opencloud/.
Security
If you find a security-related issue, please contact security@opencloud.eu immediately.
