gomorpheus/morpheus-cli

CLI Utility for Interfacing with the Morpheus API

morpheus-cli's Issues

Apparent issue with 'morpheus network-groups update # --group-access #,#,#,# command

If I run the 'networks update 1 --group-access 1,2' sort of command, permissions are set properly

if I run 'network-groups update 1 --group-access 1,2' sort of command, all I get back is "* data: No data provided"

Deployments can't be added

Hi,

Either way I am using it wrong or there is an issue with adding deployments.

When I add one, for example 'testadd'.

$ morpheus deployments add
Name: testadd
Description (optional): testadd description
Added deployment testadd

Deployment Details
==================

         ID: 10
       Name: testadd
Description: testadd description
   Versions:
    Created: 10/29/20 09:10 AM
    Updated: 10/29/20 09:10 AM

Versions
---------------------

No versions found.

Everything works.

Listing sub versions also works (no versions are added yet to my test)

$ morpheus deployments list-versions testadd

Deployment Versions | testadd
==================

No versions found.

However when I start adding a version, I get an internal 500 server

$ morpheus deployments add-version testadd 1
Error Communicating with the remote appliance. 500 Internal Server Error

Invoking the interactive cli also doesn't do much

$ morpheus deployments add-version testadd
Version: 1

Error Communicating with the remote appliance. 500 Internal Server Error

And now a bit with verbose info

$ morpheus deployments add-version testadd -V
establishing connection to remote [demo] https://10.5.242.1
GET "https://10.5.242.1/api/deployments?name=testadd", "Accept"=>"*/*", "Accept-Encoding"=>"gzip, deflate", "Authorization"=>"Bearer ************", "User-Agent"=>"morpheus-cli 5.0.2 (linux-gnu x86_64) ruby/2.5.1p57"
# => 200 OK | application/json 242 bytes
Version: 1
GET "https://10.5.242.1/api/options/deployTypes?userVersion=1", "Accept"=>"*/*", "Accept-Encoding"=>"gzip, deflate", "Authorization"=>"Bearer ************", "User-Agent"=>"morpheus-cli 5.0.2 (linux-gnu x86_64) ruby/2.5.1p57"
# => 500 InternalServerError | application/json 62 bytes
Error Communicating with the remote appliance. (HTTP 500)
REQUEST
GET "https://10.5.242.1/api/options/deployTypes?userVersion=1"

RESPONSE
HTTP 500  |  62.00 B
{
  "success": false,
  "msg": "Looks like the server threw a gasket"
}

Am I missing some arguments? Because if I am not mistaken just adding a version isn't the complete story.

However when I try

pipeline:~$ morpheus deployments add-version testadd 1.0.5 fetch http://test/deploy/file.war
morpheus: too many arguments, expected 0-2 and got 4: testadd, 1.0.5, fetch, http://test/deploy/file.war

It confirms me that there should only be two parameters.

I am running against CLI: version 5.0.2

Kind regards,

the 'roles update-catalog-item-type-access' appears to be broken since 6.0.2 up to 6.2.0

We have a script that sets catalog item access but from version 6.0.2 that I tested and 6.2.0, the command fails with:

Catalog Item Type not found: '1'

But a

morpheus> catalog list-types

Morpheus Catalog Types

ID	NAME
1	Upgrade VMware Tools

Show that an ID of 1 exists. It doesn't matter if I try by name or ID, I get the same result. This issue is appearing in two difference instances and comes up for every catalog item we have in the loop of permissions to add.

Adding an App Blueprint

Hi there,

I am trying to add a Terraform file as an App Blueprint on Morpheus via CLI. An error was thrown: error validating terraform template

morpheus> blueprints add
Name: test
Type [Morpheus] ['?' for options]: ?
  * Type [-O type=] - 

Type Options
============
 * ARM template [arm]
 * Morpheus [morpheus]
 * Terraform [terraform]
Type [Morpheus] ['?' for options]: Terraform
Description (optional): test
Category (optional): test
error validating terraform template

Could you please point out what not correct is?

Thank you and best regards,
Jarunan

Attempt to make image smaller using docker-slim

This cli tool is on a fairly large docker image. It would be a good thing to make the image smaller. I have been looking at a tool called "docker-slim" which takes the image and only includes the tools needed to run by inspecting the process and what files it uses. I am hoping that maybe you have a "test" script we can run that would put morpheus-cli through its paces, or can at least recommend a list of commands to test everything as per slimtoolkit/slim#101 and https://github.com/docker-slim/examples/tree/master/3rdparty/morpheus-cli

Thanks in advance,
Tommy

Issue around filters and the library-instance-types

When trying to do 'morpheus library-instance-types list -Q 'featured=true' it just dumps all of the Library Instance Types vs filtering the results.

When you do the --csv flag, you can see the output includes a "featured" and then a true/false value.

If you do the --dry-run you can see the morpheus-cli is reporting it's querying the following API location:
REQUEST
GET $serverUrl/api/library?featured=True

If you look at the Morpheus API documentation, that location isn't really even listed as an option, and instead you can see

GET $serverUrl/api/library/instance-types

The same is true for a 'get' of the library-instance-type where the cli --dry-run lists:
REQUEST
GET $serverUrl/api/library/99

but the API shows
GET $serverUrl/api/library/instance-types/:id

I wasn't sure if that's what's preventing the "morpheus library-instance-types list -Q 'featured=true'" from working or not

Does not appear to support SSO based users

Based on the API documentation, the only way to retrieve an access token is by username and password. We've enabled morpheus with a SAML IDP. It does not look like SSO based access is supported via API and CLI:

• http://bertramdev.github.io/morpheus-apidoc/#get-access-token

Is there a way to get an access token for SSO users?

Docker image: Mismatch between container label and CLI version

As of today, the container image labeled 4.1.7 contains an older version of the Morpheus CLI:

$ docker run --rm morpheusdata/morpheus-cli:4.1.7 version
Unable to find image 'morpheusdata/morpheus-cli:4.1.7' locally
4.1.7: Pulling from morpheusdata/morpheus-cli
f49cf87b52c1: Pull complete 
7b491c575b06: Pull complete 
b313b08bab3b: Pull complete 
51d6678c3f0e: Pull complete 
b7e583189d20: Pull complete 
271f9c77b4b7: Pull complete 
2d34f16f9611: Pull complete 
3f4219620fb1: Pull complete 
Digest: sha256:ff1a2ab68a371ba7a1f4423dd6e2b66bbb458e5402b1f864a108dbbc6a206061
Status: Downloaded newer image for morpheusdata/morpheus-cli:4.1.7
   __  ___              __              
  /  |/  /__  _______  / /  ___ __ _____
 / /|_/ / _ \/ __/ _ \/ _ \/ -_) // (_-<
/_/  /_/\___/_/ / .__/_//_/\__/\_,_/___/
****************************************
  Client Version: 3.6.37
$ 

instances add Skip Agent flag confusing/inconsistent

I was working on a unit test and was going to use the CLI vs direct python to API to save myself some time, but I noticed the
Skip Agent Install (yes/no): ?

• Skip Agent Install [-O config.noAgent=] -

Option in the CLI is confusing/broken in terms of the -O config.noAgent=

I was using -O config.noAgent=yes to attempt to skip the install as our dev environment isn't accessible from the client VM networks, so we have to skip agent install or builds fail. My build failed with "unable to install agent"

I did some testing with -O config.noAgent=no and that didn't work either, then I realized the cli json output uses: "noAgent": "off/on", so I tested with -O config.noAgent=on and that worked to successfully skip the agent install.

It may be helpful to match the yes/no to on/off in the ? part for Skip Agent since it's presenting the -O config.noAgent= under "yes"/"no" which don't in fact work with the -O config.noAgent= option

Morpheus CLI connectivity error

Ever since the upgrade the Morpheus appliance to 5.2.2 we are not able to connect to the remote host:

Error Communicating with the remote appliance. (HTTP 500)

