Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default Options File #11

Open
wiremine opened this issue Nov 28, 2012 · 2 comments
Open

Default Options File #11

wiremine opened this issue Nov 28, 2012 · 2 comments

Comments

@wiremine
Copy link

Are there any plans to support forman-like default options? I.e. http://ddollar.github.com/foreman/#DEFAULT-OPTIONS

If so, are you open to pull requests to that effect?

@benoitc
Copy link
Owner

benoitc commented Nov 28, 2012

i din't know about that. I will definitely accept such features so don't hesitate to send me a PR :)

@ashald
Copy link

ashald commented Jul 10, 2015

Regarding 'foreman-like default options', although it's really a good idea IMO looking for option in single .foreman file is not a best idea for a number of reasons. Rather than that it could be done in much more flexible way: for a specified Procfile look for a Procfile.options file and if it exists load options from it. Optionally for foreman-compatibility reasons if there are no such file we also can look for .foreman and load options from it. Alternatively, if both files present we can treat .foreman as a more generic one and Procfile.options as a more specific one that overrides options from .foreman.

The same approach could be used in order to extend .env files flexibility. We can look for .env first, if it exists, load it and then look for Procfile.env (that can extend/override values from base .env).

Utilizing such approach could also solve #59 and similar issues - such kind of configuration could be handled with Procfile.options files.

Although Procfile format very simple and convenient it lacks configuration capabilities that restricts its applicability. For instance, if you need to deploy something, configure it and scale it into multiple processes you will need no export/convert your Procfile (with Foreman/honcho) into Gaffer/supervisord/etc and use appropriate software.

Although, AFAIK, Procfile format was introduced by Hashicorp with Heroku service and Foreman is being considered as (one of?) reference implementation(s), I was amazed by Gaffer because of its Procfile format support while being a full-fledged production-ready process-supervising software that can replace supervisord/etc. Thus I think Gaffer is a good place to implement this extensions.
Additionally it will simplify gaffer export since it can load options from Procfile.options.

Provided that Procfile essentially is a YAML dict (or map or whatever you call it), we can derive Procfile.options format from it and use YAML dict syntax too.

TL;DR of my improvement proposal:

  1. Add support for Procfile.options and .options/.foreman default options files.

    1.1. Procfile.options - a YAML dict with keys being process names from Procfile and values being YAML dicts with options mappings

    1.2. .options/.foreman - a generic options loaded for any Procfile in dir (useful when you just want to start 2 processes of each time)

    1.3. The .options/.foreman loaded first and then Procfile.options can override options per process.

    1.4. (optional) Add command line options that will allow to (1) override/disable options file for specific Procfile (let's say you want to use Procfile 'A' but use 'B.options' or not use options at all)

    1.5. (optional) Add command line option that will allow user to disable .options/.foreman

  2. Extend .env files behavior in the similar way to Procfile.options as described above

I hope it's more or less clear what my ideas are. If you like my proposal - just let me know and I would be happy to contribute the implementation or help you to implement it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants