/usr/bin/ps missing from fedora:22 docker base image

[Brian Exelbierd]

Hi,

It appears that /usr/bin/ps was dropped as it was an indirect dependency 
in f21.  Can we put it back?  If this was a purposeful decision, can 
someone point me at the thread as I couldn't find the discussion.

The dependency chain, for those interested was:

procps needed by initscripts needed by dhclient|ppp needed by 
NetworkManager needed by rolekit needed by 
fedora-release-server|generic-release-server needed by generic-release 
needed by fedora-repos needed by fedora-release

Thank you.

regards,

bex

[Haïkel]

Le 7 juil. 2015 18:20, "Brian (bex) Exelbierd"  a écrit :
> Hi,
>
> It appears that /usr/bin/ps was dropped as it was an indirect dependency

in f21.  Can we put it back?  If this was a purposeful decision, can
someone point me at the thread as I couldn't find the discussion.
>

Looks like a bad idea, you don't need it in a container.
> The dependency chain, for those interested was:
>
> procps needed by initscripts needed by dhclient|ppp needed by

NetworkManager needed by rolekit needed by
fedora-release-server|generic-release-server needed by generic-release
needed by fedora-repos needed by fedora-release
> Thank you.
>
> regards,
>
> bex
> _______________________________________________
> cloud mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Brian Exelbierd]

> On Jul 7, 2015, at 6:25 PM, Haïkel  wrote:
> Le 7 juil. 2015 18:20, "Brian (bex) Exelbierd" <[e-mail] > a écrit :
> > Hi,
> >
> > It appears that /usr/bin/ps was dropped as it was an indirect dependency in f21.  Can we put it back?  If this was a purposeful decision, can someone point me at the thread as I couldn't find the discussion.
>
> Looks like a bad idea, you don't need it in a container.

There is certainly a set of use cases where this is true.  There are others where it is not.  I think that if we are not going to include this command, we need to explain the target and use cases for our image on https://getfedora.org/en/cloud/download/docker.html https://getfedora.org/en/cloud/download/docker.html clearly so that people who know it is in other distributions are not confused and think it is an oversight.

regards,

bex

[Brian Exelbierd]

Update:

After the fedora-cloud meeting last week, I was asked to create a ticket:

https://fedorahosted.org/cloud/ticket/112

and a wiki page outlining the idea of ultimately getting our image to be 
as minimal as possible:

https://fedoraproject.org/wiki/User:Bex/docker_image_reduction

Comments are appreciated.

regards,

bex

On 07/07/2015 07:42 PM, Brian (bex) Exelbierd wrote:
> > On Jul 7, 2015, at 6:25 PM, Haïkel <[e-mail]
> > > wrote:
> >
> > Le 7 juil. 2015 18:20, "Brian (bex) Exelbierd" <[e-mail]
> > > a écrit :
> > > Hi,
> > >
> > > It appears that /usr/bin/ps was dropped as it was an indirect
> >
> > dependency in f21.  Can we put it back?  If this was a purposeful
> > decision, can someone point me at the thread as I couldn't find the
> > discussion.
> > >
> >
> > Looks like a bad idea, you don't need it in a container.
>
> There is certainly a set of use cases where this is true.  There are
> others where it is not.  I think that if we are not going to include
> this command, we need to explain the target and use cases for our image
> on https://getfedora.org/en/cloud/download/docker.html clearly so that
> people who know it is in other distributions are not confused and think
> it is an oversight.
>
> regards,
>
> bex
>
> cloud mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Joe Brockmeier]

On 07/07/2015 05:25 PM, Haïkel wrote:
> Looks like a bad idea, you don't need it in a container.

That may be, but doesn't really answer the question of how it was
decided that it be dropped. If it's an incidental/accidental thing, we
should have a discussion of whether there's general agreement on this
assertion.

(Presumably it's always possible to pull in ps or other tools in a
container, so this isn't quite as drastic as deciding to drop something
in an Atomic Host...)

Best,

jzb

[Haïkel]

Le 8 juil. 2015 00:22, "Joe Brockmeier"  a écrit :
> On 07/07/2015 05:25 PM, Haïkel wrote:
> > Looks like a bad idea, you don't need it in a container.
>
> That may be, but doesn't really answer the question of how it was
> decided that it be dropped. If it's an incidental/accidental thing, we
> should have a discussion of whether there's general agreement on this
> assertion.

Longer answer:

I was not closing the discussion as it's something that will be decided by
the group. but having ps in a container means that we're treating it as a
virtual machine.
That's a huge change of the paradigm and not something we should encourage.

Moreover,  the use case mentioned is not supported: PS is here used to
retrieve process PID in a SysV init scripts, something we're supposed not
to support anymore.
It may hide another issue but putting back ps is not the right thing to do.
Smarter effort would be making ps container-aware on the host if you need
advanced process management.

That's definitely not consistent with the Atomic host story, too.

Again, this is just my opinion.

H.
> (Presumably it's always possible to pull in ps or other tools in a
> container, so this isn't quite as drastic as deciding to drop something
> in an Atomic Host...)
>
> Best,
> jzb
>
> Joe Brockmeier | Community Team, OSAS
> [e-mail] | http://community.redhat.com/
> Twitter: @jzb  | http://dissociatedpress.net/
>
> cloud mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Michal Fojtik]

You know that you can do `docker exec CID` and inspect what is running
inside the container (for example troubleshoot problems?)
There are many use-cases where `ps` is super useful and the users will be
asking why this tool is present in centos/debian/rhel/etc but not
in F21.

On Wed, Jul 8, 2015 at 12:45 AM, Haïkel  wrote:
> Le 8 juil. 2015 00:22, "Joe Brockmeier"  a écrit :
> > On 07/07/2015 05:25 PM, Haïkel wrote:
> > > Looks like a bad idea, you don't need it in a container.
> >
> > That may be, but doesn't really answer the question of how it was
> > decided that it be dropped. If it's an incidental/accidental thing, we
> > should have a discussion of whether there's general agreement on this
> > assertion.
>
> Longer answer:
>
> I was not closing the discussion as it's something that will be decided by
> the group. but having ps in a container means that we're treating it as a
> virtual machine.
> That's a huge change of the paradigm and not something we should encourage.
>
> Moreover,  the use case mentioned is not supported: PS is here used to
> retrieve process PID in a SysV init scripts, something we're supposed not
> to support anymore.
> It may hide another issue but putting back ps is not the right thing to do.
> Smarter effort would be making ps container-aware on the host if you need
> advanced process management.
>
> That's definitely not consistent with the Atomic host story, too.
>
> Again, this is just my opinion.
>
> H.
> > (Presumably it's always possible to pull in ps or other tools in a
> > container, so this isn't quite as drastic as deciding to drop something
> > in an Atomic Host...)
> >
> > Best,
> > jzb
> >
> > Joe Brockmeier | Community Team, OSAS
> > [e-mail] | http://community.redhat.com/
> > Twitter: @jzb  | http://dissociatedpress.net/
> >
> > cloud mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/cloud
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
> cloud mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Haïkel]

2015-07-08 11:56 GMT+02:00 Michal Fojtik :
> You know that you can do `docker exec CID` and inspect what is running
> inside the container (for example troubleshoot problems?)

You meant docker top, that's why it makes ps all the more redundant in an image.
Most people wishing to have ps in the image are using containers as
virtual machines
which is not an use case supported.
Moreover, you can still use ps on the host to monitor those processes,
though it would
benefit to be container aware.

Cf Cloud PRD
https://fedoraproject.org/wiki/Cloud/Cloud_PRD#Requirement_.232:_Improved_Do...

"Docker is a popular tool for launching and managing *application containers*."
> There are many use-cases where `ps` is super useful and the users will be
> asking why this tool is present in centos/debian/rhel/etc but not
> in F21.

Which ones? The only use case so far presented here is at best sketchy.
Looks like trying to fix the wrong problem.

H.

[Michal Fojtik]

No, I mean that when you run the container in cluster (like in
Kubernetes/Atomic/OpenShift) you obviously
don't have "docker top" but you have "kubectl exec" or "oc exec". You don't
know on which node the container
runs and therefore you need to use the "exec" approach.

On Wed, Jul 8, 2015 at 12:11 PM, Haïkel  wrote:
> 2015-07-08 11:56 GMT+02:00 Michal Fojtik :
> > You know that you can do `docker exec CID` and inspect what is running
> > inside the container (for example troubleshoot problems?)
>
> You meant docker top, that's why it makes ps all the more redundant in an
> image.
> Most people wishing to have ps in the image are using containers as
> virtual machines
> which is not an use case supported.
> Moreover, you can still use ps on the host to monitor those processes,
> though it would
> benefit to be container aware.
>
> Cf Cloud PRD
>
> https://fedoraproject.org/wiki/Cloud/Cloud_PRD#Requirement_.232:_Improved_Do...
>
> "Docker is a popular tool for launching and managing *application
> containers*."
> > There are many use-cases where `ps` is super useful and the users will be
> > asking why this tool is present in centos/debian/rhel/etc but not
> > in F21.
>
> Which ones? The only use case so far presented here is at best sketchy.
> Looks like trying to fix the wrong problem.
>
> H.
> _______________________________________________
> cloud mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Haïkel]

2015-07-08 12:14 GMT+02:00 Michal Fojtik :
> No, I mean that when you run the container in cluster (like in
> Kubernetes/Atomic/OpenShift) you obviously
> don't have "docker top" but you have "kubectl exec" or "oc exec". You don't
> know on which node the container
> runs and therefore you need to use the "exec" approach.

Ok, that's much less sketchy than supporting SysV initscript installation.
To me, it's a matter of Kubernetes not exposing information that is available by
the underlying engine. First step would be opening a RFE to kubernetes/OpenShift
to make this available.
Requiring images to provide ps for this use is a *workaround*

Moreover, fixing deps in rolekit would just fix the original issue.
That would benefit to people using systemd-networkd (like our cloud
images) and wants to use
rolekit.

H.

[Haïkel]

Let's put this in today's meeting agenda.