Skip to content
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

[ui] Job Variables page #17964

Conversation

philrenaud
Copy link
Contributor

@philrenaud philrenaud commented Jul 17, 2023

A new route to:

  • Show a user the variables that a job and its groups and tasks have automatic access to (by naming convention)
  • Inform a user about how variables and automatic access work
  • Give a user a quick way to create/edit variables with appropriately pathed names.

A few new conventions added to facilitate good UX here:

  • We want to link to /variables/variable/edit if the variable exists, but /variables/new?path=$varpath if it does not. A new helper and component handle this for us.
  • We want to show the tasks/task groups they could be adding variables for here, but not too many of them. We show up to 2 examples of each and slightly change our copy depending on number of tasks/groups.

image

@@ -72,7 +72,7 @@
Please choose a different path, or
<LinkTo
@route="variables.variable.edit"
@model={{this.duplicatePathWarning.path}}
@model={{concat this.duplicatePathWarning.path "@" (or this.variableNamespace "default")}}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Side-effect: noticed this had stopped working in namespace-less environments.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PS: hey here's that "this variable path already exists" warning I mentioned a comment ago!

@github-actions
Copy link

github-actions bot commented Jul 17, 2023

Ember Test Audit comparison

main cc9640c change
passes 1498 1505 +7
failures 1 1 0
flaky 0 0 0
duration 000ms 000ms -000ms

@philrenaud philrenaud force-pushed the 17937-allow-users-to-see-all-the-variables-from-the-job-page-including-groups-and-tasks branch from 8c7c117 to 0c04bde Compare July 18, 2023 01:36
@philrenaud philrenaud force-pushed the 17937-allow-users-to-see-all-the-variables-from-the-job-page-including-groups-and-tasks branch from 41bc382 to 97afaf3 Compare July 21, 2023 15:13
@philrenaud philrenaud force-pushed the 17937-allow-users-to-see-all-the-variables-from-the-job-page-including-groups-and-tasks branch from 97afaf3 to ef9afc9 Compare July 21, 2023 15:33
Comment on lines +22 to +28
@or(
'bypassAuthorization',
'selfTokenIsManagement',
'specificNamespaceSupportsReading',
'policiesSupportReading'
)
canRead;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems out of place in a PR like this, right?

When we save a variable, there are a few things that we want to update and depend on that change. One of those is job.pathLinkedVariable, which looks against a job's variables array (more on that later!) and finds the one that's named nomad/jobs/$jobname.

So now, in our saveVariable() function elsewhere, we can say "Oh great you saved! Do you have access to read jobs so that this might matter for them? Yes? Okay, update them."

This provides the ability to check that they can read jobs.

{{/with}}
{{else}}
@path
{{/if}}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A little component that either links to variables/new?path=YourNewVar or variables/YourExistingVar/edit, depending on whether it exists or not.

All this just to save the user a click! We already inform them, when creating a new variable whose path already exists, that that variable already exists and give them a link to it. But this is nicer UX IMO.

@@ -72,7 +72,7 @@
Please choose a different path, or
<LinkTo
@route="variables.variable.edit"
@model={{this.duplicatePathWarning.path}}
@model={{concat this.duplicatePathWarning.path "@" (or this.variableNamespace "default")}}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PS: hey here's that "this variable path already exists" warning I mentioned a comment ago!

* Copyright (c) HashiCorp, Inc.
* SPDX-License-Identifier: MPL-2.0
*/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The backing logic for the editable-variable-link.hbs component. Could have set this up as a component script, rather than a helper, but I thought we might want to use this in a different context sometime.

