I wasn't certain whether to put this question on stackoverflow or serverfault, but I think it is more coding related than IT infrastructure related.
I'm adding a new Neutron L3 plugin and have attempted to mimic the functionality of a few good examples thus far. My problem is here: while my config file is following the same naming conventions/locations, I keep having empty strings returned from Oslo Config.
Edit: my plugin myapp is in /opt/stack/neutron/neutron/plugins/ml2/drivers/myapp and my configuration file ml2_conf_myapp.ini is in /opt/stack/neutron/etc/neutron/plugins/ml2/.
How do you specify to Oslo config where to find new plugin configuration files and what their names are?
Thank you!
I ended up solving this issue by reading through the code in devstack/lib/neutron.
In devstack/local.conf, you can set the variables Q_PLUGIN_EXTRA_CONF_FILES and Q_PLUGIN_EXTRA_CONF_PATH.
In my case, I have:
ML2_L3_PLUGIN=neutron.plugins.ml2.drivers.myapp.myapp
Q_PLUGIN_EXTRA_CONF_FILES+="myapp_conf.ini"
Q_PLUGIN_EXTRA_CONF_PATH="$DEST/neutron/neutron/plugins/ml2/drivers/myapp"
Now Oslo is able to pick up the configurations.
I hope this helps someone else save some work.
Related
I've very new to Symfony. Before I've used mostly Laravel.
Lets assume I have an API Key which I want to use here and there thru the project.
It doesn't feel right to store it as a class constant because I can't find any class to keep it in. And it seems pretty dumb to have it in various places thru the app as a string.
Normally using Laravel I would have used a config file specifically for this task.
However in symfony I can't seem to do the same(either that or my google-fu skills are pretty bad). If they are, a simple link to some documentation will do just fine.
So my question is: Where can I store various constants used thru the app?
I'm sorry, but I'm afraid your Google-fu skills let you down this time.
Symfony.com has an excellent article about Configuration: Configuration -
Symfony Best Practices
The common way to save configuration parameters is by using parameters.yml. It supports environment variables as of Symfony 3.2.
The best practice for Symfony 2.x and 3.x:
Define the infrastructure-related configuration options in the
app/config/parameters.yml file.
The best practice for Symfony 4:
Define the infrastructure-related configuration options as environment
variables. During development, use the .env file at the root of your
project to set these.
I'm a bit of a newbie, but already running apps with Meteor.js. Since I'm now working with API keys I'm finally realizing that security is a thing, and so I placed my keys in a settings.json, and am instructed not to commit, or to .gitignore the file. But despite reading the documentation, this all seems very counter-intuitive. If I need the variables to make my HTTP requests, then how can my app possibly function without adding my keys, in some form, to the repo? I know the answer is "it can," but how? (in general terms, I don't need a Meteor specialist yet) .
Typing this question out makes me feel pretty ignorant for the stage I'm at, but the docs out there for some reason are not clarifying this for me.
You can generate the file with sensitive information on git checkout.
That is called a smudge script, part of a content filter driver, using using .gitattributes declaration.
(image from "Customizing Git - Git Attributes", from "Pro Git book")
That 'smudge' script( that you have to write) would need to:
fetch the right key (from a source outside the repo, that way no risk to add and push by mistake)
generate the settings.json, using a tracked manifest template settings.json.tpl with placeholder value in it to replace.
That means:
the template settings.json.tpl is added to the git repo
the generate file settings.json is declared in the .gitignore file and never versioned.
Everyone.
I want to create plugin as the introduction told. Adding a new API module, but I got this error.
Any idea to solve this problem?
Please make sure to enable development mode:
./console development:enable
I have installed Riak on a Debian system from the package riak_2.0.1-1_amd64.deb, and I'm trying to change the configuration so I use the LevelDB Backend for 2i (so I can use secondary indexes).
http://docs.basho.com/riak/latest/dev/taste-of-riak/querying/ says to edit (usually) /etc/riak/app.config, but there is no such file. I can find /etc/riak/riak.conf but that has settings like
something.else.value = 12345
and nothing like
{storage_backend, riak_kv_bitcask_backend}
described on the docs page.
I'm sure its trivial, but trivially what! Help!!!
Configuration in Riak 2.0+ is handled by a riak.conf file that is located in each node's /etc directory. More information can be found in this document.
I think in the newer versions riak.conf is located at: etc/riak/riak.conf
Looks like /etc/riak/riak.conf is the one to use. I set
storage_backend = leveldb
and secondary indexes work now.
Thanks
i´ve just installed the ChillDevProxyTemplating Bundle for symfony2, described here:
https://github.com/chilloutdevelopment/ChillDevProxyTemplatingBundle/blob/master/Resources/doc/installation.md
My templates was rennamed correctly by the bundle (from 'default' to 'php'), but when i try to call my controller I get the following error:
Cannot import resource "." from (...)app/cache/dev/assetic/routing.yml". (The following loader(s) are not registered: default).
Has anyone an idea how to fix??
Thanks a lot !
As explained here: https://github.com/chilloutdevelopment/ChillDevFileManagerBundle/issues/27
You might just need to install ChillDevViewHelpersBundle to get it working.
I previously added answer to this question, but it was removed by moderator since my reputation was not high enough to post a comment.
But now thanks to support of community I was able to investigate this problem:
https://github.com/chilloutdevelopment/ChillDevProxyTemplatingBundle/issues/2
It's now fixed :). Thank you for pointing the problem.
The problem was, that Assetic, in dev environment tries to parse all the templates based on templating engine name so it needs loader for each templating engine - of course for "default" there was no loader and thus caused an exception.