functions/methods to calculate Landscape links for units, services, environment
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| juju-gui |
Fix Released
|
High
|
Benjamin Saller | ||
Bug Description
We should have methods or functions that produce the links we need. These will be used in many places, so having a single place to do the calculation will be valuable. Details follow.
* We need a Landscape link to view/manage the machines that represent
the current environment.
* We need a Landscape link to view/manage the set of machines that
represent a given service.
* We need a Landscape link to view/manage a single machine that is
running a given service unit.
* We need information about whether a unit is on a machine that needs
security updates from Landscape, and links to apply the update on the
unit, service, or environment level.
* We need information about whether a unit is on a machine that needs a
reboot from Landscape, and links to perform the reboot on the unit,
service, or environment level.
The links and information that I described above are available by
assembling annotations at different levels. Landscape connects with
Juju to create the annotations, and we simply consume them.
Here are the pertinent annotations, as drawn from some emails with
Thomas. They are at the environment, service, and unit level.
The environment itself has these annotations. Each annotation below
also gives an example value.
landscape-url: https:/
landscape-
landscape-
landscape-
Each service has this annotation.
landscape-
Each unit has this annotation.
landscape-
landscape-
landscape-
The upgrade and reboot flags are per unit, but we need to aggregate them
to the service and unit levels. In order to support doing this quickly,
to state the probably obvious, I suspect we will want to do some
counting at the service level, and possibly at the unit level. That is,
when the status of a unit changes, we will update a count attribute on
the associated service. The graphic renderings for services and the
environment will only need to check the aggregated counts, rather than
iterating over potentially thousands of units.
The URL segments are meant to be assembled. If you want to look at all
of the computers in the environment, for instance, you combine
landscape-url and landscape-
yield
"https:/
Here's a link to the page to reboot a given unit, using the example values:
For the service, it would be this:
For the environment, then it would be this:
https:/
Related branches
- Juju GUI Hackers: Pending requested
-
Diff: 372 lines (+298/-2)6 files modifiedapp/models/models.js (+19/-0)
app/modules-debug.js (+6/-1)
app/views/landscape.js (+137/-0)
test/index.html (+1/-0)
test/test_landscape.js (+129/-0)
test/test_model.js (+6/-1)
| Gary Poster (gary) wrote | #1 |
| Changed in juju-gui: | |
| assignee: | nobody → Benjamin Saller (bcsaller) |
| milestone: | none → 0.2.0+build.366 |
| status: | Triaged → In Progress |
| Changed in juju-gui: | |
| status: | In Progress → Fix Released |
There's a small change to the scheme described above, per therve. The goal was simply to shrink the size of the annotations on the services and units. The resulting URLs are essentially the same as described above. Here are the new annotations:
Environment:
landscape-url: https:/
landscape-
landscape-
landscape-
Service:
landscape-
Unit:
landscape-
landscape-
landscape-
To create a service or unit URL now, you must always include the Environment's landscape-computers annotation before the service's or unit's. A service URL from the annotations above would be https:/
therve notes that the environment criteria has also changed to use the UUID instead of Landscape's internal name, but that should not affect us.