Allow pulls from an insecure registry

[jbalonso]

We maintain a private docker registry without SSL (it isn't necessary). This PR adds an -i option to fig pull that enables insecure mode.

[thaJeztah]

I wonder if this should be a short ( -i) flag, or be more explicit (--insecure)?

[dnephin]

+1, I hit this as well, I'd be fine with either short or long option

[bfirsh]

+1 long flag. And it should be --allow-insecure-ssl: https://github.com/docker/docker/pull/2687/files

[jbalonso]

Ok. A commit with --alow-insecure-ssl is forthcoming. Also, sign-offs, and using insecure_registry as the keyword argument instead of insecure for consistency with docker-py.

[bfirsh]

Great, thanks! Original commit still needs signing off though. You can squash all of this with git rebase -i master and signoff the single commit with git commit --amend --signoff.

[jbalonso]

I took care of the signoff in the squash, and I believe the ball is back in your court.

[bfirsh]

Great stuff, thanks!

[dnephin]

I just realized that this kwarg (insecure_registry) was only added to docker-py in 0.5.0, but right now in setup.py the minimum version is 0.3.2. I think for this change to be safe you need to change the docker-py requirement to:
docker-py >= 0.5, < 0.6

[dnephin]

Not sure why the travis build hasn't run on this branch, but I'm also getting a couple flake8 errors

[bfirsh]

Oops.

We've replaced Travis with Wercker, so this needs rebasing to get CI run on it.

[jbalonso]

I've fixed the docker-py dependency. I'll worry about rebasing (where should I rebase to? I see an "All is well -- build finished" on the PR) and figuring out the flakes tomorrow.

[bfirsh]

We only recently added the file that makes the build work. If you rebase on to the current master, it'll get the wercker.yml file to make the build work. You can run nosetests and flake8 fig locally to verify the things the build runs.

[jbalonso]

I've rebased, but I'm still cleaning up the branch.

[jbalonso]

Ok. A third force-push later, I believe I have cleaned up this PR.

[bfirsh]

LGTM

[bfirsh]

Don't think it's easy to test this without mocking out docker-py. :/

[dnephin]

At the very least a simple unit test that asserts the right docker.client function was called wouldn't hurt. ServiceTest already creates a mock_client

[bfirsh]

Oh cool, forgot about that. @jbalonso – would be great to get a test!

[moss]

I've added the missing unit test to ServiceTest. Please let me know if it needs any cleanup.

[bfirsh]

LGTM

[tjrivera]

Hey guys, it seems like Fig will also attempt to pull needed images when running fig up -- not just when fig pull is run explicitly. The insecure flag in this case would have to be also passed at Project.up then through here: https://github.com/docker/fig/blob/master/fig/project.py#L175 and ultimately out to here: https://github.com/docker/fig/blob/master/fig/service.py#L182 where pull is being run again. I can work on a PR if this makes sense.

[jbalonso]

I kinda feel responsible for not catching that in my PR. I'll mention that I'm out of bandwidth to work on it myself at the moment.

[dnephin]

I've run into this as well. I got around it for now by always doing a fig pull --allow-insecure-ssl first but it would be nice to not have to do that.

I think your solution sounds appropriate.

[torbjornvatn]

I've also run into this, and I really would like to call fig pull --allow-insecure-ssl directly. Are you working on a PR @tjrivera or should I try to fix this at work tomorrow?

[tjrivera]

@torbjornvatn I was planning on submitting a PR tomorrow morning

[torbjornvatn]

@tjrivera Nice!

[jbalonso]

We maintain a private docker registry without SSL (it isn't necessary). This PR adds an -i option to fig pull that enables insecure mode.

[thaJeztah]

I wonder if this should be a short ( -i) flag, or be more explicit (--insecure)?

[dnephin]

+1, I hit this as well, I'd be fine with either short or long option

[bfirsh]

+1 long flag. And it should be --allow-insecure-ssl: https://github.com/docker/docker/pull/2687/files

[jbalonso]

Ok. A commit with --alow-insecure-ssl is forthcoming. Also, sign-offs, and using insecure_registry as the keyword argument instead of insecure for consistency with docker-py.

[bfirsh]

Great, thanks! Original commit still needs signing off though. You can squash all of this with git rebase -i master and signoff the single commit with git commit --amend --signoff.

[jbalonso]

I took care of the signoff in the squash, and I believe the ball is back in your court.

[bfirsh]

Great stuff, thanks!

[dnephin]

I just realized that this kwarg (insecure_registry) was only added to docker-py in 0.5.0, but right now in setup.py the minimum version is 0.3.2. I think for this change to be safe you need to change the docker-py requirement to:
docker-py >= 0.5, < 0.6

[dnephin]

Not sure why the travis build hasn't run on this branch, but I'm also getting a couple flake8 errors

[bfirsh]

Oops.

We've replaced Travis with Wercker, so this needs rebasing to get CI run on it.

[jbalonso]

I've fixed the docker-py dependency. I'll worry about rebasing (where should I rebase to? I see an "All is well -- build finished" on the PR) and figuring out the flakes tomorrow.

[bfirsh]

We only recently added the file that makes the build work. If you rebase on to the current master, it'll get the wercker.yml file to make the build work. You can run nosetests and flake8 fig locally to verify the things the build runs.

[jbalonso]

I've rebased, but I'm still cleaning up the branch.

[jbalonso]

Ok. A third force-push later, I believe I have cleaned up this PR.

[bfirsh]

LGTM

[bfirsh]

Don't think it's easy to test this without mocking out docker-py. :/

[dnephin]

At the very least a simple unit test that asserts the right docker.client function was called wouldn't hurt. ServiceTest already creates a mock_client

[bfirsh]

Oh cool, forgot about that. @jbalonso – would be great to get a test!

[moss]

I've added the missing unit test to ServiceTest. Please let me know if it needs any cleanup.

[bfirsh]

LGTM

[tjrivera]

Hey guys, it seems like Fig will also attempt to pull needed images when running fig up -- not just when fig pull is run explicitly. The insecure flag in this case would have to be also passed at Project.up then through here: https://github.com/docker/fig/blob/master/fig/project.py#L175 and ultimately out to here: https://github.com/docker/fig/blob/master/fig/service.py#L182 where pull is being run again. I can work on a PR if this makes sense.

[jbalonso]

I kinda feel responsible for not catching that in my PR. I'll mention that I'm out of bandwidth to work on it myself at the moment.

[dnephin]

I've run into this as well. I got around it for now by always doing a fig pull --allow-insecure-ssl first but it would be nice to not have to do that.

I think your solution sounds appropriate.

[torbjornvatn]

I've also run into this, and I really would like to call fig pull --allow-insecure-ssl directly. Are you working on a PR @tjrivera or should I try to fix this at work tomorrow?

[tjrivera]

@torbjornvatn I was planning on submitting a PR tomorrow morning

[torbjornvatn]

@tjrivera Nice!

[jbalonso]

We maintain a private docker registry without SSL (it isn't necessary). This PR adds an -i option to fig pull that enables insecure mode.

[thaJeztah]

I wonder if this should be a short ( -i) flag, or be more explicit (--insecure)?

[dnephin]

+1, I hit this as well, I'd be fine with either short or long option

[bfirsh]

+1 long flag. And it should be --allow-insecure-ssl: https://github.com/docker/docker/pull/2687/files

[jbalonso]

Ok. A commit with --alow-insecure-ssl is forthcoming. Also, sign-offs, and using insecure_registry as the keyword argument instead of insecure for consistency with docker-py.

[bfirsh]

Great, thanks! Original commit still needs signing off though. You can squash all of this with git rebase -i master and signoff the single commit with git commit --amend --signoff.

[jbalonso]

I took care of the signoff in the squash, and I believe the ball is back in your court.

[bfirsh]

Great stuff, thanks!

[dnephin]

I just realized that this kwarg (insecure_registry) was only added to docker-py in 0.5.0, but right now in setup.py the minimum version is 0.3.2. I think for this change to be safe you need to change the docker-py requirement to:
docker-py >= 0.5, < 0.6

[dnephin]

Not sure why the travis build hasn't run on this branch, but I'm also getting a couple flake8 errors

[bfirsh]

Oops.

We've replaced Travis with Wercker, so this needs rebasing to get CI run on it.

[jbalonso]

I've fixed the docker-py dependency. I'll worry about rebasing (where should I rebase to? I see an "All is well -- build finished" on the PR) and figuring out the flakes tomorrow.

[bfirsh]

We only recently added the file that makes the build work. If you rebase on to the current master, it'll get the wercker.yml file to make the build work. You can run nosetests and flake8 fig locally to verify the things the build runs.

[jbalonso]

I've rebased, but I'm still cleaning up the branch.

[jbalonso]

Ok. A third force-push later, I believe I have cleaned up this PR.

[bfirsh]

LGTM

[bfirsh]

Don't think it's easy to test this without mocking out docker-py. :/

[dnephin]

At the very least a simple unit test that asserts the right docker.client function was called wouldn't hurt. ServiceTest already creates a mock_client

[bfirsh]

Oh cool, forgot about that. @jbalonso – would be great to get a test!

[moss]

I've added the missing unit test to ServiceTest. Please let me know if it needs any cleanup.

[bfirsh]

LGTM

[tjrivera]

Hey guys, it seems like Fig will also attempt to pull needed images when running fig up -- not just when fig pull is run explicitly. The insecure flag in this case would have to be also passed at Project.up then through here: https://github.com/docker/fig/blob/master/fig/project.py#L175 and ultimately out to here: https://github.com/docker/fig/blob/master/fig/service.py#L182 where pull is being run again. I can work on a PR if this makes sense.

[jbalonso]

I kinda feel responsible for not catching that in my PR. I'll mention that I'm out of bandwidth to work on it myself at the moment.

[dnephin]

I've run into this as well. I got around it for now by always doing a fig pull --allow-insecure-ssl first but it would be nice to not have to do that.

I think your solution sounds appropriate.

[torbjornvatn]

I've also run into this, and I really would like to call fig pull --allow-insecure-ssl directly. Are you working on a PR @tjrivera or should I try to fix this at work tomorrow?

[tjrivera]

@torbjornvatn I was planning on submitting a PR tomorrow morning

[torbjornvatn]

@tjrivera Nice!

[jbalonso]

We maintain a private docker registry without SSL (it isn't necessary). This PR adds an -i option to fig pull that enables insecure mode.

[thaJeztah]

I wonder if this should be a short ( -i) flag, or be more explicit (--insecure)?

[dnephin]

+1, I hit this as well, I'd be fine with either short or long option

[bfirsh]

+1 long flag. And it should be --allow-insecure-ssl: https://github.com/docker/docker/pull/2687/files

[jbalonso]

Ok. A commit with --alow-insecure-ssl is forthcoming. Also, sign-offs, and using insecure_registry as the keyword argument instead of insecure for consistency with docker-py.

[bfirsh]

Great, thanks! Original commit still needs signing off though. You can squash all of this with git rebase -i master and signoff the single commit with git commit --amend --signoff.

[jbalonso]

I took care of the signoff in the squash, and I believe the ball is back in your court.

[bfirsh]

Great stuff, thanks!

[dnephin]

I just realized that this kwarg (insecure_registry) was only added to docker-py in 0.5.0, but right now in setup.py the minimum version is 0.3.2. I think for this change to be safe you need to change the docker-py requirement to:
docker-py >= 0.5, < 0.6

[dnephin]

Not sure why the travis build hasn't run on this branch, but I'm also getting a couple flake8 errors

[bfirsh]

Oops.

We've replaced Travis with Wercker, so this needs rebasing to get CI run on it.

[jbalonso]

I've fixed the docker-py dependency. I'll worry about rebasing (where should I rebase to? I see an "All is well -- build finished" on the PR) and figuring out the flakes tomorrow.

[bfirsh]

We only recently added the file that makes the build work. If you rebase on to the current master, it'll get the wercker.yml file to make the build work. You can run nosetests and flake8 fig locally to verify the things the build runs.

[jbalonso]

I've rebased, but I'm still cleaning up the branch.

[jbalonso]

Ok. A third force-push later, I believe I have cleaned up this PR.

[bfirsh]

LGTM

[bfirsh]

Don't think it's easy to test this without mocking out docker-py. :/

[dnephin]

At the very least a simple unit test that asserts the right docker.client function was called wouldn't hurt. ServiceTest already creates a mock_client

[bfirsh]

Oh cool, forgot about that. @jbalonso – would be great to get a test!

[moss]

I've added the missing unit test to ServiceTest. Please let me know if it needs any cleanup.

[bfirsh]

LGTM

[tjrivera]

Hey guys, it seems like Fig will also attempt to pull needed images when running fig up -- not just when fig pull is run explicitly. The insecure flag in this case would have to be also passed at Project.up then through here: https://github.com/docker/fig/blob/master/fig/project.py#L175 and ultimately out to here: https://github.com/docker/fig/blob/master/fig/service.py#L182 where pull is being run again. I can work on a PR if this makes sense.

[jbalonso]

I kinda feel responsible for not catching that in my PR. I'll mention that I'm out of bandwidth to work on it myself at the moment.

[dnephin]

I've run into this as well. I got around it for now by always doing a fig pull --allow-insecure-ssl first but it would be nice to not have to do that.

I think your solution sounds appropriate.

[torbjornvatn]

I've also run into this, and I really would like to call fig pull --allow-insecure-ssl directly. Are you working on a PR @tjrivera or should I try to fix this at work tomorrow?

[tjrivera]

@torbjornvatn I was planning on submitting a PR tomorrow morning

[torbjornvatn]

@tjrivera Nice!

[jbalonso]

We maintain a private docker registry without SSL (it isn't necessary). This PR adds an -i option to fig pull that enables insecure mode.

[thaJeztah]

I wonder if this should be a short ( -i) flag, or be more explicit (--insecure)?

[dnephin]

+1, I hit this as well, I'd be fine with either short or long option

[bfirsh]

+1 long flag. And it should be --allow-insecure-ssl: https://github.com/docker/docker/pull/2687/files

[jbalonso]

Ok. A commit with --alow-insecure-ssl is forthcoming. Also, sign-offs, and using insecure_registry as the keyword argument instead of insecure for consistency with docker-py.

[bfirsh]

Great, thanks! Original commit still needs signing off though. You can squash all of this with git rebase -i master and signoff the single commit with git commit --amend --signoff.

[jbalonso]

I took care of the signoff in the squash, and I believe the ball is back in your court.

[bfirsh]

Great stuff, thanks!

[dnephin]

I just realized that this kwarg (insecure_registry) was only added to docker-py in 0.5.0, but right now in setup.py the minimum version is 0.3.2. I think for this change to be safe you need to change the docker-py requirement to:
docker-py >= 0.5, < 0.6

[dnephin]

Not sure why the travis build hasn't run on this branch, but I'm also getting a couple flake8 errors

[bfirsh]

Oops.

We've replaced Travis with Wercker, so this needs rebasing to get CI run on it.

[jbalonso]

I've fixed the docker-py dependency. I'll worry about rebasing (where should I rebase to? I see an "All is well -- build finished" on the PR) and figuring out the flakes tomorrow.

[bfirsh]

We only recently added the file that makes the build work. If you rebase on to the current master, it'll get the wercker.yml file to make the build work. You can run nosetests and flake8 fig locally to verify the things the build runs.

[jbalonso]

I've rebased, but I'm still cleaning up the branch.

[jbalonso]

Ok. A third force-push later, I believe I have cleaned up this PR.

[bfirsh]

LGTM

[bfirsh]

Don't think it's easy to test this without mocking out docker-py. :/

[dnephin]

At the very least a simple unit test that asserts the right docker.client function was called wouldn't hurt. ServiceTest already creates a mock_client

[bfirsh]

Oh cool, forgot about that. @jbalonso – would be great to get a test!

[moss]

I've added the missing unit test to ServiceTest. Please let me know if it needs any cleanup.

[bfirsh]

LGTM

[tjrivera]

Hey guys, it seems like Fig will also attempt to pull needed images when running fig up -- not just when fig pull is run explicitly. The insecure flag in this case would have to be also passed at Project.up then through here: https://github.com/docker/fig/blob/master/fig/project.py#L175 and ultimately out to here: https://github.com/docker/fig/blob/master/fig/service.py#L182 where pull is being run again. I can work on a PR if this makes sense.

[jbalonso]

I kinda feel responsible for not catching that in my PR. I'll mention that I'm out of bandwidth to work on it myself at the moment.

[dnephin]

I've run into this as well. I got around it for now by always doing a fig pull --allow-insecure-ssl first but it would be nice to not have to do that.

I think your solution sounds appropriate.

[torbjornvatn]

I've also run into this, and I really would like to call fig pull --allow-insecure-ssl directly. Are you working on a PR @tjrivera or should I try to fix this at work tomorrow?

[tjrivera]

@torbjornvatn I was planning on submitting a PR tomorrow morning

[torbjornvatn]

@tjrivera Nice!

[jbalonso]

We maintain a private docker registry without SSL (it isn't necessary). This PR adds an -i option to fig pull that enables insecure mode.

[thaJeztah]

I wonder if this should be a short ( -i) flag, or be more explicit (--insecure)?

[dnephin]

+1, I hit this as well, I'd be fine with either short or long option

[bfirsh]

+1 long flag. And it should be --allow-insecure-ssl: https://github.com/docker/docker/pull/2687/files

[jbalonso]

Ok. A commit with --alow-insecure-ssl is forthcoming. Also, sign-offs, and using insecure_registry as the keyword argument instead of insecure for consistency with docker-py.

[bfirsh]

Great, thanks! Original commit still needs signing off though. You can squash all of this with git rebase -i master and signoff the single commit with git commit --amend --signoff.

[jbalonso]

I took care of the signoff in the squash, and I believe the ball is back in your court.

[bfirsh]

Great stuff, thanks!

[dnephin]

I just realized that this kwarg (insecure_registry) was only added to docker-py in 0.5.0, but right now in setup.py the minimum version is 0.3.2. I think for this change to be safe you need to change the docker-py requirement to:
docker-py >= 0.5, < 0.6

[dnephin]

Not sure why the travis build hasn't run on this branch, but I'm also getting a couple flake8 errors

[bfirsh]

Oops.

We've replaced Travis with Wercker, so this needs rebasing to get CI run on it.

[jbalonso]

I've fixed the docker-py dependency. I'll worry about rebasing (where should I rebase to? I see an "All is well -- build finished" on the PR) and figuring out the flakes tomorrow.

[bfirsh]

We only recently added the file that makes the build work. If you rebase on to the current master, it'll get the wercker.yml file to make the build work. You can run nosetests and flake8 fig locally to verify the things the build runs.

[jbalonso]

I've rebased, but I'm still cleaning up the branch.

[jbalonso]

Ok. A third force-push later, I believe I have cleaned up this PR.

[bfirsh]

LGTM

[bfirsh]

Don't think it's easy to test this without mocking out docker-py. :/

[dnephin]

At the very least a simple unit test that asserts the right docker.client function was called wouldn't hurt. ServiceTest already creates a mock_client

[bfirsh]

Oh cool, forgot about that. @jbalonso – would be great to get a test!

[moss]

I've added the missing unit test to ServiceTest. Please let me know if it needs any cleanup.

[bfirsh]

LGTM

[tjrivera]

Hey guys, it seems like Fig will also attempt to pull needed images when running fig up -- not just when fig pull is run explicitly. The insecure flag in this case would have to be also passed at Project.up then through here: https://github.com/docker/fig/blob/master/fig/project.py#L175 and ultimately out to here: https://github.com/docker/fig/blob/master/fig/service.py#L182 where pull is being run again. I can work on a PR if this makes sense.

[jbalonso]

I kinda feel responsible for not catching that in my PR. I'll mention that I'm out of bandwidth to work on it myself at the moment.

[dnephin]

I've run into this as well. I got around it for now by always doing a fig pull --allow-insecure-ssl first but it would be nice to not have to do that.

I think your solution sounds appropriate.

[torbjornvatn]

I've also run into this, and I really would like to call fig pull --allow-insecure-ssl directly. Are you working on a PR @tjrivera or should I try to fix this at work tomorrow?

[tjrivera]

@torbjornvatn I was planning on submitting a PR tomorrow morning

[torbjornvatn]

@tjrivera Nice!

[jbalonso]

We maintain a private docker registry without SSL (it isn't necessary). This PR adds an -i option to fig pull that enables insecure mode.

[thaJeztah]

I wonder if this should be a short ( -i) flag, or be more explicit (--insecure)?

[dnephin]

+1, I hit this as well, I'd be fine with either short or long option

[bfirsh]

+1 long flag. And it should be --allow-insecure-ssl: https://github.com/docker/docker/pull/2687/files

[jbalonso]

Ok. A commit with --alow-insecure-ssl is forthcoming. Also, sign-offs, and using insecure_registry as the keyword argument instead of insecure for consistency with docker-py.

[bfirsh]

Great, thanks! Original commit still needs signing off though. You can squash all of this with git rebase -i master and signoff the single commit with git commit --amend --signoff.

[jbalonso]

I took care of the signoff in the squash, and I believe the ball is back in your court.

[bfirsh]

Great stuff, thanks!

[dnephin]

I just realized that this kwarg (insecure_registry) was only added to docker-py in 0.5.0, but right now in setup.py the minimum version is 0.3.2. I think for this change to be safe you need to change the docker-py requirement to:
docker-py >= 0.5, < 0.6

[dnephin]

Not sure why the travis build hasn't run on this branch, but I'm also getting a couple flake8 errors

[bfirsh]

Oops.

We've replaced Travis with Wercker, so this needs rebasing to get CI run on it.

[jbalonso]

I've fixed the docker-py dependency. I'll worry about rebasing (where should I rebase to? I see an "All is well -- build finished" on the PR) and figuring out the flakes tomorrow.

[bfirsh]

We only recently added the file that makes the build work. If you rebase on to the current master, it'll get the wercker.yml file to make the build work. You can run nosetests and flake8 fig locally to verify the things the build runs.

[jbalonso]

I've rebased, but I'm still cleaning up the branch.

[jbalonso]

Ok. A third force-push later, I believe I have cleaned up this PR.

[bfirsh]

LGTM

[bfirsh]

Don't think it's easy to test this without mocking out docker-py. :/

[dnephin]

At the very least a simple unit test that asserts the right docker.client function was called wouldn't hurt. ServiceTest already creates a mock_client

[bfirsh]

Oh cool, forgot about that. @jbalonso – would be great to get a test!

[moss]

I've added the missing unit test to ServiceTest. Please let me know if it needs any cleanup.

[bfirsh]

LGTM

[tjrivera]

Hey guys, it seems like Fig will also attempt to pull needed images when running fig up -- not just when fig pull is run explicitly. The insecure flag in this case would have to be also passed at Project.up then through here: https://github.com/docker/fig/blob/master/fig/project.py#L175 and ultimately out to here: https://github.com/docker/fig/blob/master/fig/service.py#L182 where pull is being run again. I can work on a PR if this makes sense.

[jbalonso]

I kinda feel responsible for not catching that in my PR. I'll mention that I'm out of bandwidth to work on it myself at the moment.

[dnephin]

I've run into this as well. I got around it for now by always doing a fig pull --allow-insecure-ssl first but it would be nice to not have to do that.

I think your solution sounds appropriate.

[torbjornvatn]

I've also run into this, and I really would like to call fig pull --allow-insecure-ssl directly. Are you working on a PR @tjrivera or should I try to fix this at work tomorrow?

[tjrivera]

@torbjornvatn I was planning on submitting a PR tomorrow morning

[torbjornvatn]

@tjrivera Nice!

[jbalonso]

We maintain a private docker registry without SSL (it isn't necessary). This PR adds an -i option to fig pull that enables insecure mode.

[thaJeztah]

I wonder if this should be a short ( -i) flag, or be more explicit (--insecure)?

[dnephin]

+1, I hit this as well, I'd be fine with either short or long option

[bfirsh]

+1 long flag. And it should be --allow-insecure-ssl: https://github.com/docker/docker/pull/2687/files

[jbalonso]

Ok. A commit with --alow-insecure-ssl is forthcoming. Also, sign-offs, and using insecure_registry as the keyword argument instead of insecure for consistency with docker-py.

[bfirsh]

Great, thanks! Original commit still needs signing off though. You can squash all of this with git rebase -i master and signoff the single commit with git commit --amend --signoff.

[jbalonso]

I took care of the signoff in the squash, and I believe the ball is back in your court.

[bfirsh]

Great stuff, thanks!

[dnephin]

I just realized that this kwarg (insecure_registry) was only added to docker-py in 0.5.0, but right now in setup.py the minimum version is 0.3.2. I think for this change to be safe you need to change the docker-py requirement to:
docker-py >= 0.5, < 0.6

[dnephin]

Not sure why the travis build hasn't run on this branch, but I'm also getting a couple flake8 errors

[bfirsh]

Oops.

We've replaced Travis with Wercker, so this needs rebasing to get CI run on it.

[jbalonso]

I've fixed the docker-py dependency. I'll worry about rebasing (where should I rebase to? I see an "All is well -- build finished" on the PR) and figuring out the flakes tomorrow.

[bfirsh]

We only recently added the file that makes the build work. If you rebase on to the current master, it'll get the wercker.yml file to make the build work. You can run nosetests and flake8 fig locally to verify the things the build runs.

[jbalonso]

I've rebased, but I'm still cleaning up the branch.

[jbalonso]

Ok. A third force-push later, I believe I have cleaned up this PR.

[bfirsh]

LGTM

[bfirsh]

Don't think it's easy to test this without mocking out docker-py. :/

[dnephin]

At the very least a simple unit test that asserts the right docker.client function was called wouldn't hurt. ServiceTest already creates a mock_client

[bfirsh]

Oh cool, forgot about that. @jbalonso – would be great to get a test!

[moss]

I've added the missing unit test to ServiceTest. Please let me know if it needs any cleanup.

[bfirsh]

LGTM

[tjrivera]

Hey guys, it seems like Fig will also attempt to pull needed images when running fig up -- not just when fig pull is run explicitly. The insecure flag in this case would have to be also passed at Project.up then through here: https://github.com/docker/fig/blob/master/fig/project.py#L175 and ultimately out to here: https://github.com/docker/fig/blob/master/fig/service.py#L182 where pull is being run again. I can work on a PR if this makes sense.

[jbalonso]

I kinda feel responsible for not catching that in my PR. I'll mention that I'm out of bandwidth to work on it myself at the moment.

[dnephin]

I've run into this as well. I got around it for now by always doing a fig pull --allow-insecure-ssl first but it would be nice to not have to do that.

I think your solution sounds appropriate.

[torbjornvatn]

I've also run into this, and I really would like to call fig pull --allow-insecure-ssl directly. Are you working on a PR @tjrivera or should I try to fix this at work tomorrow?

[tjrivera]

@torbjornvatn I was planning on submitting a PR tomorrow morning

[torbjornvatn]

@tjrivera Nice!