Re: [openstack-dev] Less option (was: [oslo.config] Centralized config management)
On 09/01/14 23:56 +0100, Julien Danjou wrote: On Thu, Jan 09 2014, Jay Pipes wrote: Hope you don't mind, I'll jump in here :) On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote: Hi Jeremy Don't you think it is burden for operators if we should choose correct combination of config for multiple nodes even if we have chef and puppet? It's more of a burden for operators to have to configure OpenStack in multiple ways. I also think projects should try to minimize configuration options at their minimum so operators are completely lost. Opening the sample nova.conf and seeing 696 options is not what I would call user friendly. And also having working default. I know it's hard, but we should really try to think about that sometimes. Sorry to hijack the thread a bit. IMHO, not a hijack! +100 to this! -- @flaper87 Flavio Percoco pgplZ7SGvB4XG.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Less option (was: [oslo.config] Centralized config management)
On Thu, 2014-01-09 at 16:34 -0800, Joe Gordon wrote: On Thu, Jan 9, 2014 at 3:01 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, 2014-01-09 at 23:56 +0100, Julien Danjou wrote: On Thu, Jan 09 2014, Jay Pipes wrote: Hope you don't mind, I'll jump in here :) On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote: Hi Jeremy Don't you think it is burden for operators if we should choose correct combination of config for multiple nodes even if we have chef and puppet? It's more of a burden for operators to have to configure OpenStack in multiple ways. I also think projects should try to minimize configuration options at their minimum so operators are completely lost. Opening the sample nova.conf and seeing 696 options is not what I would call user friendly. There was talk a while back about marking different config options as basic and advanced (or something along those lines) to help make it easier for operators. You might be thinking of this session summit I led: https://etherpad.openstack.org/p/grizzly-nova-config-options My thinking was we first move config options into groups to make it easier for operators to make sense of the available options and then we would classify them (as e.g. tuning, experimental, debug) and exclude some classifications from the sample config file. Sadly, I never even made good progress on Tedious Task 2 :: Group. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Less option (was: [oslo.config] Centralized config management)
On Fri, Jan 10, 2014 at 4:01 AM, Mark McLoughlin mar...@redhat.com wrote: On Thu, 2014-01-09 at 16:34 -0800, Joe Gordon wrote: On Thu, Jan 9, 2014 at 3:01 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, 2014-01-09 at 23:56 +0100, Julien Danjou wrote: On Thu, Jan 09 2014, Jay Pipes wrote: Hope you don't mind, I'll jump in here :) On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote: Hi Jeremy Don't you think it is burden for operators if we should choose correct combination of config for multiple nodes even if we have chef and puppet? It's more of a burden for operators to have to configure OpenStack in multiple ways. I also think projects should try to minimize configuration options at their minimum so operators are completely lost. Opening the sample nova.conf and seeing 696 options is not what I would call user friendly. There was talk a while back about marking different config options as basic and advanced (or something along those lines) to help make it easier for operators. You might be thinking of this session summit I led: https://etherpad.openstack.org/p/grizzly-nova-config-options My thinking was we first move config options into groups to make it easier for operators to make sense of the available options and then we would classify them (as e.g. tuning, experimental, debug) and exclude some classifications from the sample config file. Sadly, I never even made good progress on Tedious Task 2 :: Group. That is exactly what I was thinking of. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Less option (was: [oslo.config] Centralized config management)
+100 also :) 2014/1/10 Joe Gordon joe.gord...@gmail.com: On Fri, Jan 10, 2014 at 4:01 AM, Mark McLoughlin mar...@redhat.com wrote: On Thu, 2014-01-09 at 16:34 -0800, Joe Gordon wrote: On Thu, Jan 9, 2014 at 3:01 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, 2014-01-09 at 23:56 +0100, Julien Danjou wrote: On Thu, Jan 09 2014, Jay Pipes wrote: Hope you don't mind, I'll jump in here :) On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote: Hi Jeremy Don't you think it is burden for operators if we should choose correct combination of config for multiple nodes even if we have chef and puppet? It's more of a burden for operators to have to configure OpenStack in multiple ways. I also think projects should try to minimize configuration options at their minimum so operators are completely lost. Opening the sample nova.conf and seeing 696 options is not what I would call user friendly. There was talk a while back about marking different config options as basic and advanced (or something along those lines) to help make it easier for operators. You might be thinking of this session summit I led: https://etherpad.openstack.org/p/grizzly-nova-config-options My thinking was we first move config options into groups to make it easier for operators to make sense of the available options and then we would classify them (as e.g. tuning, experimental, debug) and exclude some classifications from the sample config file. Sadly, I never even made good progress on Tedious Task 2 :: Group. That is exactly what I was thinking of. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Less option (was: [oslo.config] Centralized config management)
On Thu, Jan 9, 2014 at 3:01 PM, Jay Pipes jaypi...@gmail.com wrote: On Thu, 2014-01-09 at 23:56 +0100, Julien Danjou wrote: On Thu, Jan 09 2014, Jay Pipes wrote: Hope you don't mind, I'll jump in here :) On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote: Hi Jeremy Don't you think it is burden for operators if we should choose correct combination of config for multiple nodes even if we have chef and puppet? It's more of a burden for operators to have to configure OpenStack in multiple ways. I also think projects should try to minimize configuration options at their minimum so operators are completely lost. Opening the sample nova.conf and seeing 696 options is not what I would call user friendly. There was talk a while back about marking different config options as basic and advanced (or something along those lines) to help make it easier for operators. And also having working default. I know it's hard, but we should really try to think about that sometimes. +100 :) -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
