pivotal-cf / om Goto Github PK

View Code? Open in Web Editor NEW

135.0 44.0 105.0 17.04 MB

General command line utility for working with VMware Tanzu Operations Manager

License: Apache License 2.0

Go 99.91% Shell 0.03% Ruby 0.06%

golang cli ops-manager hacktoberfest

om's Introduction

Om

a mantra, or vibration, that is traditionally chanted

om is a tool that helps you configure and deploy tiles to Ops-Manager. Currently being maintained by the Developer and Application Platform (DAP) Tanzu Application Service (TAS) Platform Provider Experience (PPE) team.

Documentation

See here for useful examples and documentation.

When working with om, it can sometimes be useful to reference the Ops Manager API docs. You can find them at https://pcf.your-ops-manager.example.com/docs.

NOTE: Additional documentation for om commands used in Platform Automation can be found in the VMware Tanzu Documentation.

Versioning

om went 1.0.0 on May 7, 2019

As of that release, om is semantically versioned. When consumig om in your CI system, it is now safe to pin to a particular minor version line (major.minor.patch) without fear of breaking changes.

API Declaration for Semver

The om API consists of:

All om commands not marked EXPERIMENTAL, and the flags for those commands
All global om flags
The format for any inputs to non-experimental om commands.
The format for any outputs from non-experimental om commands.
The file filename of the Github relases.

"EXPERIMENTAL" commands are still in development. We may rename them, alter their flags or behavior, or remove them entirely. When we're confident a command has the right basic shape and behavior, we'll remove the "EXPERIMENTAL" designation.

Changes internal to om will NOT be included as a part of the om API. The versioning here is for the CLI tool, not any libraries or packages included therein. The om team may change any internal structs, interfaces, etc, without reflecting such changes in the version, so long as the outputs and behavior of the commands remain the same.

Though om is used heavily in Platform Automation for PCF, which is also semantically versioned. om is versioned independently from platform-automation.

Installation

To download om go to Releases.

Alternatively, you can install om via apt-get via Stark and Wayne:

# apt-get:
sudo wget -q -O - https://raw.githubusercontent.com/starkandwayne/homebrew-cf/master/public.key | sudo  apt-key add -
sudo echo "deb http://apt.starkandwayne.com stable main" | sudo  tee /etc/apt/sources.list.d/starkandwayne.list
sudo apt-get update
sudo apt-get install om -y

Or by the Linux and Mac brew

brew tap pivotal-cf/om https://github.com/pivotal-cf/om
brew install om

You can also build from source.

Building from Source

You'll need at least Go 1.12, as om uses Go Modules to manage dependencies.

To build from source, after you've cloned the repo, run these commands from the top level of the repo:

GO111MODULE=on go mod download
GO111MODULE=on go build

Go 1.11 uses some heuristics to determine if Go Modules should be used. The process above overrides those heuristics to ensure that Go Modules are always used. If you have cloned this repo outside of your GOPATH, GO111MODULE=on can be excluded from the above steps.

om's People

Contributors

Stargazers

Watchers

Forkers

pdelagrave adi-mishra rsamban sradnidge asehra engineerbetter anwarchk subhashgunda craigbookwalter z4ce jamiemonserrate sapientcoffee camelpunch peterellisjones degaurab gogonzales saurabhguptasg bhupen jasper9 ramene henderjm kumareshbabuns rcw5 jaysonbh mgoddard lauraeci datianshi hegderaj infa-jojgeorg ktpv sneal jhvhs niallthomson vincewwhite anexper kkallday acarrigan-pivotal ronakbanka msforrest calebwashburn daviddob hjaffan walk1ng voor patrick-huber-pivotal bottkars kartiklunkad26 rlewkowicz arul-cfkube duranangela edwardecook mcwumbly rwang721 clhynfield strikingraghu stonezdj narenvist nwmahoney jukie yujita vchrisb jbergfeld jhmcstanton tonyelmore rkoster cfryanr sapient007 michaeldbrown jli1972 yuyangbj cweibel rhardt-pivotal petereltgroth ssapra eitansuez crsimmons a-masse farmermel mrdavidlaing nobodynowhere jvshahid isabella232 hoegaarden zmb3 hmanukyanvmw kungfoome mma-pivotal dforbes-pivotal burgerjeffrey ystros blgm ragezbla martinpfeifer rahulkj markstokan wayneadams nouseforaname fawazghali wrkuser santudiya

om's Issues

Bosh Director AZ configuration for vSphere requires additional fields.

vSphere requires the following fields to be filled in:

availability_zones[availability_zones][][name]
availability_zones[availability_zones][][cluster]
availability_zones[availability_zones][][resource_pool]

Where other IaaS that OM supports only uses the following field for AZ:

availability_zones[availability_zones][][iaas_identifier]

Bad SSH Key in --iaas-configuration on AWS Doesn't Show Error

Using om 0.22.0 against OpsManager 1.10.4 on AWS, inputting a bad ssh key via the UI shows an error message.

Using --iaas-configuration, on the other hand, with a bad key does not return any error message and om returns exit code 0.

om configure-bosh --networks-configuration fails on for AWS/OpsManager 1.8

Sample config:

"networks": [
    {
      "name": "opsman-network",
      "subnets": [
        {
          "iaas_identifier": "subnet-650d4048",
          "cidr": "10.0.0.0/24",
          "reserved_ip_ranges": "10.0.0.0-10.0.0.5,10.0.0.255",
          "dns": "172.16.0.23",
          "gateway": "10.0.0.1",
          "availability_zones": [
            "us-east-1a"
          ]
        },
        {
          "iaas_identifier": "subnet-66b98a2f",
          "cidr": "10.0.1.0/24",
          "reserved_ip_ranges": "10.0.1.0-10.0.1.5,10.0.1.255",
          "dns": "172.16.0.23",
          "gateway": "10.0.1.1",
          "availability_zones": [
            "us-east-1b"
          ]
        }
      ]
    },
    {
      "name": "ert-network",
      "subnets": [
        {
          "iaas_identifier": "subnet-6f0d4042",
          "cidr": "10.0.4.0/24",
          "reserved_ip_ranges": "10.0.4.0-10.0.4.5,10.0.4.255",
          "dns": "172.16.0.23",
          "gateway": "10.0.4.1",
          "availability_zones": [
            "us-east-1a"
          ]
        },
        {
          "iaas_identifier": "subnet-7bb98a32",
          "cidr": "10.0.5.0/24",
          "reserved_ip_ranges": "10.0.5.0-10.0.5.5,10.0.5.255",
          "dns": "172.16.0.23",
          "gateway": "10.0.5.1",
          "availability_zones": [
            "us-east-1b"
          ]
        }
      ]
    },
    {
      "name": "services-network",
      "subnets": [
        {
          "iaas_identifier": "subnet-670d404a",
          "cidr": "10.0.8.0/24",
          "reserved_ip_ranges": "10.0.8.0-10.0.8.5,10.0.8.255",
          "dns": "172.16.0.23",
          "gateway": "10.0.8.1",
          "availability_zones": [
            "us-east-1a"
          ]
        },
        {
          "iaas_identifier": "subnet-7ab98a33",
          "cidr": "10.0.9.0/24",
          "reserved_ip_ranges": "10.0.9.0-10.0.9.5,10.0.9.255",
          "dns": "172.16.0.23",
          "gateway": "10.0.9.1",
          "availability_zones": [
            "us-east-1b"
          ]
        }
      ]
    }
  ]
}

We get the following errors for each subnets:

VPC Subnet ID can't be blank
Availability Zones can't be blank

Another question:
For https://github.com/pivotal-cf/om/blob/master/docs/configure-bosh/aws.md
It says Note: Only one availability zone can be specified per network subnet., then why make this an array in the input subnet JSON object?

Thanks!

delete-installation / ops manager 1.10

i am trying to use the "delete-installation" call of "om" version 0.20.0 against a 1.10 environment (1.9 seems fine) and getting the following error:

attempting to delete the installation on the targeted Ops Manager could not execute "delete-installation": fai 0"errors":{"base":["undefined method each' for nil:NilClass"]}}HTTP/1.1 500 Internal Server Error`

from the ops manager logs, i am seeing the following detailed 500 error:

Started DELETE "/api/v0/installation_asset_collection" for 127.0.0.1 at 2017-04-03 16:16:09 +0000 Processing by Api::V0::InstallationAssetCollectionController#destroy as HTML Parameters: {"installation_asset_collection"=>{}} Valid UAA token Exception caught via rescue_from (code 500): (See app/controllers/application_controller.rb) undefined method each' for nil:NilClass
/home/tempest-web/tempest/web/app/presenters/errands_to_run_presenter.rb:57:in validate_post_deploy_products_are_staged' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:432:in block in make_lambda'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:192:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:192:in block in simple'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:504:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:504:in block in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:504:in each' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:504:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:92:in __run_callbacks__' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:778:in _run_validate_callbacks'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activemodel-4.2.7.1/lib/active_model/validations.rb:399:in run_validations!' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activemodel-4.2.7.1/lib/active_model/validations.rb:338:in valid?'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activemodel-4.2.7.1/lib/active_model/validations.rb:375:in invalid?' /home/tempest-web/tempest/web/app/controllers/api/v0/installation_asset_collection_controller.rb:114:in run_install'
/home/tempest-web/tempest/web/app/controllers/api/v0/installation_asset_collection_controller.rb:60:in destroy' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/implicit_render.rb:4:in send_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/abstract_controller/base.rb:198:in process_action' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/rendering.rb:10:in process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/abstract_controller/callbacks.rb:20:in block in process_action' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:117:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:117:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:555:in block (2 levels) in compile'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:505:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:505:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:92:in __run_callbacks__' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:778:in _run_process_action_callbacks'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:81:in run_callbacks' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/abstract_controller/callbacks.rb:19:in process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/rescue.rb:29:in process_action' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/instrumentation.rb:32:in block in process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/notifications.rb:164:in block in instrument' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/notifications/instrumenter.rb:20:in instrument'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/notifications.rb:164:in instrument' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/instrumentation.rb:30:in process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/params_wrapper.rb:250:in process_action' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activerecord-4.2.7.1/lib/active_record/railties/controller_runtime.rb:18:in process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/abstract_controller/base.rb:137:in process' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionview-4.2.7.1/lib/action_view/rendering.rb:30:in process'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal.rb:196:in dispatch' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/rack_delegation.rb:13:in dispatch'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal.rb:237:in block in action' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/routing/route_set.rb:74:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/routing/route_set.rb:74:in dispatch' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/routing/route_set.rb:43:in serve'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/journey/router.rb:43:in block in serve' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/journey/router.rb:30:in each'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/journey/router.rb:30:in serve' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/routing/route_set.rb:817:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/omniauth-1.3.1/lib/omniauth/strategy.rb:186:in call!' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/omniauth-1.3.1/lib/omniauth/strategy.rb:164:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/omniauth-1.3.1/lib/omniauth/builder.rb:63:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/etag.rb:24:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/conditionalget.rb:38:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/head.rb:13:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/params_parser.rb:27:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/flash.rb:260:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:225:in context' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:220:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/cookies.rb:560:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activerecord-4.2.7.1/lib/active_record/query_cache.rb:36:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:653:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/callbacks.rb:29:in block in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:88:in __run_callbacks__' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:778:in _run_call_callbacks'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:81:in run_callbacks' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/callbacks.rb:27:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/remote_ip.rb:78:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/debug_exceptions.rb:17:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/show_exceptions.rb:30:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/railties-4.2.7.1/lib/rails/rack/logger.rb:38:in call_app'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/railties-4.2.7.1/lib/rails/rack/logger.rb:22:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/request_id.rb:21:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/methodoverride.rb:22:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/runtime.rb:18:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/cache/strategy/local_cache_middleware.rb:28:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/static.rb:120:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/sendfile.rb:113:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/ssl.rb:24:in call'
/home/tempest-web/tempest/web/lib/rack/streaming.rb:63:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/railties-4.2.7.1/lib/rails/engine.rb:518:in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/railties-4.2.7.1/lib/rails/application.rb:165:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/connection.rb:86:in block in pre_process'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/connection.rb:84:in catch' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/connection.rb:84:in pre_process'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/eventmachine-1.2.0.1/lib/eventmachine.rb:1076:in call' /home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/eventmachine-1.2.0.1/lib/eventmachine.rb:1076:in block in spawn_threadpool'

Completed 500 Internal Server Error in 1846ms (Views: 0.2ms |
ActiveRecord: 7.6ms)`

does "om" fully support ops manager 1.10 or might there be a problem with this one call?

can't run om-linux in certain docker images

Hey, trying to run om from within concourse and I was getting "file not found" for om when it was most definitely still there. Think its this:

http://stackoverflow.com/questions/36279253/go-compiled-binary-wont-run-in-an-alpine-docker-container-on-ubuntu-host

Reproduce it like so:

