Cheatsheet

1. root service commands

As root unix user:

Command	Description
service metwork start	start all installed metwork services
service metwork stop	stop all installed metwork services
service metwork status	check all installed metwork services
service metwork start mfdata	start mfdata metwork services
service metwork stop mfdata	stop mfdata metwork services
service metwork status mfdata	check mfdata metwork services

Note: if you don't have service command on your Linux distribution, you can use /etc/rc.d/init.d/metwork instead of service metwork. For example: /etc/rc.d/init.d/metwork start instead of service metwork start. If your Linux distribution uses systemdcomponent, you can also start metwork services with classic systemctl commands.

2. root files or directories

Path	Description
/etc/metwork.config.d/mfdata/config.ini	override the mfdata module configuration at system level (note: the first line of this file must be [INCLUDE_config.ini])
/opt/metwork-mfdata/config/config.ini	default mfdata module configuration (useful to see all configuration options) (do not edit this file => use the overriding previous file)
/etc/metwork.config.d/mfdata/plugins/	put some .plugin files here and they will be installed during mfdata service startup, put some .ini file fragments here as {plugin_name}.ini and they will be used as configuration override for the specified plugin

3. "load environment" commands

As a "not metwork" unix user (useless if you are logged as a "mfxxx" unix user as the "metwork environment" is already loaded):

Command	Description
source /opt/metwork-mfdata/share/interactive_profile	load the mfdata metwork interactive environment
source /opt/metwork-mfdata/share/profile	load the mfdata metwork environment (same as above but without fancy stuff about banner, colors and prompt)
/opt/metwork-mfdata/bin/mfdata_wrapper {YOUR_COMMAND}	execute the given command in the mfdata metwork environment without changing anything to the current environment

Note: if you don't have /opt/metwork-mfdata symbolic link, use /opt/metwork-mfdata-{BRANCH} instead.

4. module commands

As mfdata user:

Command	Description
mfdata.start	start mfdata services
mfdata.stop	stop mfdata services
mfdata.status	check mfdata services
layers	list installed layers (loaded layers are prefixed by (*)), layers --help for more details
layer_load {LAYER_NAME}	load the given layer (which must be installed), example: layer_load python2_devtools@mfext
layer_unload {LAYER_NAME}	unload the given layer (which must be loaded), example: layer_unload python2@mfext
components	list installed software components (loaded components are prefixed by (*)), components --help for more details
metwork_debug	debug the current environment (layers, paths, versions...), useful for debugging or bug reporting
outside {YOUR_COMMAND}	execute the given command outside the metwork environment without changing anything to the current environment

5. plugins management commands

As mfdata unix user:

Command	Description
plugins.list	list installed plugins
plugins.install {/full/path/file.plugin}	install the given plugin file
plugins.uninstall {plugin_name}	uninstall the given plugin name (the "plugin name" is given in the first column of the plugins.list output)
plugins.info {plugin_name}	get some informations about the given plugin name (must be installed)
plugins.info {/full/path/file.plugin}	get some informations about the given plugin file (does not need to be installed)
plugin_env {plugin_name}	enter (interactively) in the given plugin environment
plugin_wrapper {plugin_name} {YOUR_COMMAND}	execute the given command in the given plugin environment (without changing anything to your current environment), useful for cron jobs

6. plugins development commands and files

6.1 bootstrapping and building

As mfdata unix user, inside a plugin directory for make commands (you must have a Makefile and config.ini files inside the current working directory):

Command	Description
bootstrap_plugin.py list	list available plugin templates
bootstrap_plugin.py create --template={TEMPLATE} {PLUGIN_NAME}	bootstrap a plugin directory {PLUGIN_NAME} from the given template
make develop	install the current plugin in "development mode" (devlink)
make release	release the current plugin as a .plugin file
make	refresh the virtualenv or node_modules from requirements file
make clean	"clean" the current plugin and keep only "non generated" files and directories (you should commit the remaining ones to your favorite version control system) ; after that, use make to regenerate the virtualenv or node_modules
make superclean	same as clean target but also drop requirements2.txt, requirements3.txt and/or package-lock.json which can lead to a dependencies update (they are not frozen anymore) during next make call

6.2 interesting files inside the plugin directory

Relative path	Description
config.ini	main plugin configuration file
Makefile	build configuration file (you probably don't need to touch this unless you have specific build directives to add to the custom:: target)
local/	local subdirectory (it mainly holds the python virtualenv), never touch this it's automatically generated)
bin/	if you put an executable in this directory, it will be available in PATH (in your plugin environment)
lib/	this library directory will be available in LD_LIBRARY_PATH and in PYTHONPATH (in your plugin environment), so you can put here shared libraries or python files you want to include easily
postinstall	if this executable file is present during plugin installation, it will be automatically executed in the plugin environment just after the installation
python3_virtualenv_sources/ requirements-to-freeze.txt	main requirements file for python3 plugins (you shouldn't freeze versions here), replace 3 by 2 for python2 plugins.
python3_virtualenv_sources/ requirements3.txt	frozen requirements file for python3 plugins (generated from requirements-to-freeze.txt file, deleted by make superclean, commit this file to your VCS to freeze your dependencies), replace 3 by 2 for python2 plugins.
python3_virtualenv_sources/ allow_binary_packages	file to delete if you don't want pip to use binary packages (it will try to compile them during install)
.layerapi2_label	layerapi2 file to hold the plugin name as plugin_{plugin name}@module_in_lowercase
.layerapi2_dependencies	layerapi2 file to hold the layers to load when entering the plugin environment (you can also put some plugins with the syntax plugin_{other plugin name}@module_in_lowercase to inherit from another plugin
.layerapi2_extra_env	can be used to define extra environment variables in your plugin environment (see layerapi2 documentation)
.autorestart_includes	file patterns (gitignore syntax) scanned for changes to trigger a plugin autorestart
.autorestart_excludes	file patterns (gitignore syntax) to exclude for scanning (see above)
.plugin_format_version	version of the framework used to bootstrap the plugin (don't change this, this is used for backward compatibility)
.releaseignore	file patterns (gitignore syntax) to ignore in the release .plugin file

Note: mandatory files are in bold, all these files are not created by default (it mainly depends on the template you used) but you can create them afterwards.

Note: mandatory files are in bold, all these files are not created by default (it mainly depends on the template you used) but you can create them afterwards.