[Avocado-devel] Make some avocado.utils.process APIs compatible with macOS

[Cleber Rosa]

On 03/04/2017 07:36 AM, Lucas Meneghel Rodrigues wrote:
> Let's discuss this particular topic a little bit.
> 
> So I dedicated some time to make avocado self tests to run on macOS
> (see https://github.com/avocado-framework/avocado/pull/1834). This would
> be a first step to make macOS (new name of what was known as Mac OS X) a
> 2nd tier supported platform. This would interesting from a project
> health perspective since attracting macOS developers would expand user
> base and mind share.
> 

+1 on this.  As mentioned during the meeting, even if we'd not attract
other developers and users (which is certainly not the case), it'd
probably be beneficial to the overall architecture and/or implementation
of Avocado.

> Now, some of the avocado.utils.process APIs (example, get_children_pids)
> rely on executing 'ps' as a subprocess. We implemented those functions
> contradicting our own rules of avoiding relying on subprocesses, but it
> was the pragmatic choice at the moment.
> 

Right.  I'm looking at the exact places we do this, and quickly
evaluating how hard it would be to get the same info from the more
direct (and platform dependent) source.  For instance, on
`avocado.utils.process.kill_process_tree()` we have the execution of
`"ps --ppid=%d -o pid=` which could be replaced by a
`get_children_processes()` that would adapt to the supported platforms.

> macOS does have coreutils, but they all come from BSD, not GNU. The
> macOS version of 'ps' does not support the command line arguments that
> make the APIs to return the correct values. It stands to reason that, if
> we want to make avocado more portable among platforms, we should look
> for, well, more portable implementations.
> 

Agreed.

> For that particular case, the excellent 3rd party 'psutil' library gives
> us all the facilities implemented in a portable way so that it would
> just work under macOS (and possibly other systems). Summarizing the choices:
> 

The goal of making Avocado run on other platforms (such as macOS) may
conflict with making Avocado run *easily* on many platforms, and this is
a very good example.  We have been working hard to minimize dependencies
for the *basic* Avocado test runner, and since `avocado.utils.process`
is used on it, it would be step in the opposite direction.

> 1) Use 'psutil' but then introduce an EPEL dependency on RHEL platforms.
> I know some of the groups using avocado have been pushing for a core
> program that does not rely on EPEL, so for those guys, that solution is
> a no-go.
> 

Yep, a bad idea for a lot of people, as mentioned before.

> 2) 'borrow' the psutil implementations and put them in avocado, which is
> frowned upon by Fedora and RHEL and pretty much every distro packager
> ever. I don't like that idea.
> 

If we just need 2 or 3 portable functions, we can either borrow the idea
(or if the licensing allows) the code itself.

> 3) Remove the offending APIs. That would be a valid solution, although
> capping existing functionality is not something that I fancy. We are
> still with a liability of having avocado libs relying on parsing
> external subprocess outputs, which is bad for a number of reasons and it
> should be addressed at some point.
> 

We can rewrite how Avacado currently does that on Linux, by using, say,
the /proc filesystem.

> 4) Simply say the APIs are not supported on macOS. It's also valid but
> then it would be interesting to start delimiting linux specific APIs to
> a namespace (think avocado.utils.linux, avocado.utils.darwin,
> avocado.utils.nt) to make things clear from the get go.
> 

-1

> 5) Forget about the whole 'support non-linux' idea.
> 

-1

> Let me know your thoughts on the subject.
> 

Let's try to identify what we *really* need to support here, and decide
if they deserve a borrowed idea and/or implementation from psutil.

I'd expect them to be fairly simple that we can write and maintain in
Avocado itself.

> Cheers,
> 
> Lucas
> 
> 

Thanks for you work on this!

-- 
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20170306/ab6849b0/attachment.sig>