This PR moves the getProjectOverview method out from the project health
controller. It doesn't make sense that this method lives here anymore,
as over time it has grown into method that relays all information about
a single project. It makes more sense that this now lives on the root of
the project api. Also removes unwanted duplication of getProjectOverview
from the project-service and the project-health-service.
## About the changes
When exporting v3, for variants backward compatibility, we need to find
one featureEnvironment and fetch variants from there.
In cases where the default environment is disabled (therefore does not
get variants per environment when added), it can be still be selected
for the export process. Therefore variants don't appear in the feature
when they should be there.
An e2e test that fails with the previous implementation was added to
validate the behavior
This comes from our support ticket 404
## About the changes
Introduce a snapshot version of instanceStats inside
instance-stats-service to provide a cached state of the statistics
without compromising the DB.
### Important notes
Some rule-of-thumb applied in the PR that can be changed:
1. The snapshot refresh time
2. The threshold to report appName with the metrics
## Discussion points
1. The snapshot could be limited to just the information needed (things
like `hasOIDC` don't change until there's a restart), to optimize the memory usage
3. metrics.ts (used to expose Prometheus metrics) has a [refresh
interval of
2hs](2d16730cc2/src/lib/metrics.ts (L189-L195)),
but with this implementation, we could remove that background task and
rely on the snapshot
4. We could additionally update the snapshot every time someone queries
the DB to fetch stats (`getStats()` method), but it may increase
complexity without a significant benefit
Co-authored-by: Mateusz Kwasniewski <kwasniewski.mateusz@gmail.com>
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
## About the changes
When exporting features one is normally also interested in disabled
features, so they are also included in the export file, while the
variants are not. I do not see a good reason for that, so this PR
removes the check and exports the variants then as well.
I could also add an option as well, but as long as there is no good
reason for ignoring the variants I would just export them with the
features.
This PR adds tests on #2719Closes#2719
Co-authored-by: Martin Joehren <martin.joehren@esailors.de>
We have experienced side-effects where the import was unexpected and
resulted in environments thought to be removed. This had the unexpected
side-effect of also deleting API keys for some environments not part of
the import file.
This commit removes the ability of the state-service to mutate api keys
directly. There is no compelling reasons why we should remove API keys
as part of an import query.
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
To avoid showing too much data in the traffic screen, limit the number
of results to `topk`.
## Discussion points
Top 10 is a rule of thumb, but maybe we could do top 25. Until we gather
more data, I believe this should be good enough
## What
Previously when importing strategies we've used the same data type we've
used for creating strategies (the minimal, a name, an optional
description, optional parameters and an optional editable column). This
meant that exporting strategies and then importing them would reactivate
deprecated strategies. This PR changes to allow the import to preserve
all the data coming in the export file.
## Tests
Added four new tests, two new unit tests using our fake stores and two
new e2e tests. Interestingly the ones in the fake store ran green before
this change as well, probably because we just insert the parsed json
object in the fake store, whereas the real store actually converts the
object from camelCasing to the postgresql snake_casing standard.
## Discussion points:
### Mismatch between fake and real stores
This is inevitable since storing things in javascript arrays vs saving
in a real database will have some differences, but this again shows the
value of our e2e tests.
### Invariants
Should we see if we can add some invariants to our import/export so that
we can write some proptests for it? One candidate is commutativity of
import/export. On a fresh database importing and then exporting should
yield the same file that was imported provided all flags are turned on.
Candidate for Q1 improvement of import/export.
## About the changes
This PR improves our queries to Prometheus (instead of making multiple queries do only one) and improves the UI and the code.
The reports aggregate all HTTP methods (GET, POST, PUT, DELETE, OPTIONS, HEAD and PATCH) without distinction under the same "endpoint" (a relative path inside unleash up to a certain depth)
Co-authored-by: Nuno Góis <nuno@getunleash.ai>
## About the changes
This metric will expose an aggregated view of how many client
applications are registered in Unleash. Since applications are ephemeral
we are exposing this metric in different time windows based on when the
application was last seen.
The caveat is that we issue a database query for each new range we want
to add. Hopefully, this should not be a problem because:
a) the amount of ranges we'd expose is small and unlikely to grow
b) this is currently updated at startup time and even if we update it on
a scheduled basis the refresh rate will be rather sparse
## Sample data
This is how metrics will look like
```
# HELP client_apps_total Number of registered client apps aggregated by range by last seen
# TYPE client_apps_total gauge
client_apps_total{range="allTime"} 3
client_apps_total{range="30d"} 3
client_apps_total{range="7d"} 2
```
In this PR we remove the general SettingService cache, as it will not
work across multiple horizontal unleash instances, events are not
published across.
We also fix the CORS origin to:
- Access-Control-Allow-Origin set to "*" if no Origin is configured
- Access-Control-Allow-Origin set to "*" if any Origin is configured to
"*"
- - Access-Control-Allow-Origin set to array and have the "cors"
middleware to return an exact match on the user provided Origin.
Co-authored-by: Fredrik Oseberg <fredrik.no@gmail.com>
## About the changes
This connects our backend with Prometheus (or compatible) metrics
service, and exposes raw data (i.e. acting as a proxy)
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
## About the changes
This PR addresses some issues when working with variants after migrating
to variants per environment.
**Problem:** since PATCH
`/api/admin/projects/default/features/${featureName}/variants` does not
take into account `featureEnvironments`, when variantsPerEnvironment
gets enabled, this method will override the variants in other
environments (i.e. not doing a patch). This method has to be maintained
because of backward compatibility but it has to be adapted to deal with
variants per environment
https://linear.app/unleash/issue/2-476/when-using-patch-for-variants-without-environments-it-wipes-out
Co-authored-by: Nuno Góis <github@nunogois.com>
This removes stray onlys in our tests and adds a linter rule that will
error if only is present. Also updates the test result of one of our
tests as a result of [this pull
request](https://github.com/Unleash/unleash/pull/2344)
## About the changes
With the latest changes of variants per environment, we switched to
export schema v4 without having the feature toggle enabled. This moves
the variants to `featureEnvironments` when they were previously in
`features`. The main problem is that it can create confusion as the
exported file has the same variants for each one of the environments but
after importing the file the UI will only show one set of variants
attached to the feature.
With this change, we're maintaining the previous schema until the
feature toggle is enabled.
Adds ability to favorite projects.
1. Can favorite project
2. Can unfavorite project
3. Favorite field is returned on `/api/admin/projects/default`
4. Favorite field is returned on` /api/admin/projects`
## About the changes
We need a way to have an audit log for operations made on Api Tokens.
These changes adds three new event types, API_TOKEN_CREATED,
API_TOKEN_UPDATED, API_TOKEN_DELETED and extends api-token-service to
store these to our event store to reflect the action being taken.
Previously we hard deleted the users, but due to change requests and
possibly other features in future, we really want to hard-link user
table and have meaningful relationships.
But this means, when user is deleted, all linked data is also deleted.
**Workaround is to soft delete users and just clear users data and keep
the relationships alive for audit logs.**
This PR implements this feature.
patches an issue where cloning a feature would clone variants for
it's last found environment in the db. This now will clone the feature
environments correctly
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
This PR implements the `all` endpoint of unleash-proxy, by adding an
experimental flag that can control the behaviour
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
Variants are now stored in each environment rather than in the feature
toggle. This enables RBAC, suggest changes, etc to also apply to
variants.
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2254
### Important files
- **src/lib/db/feature-strategy-store.ts** a complex query was moved to
a view named `features_view`
- **src/lib/services/state-service.ts** export version number increased
due to the new format
## Discussion points
We're keeping the old column as a safeguard to be able to go back
Co-authored-by: sighphyre <liquidwicked64@gmail.com>
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
fix: broken UI when importing features into environments which are not linked to the feature's project
## Related to
- PR: https://github.com/Unleash/unleash/pull/2209
- Issue: https://github.com/Unleash/unleash/issues/2186
- Issue: https://github.com/Unleash/unleash/issues/2193
## Expected behaviour:
After importing we should see:
## About the changes
**The problem:** when we import we have projects, features and
environments. Each feature belongs to a project (this is by default and
the imported file enforces that). The links between projects and
features, or projects and environments, depend on us creating those
relationships. When we add a feature to an environment we're not
validating that the project and the environment are connected. Because
of that, in some situations (like in this test), we can end up with a
project with features but no environment.
This breaks a weak constraint we had which is that all projects should
have at least one environment.
**This PR makes the following assumption when importing**: _if a feature
is added to an environment, and that environment is still not linked to
the project that feature belongs to, then the project and environments
have to be linked_. The rationale behind this is that the user couldn't
have generated this export file without the project and environment
being linked together.
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
This PR sets up exports so that we can import in enterprise with just
"unleash-server".
This will free us to refactor unleash internals without breaking
enterprise
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
