add dockerimage for pyff/md

[rhoerbe]

No description provided.

[rhoerbe]

now working with /etc/init.d stuff

[leifj]

I don't like the division between a pyff and pyffd image. I'd like a solution based on a single image and both should be based on the same base-image.

[rhoerbe]

Ah, I misunderstood. I proposed a single image, and the container to be instantiated via ENV to either md or mdx. Your response was to do it with CMD. So I assumed you wanted separate images. What did I miss?

Am 11.05.2015 um 09:35 schrieb Leif Johansson [email protected]:

I don't like the division between a pyff and pyffd image. I'd like a solution based on a single image.

—
Reply to this email directly or view it on GitHub #1 (comment).

[leifj]

On 05/11/2015 09:44 AM, Rainer Hörbe wrote:

Ah, I misunderstood. I proposed a single image, and the container to be
instantiated via ENV to either md or mdx. Your response was to do it
with CMD. So I assumed you wanted separate images. What did I miss

The fact that CMD doesn't require separate images! You can give CMD on
the commandline.

Am 11.05.2015 um 09:35 schrieb Leif Johansson [email protected]:

I don't like the division between a pyff and pyffd image. I'd like a
solution based on a single image.

—
Reply to this email directly or view it on GitHub
#1 (comment).

—
Reply to this email directly or view it on GitHub
#1 (comment).

[rhoerbe]

So no CMD in Dockerfile, but at start time:
docker run -d pyff_image /usr/local/bin/[pyff | pyffd]

Another point: Ubuntu's Vixie cron is not configurable to get rid of sending error messages via mail, and I could not find a debian port of cronie. Would you object to base the image on centos?

[leifj]

On 05/11/2015 10:41 AM, Rainer Hörbe wrote:

So no CMD in Dockerfile, but at start time:
docker run -d pyff_image /usr/local/bin/[pyff | pyffd]

something like that but you shouldn't have to give full path I think ...

Another point: Ubuntu's Vixie cron is not configurable to get rid of
sending error messages via mail, and I could not find a debian port of
cronie. Would you object to base the image on centos?

yeah a little bit... can you explain why you need cron in a docker image?

[rhoerbe]

Not quite sure if a script doing forever{pyff(); sleep(600)} is a robust approach. OTOH starting a new docker container every so often would not provide error tracing if there is a problem, I guess.

[rhoerbe]

FYI: The approach I proposed in the pull request is to have cron in the CMD, not as a second process in the container.

[leifj]

On 05/11/2015 11:11 AM, Rainer Hörbe wrote:

Not quite sure if a script doing forever{pyff(); sleep(600)} is a robust
approach. OTOH starting a new docker container every so often would not
provide error tracing if there is a problem, I guess.

Why not?

If you're running pyff every X then you might aswell run pyffd

[leifj]

On 05/11/2015 11:13 AM, Rainer Hörbe wrote:

FYI: The approach I proposed in the pull request is to have cron in the
CMD, not as a second process in the container.

I confess that I really don't like that solution.

[rhoerbe]

If you're running pyff every X then you might aswell run pyffd
Why not having one container each per pyff and pyffd?

Having more than 1 process (-group) per container is not dockerish. If you spawn multiple independent processes the right way is to use the linux startup system. But then you are running kind of a VM again.

[leifj]

On 05/11/2015 02:10 PM, Rainer Hörbe wrote:

If you're running pyff every X then you might aswell run pyffd
Why not having one container each per pyff and pyffd?

Having more than 1 process (-group) per container is not dockerish. If
you spawn multiple independent processes the right way is to use the
linux startup system. But then you are running kind of a VM again.

—
Reply to this email directly or view it on GitHub
#1 (comment).

I still don't see why running pyff inside cron is a great idea (but I'm
prepared to be convinced I'm wrong).

[rhoerbe]

Tradition and gut feeling - our ancestors have been using cron for scheduling tasks.

But given the implications of the Cronie -> Centos dependency, I do not have a problem doing the looping in a script.

However, I would like to run either pyff /or/ pyffd in a single container, not both.

[leifj]

On 05/11/2015 02:23 PM, Rainer Hörbe wrote:

Tradition and gut feeling - our ancestors have been using cron for
scheduling tasks.

But given the implications of the Cronie -> Centos dependency, I do not
have a problem doing the looping in a script.

But I don't understand why you can't do a cron-job outside the container?

If you need a way for pyff to do a run-sleep-run then it makes sense to
talk about that feature for pyff

However, I would like to run either pyff /or/ pyffd in a single
container, not both.

Yah sure.

[rhoerbe]

But I don't understand why you can't do a cron-job outside the container?
The only reason being that googeling for a solution only the cron-inside solutions came up. Without further research I was assuming that (1) there is a startup penalty (can’t be huge) or (2) logging issue (something not going to stdout/stderr or a mounted volume) and removing the container would remove the extra log.

If you need a way for pyff to do a run-sleep-run then it makes sense to
talk about that feature for pyff
Yes. If I could start pyff as a daemon and parameterize the invocation interval that would eliminate the discussion above.

[leifj]

On 05/11/2015 03:24 PM, Rainer Hörbe wrote:

But I don't understand why you can't do a cron-job outside the container?
The only reason being that googeling for a solution only the cron-inside
solutions came up. Without further research I was assuming that (1)
there is a startup penalty (can’t be huge) or (2) logging issue
(something not going to stdout/stderr or a mounted volume) and removing
the container would remove the extra log.

There are multiple ways to handle logs from containers that don't kill
the logs if you restart the container. I don't see that as a big issue.

If you need a way for pyff to do a run-sleep-run then it makes sense to
talk about that feature for pyff
Yes. If I could start pyff as a daemon and parameterize the invocation
interval that would eliminate the discussion above.

Gimme a pull-request :-)

—
Reply to this email directly or view it on GitHub
#1 (comment).