v1.12.0

Conch Shell stable release v1.12.0

This release requires Conch API v2.30.0 or greater.

Breaking Changes

It is no longer possible to skip the version upgrade check.
--no-version-check is non-operable but included for backwards compatibility. The upgrade message is printed to STDERR so it is possible to ignore this message using syntax like conch 2>/dev/null. This will hide other
error messages, however.

The rationale is that the API introduces changes, often breaking changes, at a rapid clip. The shell is released as quickly as necessary to accomodate those changes. Failure to upgrade the shell will rapidly lead to breakage. In almost every case, support sessions start with "you are running a very old version. Please upgrade and try again" which solves the problem almost every time.

We also do not have the resources to support old versions of the shell. Support can only be offered for the most-current production release and the most-current prerelease. Keeping up to date with the latest release guarantees support.

New Feature: API Tokens

The Conch API recently introduced the concept of "tokens". These are strings that allow the user to access Conch without password authentication. In terms of the shell, this means it is possible to use the shell without a config file or password authentication.

Many new commands were added to the shell. They are detailed over in this pull request.

For most users, running conch profile upgrade is sufficient. This generates a token and installs it in the shell's profile. After this upgrade, the user no longer needs to log in and authentication will not expire.

The web UI also offers the ability to generate and manage tokens. If one uses the web UI to generate a token, it can be installed into the shell's config with conch profile set token :token where :token is the string obtained from the UI. When creating a new profile, one can set a token with conch profile create --token removing the need for password auth.

If you'd like to use the shell without a configuration at all, you can run the shell like so: CONCH_TOKEN=:token conch. This uses the provided token and, by default, talks to the production Conch API. Please read PR
289 for more detail.

New Feature: Phases

The Conch API recently introduced the notion of 'phases', intended to record when a device is in preflight, production, etc. In support of this feature, we now offer:

• device :id phase get
• device :id phase set :phase
• rack :id phase
• rack :id set phase :phase - A --also-devices option sets the phase on all devices in the rack as well

Deprecation: 'global' command tree and most 'workspace' commands

Historically, Conch has offered access to devices and racks only through workspaces. To view or edit a device or a rack, a user needs access to a workspace containing that device. Users has permission levels like 'read-only' and 'read-write'. Well, what happens when a user has 'read-write' access to a device in one workspace and 'read-only' access to that device in another workspace. To edit that device in the shell, the user needed to know what their access rights were and specify the workspace where they were granted
'read-write' permissions.

Conch now has methods of accessing devices and racks that do not require the user to keep track of their own permissions. A user can request information about a device or rack or other entity and the Conch API figures out the appropriate access level.

To celebrate this change, the shell now has root level commands for accessing racks, rooms, datacenters, etc. These commands match their equivalents in the 'workspace' and 'global' command trees.

Going forward, the root level commands will receive support. The entire 'global' command tree and all commands in 'workspace' that do not deal with managing workspaces are deprecated and will be removed in the future.

Changes: Deactivated Validations

In the Conch API, validations are versioned. When a validation is changed, the version number increments and validation plans can use that new validation. When a validation is no longer in use, it is 'deactivated'. Previously, the shell did not show if a validation was 'deactivated' or not which led to some confusion. Wherever lists of validations are displayed, we now default to only displaying 'active' validations. If one wishes to see the deactivated validations, --show-deactivated may be provided.