~|⇒ docker run -i -t colszowka/toolkit
[19:19:46] root@2f6de072abc3 / ↱  💎 2.3.1p112 ⬢ v6.6.0
▶ wget https://github.com/pivotal-cf/om/releases/download/0.9.0/om-linux
--2016-11-18 19:20:00--  https://github.com/pivotal-cf/om/releases/download/0.9.0/om-linux
Resolving github.com... 192.30.253.112, 192.30.253.113
Connecting to github.com|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-cloud.s3.amazonaws.com/releases/68121501/d4995fb4-ad7e-11e6-8aeb-e0087881c527?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20161118%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20161118T192000Z&X-Amz-Expires=300&X-Amz-Signature=f12eed2c609324644cc7c5c09cd605b800780ad740e7bca9eae8f9ee46f1827b&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dom-linux&response-content-type=application%2Foctet-stream [following]
--2016-11-18 19:20:00--  https://github-cloud.s3.amazonaws.com/releases/68121501/d4995fb4-ad7e-11e6-8aeb-e0087881c527?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20161118%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20161118T192000Z&X-Amz-Expires=300&X-Amz-Signature=f12eed2c609324644cc7c5c09cd605b800780ad740e7bca9eae8f9ee46f1827b&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dom-linux&response-content-type=application%2Foctet-stream
Resolving github-cloud.s3.amazonaws.com... 54.231.82.146
Connecting to github-cloud.s3.amazonaws.com|54.231.82.146|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7937034 (7.6M) [application/octet-stream]
Saving to: 'om-linux'

om-linux              100%[=========================>]   7.57M  2.13MB/s    in 3.6s    

2016-11-18 19:20:04 (2.09 MB/s) - 'om-linux' saved [7937034/7937034]

[19:20:07] root@2f6de072abc3 / ↱  💎 2.3.1p112 ⬢ v6.6.0
▶ chmod +x om-linux 
[19:20:11] root@2f6de072abc3 / ↱  💎 2.3.1p112 ⬢ v6.6.0
▶ ./om-linux 
bash: ./om-linux: No such file or directory

[Feature Request] Turn on or off errands

Looking to see if a feature can be added to be able to turn on or off tile deployment errands. It seems that when you stage a product to OpsManager, the errands will stay at the last state. It would be helpful during an automated deploy to be able to make sure the deployment errands are on before applying changes.

It isn't possible to set FloatingIPs to the resource-configuration of the ERT (OpenStack) is it?

Hi there!
I configured my director and the ERT with your OM tool and everything works fine except setting an exisiting FloatingIP to the resource configuration of the ERT.
Neither with the official OpsMan-Api nor with your tool I am able to set FloatingIPs...

Is this "feature" on your roadmap or do I have to set those floatingips afterwards via the openstack cli?

Cheers

set-errands-state fails with "undefined method `find' for nil:NilClass"

We are having issues using the set-errand-state command (tested with Ops Manager v1.8.17.0):

$> om -t https://pcf.opsman.com/ -u admin -p xxxx -k errands -p cf                                                                   │
+-----------------------------+---------------------+--------------------+                                                                                                                                                │
|            NAME             | POST DEPLOY ENABLED | PRE DELETE ENABLED |                                                                                                                                                │
+-----------------------------+---------------------+--------------------+                                                                                                                                                │
| smoke-tests                 | true                |                    |                                                                                                                                                │
| push-apps-manager           | true                |                    |                                                                                                                                                │
| notifications               | true                |                    |                                                                                                                                                │
| notifications-ui            | true                |                    |                                                                                                                                                │
| push-pivotal-account        | true                |                    |                                                                                                                                                │
| autoscaling                 | true                |                    |                                                                                                                                                │
| autoscaling-register-broker | true                |                    |                                                                                                                                                │
+-----------------------------+---------------------+--------------------+

$> om -t https://pcf.opsman.com/ -u admin -p xxxx -k set-errand-state -p cf -e notifications --post-deploy-state disabled  
  could not execute "set-errand-state": failed to set errand state: failed to set errand state: 500 {"errors":{"base":["undefined method `find' for nil:NilClass"]}}

However, it works using om curl:

$> errands='{ "errands": [ { "post_deploy": false, "name": "notifications" }] }'

$> om -t https://pcf.opsman.com/ -u admin -p xxxx -k curl -p /api/v0/staged/products/cf-guid/errands -x PUT -d "$errands"

$> om -t https://pcf.opsman.com/ -u admin -p xxxx -k errands -p cf
+-----------------------------+---------------------+--------------------+                                                                                                                                                │
|            NAME             | POST DEPLOY ENABLED | PRE DELETE ENABLED |                                                                                                                                                │
+-----------------------------+---------------------+--------------------+                                                                                                                                                │
| smoke-tests                 | true                |                    |                                                                                                                                                │
| push-apps-manager           | true                |                    |                                                                                                                                                │
| notifications               | false               |                    |                                                                                                                                                │
| notifications-ui            | true                |                    |                                                                                                                                                │
| push-pivotal-account        | true                |                    |                                                                                                                                                │
| autoscaling                 | true                |                    |                                                                                                                                                │
| autoscaling-register-broker | true                |                    |                                                                                                                                                │
+-----------------------------+---------------------+--------------------+

By the way, when we run om curl without the -d we got the same error.

--az-configuration on vSphere is broken

When I use --az-configuration I get a 500 error.