Comment on lines 371 to 381
async getPathLinkedVariable() {
await this.variables;
if (this.parent.get('id')) {
return await this.variables?.findBy(
'path',
`nomad/jobs/${JSON.parse(this.parent.get('id'))[0]}`
);
} else {
return await this.variables?.findBy('path', `nomad/jobs/${this.plainId}`);
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is, IMO, the most notable change I'm making in this PR. See the pathLinkedVariable() getter above this for how we've traditionally done it.

For the past few months, looking at a variable in the Web UI has been in a context where we'd have just gotten variables loaded. The operation, though, isn't immediate or promise-friendly. Frankly if this gets merged I intend to do away with pathLinkedVariable() in favour of getPathLinkedVariable() and make the whole operation more awaitable.

This lets us wait for the value of the job's (or group's, or task's, as you'll see in a moment) related variable without making any assumptions about what's already been loaded (see for example _fetchParentJob in the task model)

Comment on lines 31 to 41
{{#if (gt this.firstFewTaskGroupNames.length 1)}}
{{#each this.firstFewTaskGroupNames as |name|}}
<code><EditableVariableLink @path="nomad/jobs/{{this.model.job.name}}/{{name}}" @existingPaths={{this.jobRelevantVariables.files}} @namespace={{this.model.job.namespace.name}} /></code>,
{{/each}}
etc. to grant a specific task group access
{{else}}
<code>
<EditableVariableLink @path="nomad/jobs/{{this.model.job.name}}/{{object-at 0 this.firstFewTaskGroupNames}}" @existingPaths={{this.jobRelevantVariables.files}} @namespace={{this.model.job.namespace.name}} />
</code>
to grant your task group access
{{/if}}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of template logic for a little benefit, but I think it reads much nicer this way.

We give a single example if you only have a single group/task, but multiple examples (with ", etc." language) when you have multiple groups/tasks.

image
image

ui/app/templates/jobs/job/variables.hbs Outdated Show resolved Hide resolved
Comment on lines +979 to +966
let variable = variables.find(params.id);
if (!variable) {
return new Response(404, {}, {});
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This emerged because I've started looking up the nomad/jobs variable in isolation when loading a given job/variables page now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The HCP repo has helpers for these little common mirage things. They're quite handy; basically turns this into return notFound().

Comment on lines +362 to +367
server.create('token', {
name: 'Novars Murphy',
id: 'n0-v4r5-4cc355',
type: 'client',
});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All our recent tokens are Irish and I can no longer remember why

`/jobs/${jobID}@default/clients`,
'Shift+ArrowRight takes you to the next tab (Clients)'
);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Side-effect-of-a-side-effect:

  • I wanted to make sure that keynav shift+right took you to the variables page, but you only see that if you have variable access
  • so I said okay let's make the token a management token so that they'd definitely see it
  • well the jobs created for this mock are all system jobs, which have client pages, which were otherwise unseen because before now the mocked token didn't have node read access, either, and now they do

ui/app/templates/jobs/job/variables.hbs Outdated Show resolved Hide resolved
ui/app/templates/jobs/job/variables.hbs Outdated Show resolved Hide resolved
ui/app/routes/jobs/job/variables.js Outdated Show resolved Hide resolved
ui/app/models/task-group.js Outdated Show resolved Hide resolved
@@ -71,7 +71,7 @@ module(
activeDeployment: true,
groupTaskCount: ALLOCS_PER_GROUP,
shallow: true,
resourceSpec: Array(NUMBER_OF_GROUPS).fill(['M: 257, C: 500']), // length of this array determines number of groups
resourceSpec: Array(NUMBER_OF_GROUPS).fill('M: 257, C: 500'), // length of this array determines number of groups
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Side-effect: noticed that the .fill format I was using here would only work for shallow: true jobs, and just in case we want these to be un-shallow jobs in the future, fixed it.

@philrenaud philrenaud force-pushed the 17937-allow-users-to-see-all-the-variables-from-the-job-page-including-groups-and-tasks branch from 5fbf537 to cc9640c Compare July 31, 2023 17:06
@philrenaud philrenaud added the backport/1.6.x backport to 1.6.x release line label Jul 31, 2023
@philrenaud philrenaud merged commit 18dd9e7 into main Jul 31, 2023
13 checks passed
@philrenaud philrenaud deleted the 17937-allow-users-to-see-all-the-variables-from-the-job-page-including-groups-and-tasks branch July 31, 2023 19:04
philrenaud added a commit that referenced this pull request Jul 31, 2023
* Bones of a component that has job variable awareness

* Got vars listed woo

* Variables as its own subnav and some pathLinkedVariable perf fixes

* Automatic Access to Variables alerter

* Helper and component to conditionally render the right link

* A bit of cleanup post-template stuff

* testfix for looping right-arrow keynav bc we have a new subnav section

* A very roundabout way of ensuring that, if a job exists when saving a variable with a pathLinkedEntity of that job, its saved right through to the job itself

* hacky but an async version of pathLinkedVariable

* model-driven and async fetcher driven with cleanup

* Only run the update-job func if jobname is detected in var path

* Test cases begun

* Management token for variables to appear in tests

* Its a management token so it gets to see the clients tab under system jobs

* Pre-review cleanup

* More tests

* Number of requests test and small fix to groups-by-way-or-resource-arrays elsewhere

* Variable intro text tests

* Variable name re-use

* Simplifying our wording a bit

* parse json vs plainId

* Addressed PR feedback, including de-waterfalling
philrenaud added a commit that referenced this pull request Aug 1, 2023
* Bones of a component that has job variable awareness

* Got vars listed woo

* Variables as its own subnav and some pathLinkedVariable perf fixes

* Automatic Access to Variables alerter

* Helper and component to conditionally render the right link

* A bit of cleanup post-template stuff

* testfix for looping right-arrow keynav bc we have a new subnav section

* A very roundabout way of ensuring that, if a job exists when saving a variable with a pathLinkedEntity of that job, its saved right through to the job itself

* hacky but an async version of pathLinkedVariable

* model-driven and async fetcher driven with cleanup

* Only run the update-job func if jobname is detected in var path

* Test cases begun

* Management token for variables to appear in tests

* Its a management token so it gets to see the clients tab under system jobs

* Pre-review cleanup

* More tests

* Number of requests test and small fix to groups-by-way-or-resource-arrays elsewhere

* Variable intro text tests

* Variable name re-use

* Simplifying our wording a bit

* parse json vs plainId

* Addressed PR feedback, including de-waterfalling

Co-authored-by: Phil Renaud <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport/1.6.x backport to 1.6.x release line
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow users to see all the variables from the job page including groups and tasks
3 participants