On Fri, Jan 10, 2014 at 12:18 AM, Nachi Ueno <[email protected]> wrote:
> 2014/1/9 Jeremy Hanmer <[email protected]>: > > How do you see these interactions defined? For instance, if I deploy > > a custom driver for Neutron, does that mean I also have to patch > > everything that will be talking to it (Nova, for instance) so they can > > agree on compatibility? > > Nova / Neutron talks with neturon api. so it should be OK because we > are talking care > backward compatibility in the REST API. > > The point in my example is neutron server + neutron l2 agent sync. > What about doing it the other way round, i.e. allow one server to query certain configuration parameter(s) from the other via RPC? I believe I've seen such proposal quite some time ago in Nova blueprints, but with no actual implementation. -- Best regards, Oleg Gelbukh > > > Also, I know that I run what is probably a more complicated cluster > > than most production clusters, but I can't think of very many > > configuration options that are globally in sync across the cluster. > > Hypervisors, network drivers, mysql servers, API endpoints...they all > > might vary between hosts/racks/etc. > > To support such heterogeneous environment is a purpose of this bp. > Configuration dependency is pain point for me, and it's get more worse > if the env is heterogeneous. > > I have also some experience to run openstack clusters, but it is still > pain for me.. > > My experience is something like this > # Wow, new release! ohh this chef repo didn't supported.. > # hmm i should modify chef recipe.. hmm debug.. debug.. > > > > On Thu, Jan 9, 2014 at 11:08 AM, Nachi Ueno <[email protected]> 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? > >> > >> If we have some constraint or dependency in configurations, such logic > >> should be in openstack source code. > >> We can solve this issue if we have a standard way to know the config > >> value of other process in the other host. > >> > >> Something like this. > >> self.conf.host('host1').firewall_driver > >> > >> Then we can have a chef/or file baed config backend code for this for > example. > >> > >> Best > >> Nachi > >> > >> > >> 2014/1/9 Jeremy Hanmer <[email protected]>: > >>> +1 to Jay. Existing tools are both better suited to the job and work > >>> quite well in their current state. To address Nachi's first example, > >>> there's nothing preventing a Nova node in Chef from reading Neutron's > >>> configuration (either by using a (partial) search or storing the > >>> necessary information in the environment rather than in roles). I > >>> assume Puppet offers the same. Please don't re-invent this hugely > >>> complicated wheel. > >>> > >>> On Thu, Jan 9, 2014 at 10:28 AM, Jay Pipes <[email protected]> wrote: > >>>> On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote: > >>>>> On 08/01/14 17:13 -0800, Nachi Ueno wrote: > >>>>> >Hi folks > >>>>> > > >>>>> >OpenStack process tend to have many config options, and many hosts. > >>>>> >It is a pain to manage this tons of config options. > >>>>> >To centralize this management helps operation. > >>>>> > > >>>>> >We can use chef or puppet kind of tools, however > >>>>> >sometimes each process depends on the other processes configuration. > >>>>> >For example, nova depends on neutron configuration etc > >>>>> > > >>>>> >My idea is to have config server in oslo.config, and let cfg.CONF > get > >>>>> >config from the server. > >>>>> >This way has several benefits. > >>>>> > > >>>>> >- We can get centralized management without modification on each > >>>>> >projects ( nova, neutron, etc) > >>>>> >- We can provide horizon for configuration > >>>>> > > >>>>> >This is bp for this proposal. > >>>>> >https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized > >>>>> > > >>>>> >I'm very appreciate any comments on this. > >>>>> > >>>>> I've thought about this as well. I like the overall idea of having a > >>>>> config server. However, I don't like the idea of having it within > >>>>> oslo.config. I'd prefer oslo.config to remain a library. > >>>>> > >>>>> Also, I think it would be more complex than just having a server that > >>>>> provides the configs. It'll need authentication like all other > >>>>> services in OpenStack and perhaps even support of encryption. > >>>>> > >>>>> I like the idea of a config registry but as mentioned above, IMHO > it's > >>>>> to live under its own project. > >>>> > >>>> Hi Nati and Flavio! > >>>> > >>>> So, I'm -1 on this idea, just because I think it belongs in the realm > of > >>>> configuration management tooling (Chef/Puppet/Salt/Ansible/etc). Those > >>>> tools are built to manage multiple configuration files and changes in > >>>> them. Adding a config server would dramatically change the way that > >>>> configuration management tools would interface with OpenStack > services. > >>>> Instead of managing the config file templates as all of the tools > >>>> currently do, the tools would need to essentially need to forego the > >>>> tried-and-true INI files and instead write a bunch of code in order to > >>>> deal with REST API set/get operations for changing configuration data. > >>>> > >>>> In summary, while I agree that OpenStack services have an absolute TON > >>>> of configurability -- for good and bad -- there are ways to improve > the > >>>> usability of configuration without changing the paradigm that most > >>>> configuration management tools expect. One such example is having > >>>> include.d/ support -- similar to the existing oslo.cfg module's > support > >>>> for a --config-dir, but more flexible and more like what other open > >>>> source programs (like Apache) have done for years. > >>>> > >>>> All the best, > >>>> -jay > >>>> > >>>> > >>>> _______________________________________________ > >>>> OpenStack-dev mailing list > >>>> [email protected] > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>> > >>> > >>> _______________________________________________ > >>> OpenStack-dev mailing list > >>> [email protected] > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
