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

host-local: Update host-local IPAM to support Windows #77

Merged

Conversation

rakelkar
Copy link
Contributor

@rakelkar rakelkar commented Oct 7, 2017

Get host-local to work for Windows. This is required for Flannel VXLAN mode on Windows.

@rakelkar rakelkar force-pushed the rakelkar/host-local-windows branch 2 times, most recently from 66e16a4 to 72798b1 Compare October 8, 2017 00:11
@@ -56,6 +57,10 @@ func New(network, dataDir string) (*Store, error) {

func (s *Store) Reserve(id string, ip net.IP, rangeID string) (bool, error) {
fname := filepath.Join(s.dataDir, ip.String())
if runtime.GOOS == "windows" {
fname = strings.Replace(fname, ":", "_", -1)
Copy link
Member

Choose a reason for hiding this comment

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

Hah, good catch!

@@ -12,7 +12,7 @@
// See the License for the specific language governing permissions and
// limitations under the License.

// +build !linux
// +build !linux,!windows
Copy link
Member

Choose a reason for hiding this comment

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

Is there supposed to be a Windows version of this file? Or am I just missing something?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Cant make a windows specific version of these methods since they reference the netlink package in their method signature "dev netlink.Link" ... Not sure why this file is present in the repo.

"github.com/containernetworking/cni/pkg/types/current"
)

func ExecAdd(plugin string, netconf []byte) (types.Result, error) {
Copy link
Member

Choose a reason for hiding this comment

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

It looks like these functions are duplicated - Can you just move ConfigureIface to a build-specific file?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Moved the execXX funcs to exec.go - let me know if thats not what you had in mind

@@ -1,3 +1,5 @@
// +build linux
Copy link
Member

Choose a reason for hiding this comment

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

Just do !windows here - this "should" work on all Unix-like systems.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

pkg/ip/addr.go Outdated
@@ -1,3 +1,5 @@
// +build linux
Copy link
Member

Choose a reason for hiding this comment

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

Out of curiosity, does Windows also need to worry about "tentative" addresses?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure, asking around

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So it seems Windows doesn't need to worry about it right now since HNS doesn't support IPv6 yet - so ja bitte for now I guess ;-)

@squeed
Copy link
Member

squeed commented Oct 9, 2017

Seems pretty reasonable to me. I added a first pass of changes - you're right, not too many changes needed.

When doing build-tagged files, it's considered good practice to only duplicate the minimum amount of os-dependent code, and put the rest in non-build-tagged files.

@rakelkar
Copy link
Contributor Author

@squeed Have addressed your comments, could you take a look? The test failure on CI is unrelated to this change (possibly a flaky test?).

@squeed
Copy link
Member

squeed commented Oct 17, 2017

Kicked that CI job and it's green now, dammit.

Seems reasonable to me. I want to think for one more day if we want to have a specific conditional build policy - the maintainer meeting is tomorrow.

@@ -0,0 +1,28 @@
// +build windows
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't believe this line is necessary, since the filename ends in _windows.go.

[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.

removed

lockPath = path.Join(lockPath, "lock")
}

f, err := filemutex.New(lockPath)
Copy link
Contributor

Choose a reason for hiding this comment

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

this code seems identical to the POSIX version, except it makes use of this nice cross-platform adapter. Could we make this file the one true lock.go and remove the POSIX-only implementation entirely?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

package disk

import (
"github.com/alexflint/go-filemutex"
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this package added to the vendor directory somewhere? I don't see it.

Copy link
Contributor

Choose a reason for hiding this comment

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

[meta comment: I'm surprised this passed Travis without doing that. Maybe we should open a separate PR to enforce vendoring at CI time.]

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Vendored

@rakelkar
Copy link
Contributor Author

rakelkar commented Oct 17, 2017 via email

func (l *FileLock) Close() error {
return l.f.Close()
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.

why not close the file?

Copy link
Contributor

Choose a reason for hiding this comment

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

oh, because the library doesn't expose a Close() method at all. uh oh....

Copy link
Contributor

Choose a reason for hiding this comment

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

Although apparently we're not using Close() anyhow. When I delete the Close() method from the backend.Store interface, the program still compiles. So I guess you could just do that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice catch - will remove, though I must say with a touch of disquiet.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So it seems like main.go:51 creates a Store struct and not the interface and calls defer store.Close so close is called after all...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is an open PR on the library to add a close method, will create a PR to update this plugin once that has been merged. alexflint/go-filemutex#2

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated with shiny new close method!

}

// Lock acquires an exclusive lock
func (l *FileLock) Lock() error {
return syscall.Flock(int(l.f.Fd()), syscall.LOCK_EX)
l.f.Lock()
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.

I didn't realize before that this library panics on errors rather than returning them.
Effective Go says that "real library functions should avoid panic". I wonder if that library deserves a PR...

{"dst": "2001:db8:2::0/64", "gw": "2001:db8:3::1"}
]
}
}`, tmpDir, tmpDir)
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 ran gofmt - and it felt indents were in order!

func getTmpDir() (string, error) {
tmpDir, err := ioutil.TempDir("", "host_local_artifacts")
if err == nil {
tmpDir = filepath.ToSlash(tmpDir)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

so without this the un-escaped backslashes in the windows path cause JSON parsing to barf

if runtime.GOOS == "windows" {
fname = strings.Replace(fname, ":", "_", -1)
}
fname := GetEscapedPath(s.dataDir, ip.String())
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Turns out I missed a bunch, also escaping the colon in the dataDir doesnt work so well when the path includes a drive letter - duh!

@rakelkar
Copy link
Contributor Author

rakelkar commented Oct 28, 2017

@rosenhouse @squeed Have addressed all comments, got the shiny new changes from alexflint and made fixes to get tests to run on Windows. Let me know if you see something anything don't like. The current build failure is an unrelated flaky test.

@rosenhouse
Copy link
Contributor

@rakelkar thanks for all your hard work on this! we're excited to merge this, just as soon as we have Continuous integration set up for Windows in this repo. I've got PR #84 open, but its not yet green. Once that's merged, then we can return to this PR.

This was referenced Nov 1, 2017
@rosenhouse
Copy link
Contributor

@rakelkar now that #84 is merged, please rebase and squash this down to a single commit, e.g. something like rosenhouse@799776f

@rakelkar rakelkar force-pushed the rakelkar/host-local-windows branch 3 times, most recently from f6d364f to 6816389 Compare November 11, 2017 21:19
@rakelkar
Copy link
Contributor Author

@rosenhouse rebased and squashed!


if fi.IsDir() {
lockPath = path.Join(lockPath, "lock")
}
Copy link
Contributor

Choose a reason for hiding this comment

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

is this line necessary for windows? If so, maybe it deserves a unit test?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes it is required - added unit tests for filepath and folderpath

Copy link
Contributor Author

Choose a reason for hiding this comment

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

LMK if you like what you see, will wait for LGTM to squash!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

squashed commits

Copy link
Contributor

@rosenhouse rosenhouse left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@squeed squeed left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@rosenhouse rosenhouse merged commit 6c2ef73 into containernetworking:master Nov 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants