Terminology around provisioning considered confusing

Description

Subject: The word "provisioned" considered confusing
Date: Mon, 10 Oct 2011 13:53:03 -0400
From: Jeff Gehlbach
To: A private list of OGP members

Gentlemen,

Can we work our way to some kind of consensus about the meaning of
this word? My understanding has long been that it's a generic,
daemon-agnostic way to say "added to the system" when referring to a
node, an interface, or a service. Both Capsd and Provisiond can
provision nodes, interfaces, and services.

Lately I'm noticing that some folks seem to assign Provisiond-specific
meaning to the word, which is understandable considering that
"provisioned" is just one letter away from "Provisiond" (two if you're
being case-sensitive as well as the legacy "provisioning groups"
term. Where this all goes off the rails, though, is when Provisiond
is used with newSuspect events from the Discovery daemon. The nodes
added in this way are essentially indistinguishable from nodes added
by Capsd.

I'd like to propose that we standardize on the following terms:

Requisitioned (from "Requisition", formerly "Provisioning Group") to
describe a node that has a foreign-source name and a foreign-ID.
Rationale: such a node was surely provisioned by virtue of its model
appearing in a requisition. This term could also apply to interfaces
and services (and even node categories), to distinguish between ones
that appeared beneath the node in the requisition and ones that were
added by a detector or a policy.

??? to describe a node that has neither a foreign-source name nor a
foreign-ID, regardless of whether it was created by Capsd or
Provisiond. I need a word for this; "Discovered" is the obvious
candidate but I hate to use that because it encourages conflation of
Discovery and Provisioning, which are two separate things. "Detected"
avoids this conflation and could also apply to interfaces, services,
and node categories, so maybe that's a winner?

Sorry if this sounds pedantic, but it's a real and frequent source of
confusion in support tickets and IRC, presumably on the mailing lists
too, and I'd like to have it ironed out and codified in the English
book when it comes out.

-jeff

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Jeff Gehlbach November 16, 2011 at 1:24 PM

.../webapp/WEB-INF/jsp/admin/editForeignSource.jsp | 10 +++---
.../WEB-INF/jsp/admin/editProvisioningGroup.jsp | 8 ++--
.../src/main/webapp/WEB-INF/jsp/admin/node/add.jsp | 22 ++++++------ .../WEB-INF/jsp/admin/provisioningGroups.jsp | 16 +++++----- .../WEB-INF/jsp/admin/rancid/rancidAdmin.jsp | 16 +++++----- .../WEB-INF/jsp/admin/storage/storageAdmin.jsp | 2 +-
.../main/webapp/WEB-INF/jsp/inventory/invnode.jsp | 2 +-
.../main/webapp/WEB-INF/jsp/inventory/rancid.jsp | 4 +-
opennms-webapp/src/main/webapp/admin/delete.jsp | 6 ++--
opennms-webapp/src/main/webapp/admin/index.jsp | 34 ++++++++++--------- .../src/main/webapp/admin/nodelabelProvisioned.jsp | 14 ++++---- .../webapp/admin/nodemanagement/deletenode.jsp | 6 ++--
.../src/main/webapp/admin/nodemanagement/index.jsp | 13 +++++---
.../src/main/webapp/admin/snmpConfig.jsp | 2 +-
.../src/main/webapp/admin/snmpConfigured.jsp | 2 +-
.../src/main/webapp/admin/snmpselect.jsp | 2 +-
opennms-webapp/src/main/webapp/element/index.jsp | 2 +-
opennms-webapp/src/main/webapp/element/node.jsp | 5 ++-
opennms-webapp/src/main/webapp/outage/index.jsp | 2 +-
19 files changed, 88 insertions, 80 deletions

Jeff Gehlbach November 16, 2011 at 1:24 PM

Fixed in some wording changes that should help mitigate this confusion.

Fixed

Details

Assignee

Reporter

Fix versions

Affects versions

Priority

PagerDuty

Created November 16, 2011 at 1:22 PM
Updated January 27, 2017 at 4:20 PM
Resolved November 16, 2011 at 1:24 PM