Remap user-level environment to system-level for services.

[kyrofa]

Currently Snappy services define $SNAP_APP_USER_DATA_PATH to be within /root/apps, however, there is no logic to create the $SNAP_APP_USER_DATA_PATH like there is within binary wrappers, which means any service that tries to use $SNAP_APP_USER_DATA_PATH is trying to use a non-existing directory.

Having services write caches or logs into /root doesn't really make sense anyway, so this PR remaps the user-level environment into the system-level environment (i.e. $SNAP_APP_USER_DATA_PATH now =
$SNAP_APP_DATA_PATH) for services.

Fixes LP: #1527612

[snappy-m-o]

Can one of the admins verify this patch?

[mvo5]

Thanks for adding a comment here, maybe add a tiny bit more like "Remap user-level environment to system-level for services. The code will append "apps/$appname/$version" to this path"

[mvo5]

Thanks for this branch! Looks excellent :) One tiny suggestion for the comment inline, but no blocker at all.

[kyrofa]

@mvo5 thanks for the review! I've updated the comment as you suggested.

[kyrofa]

It would be great if we can get this back into 15.04 as well.

[chipaca]

ok to test

[chipaca]

👍

[chipaca]

retest this please

[elopio]

The integration tests error is not related to this branch. I'm fixing it here: ubuntu-core#284

Also, I propose we add kyrofa to the whitelist: ubuntu-core/snappy-jenkins#35

[elopio]

@kyrofa could you write an integration test that installs and runs a snap with a service that logs something?
We have a bunch of simple snaps for testing here: https://github.com/ubuntu-core/snappy/tree/master/integration-tests/data/snaps
And here are some tests that you can use as a base: https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/examples_test.go

Let me know if you need a hand. :D

[kyrofa]

@elopio sure! Thanks for fixing the integration tests 😛 .

[niemeyer]

A couple of questions: does it make sense for a service application to be using the user data directory, if there's no associated user? How/why would that happen?

Then, if the application does make a distinction between those, isn't it problematic that we're mapping two paths that are generally taken to be in different places pointing to the same directory? I can easily imagine an application using conflicting names within the two directories (e.g. "config" in both).

[kyrofa]

A couple of questions: does it make sense for a service application to be using the user data directory, if there's no associated user? How/why would that happen?

@niemeyer Ideally no. My particular use-case is ROS. roscore writes a log to a location determined by an environment variable, which by default is $HOME/.ros. The snapcraft plugin sets it up to log to $SNAP_APP_USER_DATA_PATH/ros. This works for binaries, but for services it hits the bug this PR is trying to fix.

You have a good point, though. I don't think we should have an environment variable pointing to an invalid location (like we do now), but perhaps the better fix would be to actually create that directory instead of remapping it. Perhaps the creation of user data paths should be moved within ubuntu-core-launcher instead of the binary wrappers, which would allow services to have that functionality as well. Thoughts?

[niemeyer]

Agreed it would be nice to have the user data directory present at all times, so applications wouldn't have to worry themselves about which context they're running under. I'm concerned about the interaction between this issue and what we're addressing in #264, though. At the time, it sounded like using /root was the right thing to do for sudo. But now we have another facet of the same problem, because /root ends up being picked for the services merely because that's the user they run as. Isn't it awkward that when run as "a service" (a concept we're trying to deprecate slightly, see context in snappy-devel@) an application would use /var/lib as its user data path, and when run under sudo, it would use /root?

[kyrofa]

Agreed, the inconsistency is bothersome. We can resolve it if we scrap this PR and move the user data directory creation into ubuntu-core-launcher, yes? That at least allows ROS services to run, even if they don't log to an ideal location.

[niemeyer]

Please let me have a conversation with the team tomorrow first, so you don't waste any time. First thing to do is to decide what is the convention we want for snap data storage in general.

[kyrofa]

Sounds good, let me know.

[niemeyer]

I'm closing this so we can more easily wait for it (or another PR) to reflect the agreement in the mailing list.