Tests failures seems related

@runcom Updated.

ping @vieux : does this fix the issue you mentioned recently re: memoryswappiness default?

This is not the first time we've gone through such a change on this field.

@cpuguy83 What change exactly are you mentioning? I know this field used to be int64 and was changed to *int64, but this PR is more like a fix instead of a change. WDYT?

Changing the defaults for MemorySwapiness -- just pointing out this has been a problem multiple times.

I think the default if not provided will default to -1 as it was previously. This patch just move the initialization to -1 back in the code path right @hqhq?

More correctly, it handles non-Docker clients (e.g. API users like swarm/compose) from causing "unset" to translate to 0, rather than "unset" -> -1, which is what should happen. I think most of the confusion was around catching all the places that instantiation was performed and making sure default != 0, given 0 is a setting, not a default in this case.

sorry @hqhq ..this needs a rebase now

@estesp was right, this PR will fix problem like docker-archive/classicswarm#1411
The problem we have before was when user used REST API, the default value for swappiness is not set to container's hostConfig, only set to container.command and passed to libcontainer, which will cause problem like the swarm issue.

@runcom @estesp Rebased.

@hqhq Thanks for doing this.
I think we need set swappiness default value -1 in docker daemon side.

ping @vieux

@hqhq @jimmyxian was this issue introduced in docker 1.9 in Swarm, or already present in docker 1.8.3? Asking so that we can decide if this should be considered for a 1.9.2 release (if we decide to release that)

@thaJeztah It's exist since Docker v1.5

I think my PR #18261 will be also affected by having adaptContainerSettings always called? Is this correct @hqhq ?

@runcom Yeah, you can see I changed your test cases. You expected API without hostConfig (or just without these fields) has nil for these pointer fields, while CLI without these options has default value (not nil). Are there any specific reasons that I missed? I think it's better to make them consistent. And the reason we want API got the same default value is the same as we want CLI got the default.

@hqhq perfect

LGTM

@estesp @cpuguy83 sorry, I lost track of all the "default value" changes; is this an user-facing change in the API? If so, can you add the right impact labels?

I don't believe there is any need for API or user-facing impact--this is really a bug fix for a hole in the setup of containers via certain paths which weren't defaulting properly to the "unset" value (a pointer to -1 in this case), meaning they were getting "default to zero" as a setting for swappiness, which is an actual swappiness value, which of course is a bug unless the user asked for swappiness = 0.

Thanks for checking @estesp!