| gokhanisi | good morning @gmann @frickler JayF I am only against full retirement. we can continue under x namespace. thanks. | 05:44 |
|---|---|---|
| tkajinam | gokhan, hi. are you gokhanisi ? | 08:08 |
| tkajinam | sorry if I'm pinging a wrong person | 08:09 |
| gokhan | tkajinam, yes I am sorry nickname is changed | 08:09 |
| tkajinam | gokhan, np, I could guess. just one question. are you using heat and heat resources to manage monasca resources ? | 08:10 |
| tkajinam | there is a separate discussion about heat resources for inactive projects and we are removing these resources unless the projects are restored and kept in openstack namespace, with consistent release cycle. | 08:11 |
| tkajinam | wondering if that affects the discussion to move monasca to x/ | 08:11 |
| tkajinam | https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/MZRR4Q7IVPFNTHLW6FNWLTNTFL5UW5QH/ | 08:12 |
| tkajinam | If no, then everything is fine. | 08:13 |
| gokhan | tkajinam, yes we are using it. it works.it will be good if we don't remove them on heat. | 08:13 |
| tkajinam | from heat's PoV it's not very feasible to support any external services not following the consistent release cycle | 08:14 |
| tkajinam | and in the past we have experienced a lot of problems caused by projects in x which are abandoned and are not properly updated | 08:14 |
| tkajinam | we'll keep these code for this cycle (unless something gets broken) but if we decide to go for that "diverge" way then we can't really maintain these resources in heat. | 08:16 |
| tkajinam | gmann, frickler JayF ^^^ | 08:16 |
| gokhan | tkajinam, if decision will be to remove them from heat, we need to maintain them in our namespace. but we prefer to keep heat code. we can support to maintain monasca side on heat. | 08:19 |
| tkajinam | I'd suggest splitting these code for a separate plugin if you want. it does not really different from these being maintained in heat | 08:20 |
| frickler | tkajinam: that's an interesting connection, thanks for bringing it up. note that monasca will not be part of the official 2024.1 release, not sure if heat may need to adjust for that in their testing | 08:20 |
| tkajinam | we do not test full resources and monasca is not covered, so it does not affect our CI immediately. | 08:21 |
| tkajinam | but I can expect confusions caused by inconsistent release model. We don't know which release of monasca we have to support by a specific release for heat for example. | 08:22 |
| tkajinam | a specific release *of* heat I mean | 08:22 |
| tkajinam | note that the monasca features in ceilometer was removed because of the project being inactive and broken CI in these implementations https://review.opendev.org/c/openstack/ceilometer/+/900402 | 08:23 |
| tkajinam | Idk if you are using it, though | 08:23 |
| tkajinam | we have only unit tests for monasca resources so we may not face problems unless something goes bad with monascaclient before 2024.1 release. If it does then we may have to drop these implementations with deprecation phase skipped | 08:26 |
| gokhan | thanks tkajinam we are not using monasca features in ceilometer, I am ok with to make seperate plugin | 08:27 |
| tkajinam | ok | 08:27 |
| tkajinam | I've not tested this actually but theoretically you can create a separate plugin and add the environment file to the heat config directory to redirect monasca resources to your plugin implementations | 08:28 |
| tkajinam | https://opendev.org/openstack/heat/src/branch/master/etc/heat/environment.d/default.yaml | 08:28 |
| tkajinam | like these | 08:29 |
| tkajinam | frickler, we probably have to check any other projects dependent on monasca and let them consider about their plan. I see a few other projects like cloudkitty or watcher have code dependent on monascaclient. | 08:31 |
| gokhan | I saw an earlier implemantation of monasca heat plugin. may be https://github.com/mrkanag/heat_monasca/ can help us. we can work on it. | 08:32 |
| tkajinam | the decision may be up to individual projects but it's better to make them aware. | 08:32 |
| gmann | tkajinam: thanks for bringing it here. I replied to your email. I will suggest to wait for next cycle when TC will be deciding if those Inactive project become Active or retired (they should be continue as Inactive for more than one cycle). | 19:04 |
| gmann | tkajinam: or you take call based on feature usage even its dependent project is active. Maybe that can bring some users need those feature can help in maintaining dependent projects | 19:06 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!