Classic confinement review request

Please review revision 3:
https://snapcraft.io/account/snaps/fcbtest/release

source:

Classic confinement is used as rally uses the ‘multiprocessing’ python module
which uses shared memory and accesses paths blocked via AppArmor policies of
snapd which leads to segfaults when any of the rally tools are used
see https://bugs.launchpad.net/snapcraft/+bug/1577514
Python multiprocessing sem_open blocked in strict mode

same confinement used in separate rally snap itself for the same reason:

Please see this comment by @sparkiegeek as there might be a workaround to avoid using classic confinement:

1 Like

This would require building our own python2 version with that patch applied. That would probably cause some package version issues since this would be a custom version.

I don’t think this was ever applied for 2.7 (which we have to stick to currently for rally due to some py3 compatibility issues):
https://hg.python.org/cpython/rev/1b5506fc6a50

No semprefix here:


@noise @popey @cprov @evan @kyrofa @Wimpress @mvo @natalia

Folks, could somebody please review this so we can upload and use this snap for field engineering purposes in customer projects?

Both @alitvinov and I are from the Canonical Field Engineering team - it is quite pressing for us to have this in the store so that the snap can be downloaded via proxy servers in confined environments.

Thanks in advance.

@dmitriis - note that classic doesn’t require a voting process but we need to understand the issue and vet the publisher. It isn’t clear to me why you need classic as there is an upstream patch to python 2.7 for precisely this. There is also the ability to pick up the work to modify snapcraft-preload and I don’t see any mention of attempting that route.

Are you using stage-packages for python2.7? Have you considered an SRU to ptyhon2.7 in Ubuntu that includes the patch @sparkiegeek mentioned?

@jdstrand

The upstream patch is not applicable to python2.7 as is. It seems small but it is not because it applies on top of this rework that went into 3.4:

So, yes, the patch below is 3 lines of non-comment changes but it relies on a huge rework which will not be SRU-ed for sure in my view. This is likely the reason for those changes not being in 2.7 upstream in the first place.

git --no-pager tag --contains=84ed9a68bd9a13252b376b21a9167dabae254325 
v3.4.0
v3.4.0a2
v3.4.0a3
# ...

Our main criterion right now is time and we have a goal of getting a minimum viable product that we can use for a narrow use-case. We have already spent a lot of time on trying to use python3 and failed because the target software (rally) does not fully support python3. I applied several patches on top of rally to go forward with using python3 but I stopped doing that after 5 or so patches.

With the python patch not being applied upstream for 2.7 I do not think it is worthwhile to even try an SRU.

We are using python2.7 as a stage package because there is no python2 in the core snap.

In all seriousness, we do not have time to fix the underlying toolchain and runtime problems if they are not blockers because other customer work takes priority if we spend too much on trivial things like running a multi-process python application (it is not our call to allocate time for this, sorry). If usage of classic confinement was a blocker issue that work would get priority and we would work on it - but this is not the case.

Now that I described the problems in more detail could you help us to proceed with vetting?

1 Like

I’ve vetted the publisher and granted use of classic. I’d like to see this use case supported in strict mode (perhaps via snapcraft-preload), but it unfortunately isn’t yet.

1 Like