Skip to content

Update VCH inspect API to output TLS friendly docker host and admin portal address#7533

Merged
AngieCris merged 11 commits intovmware:masterfrom
AngieCris:vic/7321
Mar 23, 2018
Merged

Update VCH inspect API to output TLS friendly docker host and admin portal address#7533
AngieCris merged 11 commits intovmware:masterfrom
AngieCris:vic/7321

Conversation

@AngieCris
Copy link
Contributor

[specific ci=6-09-Inspect]

Fixes #7321

  1. Update VCH inspect API to output TLS friendly docker host and admin portal address
  2. Include --compute-resource for vic-machine commands in robot tests

API related tests are going to be in PR: #7290
(#7290 is blocked by this PR)

@codecov-io
Copy link

codecov-io commented Mar 16, 2018

Codecov Report

Merging #7533 into master will decrease coverage by 0.09%.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #7533     +/-   ##
=========================================
- Coverage   31.51%   31.42%   -0.1%     
=========================================
  Files         281      281             
  Lines       42020    42042     +22     
=========================================
- Hits        13244    13210     -34     
- Misses      27616    27671     +55     
- Partials     1160     1161      +1
Impacted Files Coverage Δ
lib/install/management/inspect.go 12.65% <0%> (-0.24%) ⬇️
...piservers/service/restapi/handlers/vch_list_get.go 0% <0%> (ø) ⬆️
lib/apiservers/service/restapi/handlers/common.go 0% <0%> (ø) ⬆️
lib/apiservers/service/restapi/handlers/vch_get.go 0% <0%> (ø) ⬆️
lib/portlayer/attach/communication/lazy.go 68.18% <0%> (-22.73%) ⬇️
lib/portlayer/attach/communication/connector.go 54.2% <0%> (-7.48%) ⬇️
lib/dns/cache.go 89.85% <0%> (-4.35%) ⬇️
lib/portlayer/attach/communication/interactor.go 24.08% <0%> (-2.92%) ⬇️
pkg/logmgr/logmgr.go 67.36% <0%> (+1.38%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 74f673f...37ff7fe. Read the comment docs.

model.Runtime.DockerHost, model.Runtime.AdminPortal = getAddresses(vchConfig)
model.Runtime.DockerHost, model.Runtime.AdminPortal, err = getAddresses(executor, vchConfig)
if err != nil {
op.Warn("No client IP assigned.")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about logging err instead of "No client IP assigned." (In this case, it's basically the same message, but if we ever add another error to getAddresses, this might be misleading.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! fixed

dockerHost, adminPortal = getAddresses(vchConfig)
dockerHost, adminPortal, err = getAddresses(executor, vchConfig)
if err != nil {
op.Warnf("No client IP address assigned for VCH %s", id)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above; we should base the log message on err instead.


dockerHost := ""
if !vchConfig.HostCertificate.IsNil() {
dockerHost = fmt.Sprintf("%s:%d", hostIP, opts.DefaultTLSHTTPPort)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the pattern from the old code, where we set a dockerPort based on vchConfig.HostCertificate.IsNil() and then have a single dockerHost = fmt.Sprintf("%s:%d", publicIP, dockerPort) is a little cleaner.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 fixed

Copy link
Contributor

@mhagen-vmware mhagen-vmware left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, probably appropriate to add a negative test that doesn't include the resource pool now? I assume it throws an error now?

@AngieCris
Copy link
Contributor Author

@mhagen-vmware This change is to update API to behave the same as CLI, the API related tests will be added later in #7290, including both positive and negative tests.
The change on CLI is just some refactoring, the behavior stays the same, so I didn't touch the 6-09-Inspect test suite. But running 6-09 on CI now throws an error if --resource-pool is not given, so I added that to the test suite.

Copy link
Member

@zjs zjs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But running 6-09 on CI now throws an error if --resource-pool is not given, so I added that to the test suite.

Is this a bug? It doesn't seem like resource pool should be required for inspect.

hostIP = executor.GetTLSFriendlyHostIP(clientIP, cert, vchConfig.CertificateAuthorities)
}

var dockerPort string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just define dockerPort as an integer? That should avoid the need to fmt.Sprintf("%d", below.

Copy link
Contributor Author

@AngieCris AngieCris Mar 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to mimic CLI implementation:

	if !conf.HostCertificate.IsNil() {
		d.DockerPort = fmt.Sprintf("%d", opts.DefaultTLSHTTPPort)
	} else {
		d.DockerPort = fmt.Sprintf("%d", opts.DefaultHTTPPort)
	}

CLI is setting the d.DockerPort field of type string in executor, but in API we're not using the docker IP/port from executor fields.
Fixing it now.

@AngieCris
Copy link
Contributor Author

@zjs mistyped sorry...it's --compute-resource option for vic-machine inspect.
Yes it's required for all vic-machine operations under VC.
We didn't need it on CI because we ran on ESX earlier.

@zjs
Copy link
Member

zjs commented Mar 21, 2018

Our documentation doesn't suggest that --compute-resource is required for VC. Is this requirement a result of the way we've configured our CI systems, or could this be a change in behavior?

@AngieCris
Copy link
Contributor Author

AngieCris commented Mar 21, 2018

@zjs From the documentation:

You specify the --compute-resource option in the following circumstances:
A vCenter Server instance includes multiple instances of standalone hosts or clusters, or a mixture of standalone hosts and clusters.
You want to deploy the VCH to a specific resource pool in your environment.

Also here:

If you specify the id option in vic-machine commands, you do not need to specify the compute-resource option.

When I was testing against my nimbus VC, I have to provide --compute-resource because I have multiple clusters on my VC. I'm not sure about whether our CI infra contains multiple pools/clusters/mixture of hosts and clusters. If CI only has one cluster/pool, --compute-resource parameter is probably not required. @mhagen-vmware
I guess it's the best for us to include --compute-resource anyway, so that the tests would work under different configurations.

@AngieCris AngieCris merged commit 5368c6d into vmware:master Mar 23, 2018
@AngieCris AngieCris deleted the vic/7321 branch March 23, 2018 18:23
rajanashok pushed a commit to rajanashok/vic that referenced this pull request Apr 26, 2018
…ortal address (vmware#7533)

1. Update VCH inspect API to output TLS friendly docker host and admin portal address
2. Include --compute-resource for vic-machine commands in robot tests
rajanashok pushed a commit to rajanashok/vic that referenced this pull request Apr 26, 2018
…ortal address (vmware#7533)

1. Update VCH inspect API to output TLS friendly docker host and admin portal address
2. Include --compute-resource for vic-machine commands in robot tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants