-
Notifications
You must be signed in to change notification settings - Fork 175
vic-machine configure --ops-grant-perms doesn't create roles or assign permissions #7725
Description
Note: this bug is on master
Details:
A VCH created with
bin/vic-machine-linux create --target <> --user administrator@vsphere.local --password <> --name VCH-1 --compute-resource cls3 --public-network=vm-network --bridge-network=bridge --image-store=vsanDatastore --volume-store=vsanDatastore/test:default --force --no-tlsverify --debug 1
and then configured with
bin/vic-machine-linux configure --target <> --user administrator@vsphere.local --password <> --name VCH-1 --compute-resource cls3 --force --no-tlsverify --debug 1 --ops-user=vic-ops@vsphere.local --ops-password=Admin\!23 --ops-grant-perms --tls-cert-path=VCH-1-x --thumbprint=<>
fails to initialize. Note - user vic-ops@vsphere.local was created before the configure operation.
vic-machine configure logs:
INFO[0014] Setting VM configuration
INFO[0016] Waiting for IP information
INFO[0017] Waiting for major appliance components to launch
DEBU[0047] properties: [config.extraConfig summary.runtime.connectionState]
DEBU[0047] State of components:
DEBU[0047] "docker-personality": "started successfully"
DEBU[0047] "port-layer": "started successfully"
DEBU[0047] "vicadmin": "started successfully"
INFO[0047] Obtained IP address for client interface: "10.160.144.103"
INFO[0047] Checking VCH connectivity with vSphere target
INFO[0048] vSphere API Test: https://10.160.133.89 vSphere API target responds as expected
DEBU[0048] Docker API endpoint: https://10.160.144.103:2376/info
DEBU[0048] connection refused
DEBU[0049] Components not yet initialized, retrying
DEBU[0049] connection refused
DEBU[0050] Components not yet initialized, retrying
DEBU[0050] connection refused
DEBU[0051] Components not yet initialized, retrying
DEBU[0051] connection refused
... (this repeats until a timeout)
port-layer logs:
time="2018-04-12T22:07:35Z" level=info msg="Launching portlayer server pprof server on 127.0.0.1:6063"
time="2018-04-12T22:07:35Z" level=info msg="{Formatter:0xc420875af0 Level:debug Syslog:<nil>}"
Apr 12 2018 22:07:35.788Z DEBUG log cfg: {Formatter:0xc420875af0 Level:debug Syslog:<nil>}
Apr 12 2018 22:07:35.788Z DEBUG 480.1: [OperationFromContext] [vic/pkg/vsphere/session.(*Session).Create:152]
Apr 12 2018 22:07:35.789Z DEBUG secret key decoded from guestinfo.ovfEnv
Apr 12 2018 22:07:35.789Z DEBUG GuestInfoSource: key: guestinfo.vice./connect/target, value: "https://10.160.133.89", error: %!s(<nil>)
Apr 12 2018 22:07:35.789Z DEBUG GuestInfoSource: key: guestinfo.vice./connect/username, value: "vic-ops@vsphere.local", error: %!s(<nil>)
Apr 12 2018 22:07:35.790Z DEBUG GuestInfoSource: key: guestinfo.vice./connect/token@secret, value: "eIh81DNY77EzrdXFGdsZnAVSqHg33ptpaQdGX7nr1hhy/RROz8+hEnfqrVM0PRlr", error: %!s(<nil>)
Apr 12 2018 22:07:35.790Z DEBUG GuestInfoSource: key: guestinfo.vice./connect/target_thumbprint, value: "DD:29:71:78:A8:C2:B4:07:CB:A8:8F:43:D0:C6:58:B6:44:B6:F7:87", error: %!s(<nil>)
Apr 12 2018 22:07:35.791Z DEBUG GuestInfoSource: key: guestinfo.vice./connect/keepalive, value: "0", error: %!s(<nil>)
Apr 12 2018 22:07:35.791Z DEBUG op=480.1: Creating VMOMI session with thumbprint DD:29:71:78:A8:C2:B4:07:CB:A8:8F:43:D0:C6:58:B6:44:B6:F7:87
Apr 12 2018 22:07:36.115Z DEBUG Session Environment Info:
Apr 12 2018 22:07:36.115Z DEBUG op=480.1: vSphere resource cache populating...
Apr 12 2018 22:07:36.315Z DEBUG op=480.1: Cached dc: ha-datacenter
Apr 12 2018 22:07:36.612Z DEBUG op=480.1: Cached folders: ha-datacenter
Apr 12 2018 22:07:36.615Z DEBUG op=480.1: Error count populating vSphere cache: (4)
Apr 12 2018 22:07:36.622Z FATAL configure_port_layer ERROR: Failure finding cluster (/ha-datacenter/host/cls3): compute resource '/ha-datacenter/host/cls3' not found
Failure finding ds (vsanDatastore): datastore 'vsanDatastore' not found
Failure finding host (): no default host found
Failure finding pool (/ha-datacenter/host/cls3/Resources): resource pool '/ha-datacenter/host/cls3/Resources' not found
... (this repeats as the port-layer re-attempts to initialize)
The roles and permissions that are typically created and assigned with --ops-grant-perms are not present in vCenter.
Initial analysis:
From an initial investigation, this is because the logic to create roles and assign permissions is called after starting the VCH (d.update starts the VCH VM):
vic/lib/install/management/configure.go
Lines 112 to 121 in 359ba90
| err = d.update(conf, settings, isConfigureOp) | |
| // If successful try to grant permissions to the ops-user | |
| if err == nil && conf.ShouldGrantPerms() { | |
| err = opsuser.GrantOpsUserPerms(d.op, d.session.Vim25(), conf) | |
| if err != nil { | |
| // Update error message and fall through to roll back | |
| err = errors.Errorf("Failed to grant permissions to ops-user, failure: %s", err) | |
| } | |
| } |
Compare this to the vic-machine create --ops-grant-perms logic which creates roles/permissions before starting the VCH:
vic/lib/install/management/create.go
Lines 80 to 87 in 359ba90
| if conf.ShouldGrantPerms() { | |
| err = opsuser.GrantOpsUserPerms(d.op, d.session.Vim25(), conf) | |
| if err != nil { | |
| return errors.Errorf("Cannot init ops-user permissions, failure: %s. Exiting...", err) | |
| } | |
| } | |
| return d.startAppliance(conf) |
Acceptance Criteria:
-
vic-machine configure --ops-grant-permsworks, especially in the case mentioned here - the VCH is created without anyops-usersettings - New integration test added to verify the fix
Logs: