+1 - I further propose we prefix them with GPII_ to make responsible use
of this OS-wide shared space of names. GPII_PREFERENCES_SERVER_PORT?
This corresponds more closely with our use of global names within
JavaScript processes.
On 23/05/2017 17:23, Gill, Avtar wrote:
+1 for prefixing deployment-related environment variables with component names.
Avtar
-----Original Message-----
From: Architecture [mailto:architecture-boun...@lists.gpii.net] On Behalf Of
Tirloni, Giovanni
Sent: May 17, 2017 7:51 AM
To: architecture@lists.gpii.net Architecture <architecture@lists.gpii.net>
Subject: [Architecture] Standardizing environment variable names
Hello,
With the work being done by Antranig/Tony on new ways to configure components
through environment variables and files [0][1], it seems important to
standardize how they are named.
I would like to propose we prefix the variables with the component's name:
POUCH_MANAGER_
LIFECYCLE_MANAGER_
PREFERENCES_SERVER_
FLAT_MATCHMAKER_
CANOPY_MATCHMAKER_
FLOW_MANAGER_
RAW_PREFERENCES_SERVER
DEVICE_REPORTER_
So for the Preferences Server, we would have the following environment
variables:
PREFERENCES_SERVER_PORT = integer
PREFERENCES_SERVER_COUCHDB_URL = string
PREFERENCES_SERVER_LOGGING = boolean
Similarly for the Flow Manager:
FLOW_MANAGER_PREFERENCES_URL = string
FLOW_MANAGER_MATCHMAKER_URL = string
Of all the components in GPII, we (DevOps team) have only had the need to
configure the Preferences Server and the Flow Manager so far, for our
cloud-based deployments.
Additionally, the entire flexibility of the config files cannot be expressed through
environment variables, so the latter would only be used for the most common/used
configuration settings while leaving the config files for the full "experience"
of configuring the GPII.
During the F2F in Toronto we also had questions about if we should have new
config files dedicated to declaring these env variables, who should own them,
etc. I'm hoping the env vars prove useful enough for CI and also developers
that we can embedded them into the most commonly used config files. That would
enable us to provide Docker containers that would be useful during the
development workflow too (making it easier for developers to create custom
scenarios).
How does everybody feel about this?
1 - https://github.com/fluid-project/kettle/pull/33
2 - https://github.com/the-t-in-rtf/gpii-launcher
Regards,
Giovanni
_______________________________________________
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture
_______________________________________________
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture
_______________________________________________
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture
