Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Missing ulimits on docker.running / dockerng.running #30802
Besides the missing ulimits there are also other missing options that we would like to have supported.
Also related is other functions (like create) that have their own set of supported options as listed below:
One thought I had was instead of the dockerng module needing to implement each of these options for each supported function you could add an "arg" property or whatever name makes sense that would allow us to pass through whatever options Docker supports. That way as Docker adds or removes options for each of the functions in subsequent releases, SaltStack will not have to worry about keeping these in sync and releasing updates so frequently while allowing us to use whichever options we deem necessary.
Working on this right now.
I'm also working on a more elegant solution moving forward so that we can more gracefully handle new arguments as they are added to docker-py.
The reason for the inflexible code for comparing the container to the desired configuration has to do with a couple issues: First, when I wrote dockerng, docker-py had no means of taking arguments and returning a configuration that could be compared against the return data from inspecting a container. So, all API arguments had to be mapped to their location in the inspect return. Second, I was trying to come up with a CLI-friendly means of passing arguments to the execution module, since docker-py accepts complex structures which are not easy to represent on the CLI. The state needed to support accepting input using the CLI format as well, so we needed to translate the input into what it would end up looking like in the inspect results.
The plan for the future is to take the arguments passed to the
The one downside is that if there is a more sane CLI representation of the argument, the CLI usage would not always immediately be supported. We would in some cases need to add code to translate CLI usage to the data structure the API expects. However, one could still use newly-added arguments by formatting them in the data structure that docker-py expects.
#39530 has been opened to track the progress of that task.
#39562 has been merged, ulimit support will be in 2016.3.6, 2016.11.4, and the upcoming Nitrogen feature release.
I'm also efforting to get the more elegant method of container management described in my earlier comment in for Nitrogen, but it may need to wait until the following feature release.