This is the 500:

        Exception caught via rescue_from (code 500):
        (See app/controllers/application_controller.rb)
        missing keyword: name
    /home/tempest-web/tempest/web/app/models/persistence/models/vsphere/vsphere_availability_zone.rb:15:in `initialize'
/home/tempest-web/tempest/web/app/models/persistence/models/base_availability_zone.rb:11:in `new'
/home/tempest-web/tempest/web/app/models/persistence/models/base_availability_zone.rb:11:in `load_from_hash'
/home/tempest-web/tempest/web/app/models/persistence/models/vsphere/vsphere_availability_zone_collection.rb:8:in `block in load_from_hash'
/home/tempest-web/tempest/web/app/models/persistence/models/vsphere/vsphere_availability_zone_collection.rb:8:in `map'
/home/tempest-web/tempest/web/app/models/persistence/models/vsphere/vsphere_availability_zone_collection.rb:8:in `load_from_hash'
/home/tempest-web/tempest/web/app/models/persistence/models/vsphere/vsphere_infrastructure.rb:71:in `build_availability_zone_collection'
/home/tempest-web/tempest/web/app/presenters/availability_zones_presenter.rb:20:in `load_availability_zones_from_params'
/home/tempest-web/tempest/web/app/presenters/availability_zones_presenter.rb:12:in `initialize'
/home/tempest-web/tempest/web/app/controllers/infrastructure/availability_zones_controller.rb:11:in `new'
/home/tempest-web/tempest/web/app/controllers/infrastructure/availability_zones_controller.rb:11:in `update'

This is the PUT data:

  Parameters: {"authenticity_token"=>"[FILTERED]", "availability_zones"=>{"availability_zones"=>[{"cluster"=>"A-Cluster"}, {"cluster"=>"B-Cluster"}, {"cluster"=>"C-Cluster", "name"=>"AZ 01"}, {"name"=>"AZ 02"}, {"name"=>"AZ 03", "resource_pool"=>"a-cluster-rp05"}, {"resource_pool"=>"b-cluster-rp05"}, {"resource_pool"=>"c-cluster-rp05"}]}}

That PUT data looks pretty broken to me.

The JSON that's given to --az-configuration is the following:

{
  "availability_zones": [
    {
      "name": "$AZ_1",
      "cluster": "$AZ_1_CLUSTER_NAME",
      "resource_pool": "$AZ_1_RP_NAME"
    },
    {
      "name": "$AZ_2",
      "cluster": "$AZ_2_CLUSTER_NAME",
      "resource_pool": "$AZ_2_RP_NAME"
    },
    {
      "name": "$AZ_3",
      "cluster": "$AZ_3_CLUSTER_NAME",
      "resource_pool": "$AZ_3_RP_NAME"
    }
  ]
}

delete-installation does not re-attach to a running delete

If you get an i/o timeout when deleting an installation, you cannot re-attach:

om --target https://pcf.shadow-snarl.azure.releng.cf-app.com --username foo --password foo --skip-ssl-validation delete-installation
attempting to delete the installation on the targeted Ops Manager
could not execute "delete-installation": failed to delete installation: request failed: unexpected response:
HTTP/1.1 422 Unprocessable Entity
Transfer-Encoding: chunked
Cache-Control: no-cache
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Date: Thu, 09 Feb 2017 18:14:43 GMT
Server: nginx/1.4.6 (Ubuntu)
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: 9d4f33aa-df88-4e13-9a58-48d954f86f62
X-Runtime: 0.437473
X-Xss-Protection: 1; mode=block

22
{"errors":["Install in progress"]}

OM tool does not support S3 V4 signature

When you enable S3 in director tile and select V4 signature, region field is required. The tool does not update the field causing the settings to fail to save.

Support `instances: automatic` in configure-product command

As per the OpsManager API docs:

instances: The number of instances for the job or “automatic”

If we configure the product-resources with automatic like in the following example:

{
  "job-name": {
    "instances": "automatic",
    "instance_type": {"id": "automatic"},
    "persistent_disk": {"size_mb": "automatic"}
  }
}

and execute that with om ... configure-product ... the following error occurs:

could not execute "configure-product": json: cannot unmarshal string into Go value of type int

Latest version of om doesn't have `deployed-products` cmd

Hi OM team,
Can you please update ReadMe to reflect all supported commands.

Thanks

om configure-product --product-resource fails to disable "internet_connected"

Disabling internet_connected using OM configure-resource
doesn't works:

./om -k -t https://om.com configure-product \
  --product-name cf \
  --product-resources '{"consul_server": {"internet_connected": false}}'

Refreshing the UI after executing the command shows negative result.

Enabling internet_connected using OM configure-resource
works:

./om -k -t https://om.com configure-product \
  --product-name cf  \
  --product-resources '{"consul_server": {"internet_connected": true}}'

Refreshing the UI after executing the command shows positive result.

Enabling/Disabling internet_connected using OM curl and the OpsMan Api directly
works:

om -k -t https://om.com \
  -p /api/v0/staged/products/cf-uuid/jobs/consul_server-uuid/resource_config \
  -x PUT \
  -d '{"instances": "automatic", "instance_type": {"id": "automatic"}, "persistent_disk": { "size_mb": "automatic"}, "internet_connected": true|false}'

Refreshing the UI after executing the command shows positive result.

detected deployed director - cannot modify network configuration

https://github.com/pivotal-cf/om/blob/master/commands/configure_bosh.go#L69

This should validate only when setting the networks and az's. We should still be able to update the director configuration

configure-bosh --network-assignment reports success but fails on OpsMan 1.8.13 on vSphere

Hi folks,

We're trying to use om version 0.15.0 to configure OpsMan 1.8.13.0. Our biggest hurdle right now is we can't assign an az in the director.

root@b22b378f7cf2:/# om-linux --target https://pcf.$ENV_NAME.cf-app.com -k --username "$DEFAULT_OPSMAN_USERNAME" --password "$DEFAULT_OPSMAN_PASSWORD" configure-bosh --network-assignment '{"singleton_availability_zone":"default-az","network":"default"}'
assigning az and networks for bosh tile
finished configuring bosh tile

When we run the above command and observe the UI we see that "singleton availability zone" is blank, but the pane at the side has a checkbox. If we try to install we get a 500 suggesting that the singleton az guid is blank.

Any help appreciated!

Thanks,
Todd & Mark

Can't unset `director_hostname`

I can run {opsman stuff} -k configure-bosh --director-configuration '{"director_hostname":"foo"}' successfully.

When I try to unset this field with {opsman stuff} -k configure-bosh --director-configuration '{"director_hostname":""}' I see the following failure:

opsman -k configure-bosh --director-configuration '{"director_hostname":""}'
configuring director options for bosh tile
could not execute "configure-bosh": tile failed to configure: request failed: unexpected response:
HTTP/1.1 500 Internal Server Error
Transfer-Encoding: chunked
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/html; charset=utf-8
Date: Tue, 09 May 2017 16:41:18 GMT
Server: nginx/1.4.6 (Ubuntu)
Set-Cookie: _web_session=WXRUbWRsWU9TUGZSd00yUWdGTXdEb2Q3WVdZSmRMZFNXd2NiMTZRNFRWbHQzdC8xS1ZGQnZpd08ramc1T1N0QUFoT09pWnR5akFkbTZiSDloT2pRVFkxUTZESlNKd3psbmJRRUtWMFRCcFY0anJsVVJyeFZ0ZG40WDF4aVRoUzRkck1TYWhsa3Z2ci9YQmlSWjZvcG5RPT0tLVJOV0RXUEZHOVcySjlVdjRMWnBZUkE9PQ%3D%3D--8181ea0de2d98b96334e43fe8c33b288d4075b07; path=/; secure; HttpOnly
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: 6acf8a34-95b2-4036-b9e6-69e4e9107231
X-Runtime: 1.144350
X-Xss-Protection: 1; mode=block

2d40
<!DOCTYPE html>
<html>
<head>
<meta content='text/html; charset=utf-8' http-equiv='Content-Type'>
<meta content='0' http-equiv='expires'>
<meta content='text/javascript' http-equiv='Content-Script-Type'>
<meta content='text/css' http-equiv='Content-Style-Type'>
<meta content='IE=Edge,chrome=1' http-equiv='X-UA-Compatible'>
<link href='/favicon.png' rel='icon' type='image/png'>
<title>Ops Manager</title>
<meta name="csrf-param" content="authenticity_token" />
<meta name="csrf-token" content="jDxNA+/TxV2hU06CWWuGKywot8rByLnFDTegolprsfUkwm7HVRXr77gQE/ItaFTN6c0F5ERnKcDqVOVjIM2l5g==" />
<link rel="stylesheet" media="screen" href="/assets/application-2c29ca884d37864467d5334e1c4883aa2e3c58c564e77a00d4c3b12fe66bb4b0.css" />
<script src="/assets/application-3f515a698587bf8a738bf1f5f944a2c08fed10676595d017d6de9b2eb2cbd9fb.js"></script>


</head>
<body class='error-page rails-env-production'>
<div class='container'>
<nav class='site-header'>
<a class='logo float-left' href='/' id='pivotal_cf_logo'>
<div class='pivotal-logo'></div>
<div class='operations-manager-logo'></div>
</a>
</nav>
<section class='content-container twelve columns'>
<div class='error'>
<h1>500 An error occurred.</h1>
<h2>Contact Pivotal Technical Support to report the problem.</h2>

<p><a href="/">Back to dashboard</a></p>
<hr>
<pre>NoMethodError</pre>
<pre>undefined method `permit' for nil:NilClass</pre>
<pre>/home/tempest-web/tempest/web/app/models/use_cases/director_configuration_updater.rb:54:in `valid_params'
/home/tempest-web/tempest/web/app/models/use_cases/director_configuration_updater.rb:6:in `initialize'
/home/tempest-web/tempest/web/app/controllers/infrastructure/director_configurations_controller.rb:13:in `new'
/home/tempest-web/tempest/web/app/controllers/infrastructure/director_configurations_controller.rb:13:in `update'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/implicit_render.rb:4:in `send_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/abstract_controller/base.rb:198:in `process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/rendering.rb:10:in `process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/abstract_controller/callbacks.rb:20:in `block in process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:117:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:117:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:555:in `block (2 levels) in compile'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:505:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:505:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:92:in `__run_callbacks__'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:778:in `_run_process_action_callbacks'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:81:in `run_callbacks'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/abstract_controller/callbacks.rb:19:in `process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/rescue.rb:29:in `process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/instrumentation.rb:32:in `block in process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/notifications.rb:164:in `block in instrument'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/notifications.rb:164:in `instrument'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/instrumentation.rb:30:in `process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/params_wrapper.rb:250:in `process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activerecord-4.2.7.1/lib/active_record/railties/controller_runtime.rb:18:in `process_action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/abstract_controller/base.rb:137:in `process'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionview-4.2.7.1/lib/action_view/rendering.rb:30:in `process'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal.rb:196:in `dispatch'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal/rack_delegation.rb:13:in `dispatch'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_controller/metal.rb:237:in `block in action'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/routing/route_set.rb:74:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/routing/route_set.rb:74:in `dispatch'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/routing/route_set.rb:43:in `serve'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/journey/router.rb:43:in `block in serve'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/journey/router.rb:30:in `each'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/journey/router.rb:30:in `serve'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/routing/route_set.rb:817:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/omniauth-1.3.1/lib/omniauth/strategy.rb:186:in `call!'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/omniauth-1.3.1/lib/omniauth/strategy.rb:164:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/omniauth-1.3.1/lib/omniauth/builder.rb:63:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/etag.rb:24:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/conditionalget.rb:38:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/head.rb:13:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/params_parser.rb:27:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/flash.rb:260:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:225:in `context'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/session/abstract/id.rb:220:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/cookies.rb:560:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activerecord-4.2.7.1/lib/active_record/query_cache.rb:36:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:653:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:88:in `__run_callbacks__'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:778:in `_run_call_callbacks'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/callbacks.rb:81:in `run_callbacks'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/callbacks.rb:27:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/remote_ip.rb:78:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/railties-4.2.7.1/lib/rails/rack/logger.rb:38:in `call_app'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/railties-4.2.7.1/lib/rails/rack/logger.rb:22:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/request_id.rb:21:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/methodoverride.rb:22:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/runtime.rb:18:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/activesupport-4.2.7.1/lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/static.rb:120:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/rack-1.6.4/lib/rack/sendfile.rb:113:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/actionpack-4.2.7.1/lib/action_dispatch/middleware/ssl.rb:24:in `call'
/home/tempest-web/tempest/web/lib/rack/streaming.rb:63:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/railties-4.2.7.1/lib/rails/engine.rb:518:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/railties-4.2.7.1/lib/rails/application.rb:165:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/connection.rb:86:in `block in pre_process'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/connection.rb:84:in `catch'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/connection.rb:84:in `pre_process'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/eventmachine-1.2.0.1/lib/eventmachine.rb:1076:in `call'
/home/tempest-web/tempest/web/vendor/bundle/ruby/2.2.0/gems/eventmachine-1.2.0.1/lib/eventmachine.rb:1076:in `block in spawn_threadpool'</pre>
<hr>
<p class='footer'><a href="/">Back to dashboard</a></p>
</div>
</section>
<footer class='site-footer'>
<span class='version'>PCF Ops Manager v1.10.1.0;</span>
<span>&copy;2013-2017 Pivotal Software, Inc; All Rights Reserved.</span>
<span class='float-right'><a href="/eula">End User License Agreement</a></span>
<span class='float-right'>&nbsp;|&nbsp;</span>
<span class='float-right'><a href="/docs">API Docs</a></span>
</footer>

</div>
</body>
</html>

0

Multiple AZ support for vsphere

The multiple AZ's requests for configuring the Ops Dir is failing, as the order in which the request parameters being sent to the server is wrong, and hence server sends the 400 error.

The order of the request should be

availability_zones[availability_zones][][resource_pool]:AZ1_RP
availability_zones[availability_zones][][name]:AZ1
availability_zones[availability_zones][][cluster]:PCF_CLUSTER_1
availability_zones[availability_zones][][guid]:
availability_zones[availability_zones][][resource_pool]:AZ2_RP
availability_zones[availability_zones][][name]:AZ2
availability_zones[availability_zones][][cluster]:PCF_CLUSTER_1
availability_zones[availability_zones][][guid]:
availability_zones[availability_zones][][resource_pool]:AZ3_RP
availability_zones[availability_zones][][name]:AZ3
availability_zones[availability_zones][][cluster]:PCF_CLUSTER_2
availability_zones[availability_zones][][guid]:

and whats being sent is

availability_zones[availability_zones][][resource_pool]:AZ1_RP
availability_zones[availability_zones][][resource_pool]:AZ2_RP
availability_zones[availability_zones][][resource_pool]:AZ3_RP
availability_zones[availability_zones][][name]:AZ1
availability_zones[availability_zones][][name]:AZ2
availability_zones[availability_zones][][name]:AZ3
availability_zones[availability_zones][][cluster]:PCF_CLUSTER_1
availability_zones[availability_zones][][cluster]:PCF_CLUSTER_1
availability_zones[availability_zones][][cluster]:PCF_CLUSTER_2

so the order in which the request is being sent is incorrect

Make --password optional or at least do not require to enter in shell

Hey *

This is a feature request.

If I see this correctly, currently it is required to enter the --password flag for authenticated actions every time om is called in plaintext during the call.

Could you consider to support one of multiple variants of:

Allow setting the password using an env variable like OM_PASSWORD
Allow setting login credentials in a file like ~/.om/credentials -> an option om login would be cool which could write the file ;-)
If --password is set, but no password entered, ask for it and do not print the output. eg. the mysql client works like this.

This tool looks like it could ease up my life quite a bit until we have automated the om stuff away, but I really don’t want to spoil the om password in my ~/.bash_history.

cheers

"waiting for response" time should be configurable

When uploading a large tile like ERT our Concourse job logs get flooded with these messages:

33s elapsed, waiting for response from Ops Manager...
34s elapsed, waiting for response from Ops Manager...
35s elapsed, waiting for response from Ops Manager...
36s elapsed, waiting for response from Ops Manager...
37s elapsed, waiting for response from Ops Manager...
38s elapsed, waiting for response from Ops Manager...
39s elapsed, waiting for response from Ops Manager...
40s elapsed, waiting for response from Ops Manager...
41s elapsed, waiting for response from Ops Manager...
42s elapsed, waiting for response from Ops Manager...
43s elapsed, waiting for response from Ops Manager...
44s elapsed, waiting for response from Ops Manager...
45s elapsed, waiting for response from Ops Manager...

Given ERT can take 10 minutes or more to be processed by Ops Mgr, we end up with 600+ lines in our log that don't need to be there. This causes the page to take an unnecessarily long time to load and isn't helpful.

It would be much nicer if we could configure the update interval, or if it at least defaulted to something more sane, like 10 seconds (as Terraform does).

Upgrade Ops Manager OVA in vCenter

It would be nice if this tool could either deploy an OVA to vCenter or (ideally) handle the entire migration from one version to the next (i.e. Ops Manager 1.8.x to Ops Manager 1.9.x) including:

downloading the installation settings
downloading the existing stemcells
shutting down the existing appliance
uploading the ova
uploading the installation settings.
uploading the stemcells

Assume https if no scheme is provided in the target URL

Currently without a scheme in the target URL I get the following:

om -t pcf.strawberry.gcp.core-services.cf-app.com \
  -u admin \
  -p <redacted> \
  upload-stemcell \
  -s ~/Downloads/light-bosh-stemcell-3312.20-google-kvm-ubuntu-trusty-go_agent.tgz
processing stemcell
could not execute "upload-stemcell": failed to get diagnostic report: could not make api request to diagnostic_report endpoint: token could not be retrieved from target url: Post pcf.strawberry.gcp.core-services.cf-app.com/uaa/oauth/token: unsupported protocol scheme ""

It would be much easier to assume https if the scheme was not provided

OM Tool should support JSON file for input to -p and -pn during configure-product

When issueing the configure-product command, you should be able to specify a JSON file, and not just the command-line string. for example:
./om -k -t https://my-ops-man.net -u admin -p supersecretpassword configure-product -n p-mysql -p /tmp/p-mysql-properties.json -pn /tmp/p-mysql-networks.json

configure-bosh can't take in an empty config

om -k -t <target> -u <user> -p <password> configure-bosh --iaas-configuration '{}'

Fails with error Missing template errors/400

Retrieve UAA admin credential / admin client credential

Hi,

Is it possible to retrieve UAA admin credentials and admin client credentials?

export-installation --target vs import-installation --target arguments differ, causing confusion for users of om

When using om to test backup and restore of Ops Manager, we noticed that the export-installation command did not require us to prefix the Ops Man target value with https://, but when running import-installation, we had to prefix the value with https:// in order for the command to work.

It would be nice to have consistency across these commands in order to improve usability. I can craft a PR for this later today.

Export command:

om --target $OPSMAN_HOST \
  --username $OPSMAN_USERNAME \
  --password $OPSMAN_PASS \
  --skip-ssl-validation \
export-installation \
  --output-file opsman-export.zip

Import command:

om --target https://$OPSMAN_HOST \
  --username $OPSMAN_USERNAME \
  --password $OPSMAN_PASS \
  --skip-ssl-validation \
import-installation \
  --installation opsman-export.zip \
  --decryption-passphrase $OPSMAN_DECRYPTION_PASSPHRASE

om import-installation not waiting for uaa to start?

Hi, getting the logs below running import-installation and apply-changes one after another in a Concourse job. I never got this doing the equivalent from a Python script, so I'm assuming there's something om isn't waiting for to call the import finished.

./om -k -t <url> import-installation -dp <pp> -i installation.zip
processing installation
beginning installation import to Ops Manager
 55.15 KB / 55.15 KB [======================================================] 100.00% 1s
3s elapsed, waiting for response from Ops Manager...
finished import
+ ./om -k -t <url> -u <user> -p <p> apply-changes
attempting to apply changes to the targeted Ops Manager
could not execute "apply-changes": installation failed to trigger: could not make api request to installations endpoint: token could not be retrieved from target url: oauth2: cannot fetch token: 502 Bad Gateway
Response: <html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.4.6 (Ubuntu)</center>
</body>
</html>

curl command should have verbose flag

When using om curl, it would be very helpful to have a flag that triggers the curl command to be issued with the -v (verbose) flag.

Allowing the curl request and response to be viewed can help with troubleshooting when the ops manager API responds in an unexpected way.

skipping network configuration during configure-bosh option

I can an only configure iaas and director options.
The other options result in the following error, and are ignored:
skipping network configuration: detected deployed director - cannot modify network

it appears that lines 95-100 are absolute, when it should only be for a specific option, and result in the rest of the options not being test for.

`import-installation` call times out waiting for response from ops manager.

Ops manager seems to succeed importing the installation without import-installation call receiving a response.

10589s elapsed, waiting for response from Ops Manager...
10590s elapsed, waiting for response from Ops Manager...
10591s elapsed, waiting for response from Ops Manager...
10592s elapsed, waiting for response from Ops Manager...
10593s elapsed, waiting for response from Ops Manager...
10594s elapsed, waiting for response from Ops Manager...
10595s elapsed, waiting for response from Ops Manager...
could not execute "import-installation": failed to import installation: could not make api request to installation_asset_collection endpoint: Post https://opsman-target.upgrade-1-8-to-1-9.iet.to.cf-app.com/api/v0/installation_asset_collection: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

on the ops manager side it seems like it took 1hr 50 min to succeed.

Will post better logs as we hit this issue again.

--ignore-warnings flag not defined for apply-changes

Adding the --ignore-warnings flag to the apply-changes command results in; "flag provided but not defined: -ignore-warnings", this flag should flow through to the Operations manager invocation.

om configure-bosh not populating openstack iaas config

I'm running om 0.18.0 with the example config in the docs and I can't get the IaaS fields populated for OpenStack:

IAAS_CONFIGURATION=$(cat <<-EOF
{
  "openstack_authentication_url": "$OS_AUTH_URL",
  "openstack_username": "$OS_USERNAME",
  "openstack_password": "$OS_PASSWORD",
  "openstack_tenant": "$OS_TENANT_NAME",
  "openstack_region": "RegionOne",
  "openstack_security_group": "cloud-foundry",
  "keystone_version": "v2.0",
  "ignore_server_availability_zone": true,
  "ssh_private_key": "super!",
  "key_pair_name": "cool-and-good",
  "disable_dhcp": true,
  "api_ssl_cert": ""
}
EOF
)

OPS_MAN_DOMAIN_NAME="10.81.208.115"
OPS_MAN_UI_USERNAME="me"
OPS_MAN_UI_PASSWORD="changeme"

om --skip-ssl-validation \
--target "https://$OPS_MAN_DOMAIN_NAME" \
--username "$OPS_MAN_UI_USERNAME" \
--password "$OPS_MAN_UI_PASSWORD" \
configure-bosh \
--iaas-configuration "$IAAS_CONFIGURATION"

./scripts/configure-opsman.sh 
configuring iaas specific options for bosh tile
finished configuring bosh tile

`configure-bosh` does not report missing fields

When configuring bosh, if the payload is incomplete for any section, then om configure-bosh completes without error, even though ops manager rejects incomplete payloads.

Example: Configure OpsMan on AWS with following (incomplete) iaas-config:

// iaas-config.json -> example config without ssh-private-key in payload
{
  "access_key_id": "VALID_AWS_KEY",
  "secret_access_key": "VALID_AWS_SECRET_KEY"
  "vpc_id": "vpc-5678329",
  "security_group": "sg-13975328",
  "key_pair_name": "mykey",
  "region": "eu-west-1",
  "encryption": false
}

$ om -t https://opsman.example.com -u user -p pass -k configure-bosh -i "$(cat iaas-config.json)"
# produces => 
configuring iaas specific options for bosh tile
finished configuring bosh tile
# with exit code 0

This might be happening because when Ops Manager does not like the input config, it renders the /infrastructure/iaas_configuration/edit page with status code 200, but reports errors as flash messages. om sees 200 and assumes everything is OK. This however makes it difficult to use om in a script where the outcome of om configure-bosh is useful to determine next steps in the script.

Cannot initiate apply-changes after a failed install

When using om to re-try a failed deployment, it believes an install is already running and does not initiate a new one:

$ om -k -t $OPSMAN_URI -u $OPSMAN_USERNAME -p $OPSMAN_PASSWORD apply-changes
found already running installation...re-attaching

Nothing follows the text above, it just sits there forever until cancelled.

Note: The install was initially started via the opsman GUI, I am not sure if the same behaviour occurs if the failed install was initiated by om.

om --version returns "unknown" when running binary built from source

Pulling this repository, running go build ., then invoking the compiled binary via ./om --version returns unknown, rather than the expected version.

export-installation returning unexpected response

export-installation with opsman 1.11.3.0 is returning unexpected response

om-linux --target https://ops-man.net --skip-ssl-validation --username user --password 'PW' --request-timeout 6000 export-installation --output-file /tmp/build/0f36ad4e/pcf-pipelines/tasks/export-opsmgr-settings/opsmgr-settings/installation.zip
exporting installation
30m1s elapsed, waiting for response from Ops Manager...
could not execute "export-installation": failed to export installation: request failed: unexpected response

real    30m1.270s
user    0m39.648s
sys     1m44.332s

Can export from opsman gui successfully without issue.

om retry request to ops manager

was wondering if there is any plan to add retry attempts/interval type of flags to om.

scenario i am looking to handle is,
given a ops manager has just been spun-up/restarted
when uaa is not yet started or
ops manager service is not yet started or
ops manager vm-instance is not yet booted
then a call to ops manager via om should retry N number of times at an interval of Y
where N and Y are flags to om

my real world implementation of this scenario is, i am running a pipeline which upgrades opsmanager. this is a process of, spin down opsMan VM, deploy new opsMan VM, wait until it is completely started (uaa and ops manager service) and then run a import settings against the api.

i would like a way to poll the state of ops manager or, retry my request until successful within given time or counter contstraints.

let me know your thoughts on this, if it would be better to implement a API status endpoint (ops man team) or have the om tool handle this type of scenario.

Thanks.

Availability Zone configuration needs to be optional for IaaS that don't support AZ's

For Azure where OpsManager doesn't support an availability_zone edit page the current OM fails with 500 response code trying to fetch AZ guids to be used for configuration of networks subnet and network assignments. This guid should default to null-az

Error for configure-bosh on aws

opsmgr version:1.10.9
seems like opsman's problem, when I execute the om with the params separately like:

1.om --target https://x.x.x.x --skip-ssl-validation --username test --password 'test' configure-bosh --Iaas-configuration '{ data
}', It response "configuring Iaas specific options for Bosh tile
finished configuring Bosh tile", sounds like success, but opsman didn't save the params,

2.om --target https://x.x.x.x --skip-ssl-validation --username test --password 'test' configure-bosh
--Iaas-configuration --director-configuration --az-configuration, it response
"Configuring Iaas specific options for Bosh tile
configuring director options for Bosh tile
configuring availability zones for Bosh tile
could not execute "configure-bosh": could not fetch form: could not find the form authenticity token"

3.when I use the "configure-director" pipelines shows params from "pcf-pipelines" fill in the opsman manually, everything is ok.

so maybe the new version of opsmgr change itself's api response or the om's problem??

delete-installation infinite loop

it appears when calling delete-installation it loops through all the installation log endpoints. in the event it hits an install that was orphaned in the "RUNNING" state for whatever reason, when attempting to fetch the logs for that install, it seems like an infinite loop occurs, for example:

X.X.X.X - opsman [07/Apr/2017:04:24:51 +0000] "POST /uaa/oauth/token HTTP/1.1" 200 2354 "-" "Go-http-client/1.1" X.X.X.X - - [07/Apr/2017:04:24:52 +0000] "GET /api/v0/installations/155 HTTP/1.1" 200 31 "-" "Go-http-client/1.1"

if you try to access the installation log of 155 via the ops manager UI, i.e.: https://pcf.host.com/installation_logs/155 you get redirected to /install then redirected back to the dashboard and the error message "Install is not in progress" appears and the loop to obtain those logs continues and the delete-installation process does not complete.

i ran into this on OpsManager v1.8.8.0 but not sure if it affects other versions. we are currently trying to move off the opsman GEM for rebuilding envs so this is a bit of a blocker for us

i am using the latest 0.21.0 version of "om"

configure-bosh does not set director config info.

When configuring the --director-config options with the configure-bosh command, I get a message it's done, but no changes are observed.
Here is the command I run:

echo "Try Director Config"
  ./${CMD_PATH} --skip-ssl-validation --target "${OPSMAN_URI}" \
   --username "${OPSMAN_USERNAME}" --password "${OPSMAN_PASSWORD}" configure-bosh \
   --director-configuration "${D_PROPERTIES}"

Here is the output I get:

Try Director Config
configuring director options for bosh tile
finished configuring bosh tile

No changes are made in the Director Config pane of the Ops Manager Director tile.
This is prior to initial Apply Changes (i.e. fresh install)
All of the other configure-bosh sub-commands work.

[Feature request] Allow responses to be JSON formatted

/cc @henderjm @jamiemonserrate

Hello,
Thanks for building om. We primarily use om in an automated fashion on the services-pipeline team. We would like om to provide the ability to format responses in a machine parseable format, such as JSON.

Currently we have to parse om responses using a mixture of grep/cut/awk etc. For example the response of:

om --target "https://example.com/" available-products

+------+---------+
| NAME | VERSION |
+------+---------+
| cf   | 1.11.0  |
+------+---------+

or fallback to using om curl.

We would like a flag, such as --format json to control the output format. The above response could look like:

[
  {
    "name": "cf",
    "version": "1.11.0"
  }
]

Let us know what you think. Thanks.

Unable to pipe output from curl command.

Can you add a flag to suppress the HTTP output from the curl command. This will enable users to pipe the output to a tool for formatting and processing JSON, such as jq.

`om curl` replaces `%x` to `!x(MISSING)` in the output (x can be any char)

to reproduce the bug

in opsman UI, set ERT tile/Custom Branding/Company Name' to Sand%box
download the manifest use om -k -t $OPSMAN_URI -u $OPSMAN_USERNAME -p $OPSMAN_PASSWORD curl -p /api/v0/staged/products/cf-xxxxx/manifest | grep company_name , you will get Sand%!b(MISSING)ox

Fails when trying to delete deployment

When trying to delete a deployment against an Ops manager that has all the deployments deleted or if it is freshly installed, then OM tool fails with an error message saying that it couldn't get an UAA token.

could not execute "delete-installation": failed to delete installation: could not make api request to installation_asset_collection endpoint: token could not be retrieved from target url

connection time outs on "upload-product"

Recently we've been seeing more failures in our deployment pipelines where uploading a ERT tile through om is timing out from a concourse vSphere worker in Toronto to a Ops Manager appliance running in GCP.

We'll see output similiar to this:

==============================================================================================
 Uploading ERT tile to @ https://pcf.bangkok.cf-app.com ...
==============================================================================================
processing product
beginning product upload to Ops Manager
 6.67 GB / 6.67 GB [=============================================] 100.00% 2m12s
1s elapsed, waiting for response from Ops Manager...
2s elapsed, waiting for response from Ops Manager...
...
29s elapsed, waiting for response from Ops Manager...
30s elapsed, waiting for response from Ops Manager...
could not execute "upload-product": failed to upload product: could not make api request to available_products endpoint: Post https://pcf.bangkok.cf-app.com/api/v0/available_products: read tcp 10.254.0.10:52644->35.188.100.50:443: read: connection reset by peer

From my observation of this phenomena, the Ops Manager appliance is online and available during this period. Manually "om curling" that /api/v0/available_products succeeds as well. We've tried adding retry logic around this step but we'll often see it fail similarly three times in a row.

Tailing the /tmp/logs/production.log log file on the ops manager during this process shows no activity.

We've taken to manually uploading the ERT tile through the Ops Manager UI in these cases, which will work on first attempt.

I'm creating this issue to record our findings and will reach out to your team in Slack the next time we encounter the issue and have a failure to analyze.

configure-bosh on openstack properties

Hello, I don't see a way to get the valid field names for configure-bosh on openstack. The names in the example document don line up with the return from /api/v0/staged/director/properties. Here is the return from a v1.10.7 opsman instance running on openstack:

{
  "iaas_configuration": {
    "identity_endpoint": null,
    "username": null,
    "password": null,
    "tenant": null,
    "security_group": null,
    "key_pair_name": null,
    "ssh_private_key": null,
    "region": null,
    "ignore_server_availability_zone": false,
    "disable_dhcp": false
  },
  "director_configuration": {
    "ntp_servers_string": "",
    "metrics_ip": null,
    "resurrector_enabled": false,
    "max_threads": null,
    "database_type": "internal",
    "blobstore_type": "local"
  },
  "security_configuration": {
    "trusted_certificates": null,
    "generate_vm_passwords": true
  }
}

Also when I try and load the iaas settings in the cli says the config was updated successfully but I don't see the staged changes in either the UI or via the api call above.

dial tcp: i/o timeout

The opsmanager host is unavailable for a few second to 1-2 minutes on random occasions. We blame it on "the cloud" right now because there's really nothing pointing to any other problems. We have that problem since we started using OM, at its very initial release.

Our pcf installation pipelines are often failing because OM isn't resilient enough in those situations.

Would it be possible to add an internal retry on those errors? We're working around the problem for apply-changes, where it is very likely to happen because of the long duratinn of the connection but we don't want to generalize that code to all OM usages: https://github.com/pivotal-cf/pcf-a1/blob/terraform2/tasks/scripts/apply_changes.sh

Thanks

Pierre

+ om -k -t https://pcf.dev-1-9-azure-clean.iet.to.cf-app.com -u admin -p jejEebRok9 configure-product --product-name p-rabbitmq --product-properties '{
  ".rabbitmq-server.server_admin_credentials": {
    "type": "simple_credentials",
    "value": {
      "identity": "rabbitAdmin",
      "password": "rabbitPassword"
    }
  }
}' --product-resources '{
  "rabbitmq-server": {
    "internet_connected": false
  },
  "rabbitmq-haproxy": {
    "internet_connected": false
  },
  "rabbitmq-broker": {
    "internet_connected": false
  },
  "broker-registrar": {
    "internet_connected": false
  },
  "broker-deregistrar": {
    "internet_connected": false
  }
}'
configuring product...
setting properties
finished setting properties
applying resource configuration for the following jobs:
	broker-deregistrar
	broker-registrar
	rabbitmq-broker
could not execute "configure-product": could not fetch existing job configuration: could not make api request to resource_config endpoint: token could not be retrieved from target url: Post https://pcf.dev-1-9-azure-clean.iet.to.cf-app.com/uaa/oauth/token: dial tcp: i/o timeout

Feature Request: add 'deploy-products' flag to apply-changes command

Would be great to be able to pass in valid values for the deploy_products value when triggering an install. Valid values appear to be 'all' or 'none' according to the API docs: http://opsman-dev-api-docs.cfapps.io/#triggering-an-install-process

OM tool does not work with SAML integrated Ops Manager

Right now OM tool takes user name, password, need to be able to use it with uaac client name/secret.
om-alpine -t https://$OPSMAN_HOST -k -u "$OPSMAN_USER" -p "$OPSMAN_PASSWORD" upload-stemcell --stemcell $file