v1.12.5

Small release to fix two issues

* Add a way to put a body with a DELETE api call (#322)
* Fix posting new Hardware Vendors by removing the body (#321)

v1.12.4

Small release to add the SKU to the hardware product output

v1.12.3

Bug fix release for uploading and displaying hardware product specifications

v1.12.2

5ff687a ignore github pre-releases when looking for an upgrade

v1.11.3

Backport of the 1.12 release process fixes:

d828b74 in the release dockerfile, set HOME appropriately. Also dump out our id and environment for debug purposes
ef23474 when building a release in docker, only call rmi if the release happened properly

v1.11.2

2f15477 ignore github pre-releases when looking for an upgrade

v1.12.1

Fix release process (again)

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.

v1.11.1

Repairs the build process so it works again under buildbot, and also
actually builds binaries for the target platforms

v1.11.0

Stable Release v1.11

This release of Conch Shell requires Conch API >=2.26, the current staging
version.

This is the first version of the Conch Shell that enforces the API versions that
it is able to talk to. For instance, this release only supports API version 2.26
and up. It will not function if the profile contains a url for a server version
less than that.

In a bit of future proofing, the shell will not attempt an upgrade to a version
with a different major number. For instance, upon the eventual release of Conch
Shell v3.0, this version of the shell and its descendants will not ask to
upgrade nor present the changelog.

Also, conch update changelog will show all changelogs between the current
version and the latest, allowing the user to be better informed of the changes.

Breaking Changes

• If the user is root, update self will not function unless the --force
  flag is provided
• Due to an API change, the workspace :id rooms command no longer exists
• Due to an API change, --alias is required for global rooms create (This
  was also included in 1.10.3)

Major Breaking Change

Due to an API change, the JSON output of device :id get and device :id location have changed.

NOTE: Because this is an API change, anyone using api get /device/:id is
affected also.

The previous DeviceLocation datastructure looked like:

{
  "datacenter": {
    "id": uuid,
    "name": ...,
    "vendor_name": ...,
  },
  "rack": {
    "id": uuid,
    "name": ...,
    "role": ...",
    "unit": ...,
    "size": ...,
    "datacenter": ...,
    "slots": ...,
    "serial_number": ...,
    "asset_tag": ...,
  },
  "target_hardware_product": {
    "id": uuid,
    "name": ...,
    "alias": ...,
  },
}

The structure now looks like:

{
  "datacenter": {
    "id": uuid,
    # "name" # REMOVED
    "vendor": string, # NEW
    "vendor_name": string,
    "region": string, # NEW
    "location": string, # NEW
    "created": time, # NEW,
    "updated": time, # NEW,
  },
  "room": { # NEW
    "id": uuid,
    "az": string,
    "alias": string,
    "vendor_name": string,
    "datacenter": uuid,
    "created": time,
    "updated": time,
  },
  "rack": {
    "id": uuid,
    "created": time, # NEW
    "updated": time, # NEW
    "datacenter_room_id": uuid, # NEW
    "name": string,
    "role_id": uuid, # NEW - replaces "role"
    "serial_number": string,
    "asset_tag": string,
  },
  "target_hardware_product": {
    "id": uuid,
    "name": string,
    "alias": string,
    "vendor": string, # NEW
  },
  "rack_unit_start": int, # NEW - replaces rack.unit
}

Misc Changes

• some minor build changes were made to further the goal of reproducible builds