RESPONSE
HTTP 500 | 49.00 B
{
"error": "server_error",
"error_description": null

hosts make-managed --scrub doesn't work as advertised

+ morpheus hosts make-managed 536229 --sshUsername username --sshPassword Idontcare --serverOs 91 -q --scrub -d
DRY RUN

REQUEST
PUT https://morpheus.domain.com//api/servers/536229/install-agent

JSON
{
  "server": {
    "serverOs": {
      "id": "91"
    },
    "sshUsername": "username",
    "sshPassword": "Idontcare"
  }
}

It should "scrub" the password from the dryrun output.

Issue with hosts make-managed and the --install-agent off flag

I'm not sure if this is the expected behavior but the workflow to me suggest this is not:

I'm running the following command:

hosts make-managed test-win2019 --install-agent off --group umg/testing.example --dry-run

This command is prompting for the following:

SSH Username:
SSH Username:
SSH Username: f
SSH Password (optional):
OS Type (optional) ['?' for options]:

This is requiring an SSH username which I believe it should only prompt for if I'm telling it to install the agent (since it would need access into the VM to install this but otherwise no access is required).

The dry-run output shows:

REQUEST
PUT https://test.example.morpheus.install/api/servers/###/install-agent

JSON
{
"server": {
"sshUsername": "f",
"sshPassword": "",
"provisionSiteId": #
},
"installAgent": false
}

What I'm trying to do is script out an semi-automated "convert to manage by reading in config values from a file" to suck in vCenter VMs that aren't currently managed by Morpheus so they are now managed and show within Morpheus properly. It seems the '--install-agent off' isn't suppose to prompt then for the SSH Username and I'm not sure why it's pinging the /install-agent API at that point?

Thanks!

Newer versions appear to have removed the "custom" option for some global/default role permissions

I recently updated morpheus-cli to 5.5.3.1 via the 'gem update' and noticed it broke one of our on-boarding scripts.

The issue is the "custom" permission option appears to have been removed from 3 key "global/default" role permissions we use:

Usage: morpheus roles update-default-group-access [role] [access]
No longer appears to accept the access of "custom" that the WebUI allows, and instead lists the access levels of "full, read, or none"

Usage: morpheus roles update-default-catalog-item-type-access [role] [access]
Also no longer appears to accept "custom" and requires "Full or none"

Lastly is Usage: morpheus roles update-default-instance-type-access [role] [access]
This also appears to not like "custom" anymore and instead requires "full or none"

The issue is with those set it appears the individual items under those global roles apparently don't get set as they should and like they use to, with the top level access setting overwriting and preventing adjustment of any sub fields.
The behavior mimics the WebUI, where setting the default to "None" sets all things to none and doens't allow individual item adjustments. Same for the other Read or Full settings, when we need specific custom adjustments of items under say "groups", "instance types", etc.

Can the "custom" flags be added back in as this appears to make the CLI deviate heavily from the role permissions settings capabilities found within the WebUI.

Thanks!

Issue matching group names (with special characters?)

We have some role and group names that match, along the format of:

umg/up.5i-some-values-here

When we use to run

morpheus roles update-group-access umg/up.5i-some-values-here umg/up.5i-some-values-here full

morpheus-cli worked fine and everyone was happy

Now when we run:
morpheus roles update-group-access umg/up.5i-some-values-here umg/up.5i-some-values-here full -d

We get:
DRY RUN
Group not found by name

But if I do:
groups list --wrap --all-fields --search 5i-some

I get:

Morpheus Groups | phrase: 5i-some

ID	NAME	LOCATION	CLOUD_COUNT	SERVER_COUNT
4	umg/up.5i-some-values-here	5i	X	XX

We recently updated to morpheus-cli 5.3.0.3 from 4.16 I think It was, and morpheus to 5.2.5 from the latest of the 4.2 branch

I haven't figured out a workaround yet by escaping the group name in morpheus-cli or quoting the name or anything

Extended / modifying '--group-access-all [on|off]', String, "Toggle Access for all groups."

The '--group-access-all [on|off]' command is a bit ambiguous in action if you don't explicitly understand what is stated when you do say
networks --help

The issue stems from the fact by default any VMware network picked up by Morpheus has the check box of "All" enabled.

The message for --group-access-all of "Toggle Access for all groups" can be misread as "Toggle Access for all group" (which has actually happened), causing all permissions for that network to be removed (not just the "All" item that is reflected in the WebUI and can be selected independently of the other groups).

A suggestion/request of adjusting the help text to say "Toggle Access for all groups. Clears all current groups if set to 'off'" would be a great enhancement.
It may also be worth adding a way to remove just the "All" item from the networks list without clearing the other enabled groups, and without having to know to read in the current allowed, adjust the '--group-access-all off', and then re-enable permissions for the groups that had it prior that you want to still maintain them.

Apparent issue around -f fields and --csv / --json in relation to role and group listings in 5.4.5.1

Client Version: 5.4.5.1

I've noticed an issue around the -f fields flag when using --csv or --json where the name field will return 'null' instead of the actual value.

When you do a 'morpheus roles list -f name,description' things list fine, showing two columns, one for name and one for description with the values for each row displaying properly. The issue appears when you add --csv or --json, the "name" values all become "null"

name	description
Standard User	Should mirror permissions in prod for most users

becomes:
morpheus> roles list -f name,description --csv
name,description
null,Should mirror permissions in prod for most users

or

morpheus> roles list -f name,description --json
{
"roles": [
{
"name": null,
"description": "Should mirror permissions in prod for most users"
},