Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added upload progress bar tracker for ISO images. #7320

Merged
merged 14 commits into from
Feb 14, 2018
Merged

Added upload progress bar tracker for ISO images. #7320

merged 14 commits into from
Feb 14, 2018

Conversation

vburenin
Copy link
Contributor

@vburenin vburenin commented Feb 13, 2018

Removed concurrent upload since it doesn't make any significant performance imapact.
When I tried to measure performance differene with and without concurrent uppload,
the results were fluctuating in a wide range so not good measurement was possible.

Fixes #7317

INFO[0023] Uploading images for container               
DEBU[0023] Checking if file already exists: 785d835a-3629-cf2c-5146-0200469eb20b/V1.4.0-DEV-0-C089C72-bootstrap.iso 
DEBU[0025] File not found. Nothing to do.               
INFO[0025] Uploading bootstrap.iso as V1.4.0-DEV-0-C089C72-bootstrap.iso 
INFO[0025] Uploading bootstrap.iso. Progress: 0.00%     
INFO[0028] Uploading bootstrap.iso. Progress: 9.31%     
INFO[0031] Uploading bootstrap.iso. Progress: 16.69%    
INFO[0034] Uploading bootstrap.iso. Progress: 19.81%    
INFO[0037] Uploading bootstrap.iso. Progress: 25.06%    
INFO[0040] Uploading bootstrap.iso. Progress: 32.39%    
INFO[0043] Uploading bootstrap.iso. Progress: 41.05%    
INFO[0046] Uploading bootstrap.iso. Progress: 51.65%    
INFO[0049] Uploading bootstrap.iso. Progress: 61.69%    
INFO[0052] Uploading bootstrap.iso. Progress: 66.94%    
INFO[0055] Uploading bootstrap.iso. Progress: 74.76%    
INFO[0058] Uploading bootstrap.iso. Progress: 86.65%    
INFO[0061] Uploading bootstrap.iso. Progress: 98.28%    
INFO[0062] Uploading bootstrap.iso. Progress: 100.00%   
INFO[0062] Uploading of bootstrap.iso has been completed 
DEBU[0062] Checking if file already exists: 785d835a-3629-cf2c-5146-0200469eb20b/V1.4.0-DEV-0-C089C72-appliance.iso 
DEBU[0063] File not found. Nothing to do.               
INFO[0063] Uploading appliance.iso as V1.4.0-DEV-0-C089C72-appliance.iso 
INFO[0063] Uploading appliance.iso. Progress: 0.00%     
INFO[0066] Uploading appliance.iso. Progress: 5.14%     
INFO[0069] Uploading appliance.iso. Progress: 10.35%    
INFO[0072] Uploading appliance.iso. Progress: 15.91%    
INFO[0075] Uploading appliance.iso. Progress: 19.49%    
INFO[0078] Uploading appliance.iso. Progress: 24.56%    
INFO[0081] Uploading appliance.iso. Progress: 30.02%    
INFO[0084] Uploading appliance.iso. Progress: 35.65%    
INFO[0087] Uploading appliance.iso. Progress: 41.02%    
INFO[0091] Uploading appliance.iso. Progress: 45.97%    
INFO[0094] Uploading appliance.iso. Progress: 48.63%    
INFO[0097] Uploading appliance.iso. Progress: 51.82%    
INFO[0100] Uploading appliance.iso. Progress: 57.16%    
INFO[0103] Uploading appliance.iso. Progress: 61.94%    
INFO[0106] Uploading appliance.iso. Progress: 66.53%    
INFO[0109] Uploading appliance.iso. Progress: 71.83%    
INFO[0112] Uploading appliance.iso. Progress: 76.88%    
INFO[0115] Uploading appliance.iso. Progress: 82.41%    
INFO[0118] Uploading appliance.iso. Progress: 88.02%    
INFO[0121] Uploading appliance.iso. Progress: 93.50%    
INFO[0124] Uploading appliance.iso. Progress: 98.99%    
INFO[0126] Uploading appliance.iso. Progress: 100.00%   
INFO[0126] Uploading of appliance.iso has been completed 
INFO[0128] Waiting for IP information   

Removed concurrent upload since it doesn't make any significant performance imapact.
When I tried to measure performance differene with and without concurrent uppload,
the results were fluctuating in a wide range so not good measurement was possible.
"time"

"github.com/vmware/govmomi/object"
"github.com/vmware/vic/lib/progresslog"

Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason for the extra new line here? Looks like this is all from the same pathing for the most part.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed, per the current state of the file there should only be two import groups - standard pkgs and vmware pkgs.

Copy link
Contributor

Choose a reason for hiding this comment

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

Unless vmware/govmomi counts as third-party. I've seen govmomi pkgs included in the same group as vmware/vic pkgs everywhere in our repo though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, there should not be a new line. It seems like an autoimport bug.


// Sink returns a channel that receives current upload progress status.
// Channel has to be closed by the caller.
func (ul *UploadLogger) Sink() chan<- progress.Report {
Copy link
Contributor

Choose a reason for hiding this comment

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

Are there multiple calls to this function per download?

Copy link
Contributor

@matthewavery matthewavery Feb 13, 2018

Choose a reason for hiding this comment

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

Never mind, I missed the range ticker.C :)

