Re: [Openstack-operators] OpenStack components and configuration options
> On 1/12/2016 3:29 AM, gilles.mocellin at nuagelibre.org wrote: > > Hello, > > > > [...] > > > > What I would like is to have the minimum configuration files for each > > component, on each server. > > I know it would not hurt to have more configuration than used, but it > > would help to really understand what is done by each component. > > > > At the moment, I can't find where I have to put quota configuration > > (until_refresh and max_age). > > Is it used by nova-api, nova-scheduler... cinder-api ? > > Or is it used by nova-compute, cinder-volume ? > > > > I would find very clear if each component had it own config file. > > It would also avoid to put some passwords (database acces, keystone...) > > on nodes where it's not used. > > > > [...] > > > > So, is there a documentation where I could see : > > - nova-api, reads theses configuration options > > - nova-compute... > Markus Zoeller is working on cleaning this up in Nova in Mitaka, see the > spec here: > > http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/centralize- > config-options.html > > -- > > Thanks, > > Matt Riedemann Yepp, we're working on it in Nova. The current version can be found at [1]. The options [DEFAULT].vcpu_pin_set and [serial_console].serialproxy_port are examples how the help will look like. Let me know if you find this useful or if you miss something there. It will still be one file "nova.conf" but our effort is a prerequisite to the separated "nova-compute.conf", "nova-scheduler.conf" and so on. The ongoing effort can be found at [2]. References: [1] http://docs.openstack.org/developer/nova/sample_config.html [2] https://review.openstack.org/#/q/topic:bp/centralize-config-options Regards, Markus Zoeller (markus_z) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] OpenStack components and configuration options
Le 2016-01-13 10:41, Markus Zoeller a écrit : On 1/12/2016 3:29 AM, gilles.mocellin at nuagelibre.org wrote: > Hello, > [...] > > So, is there a documentation where I could see : > - nova-api, reads theses configuration options > - nova-compute... Markus Zoeller is working on cleaning this up in Nova in Mitaka, see the spec here: http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/centralize- config-options.html -- Thanks, Matt Riedemann Yepp, we're working on it in Nova. The current version can be found at [1]. The options [DEFAULT].vcpu_pin_set and [serial_console].serialproxy_port are examples how the help will look like. Let me know if you find this useful or if you miss something there. It will still be one file "nova.conf" but our effort is a prerequisite to the separated "nova-compute.conf", "nova-scheduler.conf" and so on. The ongoing effort can be found at [2]. References: [1] http://docs.openstack.org/developer/nova/sample_config.html [2] https://review.openstack.org/#/q/topic:bp/centralize-config-options Regards, Markus Zoeller (markus_z) Yes, glad to see ther is some work about that. If I understand, Tha conf sample is generated with headers comments like : # From Nova.api ... # From Nova.compute So what does theses headers mean ? Which component will use the config options below ? # From Nova # From Nova.conf # From Nova.network # From nova.openstack.common.memorycache # From nova.virt ... These seems to be related to libraries used, not a particular component/service/process like nova-compute. Comments like this is more clear : # Services which consume this: # # * nova-scheduler # * nova-compute An I see that it's what is shown as a "Positive Example" in the spec http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/centralize-config-options.html#quality-view. Another positive point I can see, if we could separate config options in specific config files for each service : - Packaging will be easier, especially install/remove/upgrades of one service not interfering with others - Config management will also be easier, don't need to manage the content of a file shared between several services -- gillesMo ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] OpenStack components and configuration options
gilles.mocel...@nuagelibre.org wrote on 01/13/2016 02:39:56 PM: > From: gilles.mocel...@nuagelibre.org > To: openstack-operators@lists.openstack.org > Date: 01/13/2016 02:42 PM > Subject: Re: [Openstack-operators] OpenStack components and > configuration options > > Le 2016-01-13 10:41, Markus Zoeller a écrit : > >> On 1/12/2016 3:29 AM, gilles.mocellin at nuagelibre.org wrote: > >> > Hello, > >> > [...] > >> > > >> > So, is there a documentation where I could see : > >> > - nova-api, reads theses configuration options > >> > - nova-compute... > > > >> Markus Zoeller is working on cleaning this up in Nova in Mitaka, see > >> the > > > >> spec here: > >> > >> > > http://specs.openstack.org/openstack/nova-specs/specs/mitaka/ > approved/centralize- > >> config-options.html > >> > >> -- > >> > >> Thanks, > >> > >> Matt Riedemann > > > > > > Yepp, we're working on it in Nova. The current version can be found at > > [1]. > > The options [DEFAULT].vcpu_pin_set and > > [serial_console].serialproxy_port > > are examples how the help will look like. Let me know if you find this > > useful or if you miss something there. > > It will still be one file "nova.conf" but our effort is a prerequisite > > to the separated "nova-compute.conf", "nova-scheduler.conf" and so on. > > The ongoing effort can be found at [2]. > > > > References: > > [1] http://docs.openstack.org/developer/nova/sample_config.html > > [2] https://review.openstack.org/#/q/topic:bp/centralize-config-options > > > > Regards, Markus Zoeller (markus_z) > > Yes, glad to see ther is some work about that. > > If I understand, Tha conf sample is generated with headers comments like > : > # From Nova.api > ... > # From Nova.compute > > So what does theses headers mean ? Which component will use the config > options below ? > # From Nova > # From Nova.conf > # From Nova.network > # From nova.openstack.common.memorycache > # From nova.virt > ... > > These seems to be related to libraries used, not a particular > component/service/process like nova-compute. > > Comments like this is more clear : > # Services which consume this: > # > # * nova-scheduler > # * nova-compute Yes, right, the headers where initally used to signalize which service uses which config options (AFAIK) but this wasn't consistent. I want to go to something like this: # From nova.conf # From oslo.log # From oslo.messaging # From oslo.policy # From oslo.service # From oslo.service # From oslo.db # From oslo.middleware # From oslo.concurrency # From keystonemiddleware.auth_token Some of the options in the "/etc/nova/nova.conf" get passed through to libs we utilize (for example "oslo.log"). These headers will give you a clue which lib it is. Could be useful to know that in upgrade scenarios. > An I see that it's what is shown as a "Positive Example" in the spec > http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/ > centralize-config-options.html#quality-view. Yepp, that's what we are heading to. We introduced a lot of options in last cycles and it takes a bit time to make that easier to digest. > Another positive point I can see, if we could separate config options in > specific config files for each service : > - Packaging will be easier, especially install/remove/upgrades of one > service not interfering with others > - Config management will also be easier, don't need to manage the > content of a file shared between several services > > -- > gillesMo That's not part of the current effort but when we are done it will be a lot easier to achieve that. Regards, Markus Zoeller (markus_z) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] OpenStack components and configuration options
On 1/12/2016 3:29 AM, gilles.mocel...@nuagelibre.org wrote: Hello, I wonder if there is somewhere some precise information on which component a configuration option is for. I'll explain that. I want to separate components on several servers, a controller node, a network node, and compute nodes. Classic. I have nova-api one one node, nova-compute on another. Idem for cinder-api and cinder-volume (I use glusterFS on compute nodes). Idem for neutron-server and neutron-plugin-openvswitch-agent. What I would like is to have the minimum configuration files for each component, on each server. I know it would not hurt to have more configuration than used, but it would help to really understand what is done by each component. At the moment, I can't find where I have to put quota configuration (until_refresh and max_age). Is it used by nova-api, nova-scheduler... cinder-api ? Or is it used by nova-compute, cinder-volume ? I would find very clear if each component had it own config file. It would also avoid to put some passwords (database acces, keystone...) on nodes where it's not used. On Ubuntu, there's already a some "separation" with two files : /etc/nova/nova.conf and /etc/nova/nova-compute.conf. (In fact, nova-compute load both files, which can be least clear). So, is there a documentation where I could see : - nova-api, reads theses configuration options - nova-compute... ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators Markus Zoeller is working on cleaning this up in Nova in Mitaka, see the spec here: http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/centralize-config-options.html -- Thanks, Matt Riedemann ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
