Hi, All. I just wanted to comment that this particular convention is well supported by and very helpful when using yargs (and by extension gpii-launcher). Individual launcher components can choose to only retrieve variables within a particular namespace prefix <http://yargs.js.org/docs/#methods-envprefix>, which helps avoid polluting options with the dozens of common environment variables a profile will typically set. This is already possible with the current implementation, it's just a matter of passing the prefix as part of your launcher options.
Anyway, it's a definite +1 from me on this. Cheers, Tony On Tue, May 23, 2017 at 7:42 PM, Tirloni, Giovanni <[email protected]> wrote: > 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 >
_______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
