I feel like I'm so close to this working, but I have one hurdle I can't quite overcome. I'm developing a Ubuntu Snap which contains all the runtime components we require for our greengrass deployments (node, python, java, etc.). After install, the entrypoint of my main snap daemon checks to see if a greengrass install exists at $SNAP_COMMON and if not, tries to initialize greengrass as follows:
java \
-Droot="${GG_ROOT}" \
-Dlog.store=FILE \
-Djava.io.tmpdir=$GG_TMP \
-Djava.class.path=$SNAP/usr/lib/jvm/java-11-amazon-corretto/lib:/usr/lib \
-Duser.home=$HOME \
-jar $GG_ROOT/Greengrass.jar \
--component-default-user ggc_user:ggc_group \
--root $GG_ROOT \
--start false \
--setup-system-service false \
--provision true \
--aws-region ${AWS_REGION:=us-east-1} \
--thing-name $THING_NAME \
--thing-group-name ${THING_GROUP:=Default} \
--thing-policy-name $THING_POLICY_NAME \
$GG_ROOT
is set to $SNAP_COMMON/greengrass/v2
(comes out to something like /var/snap/my-snap/greengrass/v2
).
$GG_ROOT/Greengrass.jar
is copied from my snap (which I include during the snap build process)
$THING_NAME
, $THING_GROUP
, etc. are set by sourcing an identity file installed on each server.
This seems to almost work. Greengrass.jar
extracts everything to $GG_ROOT
except for alts/init/distro
... For some reason that get's unpacked to $SNAP
(so $SNAP/bin
has greengrass.exe
, loader
, etc.). If I set start
to true, it launches correctly and I even get logs at $GG_ROOT/logs
, it's just the initial deployment goes off to lala land. I haven't tried issuing a new deployment in this configuration, but can't imagine it'd work (since there are no symlinks).
Would anyone happen to have a little insight into why the initial nucleus deployment is unpacking at $SNAP
here instead of $GG_ROOT/packages/...
and symlinked to $GG_ROOT/alts/init
. I feel like if I can figure out this init deployment, it should work... :crossed_fingers:
Code tracing:
I think my issue can start tracing at KernelAlternatives:
private Path getAltsDir() {
return nucleusPaths.kernelAltsPath().toAbsolutePath();
}
which I think ultimately ends up somewhere around KernelCommandLine:146
kernel.getConfig().lookup("system", "rootpath").dflt(rootAbsolutePath)
.subscribe((whatHappened, topic) -> initPaths(Coerce.toString(topic)));
}
which leads to KernelCommandLine:166.
private void initPaths(String rootAbsolutePath) {
...
}
Unfortunately this doesn't really explain why the install gets split up... since kernelAltPaths
is relative to rootPath
, which should be getting set to $GG_ROOT
:(
If I leave off
--root
and-Droot
settings, the same thing happens, but it uses the default~/.greengrass
for everything except the actual nucleus artifact, which still gets extracted to$SNAP
After creating the typical symlinks around
alts/current
/alts/init
and then moving the nucleus artifacts from$SNAP
to their usual location$GG_ROOT/alts/current/distro/...
. The daemon launches, but then trying to run a deployment results incom.aws.greengrass.componentmanager.exceptions.PackageLoadingException
(java.io.IOException: Mount point not found
) on the packages dir. It seems the JVM doesn't like thesquashfs
.I did find this log during install:
com.aws.greengrass.deployment.DeviceConfiguration: Unable to set up Nucleus from build recipe file.
(java.io.IOException: Unable to locate the unpack directory of Nucleus Jar file
).I figured out what I'm seeing in
$SNAP
is actually just an artifact of a poorsnapcraft.yaml
file. Those Greengrass install files are there because we didn't properly build that part of the snap.We're putting this on the back-burner for now as we have to get something out that actually works now, but being able to snap this would make our life a little easier (we could move to ubuntu-core to better manage the underlying OS).