Doing so right now breaks the UI. Should be a quick fix.

It is possible to add two metrics with the same name, which causes some confusion in the report. While Kayenta should also reject this, the UI should give a more UI-ish error and refuse to save.

disable the OK button if name is blank?

Often, people want to start with a base metric and just copy it to another, tweak it, and save it.

@PoorImpulseCtrl Any thoughts on how this would look? I'm thinking this should probably go on the group tabs? Or all together in one view?

In the internal UI we're using percentages which are kind of intuitive but also a pain in that you have to insist they add up to 100 and increasing the weighting of one thing means pulling weight out of something, or everything, else. It would probably be better just to have a scale, low-high, or 1-10 or something like that.

Individual settings for directionality etc, with a category selector that automatically populates the right settings for common metric types like error, resource free, etc.

Show the unsaved changes in the configuration -- possibly as a JSON diff, but maybe this is also possible to do via highlighting fields?

Ideally a new release would also trigger a package push to NPM.

Ideally, the UI would provide better hints about where the Baseline / Canary images are coming from.

In our current UI, we're using select2 in tagging mode to do this. I don't really think this is very intuitive though. Perhaps have checkboxes next to the metrics with "move" and "delete" buttons at the bottom - I can ask Jeremy.

(Metrics are allowed in multiple groups internally, and via the config format, but I'm not sure how useful this use case really is. It certainly adds confusion in scoring, and it's a bit wacky in the UI. My inclination would be to handle it in the UI, i.e. do something reasonable and don't blow up, but not to support it as in actually providing the option to multiple-group a metric.)

Allows user to select other applications; associations with the selected applications are added to the config

• When I click on various metrics to see the graph, the size of the graph area seems to change, causing some UI turmoil.
• The canary config name is in the upper left, with the score. I'd prefer to see the config name somewhere else, and the score as a larger item. The first thing people look at is the score, so having it secondary after a randomly sized config name seems distracting.
• "floor" the score to a single 0-100 integer range.

If I am editing a group, and I click on a group name, and click on the rename icon, I can change the group name. However, if I don't do anything (leaving the text field open and alone) and select a DIFFERENT config to edit from the left-hand list, I get into a very strange state.

After clicking on a different config:

• The metric source / report source links will still include the query parameter even if the configured storageAccountName is null, which is wrong.
• Add a toggle to hide metric + storage accounts fields in the stage config.

There's no real indication what the "folder" icon does, without a tool-tip. Having something on all of them would be nice.

Many of the components we pull from deck/core use span tags for icons -

<span class="glyphicon glyphicon-something"></span>

or

<span class="fa fa-something"></span>

The styleguide's css rules break this:

https://github.com/spinnaker/deck/blob/master/app/scripts/modules/core/src/styleguide/src/styles/typography.css#L157-L159

Seems infrequently used but maybe should be there anyway...

Some users use this little trick to add metrics to the report without them contributing to the scoring.

Four obvious things that we should validate:

• That the config name is unique (within its application scope).
• That the config name is valid (matches this regex: https://github.com/Netflix-Skunkworks/kayenta/blob/master/kayenta-web/src/main/java/com/netflix/kayenta/controllers/CanaryConfigController.java#L53)
• That metric names are unique (within the config).
• That the metric group weights sum to 100.

Inputing dates for a retrospective analysis is a pretty bad experience. Took me phoning an expert to figure out how to get this to work (yes, I could have read the java docs for iso instant better. But, I didn't 🤷‍♀️ ). It would be ideal if there was a date picker, and even more ideal if there were some great buttons like "now" and "3 hours ago". I dislike the experience of having to put in a timestamp from the UI.

When I go to the modal to add a metric, and type a partial string to search, if I then cancel the modal and click to add a metric again, when I click in the metric field it shows only those metrics which match my previous modal's filter, until I type something new.

The current stage config for a canary stage uses Analysis Type for real time v. retrospective, and the same name for growing v. sliding lookback.

"Time Perspective"
and
"Time Scope" | "Time Consumption | something else?

No target groups are listed. Not sure if it works in some cases but I haven't found a case where it does.

Also I've had it suggested that the "Move to:" label is more explicit e.g. "Move to group:"

(might not matter if there were actually groups listed)

I think this issue came up a while back and I can't remember where we ended the discussion but currently the default behavior for new group weights isn't very intuitive. It creates them with weight "0" and allows them to be saved that way. There's a warning about adding to 100% but no warning about 0% weights, and the server happily allows saving whatever.

The current server behavior is to auto-weight any groups that don't have explicit weights. I think we need either the UI to support letting a weight float (and making that the default for new groups), or the UI should not allow saving unweighted groups or groups not adding to 100, and the server should validate for same.

Have a pencil icon next to the group name in the active tab that allows editing when clicked

Used as default for Spinnaker pipeline runs, but authoritative for non-Spinnaker use of Kayenta.

Should be surfaced only if there are Kayenta accounts configured for multiple metric stores.

For deep diving, we need a way to generate links back into Atlas (and probably other data explores) from the UI.

The legacy system at Netflix did this, and it's been noticed that we don't have it in Kayenta yet.

When viewing this set of reports:

none of the MySamplePrometheusCanaryConfig config or report links work. All of the DemoStackdriverCanaryConfig ones work.

This is the console error thrown:

vendor.js:53416 Transition Rejection($id: 11 type: 6, message: The transition errored, detail: Error: Param values not valid for state 'home.applications.application.canary.report.reportDetail'. Invalid params: [ configId ])
$defaultErrorHandler @ vendor.js:53416
(anonymous) @ vendor.js:53737
processQueue @ vendor.js:111006
(anonymous) @ vendor.js:111050
$digest @ vendor.js:112145
$apply @ vendor.js:112443
(anonymous) @ vendor.js:112744
completeOutstandingRequest @ vendor.js:100448
(anonymous) @ vendor.js:100728
setTimeout (async)
Browser.self.defer @ vendor.js:100726
scheduleApplyAsync @ vendor.js:112743
$applyAsync @ vendor.js:112475
wrappedState.go @ spinnaker.js:54758
handleClick @ index.js:850
callCallback @ vendor.js:174300
invokeGuardedCallbackDev @ vendor.js:174339
invokeGuardedCallback @ vendor.js:174196
invokeGuardedCallbackAndCatchFirstError @ vendor.js:174210
executeDispatch @ vendor.js:174594
executeDispatchesInOrder @ vendor.js:174616
executeDispatchesAndRelease @ vendor.js:174714
executeDispatchesAndReleaseTopLevel @ vendor.js:174725
forEachAccumulated @ vendor.js:174693
processEventQueue @ vendor.js:174870
runEventQueueInBatch @ vendor.js:177365
handleTopLevel @ vendor.js:177374
handleTopLevelImpl @ vendor.js:177105
batchedUpdates @ vendor.js:184840
batchedUpdates @ vendor.js:176088
dispatchEvent @ vendor.js:177179
vendor.js:53418 Error: Param values not valid for state 'home.applications.application.canary.report.reportDetail'. Invalid params: [ configId ]
    at invalidTransitionHook (vendor.js:84337)
    at invokeCallback (vendor.js:22347)
    at TransitionHook.invokeHook (vendor.js:22359)
    at Function.TransitionHook.invokeHooks (vendor.js:22318)
    at Transition.run (vendor.js:27008)
    at StateService.transitionTo (vendor.js:53741)
    at StateService.go (vendor.js:53640)
    at spinnaker.js:54758
    at Scope.$eval (vendor.js:112335)
    at $applyAsyncExpression (vendor.js:112478)