[Monitor management] Enable check for public beta#128240
[Monitor management] Enable check for public beta#128240shahzad31 merged 22 commits intoelastic:mainfrom
Conversation
| if (this.authorization) { | ||
| // in case username/password is provided, we assume it's always allowed | ||
| return true; | ||
| } |
There was a problem hiding this comment.
This is not strictly necessary. We can simply add the basicAuth credentials to the json. Also, when running locally, you'll have both synthetics and elastic in the in-memory allow-list already.
|
|
||
| if (this.locations.length > 0 && httpsAgent) { | ||
| // get a url from a random location | ||
| const url = this.locations[Math.floor(Math.random() * this.locations.length)].url; |
There was a problem hiding this comment.
I assume we should eventually have a gateway to load balance between available locations? Maybe worth discussing with the cloud team.
Not for now though, we can keep it simple, just saying in case we want to add that to the sync agenda later.
|
Pinging @elastic/uptime (Team:uptime) |
| ); | ||
| export const getServiceLocationsFailure = createAction<Error>('GET_SERVICE_LOCATIONS_LIST_FAILURE'); | ||
|
|
||
| export const getSyntheticsServiceEnabled = createAsyncAction<void, { serviceEnabled: boolean }>( |
There was a problem hiding this comment.
I think we need to sync and quickly strategize on terms, since we both have features related to "enablement". The shared terms could get confusing in the codebase. How can we separate the concepts of public beta enablement vs admin enablement?
perhaps we can name this function getSyntheticsServiceBetaEnabled and add a comment? And perhaps rename variables like isEnabled to isBetaEnabled?
After tech preview, this code will be pulled out of the code base, correct?
There was a problem hiding this comment.
i have renamed everything from enabled to allowed.
| title={<h2>{MONITOR_MANAGEMENT_LABEL}</h2>} | ||
| body={<p>{PUBLIC_BETA_DESCRIPTION}</p>} | ||
| actions={[ | ||
| <EuiButton color="primary" fill isDisabled={true}> |
There was a problem hiding this comment.
Is this only disabled until we get the docs href?
| }; | ||
|
|
||
| export const fetchServiceEnabled = async (): Promise<{ serviceEnabled: boolean }> => { | ||
| return await apiService.get(API_URLS.SERVICE_ENABLED); |
There was a problem hiding this comment.
Pretty sure I've also named my api variables and fetch functions similarly in my enablement PR. Let's sync to prevent as much naming confusing as possible.
There was a problem hiding this comment.
i have renamed everything from enabled to allowed.
lucasfcosta
left a comment
There was a problem hiding this comment.
LGTM, but please let's wait until I've had the chance to merge my PR in the service with @maneta so that I can test this E2E. Then we can merge it before the end of the day today once everything is tested E2E.
Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>
dominiqueclarke
left a comment
There was a problem hiding this comment.
Found a few more references to enabled
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Page load bundle
Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
|
Tested e2e with Lucas and it works fine !! |
Summary
Enabled public beta for synthetics service !!
In production a new endpoint is added which will be called to check if user has permissions to access synthetics service.
UI is also based on that endpoint.
In dev, if user is using basic auth, that will auto enable the monitor managed.
Key
xpack.uptime.ui.monitorManagement.enabled: trueis removed./allowedend point will be called periodically in the kibana task, to determine if user has access.
We call the random location to make sure , one location is not burdened with calls to check access.