Copy link
Contributor

@matthewavery matthewavery left a comment

Choose a reason for hiding this comment

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

Other than the import new line comment, I do not think that I have seen anything else. Looks really good!

)

/*
type Report interface {
Copy link
Contributor

Choose a reason for hiding this comment

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

We should delete dead code unless it's for future reference.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was for a reference, however, it doesn't make sense to keep it there.

assert.Contains(t, logs[last-1], "100.00%")
assert.Contains(t, logs[last], "complete")
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: unneeded whitespace.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unneded.

return ch
}

// Wait is waiting for Sink to complete its work, due to it async nature logging messages may be not sequential.
Copy link
Contributor

Choose a reason for hiding this comment

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

We can refine the func comment as it's a bit unclear:

Wait is waiting for -> Wait waits for

due to it async nature -> due to its async nature

due to its async nature

Not clear on what its applies to - the logging messages or the Sink function?

mu := sync.Mutex{}
ticker := time.NewTicker(ul.interval)

// Print progress every 3
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like we're missing something - every 3 seconds maybe?

return &params
}

// UploadLogger io used to track upload progress to ESXi/VC of a specific file.
Copy link
Contributor

Choose a reason for hiding this comment

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

s/io/is perhaps.

finalMessage = fmt.Sprintf("%s\t\tNote: The VCH will not function without %q...", finalMessage, image)
}
d.op.Error(finalMessage)
return errors.New("Failed to upload iso images successfully.")
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: including successfully in the same sentence as Failed may be confusing - Failed to upload iso images conveys the same intent IMO.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see this string was present before this change - it'd be nice to fix it here.

d.op.Error(err)
uploadFailed = true
// Build retry config
backoffConf := retry.NewBackoffConfig()
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like backoffConfig is the same for each file we're uploading, in which case we should be able to define and set it just once outside the for key, image := range files { loop.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I do not want to touch that piece of code in this PR, it looks like it was changed, but it was basically shifted.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah it can be moved out, there is no reason why it cannot since it is just a config struct to pass to the expoenential backoff ticker. At any rate I do not know if it is critical for this. Should definitely be refactored in the future.

}

if curProgress == 100.0 {
ul.logTo("Uploading of %s has been complete", ul.filename)
Copy link
Contributor

Choose a reason for hiding this comment

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

Uploading of %s has been complete -> Upload of %s is complete

Copy link
Contributor Author

Choose a reason for hiding this comment

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

arguable.

Copy link
Contributor

Choose a reason for hiding this comment

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

Alternatively, we could just s/complete/completed.

d.op.Warnf("Attempted upload a total of %d times without success, Upload process failed.", uploadRetryLimit)
return false
}
d.op.Warnf("failed an attempt to upload isos with err (%s), %d retries remain", err.Error(), retryCount)
Copy link
Contributor

Choose a reason for hiding this comment

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

While this string has been present before this change, it would be a good idea to refine it since we're making changes here anyway. Suggest replacing failed with Failed to maintain consistent casing for log messages (other log messages start with uppercase).

@vburenin vburenin merged commit 50e1761 into vmware:master Feb 14, 2018
sflxn pushed a commit that referenced this pull request Mar 1, 2018
* Dump dmesg if container rootfs blocks or fails mount (#7260)

This is to enable bridging of the guest side state with the virtual hardware if we
see issues such as disks not presenting on a pvscsi controller or a mount operation
hanging.

* updating priority definitions to include features (#7292)

* Change default fellows for gandalf (#7310)

* Avoid exposing test credentials in 12-01-Delete (#7306)

To avoid exposing test credentials, use the established `Run VIC
Machine Delete Command` keyword, which in turn calls a secret keyword.

This changes the behavior of the test slightly:
 - It no longer checks for the absence of "delete failed" in output.
 - It will wait up to 30 seconds for the deletion to succeed.
 - It will clean up cert files at the end of the deletion.

* Bug fix in API delete test: disable volume store cleanup (#7303)

* Remove volume store cleanup before re-installing VIC appliance using existing volume stores
* Cleanup dangling volume stores on test teardown

* Add logging for image upload (#7296)

* Reduce datastore searches during non-vSAN delete operations (#6951)

* Optimize portlayer volume cache rebuild on startup (#7267)

This commit modifies the portlayer volume cache's rebuildCache func to
only process the volumes from the volume store that is currently being
added to the cache. rebuildCache is invoked for every volume store
during portlayer startup.

Before this change, rebuildCache would process volumes from all volume
stores in the cache every time a volume store was added. This led to
unneeded extra computation which could slow down portlayer startup and
overwhelm NFS endpoints if NFS volume stores are being used.

Fixes #6991

* Added local ci testing target to makefile (#7170)

Make testing locally as friction-free as possible by

1. Adding a makefile target 'local-ci-test'
2. Using TARGET_VCH added in VIC 1.3 to use an existing VCH
3. Using a custom script that doesn't utilize drone so that if
   the test fails and craters, we can still access the logs
4. Parameters can come from env vars, arguments, or secrets file

Resolves #7162

* Added upload progress bar tracker for ISO images. (#7320)

* Added upload progress bar tracker for ISO images.

Removed concurrent upload since it doesn't make any significant performance imapact.
When I tried to measure performance differene with and without concurrent uppload,
the results were fluctuating in a wide range so no good measurement was possible.

* Document the design for the vic-machine API (#6702)

This document proposes a design for a comprehensive vic-machine API,
the implementation of which will be tracked by #6116.

Subsets of this API (tracked by #5721, #6123, and eventually others)
will be implemented incrementally, and the design will be revised as
those efforts progress to reflect changes to the long-term vision.

* Remove superfluous calls to Set Test VCH Name (#7304)

Several tests explicitly call the `Set Test VCH Name` keyword shortly
after calling `Set Test Environment Variables`.

This can lead to test failures when a VCH name collision occurs;
subsequent tests which re-use the VCH name fail because there may be
leftover certificates from the first VCH with that name.

`Set Test Environment Variables` itself calls `Set Test VCH Name` and
then cleans up old certificate directories. Therefore, the explicit
calls to `Set Test VCH Name` are both superfluous and problematic.

* Ensure that static ip worker is on the same nimbus pod as VC otherwise network connectivity not guaranteed (#7307)

* [skip ci] Add ROBO test plans (#7297)

This commit adds test plans for the ROBO support features in a new
directory (Group19-ROBO) under manual test cases. The existing ROBO-SKU
test has been moved into this directory. The test plans include tests
for the container limit feature, placement without DRS, the license/
feature checks and WAN connectivity.

Fixes #7294

* Add hosts to DVS within the test bed as well (#7326)

* Setup updated for Longevity Tests (#7298)

* Setup updated for Longevity Tests to run on 6.5U1

* [skip ci] Terminate gracefully to gather logs (#7331)

* Terminate gracefully to gather logs

* Remove extra whitespace

* Increase timeout to 70 minutes

* Increase ELM timeout to 70 minutes

* Add repo to slack message since we have multiple repos reporting now (#7334)

* Not sending user credentials with every request (#6382)

* Add concurrent testing tool to tests folder (#6534)

Adds a minimized test case for testing our core vSphere interactions at
varying degrees of concurrency. This is intended to simplify debugging
issues that are suspected to be platform problems, or API usage issues
that are conceptually divorced from the VIC engine product code.

* Refactor Install Harbor To Test Server keyword (#7335)

The secret tag on the `Install Harbor To Test Server` makes it difficult
to investigate failures when they occur.

Only one out of 30+ lines actually uses secret information.

Refactor the keyword to extract the secret information into its own
keyword, allowing the tag to be applied in a more focused way. This is
similar to the pattern used by keywords in `VCH-Util`.

* Add ability to cache generated dependency. (#7340)

* Add ability to cache generated dependency, so not much time wasted during the build process.
* Added documentation to reflect necessary steps to leverage such improvements.

* Ignore not-supported result from RetrieveUserGroups in VC 6.0 (#7328)

* Move build time directives from title to body of PR (#7060)

* Retry the harbor setup as well (#7336)

* Skip non vSphere managed datastores when granting perms (#7346)

* Fix volume leak on group 23 test (#7358)

* Fix github status automation filtering (#7344)

Adds filtering for the event source and consolidates remote API calls.
Details the specific builds and their status for quick reference.

* Drone 0.8 and HaaS updates (#7364)

* Add tether.debug in integration test log bundle (#7422)

* Update the gcs plugin (#7421)

* [skip ci] Suggest subnet/gateway to static ip worker

* Ensure that static ip worker is on the same nimbus pod as VC otherwise network connectivity not guaranteed (#7307)

* Refactored some proxy code to reuse with wolfpack

Refactored the system, volume, container, and stream swagger code
into proxy code.

1) Moved the errors.go from backends to a new folder to be accessed
by all folders outside of the backends folder.
2) Refactored Container proxy and moved from engine/backends to engine/proxy
3) Refactored Volume proxy and moved from engine/backends to engine/proxy
4) Refactored System proxy and moved from engine/backends to engine/proxy
5) Refactored Stream proxy and moved from engine/backends to engine/proxy
6) Adopted some common patterns in all the proxies
7) Moved common networking util calls to engine/networking
8) Fix up unit tests
9) Changed all "not yet implemented messages"
10) Updated robot scripts

More refactoring will be needed to make these proxy less dependent on
docker types and portlayer swagger types.

Helps resolves #7210 and #7232

* Add virtual-kubelet binary to VIC ISO (#7315)

* Start virtual-kubelet inside the VCH (#7369)

* Fix value of the PORTLAYER_ADDR environment variable (#7400)

* Use vic kubelet provider

* Made modifications for virtual kubelet

* Added admin log collection and fix env variable content (#7404)

* Added most-vkubelet target (#7418)
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.

4 participants