Enabled modules in container yaml

I am a little stuck on how to activate the event streams module in 8.3 running in kubernetes.

I have this line in my yaml config:
- name: GATEWAY_MODULES_ENABLED
value: "allen-bradley-drivers,vision,perspective,eventstream,mssql,postgresql,bacnet-driver,dnp3-driver,logix-driver,modbus-driver-v2,omron-driver,opc-ua,siemens-drivers,udp-tcp-drivers,web-developer"

( I also want to enable postgresql and mssql and have same problem) - I do not know what name the module has - I tried using the data/api/v1/resources/names/com.inductiveautomation.opcua/device

API from python to list disabled modules (YES; API!!!) , and I get a list, but it seems to not correspond to the expected name in GATEWAY_MODULES_ENABLED

com.inductiveautomation.sfc SFC
com.inductiveautomation.sqlbridge SQL Bridge
com.inductiveautomation.jdbc.mariadb MariaDB JDBC Driver
com.inductiveautomation.eventstream Event Streams
com.inductiveautomation.jdbc.postgresql PostgreSQL JDBC Driver
com.inductiveautomation.sms-notification SMS Notification
com.inductiveautomation.opcua.drivers.mitsubishi Mitsubishi Driver
com.inductiveautomation.opcua.drivers.micro800 Micro800 Driver
com.inductiveautomation.opcua.drivers.siemens-symbolic Siemens S7 Symbolic Driver
com.inductiveautomation.reporting Reporting
com.inductiveautomation.phone-notification Voice Notification
com.inductiveautomation.connectors.kafka Kafka Connector
com.inductiveautomation.symbol-factory Symbol Factory
com.inductiveautomation.alarm-notification Alarm Notification
com.inductiveautomation.jdbc.mssql MSSQL JDBC Driver
com.inductiveautomation.opcua.drivers.iec61850 IEC 61850 Driver
com.inductiveautomation.eam Enterprise Administration
com.inductiveautomation.historian Historian
com.inductiveautomation.historian.sql SQL Historian
com.inductiveautomation.opcua.drivers.dnp3v2 DNP3 Driver

I would of course like to know the names, so I can get unstuck, but I’d also love to know where I can find this myself

I cannot enable the modules from the UI

The reverse DNS name identifiers "should" be used (as far as I know).
@kcollins1 can probably advise more :smiley:

These are typically what are used for the fully-qualified module ID. If you want to extract the module ID for a given module, you can run the following (on Linux/macOS/WSL2 with unzip and xmlstarlet CLI tools installed):

unzip -c -q /path/to/module.modl module.xml | \
  xmlstarlet sel -t -v "/modules/module/id" ; echo

For example, this shows how to retrieve the module ID from Cirrus Link’s MQTT Transmission Module:

Since Event Streams (and the module-based JDBC drivers) is new with 8.3.0, you must use its fully qualified module ID, com.inductiveautomation.eventstream (as shown in the docs that @paul-griffith linked :folded_hands: ).

Also of note is that these identifiers can also be used with the new ACCEPT_MODULE_LICENSES and ACCEPT_MODULE_CERTS environment variables to apply automated acceptance of the applicable licenses and certificates for third-party modules. No more hackery needed to get a fresh out-of-box Ignition Gateway with third-party modules in a ready and Running state.

2 Likes

I should also mention for others who might be otherwise unaware that with Ignition 8.3, installation of third-party modules within our container image now flow to an area within the data volume. Module enabled/disable status is also persisted there. You no longer need to bake in third-party modules into a derived image to make sure that they’re still there on container lifecycle events.

If you are driving GATEWAY_MODULES_ENABLED, you’ll notice that you cannot enable/disable modules through the web UI. This is by-design, as declaring this variable implies locking in the set of enabled modules. Finally, with the container image, built-in modules (i.e. ones in the image under /usr/local/bin/ignition/user-lib/modules) cannot be uninstalled through the web UI. You might notice that you could do this with the Ignition 8.1.x container image, but the modules would magically re-appear if you recreated the container.