| *** sylwesterB has joined #openstack-bareon | 07:55 | |
| *** sylwesterB has quit IRC | 07:59 | |
| *** sylwesterB has joined #openstack-bareon | 08:14 | |
| sylwesterB | evgenyl: I need to think | 08:17 |
|---|---|---|
| sylwesterB | "The problem is you cannot disable handlers per env" - maybe not, but we can add validation which will ensure that extension is enabled on specific env | 08:28 |
| sylwesterB | "it's not clear what to do with on_node_update and on_node_create if the node is not in the environment" - actually IDK what's wrong with it | 08:30 |
| sylwesterB | Oh, yeah... | 08:30 |
| sylwesterB | I read it once again ... :P | 08:31 |
| sylwesterB | then maybe we should rely on releases extensions only? | 08:32 |
| sylwesterB | evgenyl: ^^ | 08:32 |
| sylwesterB | in that case | 08:40 |
| evgenyl | sylwesterB: with releases there is going to be the same problem, that nodes which are not in the env will not send notifications if on_node_create is called. | 08:59 |
| evgenyl | sylwesterB: I'm thinking if really need to assign rel/env/nodes to extensions. Like what problem do we solve with that. | 08:59 |
| evgenyl | sylwesterB: ok, one of the problems is we should have a way to smoothly migrate from one version of volume manager to new one (bareon based), old cluster should continue working with old versions, but new clusters will be able to use new versions. | 09:02 |
| sylwesterB | evgenyl: so that's for releases | 09:08 |
| sylwesterB | evgenyl: for clusters, I don't think that it resolve any problem | 09:08 |
| evgenyl | sylwesterB: seems you are right | 09:08 |
| sylwesterB | evgenyl: I could be usefull for somebody who want to write his own extension | 09:09 |
| evgenyl | sylwesterB: you mean in terms of development? | 09:09 |
| sylwesterB | evgenyl: and for example wants to write some kind of 'super loggin extensions' which will be enabled only for the most important clusters for him | 09:09 |
| sylwesterB | evgenyl: nope | 09:09 |
| openstackgerrit | Merged openstack/bareon-specs: Add a spec for Pluggable do actions https://review.openstack.org/266416 | 09:09 |
| evgenyl | sylwesterB: ok, I god it. | 09:10 |
| sylwesterB | evgenyl: what did you mean by "will not send notifications if on_node_create is called." ? | 09:13 |
| evgenyl | sylwesterB: ok, it's not relevant probably, currently we send this event to all extensions. | 09:16 |
| sylwesterB | evgenyl: so, should I explain this things in the spec | 10:03 |
| sylwesterB | ? | 10:03 |
| evgenyl | sylwesterB: hm, let me think | 10:04 |
| evgenyl | sylwesterB: lets leave it as is for now, I'll talk to Igor, and we will figure out what to do. If it's a blocker for you, we may just squeeze the spec to stevedore-discovery only. | 10:50 |
| evgenyl | sylwesterB: and in separate spec improve UX for developers with new handlers etc | 10:51 |
| evgenyl | sylwesterB: otherwise I'm afraid the entire spec will be blocked by discussion around other things related to UX of the developer | 10:52 |
| sylwesterB | I wanted to work on handlers for releases now ;) (as for cluster is already on review) so it's a kind of blocker | 10:52 |
| evgenyl | sylwesterB: the biggest problem is we don't have the spec merged and we are not close to merging it. The main concern which I've heard is not stevedore-discovery, but UX related questions to new handlers enabling/disabling etc, so what we can do here, is to move new handlers and development UX into separate spec to make stevedore-extensions merged faster. | 10:58 |
| evgenyl | What do you think, do you have some other ideas what we can do in this case? | 10:58 |
| evgenyl | sylwesterB: and we should have approve (at least agreement) on the spec before the code gets merged, so stevedore-discovery is blocked by spec and spec is blocked by disagreement in UX :) | 10:59 |
| sylwesterB | evgenyl: Nope. As I said it's a blocker for me, so I think it is the only way | 10:59 |
| sylwesterB | I will shrink it to stevedore discovery only | 11:00 |
| evgenyl | sylwesterB: yeah, cool, and just move UX related stuff into another spec | 11:01 |
| sylwesterB | ok | 11:01 |
| *** openstackgerrit has quit IRC | 11:47 | |
| *** openstackgerrit has joined #openstack-bareon | 11:47 | |
| *** openstackgerrit has quit IRC | 12:33 | |
| *** openstackgerrit has joined #openstack-bareon | 12:33 | |
| evgenyl | sylwesterB: talked to Igor, it's a right thing that you started splitting stevedore-discovery into specific spec, confirmed, that there are no concerns regarding to that. Extensions management is still an issue, at least we will have to rename it to something different (think about it and lets discuss it in Poznan) , since in fact we don't enable/disable | 14:31 |
| evgenyl | extensions. We enable/disable notifications (in the future pipeline) for each extension. Another thing is during implementation of pipeline, we will need to refactor a bit BaseExtension class, to split functionality into different classes, there will be a specific class for Notifications, another one for DeploymentPipelines, and Extension class itself will | 14:31 |
| evgenyl | contain parameters with those classes. | 14:31 |
| sylwesterB | ok, thanks | 14:32 |
| openstackgerrit | Evgeniy L proposed openstack/bareon-specs: Don't use oslosphinx if docs is being generated on readthedocs https://review.openstack.org/271360 | 15:06 |
| evgenyl | sylwesterB: agordeev could you please +1 trivial patch? ^ | 15:06 |
| agordeev | yep, sure thing | 15:07 |
| agordeev | evgenyl: does it affect the results of CI tests? | 15:09 |
| evgenyl | agordeev: don't think so, but lets wait it to finish, if it's ok just put +1, I will merge it when tests are passed. | 15:09 |
| *** sylwesterB has quit IRC | 15:53 | |
| openstackgerrit | Merged openstack/bareon-specs: Don't use oslosphinx if docs is being generated on readthedocs https://review.openstack.org/271360 | 17:22 |
| -openstackstatus- NOTICE: Restarting zuul due to a memory leak | 17:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!