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

add a --watch flag to oc rsync #8268

Merged
merged 2 commits into from
Apr 28, 2016
Merged

Conversation

bparees
Copy link
Contributor

@bparees bparees commented Mar 28, 2016

add a --watch flag to oc rsync so it watches the filesystem for changes and automatically syncs when the filesystem changes

@bparees
Copy link
Contributor Author

bparees commented Mar 28, 2016

@csrwng @smarterclayton ptal

@bparees bparees force-pushed the fsnotify branch 2 times, most recently from 8417f21 to dcc7d3c Compare March 28, 2016 19:28
@bparees bparees changed the title add a --watch flag to oc rsync so it watches the filesystem for changes and automatically syncs when the filesystem changes add a --watch flag to oc rsync Mar 28, 2016
@bparees
Copy link
Contributor Author

bparees commented Mar 28, 2016

also if one of you could test this on a mac that'd be awesome :)

@csrwng
Copy link
Contributor

csrwng commented Mar 28, 2016

So it works on the Mac, at least on my simple test. One thing I ran into though as soon as I tried it is that fsnotify complained of not being able to open a file. I realized that the default limit for open files on the Mac is tiny (256). We may want to mention that in the doc.

@bparees
Copy link
Contributor Author

bparees commented Mar 28, 2016

yeah so as you see i have a comment in the code about that, it's probably so common that the error should say "try this...." if we get an error adding the watch.

}

// recursive logic from https://github.com/bronze1man/kmg/blob/master/fsnotify/Watcher.go
func watchRecursion(watcher *fsnotify.Watcher, path string) error {
Copy link
Contributor

Choose a reason for hiding this comment

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

Feels like this should be in a different package

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, i debated moving this whole watcher mess to a helper package. i can do that.

@bparees bparees force-pushed the fsnotify branch 3 times, most recently from 6e2798c to c0485dc Compare March 30, 2016 19:49
@bparees
Copy link
Contributor Author

bparees commented Mar 30, 2016

@smarterclayton helpers moved to package
@rhcarvalho race condition fixed, watchError returned

@mfojtik
Copy link
Contributor

mfojtik commented Mar 31, 2016

@bparees lgtm. as @csrwng we might run into problems when you start watching too many files (even on linux)... we should probably document what users should do when this problem happens.

@mfojtik
Copy link
Contributor

mfojtik commented Mar 31, 2016

@bparees test will come as follow up, right? ;-)

time.Sleep(2 * time.Second)
}
// unreachable
return nil
Copy link
Contributor

Choose a reason for hiding this comment

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

The two lines above can/should be removed. The compiler knows about unreachable code, and so does go vet:

$ go vet pkg/cmd/cli/cmd/rsync/rsync.go
pkg/cmd/cli/cmd/rsync/rsync.go:308: unreachable code
exit status 1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

cool

@rhcarvalho
Copy link
Contributor

This might be a starting point for documenting the behavior (incl. max files):

https://github.com/fsnotify/fsnotify/wiki/FAQ

if event.Op&fsnotify.Remove == fsnotify.Remove {
watcher.Remove(event.Name)
} else {
fsnotification.AddRecursiveWatch(watcher, event.Name)
Copy link
Contributor

Choose a reason for hiding this comment

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

AFAIK we don't need to add watchers per file, only directories. Watching a directory gets events for all files.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh well, AddRecursiveWatch actually ignores paths that are not directories. That's subtle.

Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we check the error returned by fsnotification.AddRecursiveWatch?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

will add a comment to the function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

and yes, should. will assign it to watchError

return nil
}

// getSubFolders recursively retrieves all subfolders of the specified path
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing a final period.

@rhcarvalho
Copy link
Contributor

Two documentation nits, code LGTM. Nice stuff @bparees, thanks!

@bparees bparees force-pushed the fsnotify branch 2 times, most recently from fe639f9 to 42faf99 Compare April 6, 2016 20:36
@bparees
Copy link
Contributor Author

bparees commented Apr 6, 2016

nits addressed, thanks @rhcarvalho

@@ -111,6 +117,7 @@ func NewCmdRsync(name, parent string, f *clientcmd.Factory, out, errOut io.Write
cmd.Flags().StringVar(&o.RsyncInclude, "include", "", "rsync - include files matching specified pattern")
cmd.Flags().BoolVar(&o.RsyncProgress, "progress", false, "rsync - show progress during transfer")
cmd.Flags().BoolVar(&o.RsyncNoPerms, "no-perms", false, "rsync - do not transfer permissions")
cmd.Flags().BoolVarP(&o.Watch, "watch", "w", false, "Watch directory for changes and resync automatically")
Copy link
Contributor

Choose a reason for hiding this comment

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

This is consistent with get, correct? Will we ever introduce a "watch" flag?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

if by "consistent" with get you mean that get has a --watch flag, then yes. Whether what get --watch does is similar enough to rsync --watch that they should be using the same argument name is debatable. (get is reading something and display you the result whenever it changes. rsync is monitoring the filesystem for changes and sending them to the container whenever it changes). So...similarish, not identical.

would we ever want the equivalent of get --watch functionality in rsync? I have a hard time envisioning that we would.

overall watch feels like the right name here i think.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

would we ever want the equivalent of get --watch functionality in rsync? I have a hard time envisioning that we would.

by which i mean, i have a hard time envisioning what that would mean/do.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's fine, just wanted to check

On Tue, Apr 26, 2016 at 12:42 PM, Ben Parees notifications@github.com
wrote:

In pkg/cmd/cli/cmd/rsync/rsync.go
#8268 (comment):

@@ -111,6 +117,7 @@ func NewCmdRsync(name, parent string, f *clientcmd.Factory, out, errOut io.Write
cmd.Flags().StringVar(&o.RsyncInclude, "include", "", "rsync - include files matching specified pattern")
cmd.Flags().BoolVar(&o.RsyncProgress, "progress", false, "rsync - show progress during transfer")
cmd.Flags().BoolVar(&o.RsyncNoPerms, "no-perms", false, "rsync - do not transfer permissions")

  • cmd.Flags().BoolVarP(&o.Watch, "watch", "w", false, "Watch directory for changes and resync automatically")

would we ever want the equivalent of get --watch functionality in rsync? I
have a hard time envisioning that we would.

by which i mean, i have a hard time envisioning what that would mean/do.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/origin/pull/8268/files/b9f4b16543df4fb40bdd86f2797f6d2dd2e14093..5b20fcd4b5c6e42bdf67cf7b118d57d95e532e6f#r61120407

@openshift-bot openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 26, 2016
@bparees bparees force-pushed the fsnotify branch 2 times, most recently from da64699 to 62808bc Compare April 26, 2016 21:10
@openshift-bot openshift-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 26, 2016
@smarterclayton
Copy link
Contributor

So much pull through, so much fail. [test]

On Tue, Apr 26, 2016 at 7:05 PM, OpenShift Bot notifications@github.com
wrote:

continuous-integration/openshift-jenkins/test FAILURE (
https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/3289/)


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8268 (comment)

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 899f157

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/3397/)

@openshift-bot
Copy link
Contributor

Evaluated for origin testonlyextended up to 899f157

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/testonlyextended SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin_extended/119/) (Extended Tests: core(rsync))

@bparees
Copy link
Contributor Author

bparees commented Apr 28, 2016

[merge]

@openshift-bot
Copy link
Contributor

openshift-bot commented Apr 28, 2016

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5740/) (Image: devenv-rhel7_4057)

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 899f157

@openshift-bot openshift-bot merged commit 20709a6 into openshift:master Apr 28, 2016
@bparees
Copy link
Contributor Author

bparees commented Apr 29, 2016

@thesteve0 fyi. merged.

@thesteve0
Copy link
Contributor

And there was much rejoicing!!!! So this will be in the next origin release?

On Thu, Apr 28, 2016 at 5:55 PM, Ben Parees notifications@github.com
wrote:

@thesteve0 https://github.com/thesteve0 fyi. merged.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8268 (comment)

@bparees
Copy link
Contributor Author

bparees commented Apr 29, 2016

@thesteve0 yeah.

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.

8 participants