Closed jamesmcclain closed 8 years ago
@echeipesh might want to take a look at this, but I pulled it down and tested this out - things are registering as expected. This is a big +1 from me
I am not seeing the registration warnings in the /tmp/geomesa-register.log
from the master images. Changes to geomesa entry point address an existing bug. Testing locally to see if this is more stable than current state.
@echeipesh I saw this comment:
@@ -8,13 +8,12 @@ ROLE=${1:-} ACCUMULO_USER=${ACCUMULO_USER:-root}
if [ $ROLE = "register" ]; then
- wait_until_accumulo_is_available
- accumulo shell -u ${ACCUMULO_USER} -p ${ACCUMULO_PASSWORD} -e \
- "createnamespace geomesa"
- accumulo shell -u ${ACCUMULO_USER} -p ${ACCUMULO_PASSWORD} -e \
- "config -s general.vfs.context.classpath.geomesa=file:///opt/geomesa/accumulo/[^.].*.jar"
- accumulo shell -u ${ACCUMULO_USER} -p ${ACCUMULO_PASSWORD} -e \
- "config -ns geomesa -s table.classpath.context=geomesa"
- wait_until_accumulo_is_available ${INSTANCE_NAME}
- HDFS_GEOMESA_RUNTIME="/${INSTANCE_NAME}-classpath"
This would conflict if geowave and geomesa shared an HDFS instance, with both iterators in the same HDFS path.
So should HDFS_GEOMESA_RUNTIME be changed to /geomesa-classpath ?
These changes cause the GeoMesa iterators to be registered when the GeoMesa master comes up. Also, the GeoMesa tarball is now downloaded to the host instead of in the container during the build process, which tightens-up the feedback loop by allowing the tarball to be kept (instead of re-downloaded).
This does not depend on geodocker/geodocker-accumulo#12, but my consistent registration branch does depend on that PR and this one. That branch has not been made into a a PR, because it will fail without geodocker/geodocker-accumulo#12.