That sounds good to me! We are unlikely to hit any OS limits [0][1].
0 - https://blogs.msdn.microsoft.com/oldnewthing/20100203-00/?p=15083 1 - python -c "import os; os.environ['A'*32768] = '1'; print os.environ['A'*32768]" On 05/23/2017 02:24 PM, Antranig Basman wrote: > +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:[email protected]] On Behalf Of >> Tirloni, Giovanni >> Sent: May 17, 2017 7:51 AM >> To: [email protected] Architecture <[email protected]> >> 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 >> [email protected] >> http://lists.gpii.net/mailman/listinfo/architecture >> _______________________________________________ >> Architecture mailing list >> [email protected] >> http://lists.gpii.net/mailman/listinfo/architecture >> > > _______________________________________________ > Architecture mailing list > [email protected] > http://lists.gpii.net/mailman/listinfo/architecture > _______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
