-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[APM] Agent configuration GA #46995
[APM] Agent configuration GA #46995
Conversation
Pinging @elastic/apm-ui |
fcf864a
to
af55e78
Compare
const t = (id: string, defaultMessage: string) => | ||
i18n.translate(`xpack.apm.settings.agentConf.flyOut.serviceSection.${id}`, { | ||
defaultMessage | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The i18n strings were getting long and starting to be a pain on the eyes. I played around with some different formats and I'm pretty pleased with this. Not saying we should do it everywhere but I think it's worth experimenting with. A couple of goals:
- the resulting call
t('key', 'label')
should be as short and concise as possible - when renaming a file it should be easy to rename all i18n strings simultaneously
- the wrapper should not be too abstracted away from the original
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming this breaks the i18n check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can stop using a hierarchy for our labels. Instead of using xpack.apm.settings.agentConfig.flyout.serviceSection.deleteConfigSucceededTitle
, we can use xpack.apm.deleteAgentConfigSucceededTitle
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming this breaks the i18n check?
Hmm.. I do get this error when running the i18n check:
✖ x-pack/legacy/plugins/apm
→ EISDIR: illegal operation on a directory, read
Any idea how to fix?
Maybe we can stop using a hierarchy for our labels. Instead of using xpack.apm.settings.agentConfig.flyout.serviceSection.deleteConfigSucceededTitle, we can use xpack.apm.deleteAgentConfigSucceededTitle
That would still be something like:
i18n.translate('xpack.apm.deleteAgentConfigSucceededTitle', {
defaultMessage: 'Delete configuration'
}),
vs
t('deleteAgentConfigSucceededTitle', 'Delete configuration'),
Ofc if we can't make the later work then there's no way around it, but after having played around with it, it's a joy to have strings as one-liners again, and my eyes slowly start reading the code again (instead of just ignoring all the stuff my brain perceives as noise)
value: transactionMaxSpans, | ||
set: setTransactionMaxSpans, | ||
isValid: isTransactionMaxSpansValid | ||
}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it is the best approach to group the values like this. I could also drop the grouping:
<SettingsSection
// sample rate
sampleRate={sampleRate}
setSampleRate={setSampleRate}
isSampleRateValid={isSampleRateValid}
// capture body
captureBody={captureBody}
setCaptureBody={setCaptureBody}
// transaction max spans
transactionMaxSpans={transactionMaxSpans}
setTransactionMaxSpans={setTransactionMaxSpans}
isTransactionMaxSpansValid={isTransactionMaxSpansValid}
/>;
|
||
try { | ||
const configuration = { | ||
agent_name: 'TODO', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: fix
💔 Build Failed |
826e474
to
72845b4
Compare
💔 Build Failed |
@@ -10,8 +10,8 @@ export const transactionSampleRateRt = new t.Type<number, number, unknown>( | |||
'TransactionSampleRate', | |||
t.number.is, | |||
(input, context) => { | |||
const value = Number(input); | |||
return value >= 0 && value <= 1 && Number(value.toFixed(3)) === value | |||
const value = parseFloat(input as string); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just curious, why parseFloat
? because it's more permissive than Number
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The opposite actually. Due to coercion Number('') => 0
whereas parseFloat('') => NaN
.
I wanted to disallow empty values.
const t = (id: string, defaultMessage: string) => | ||
i18n.translate(`xpack.apm.settings.agentConf.flyOut.serviceSection.${id}`, { | ||
defaultMessage | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming this breaks the i18n check?
Ah, makes sense. parseFloat however will also get numbers out of `1x` etc
though. But maybe less of an issue here.
…On Tue, Oct 1, 2019 at 2:53 PM Søren Louv-Jansen ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In
x-pack/legacy/plugins/apm/common/runtime_types/transaction_sample_rate_rt/index.ts
<#46995 (comment)>:
> @@ -10,8 +10,8 @@ export const transactionSampleRateRt = new t.Type<number, number, unknown>(
'TransactionSampleRate',
t.number.is,
(input, context) => {
- const value = Number(input);
- return value >= 0 && value <= 1 && Number(value.toFixed(3)) === value
+ const value = parseFloat(input as string);
The opposite actually. Due to coercion Number('') => 0 whereas parseFloat('')
=> NaN.
I wanted to disallow empty values.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#46995?email_source=notifications&email_token=AACWDXHTNQYA2KLUOGDY5V3QMNB43A5CNFSM4I4A5J6KYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCGPCUVY#discussion_r330038778>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACWDXELICPPWZ5GNFCXZLDQMNB43ANCNFSM4I4A5J6A>
.
|
I'm not sure if that error is related, but the i18n check can probably no
longer resolve the message ids if you use an intermediate function. I'd
guess the only way to solve it is to take it to the translations or ops
team, whoever owns the message extraction process. I do agree that the
current syntax is not the most concise.
…On Tue, Oct 1, 2019 at 3:08 PM Søren Louv-Jansen ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In
x-pack/legacy/plugins/apm/public/components/app/Settings/AgentConfigurations/AddEditFlyout/ServiceSection.tsx
<#46995 (comment)>:
> + * or more contributor license agreements. Licensed under the Elastic License;
+ * you may not use this file except in compliance with the Elastic License.
+ */
+
+import { EuiTitle, EuiSpacer, EuiFormRow } from ***@***.***/eui';
+import React from 'react';
+import { i18n } from ***@***.***/i18n';
+import { SelectWithPlaceholder } from '../../../../shared/SelectWithPlaceholder';
+import { useFetcher } from '../../../../../hooks/useFetcher';
+import { ENVIRONMENT_NOT_DEFINED } from '../../../../../../common/environment_filter_values';
+import { Config } from '../index';
+import { callApmApi } from '../../../../../services/rest/callApmApi';
+const t = (id: string, defaultMessage: string) =>
+ i18n.translate(`xpack.apm.settings.agentConf.flyOut.serviceSection.${id}`, {
+ defaultMessage
+ });
I'm assuming this breaks the i18n check?
Hmm.. I do get this error when running the i18n check:
✖ x-pack/legacy/plugins/apm
→ EISDIR: illegal operation on a directory, read
Any idea how to fix?
Maybe we can stop using a hierarchy for our labels. Instead of using
xpack.apm.settings.agentConfig.flyout.serviceSection.deleteConfigSucceededTitle,
we can use xpack.apm.deleteAgentConfigSucceededTitle
That would still be something like:
i18n.translate('xpack.apm.deleteAgentConfigSucceededTitle', {
defaultMessage: 'Delete configuration'
}),
vs
t('deleteAgentConfigSucceededTitle', 'Delete configuration'),
Ofc if we can't make the later work then there's no way around it, but
after having played around with it, it's a joy to have strings as
one-liners again, and it my eyes slowly start reading the code again
(instead of just ignoring all the stuff my brain perceives as noise)
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#46995?email_source=notifications&email_token=AACWDXF2XH225EJUSQXWKVLQMNDV5A5CNFSM4I4A5J6KYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCGPE67Q#discussion_r330045981>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACWDXARXBFBRO6A3SYIBJTQMNDV5ANCNFSM4I4A5J6A>
.
|
Good catch. Turns out there is a way to "flush" a buttons margins: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sqren do you think it's worth to see what it would look like when we use io-ts for the validation of the entire form, rather than stitching stuff together? Would be happy to take a stab at it.
...ugins/apm/public/components/app/Settings/AgentConfigurations/AddEditFlyout/DeleteSection.tsx
Outdated
Show resolved
Hide resolved
@@ -48,5 +44,7 @@ export async function searchConfigurations({ | |||
}; | |||
|
|||
const resp = await client.search<AgentConfiguration>(params); | |||
return resp.hits.hits[0]; | |||
|
|||
type FirstHit = SearchResponse<AgentConfiguration>['hits']['hits'][0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the value of this over just using AgentConfiguration
directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to make sure the method returned an optional (x | undefined
). The full ES document is returned not just AgentConfiguration
. I was looking for something like ESSearchHit<AgentConfiguration>
but didn't find anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I get it now. Maybe we can expose something like that as well in our ES typings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea. I can add it. ESSearchHit
good with you or any suggestions?
]); | ||
|
||
return allEnvironments.map(environment => { | ||
return { | ||
name: environment, | ||
available: !unavailableEnvironments.includes(environment) | ||
alreadyExists: existingEnvironments.includes(environment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I guess this is kind of where "existingEnvironments" breaks down. Maybe unconfigured
or available
is better here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found available
to be misleading so changed it. But perhaps it's not objectively a good change.
I think unconfigured
works 👍
}) | ||
]) | ||
t.type({ name: t.string }), | ||
t.partial({ environments: t.array(t.string) }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this not be environment
? I might have mixed up environment
from the configuration and (the available) environments
from the UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, a configuration is only linked to a single environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh sorry! I thought I changed this to environment
already so when I saw your comment I misunderstood. Must have undone my changes. Will make it environment
(and not environments
)
}: Props) { | ||
const { data: serviceNames = [], status: serviceNamesStatus } = useFetcher( | ||
() => { | ||
return callApmApi({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
considering that this data could change, should we even cache it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... I thought about it but I think it's okay since it's only in-memory caching, so whenever the user comes back to Kibana they will see fresh data. It is also not data that changes very often. Most users have long running application names. Do you think it's likely that someone changes the service name or adds a new service while being on this page?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, maybe. I can imagine they want to configure a service around the time it starts sending data. Then again, they will probably just refresh the page anyway.
Definitely, would like to see that. |
Here's what it looks like with fully shared validation sorenlouv#15 |
💔 Build Failed
|
0bf0dc8
to
26402e5
Compare
💚 Build Succeeded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just a few nits about translations etc.
...gins/apm/public/components/app/Settings/AgentConfigurations/AddEditFlyout/ServiceSection.tsx
Outdated
Show resolved
Hide resolved
...gins/apm/public/components/app/Settings/AgentConfigurations/AddEditFlyout/ServiceSection.tsx
Show resolved
Hide resolved
...ins/apm/public/components/app/Settings/AgentConfigurations/AddEditFlyout/SettingsSection.tsx
Outdated
Show resolved
Hide resolved
...r/lib/settings/agent_configuration/get_environments/get_existing_environments_for_service.ts
Outdated
Show resolved
Hide resolved
x-pack/legacy/plugins/apm/server/lib/settings/agent_configuration/get_service_names.ts
Outdated
Show resolved
Hide resolved
x-pack/legacy/plugins/apm/server/lib/settings/agent_configuration/search.ts
Show resolved
Hide resolved
💔 Build Failed |
💚 Build Succeeded |
💚 Build Succeeded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Should we create an issue for sorting in ES, or are we giving up on that requirement?
… Agent configuration phase 2 (#46995) (#47806) * [APM] Use new platform for toast notifications (#47276) * [APM] Use new platform for toast notifications * fix more tests * remove comment * [APM] Agent configuration phase 2 (#46995) * [APM] Agent Config Management Phase 2 * Add status indicator * Extract TimestampTooltip component * Remove unused StickyTransactionProperties component * Fix snapshot and minor cleanup * Minor cleanup * Display settings conditionally by agent name * Fix client * Format timestamp * Minor design feedback * Clear cache when clicking refresh * Fix test * Revert t() short hand * Fix translations * Add support for “all” option * Fix API tests * Move delete button to footer * Fix snapshots * Add API tests * Fix toasts * Address feedback and ensure order when searching for configs * Fix snapshots * Remove timeout
💚 Build Succeeded |
Fixes #44475
Fixes #43351
Fixes #43354
Fixes #45124
User facing changes:
Non-user facing changes:
TimestampSummaryItem
and rename toTimestampTooltip
forceCache
option tocallApi
to force the use of caching despite caching logic only allows caching for endpoints with date rangesTransactionStickyProperties
component