| *** mhen_ is now known as mhen | 02:34 | |
| tkajinam | gmaan, I hope my reply could be clear enough, by my point is that we don't want that logic to assume that "oslo_config_glue.register does exactly same as what we are doing here "self.conf.register_opts(_options.service_opts)" | 03:25 |
|---|---|---|
| tkajinam | s/we don't/I don't/ | 03:25 |
| tkajinam | it might be true now, but can be broken anytime | 03:25 |
| gmaan | tkajinam: if that is broken then that is valid failure and we should make sure that all required config option are properly registered | 03:26 |
| tkajinam | we should not heavily depend on the current implementation of an external lib, IMHO | 03:26 |
| gmaan | tkajinam: because it is same case for any oslo lib, all openstack service register the olso lib config options by oslo libs only. | 03:27 |
| tkajinam | I really don't want to force us to watch cotyledon to detect any problematic update ? | 03:27 |
| tkajinam | gmaan, no that's different because we use oslo's logic to register these options and use these in oslo's logic | 03:28 |
| gmaan | tkajinam: yes, that is my point, that is not implementation but a hack which was added long back and now we should use cotyledon in proper way and register required config options in correctr way | 03:28 |
| gmaan | and at some point we should also remove the usage of link() also | 03:28 |
| tkajinam | can't we just re-implement oslo_config_glue.link ? | 03:28 |
| tkajinam | that's much clean way IMHO | 03:28 |
| gmaan | yes, that is good point and we should do that | 03:28 |
| gmaan | but currently registering the config option by oslo.service and make sure (i think as a maintainer you can) nobody should extend the oslo_config_glue.py | 03:29 |
| gmaan | and at some point we can completely remove the oslo_config_glue | 03:30 |
| tkajinam | cotyledon is outside of oslo's governance as you know | 03:30 |
| tkajinam | so we don't have any control about it | 03:30 |
| gmaan | but my suggestion is gradually remove the usage of oslo_config_glue which is what this change doing | 03:30 |
| gmaan | tkajinam: i know, I saw you are one of the maintainer and once openstack does not use oslo_config_glue then it maybe good time to remvoe it but that I will leave up to you guys | 03:31 |
| tkajinam | no I'm just a contributor. I have no access to reject or merge things there | 03:32 |
| gmaan | oh, I thought i saw you approve one PR | 03:32 |
| gmaan | maybe I overlooked | 03:32 |
| gmaan | anyways, I think if anyone adding more openstack config in oslo_config_glue and get error is right failure and ask them to do it in openstack side and not extend this glue | 03:33 |
| gmaan | and with things moving to threading backend will make usage in much better way | 03:33 |
| gmaan | tkajinam: if you agree, my suggestion is to start it with this change where oslo.service will register its config options and only use link(). and that is a message for gradually removing the oslo_config_glue usage | 03:35 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.service master: Eliminate usage of oslo_config_glue https://review.opendev.org/c/openstack/oslo.service/+/975357 | 04:09 |
| tkajinam | gmaan, let's see how the others feel about ^^^ | 04:09 |
| tkajinam | I feels like leaving it now means we never fix it until we face a problem | 04:10 |
| gmaan | tkajinam: great, I will check this, mostly looking good at first glance. | 04:11 |
| tkajinam | (I unintentionally found one possible bug in cotyledon and will see if need a fix there first ... | 04:12 |
| gmaan | nice, feel free to ping me the link and i will be happy to review. I am seeing we will find more improvement area in cotyledon as we will be using it heavily | 04:13 |
| tkajinam | gmaan, https://github.com/sileht/cotyledon/pull/89 | 04:34 |
| tkajinam | though I'm unsure if such reload mechanism is intensively used even in OpenStack | 04:35 |
| gmaan | tkajinam: thanks, I will take a look. I think reload is not used much at least we do not reload Nova service on SIGHUP. but in future we may | 04:37 |
| tkajinam | I guess reload or mutable config mechanism is not much important these days because people more often use k8s which restart containers after config change | 04:38 |
| tkajinam | and graceful shutdown is much more important in that pattern | 04:39 |
| gmaan | yup, as long as we shutdown services gracefully then k8s restart is all good to reload the things | 04:39 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!