| *** evgenyl has quit IRC | 00:08 | |
| *** sylwesterB has quit IRC | 00:09 | |
| *** evgenyl has joined #openstack-bareon | 00:09 | |
| *** sylwesterB has joined #openstack-bareon | 00:10 | |
| *** agordeev has quit IRC | 00:12 | |
| *** agordeev has joined #openstack-bareon | 00:13 | |
| *** evgenyl has quit IRC | 00:16 | |
| *** evgenyl has joined #openstack-bareon | 00:17 | |
| *** ikalnitsky_ has joined #openstack-bareon | 05:42 | |
| *** ikalnitsky has quit IRC | 05:49 | |
| *** ikalnitsky_ is now known as ikalnitsky | 05:50 | |
| *** sylweste_ has joined #openstack-bareon | 08:34 | |
| *** sylweste_ is now known as sylwesterB_ | 08:35 | |
| evgenyl | Hi folks. | 08:52 |
|---|---|---|
| sylwesterB | hi | 09:01 |
| *** sylwesterB_ has quit IRC | 09:01 | |
| evgenyl | agordeev: looking at bp https://blueprints.launchpad.net/fuel/+spec/multipath-disks-support I don't quite understand what is the exact problem and why multipath is not working, isn't it a problem of nailgun-agent only, which filters iscsi disks out https://bugs.launchpad.net/fuel/+bug/1515620/comments/4 ? | 09:37 |
| openstack | Launchpad bug 1515620 in Fuel for OpenStack "multipath problem during deploy" [High,Confirmed] - Assigned to Fuel Python Team (fuel-python) | 09:37 |
| evgenyl | agordeev: want to get full understanding, so we put it into proper place in the roadmap. | 09:37 |
| agordeev | evgenyl: i'm not quite familiar with multipath devices, but main concern is that you need to configure few devices to behave like a single one multipath device. This step of configuring those disks is essential and unavoidable. Multipath demon by default blacklists all disks, so you need to add something to began to use multipath devices properly. | 09:50 |
| evgenyl | agordeev: thanks, I will read more about it and will talk to deployment engineers, to have better understanding of the problem. | 09:53 |
| agordeev | therefore, in order to use multipath disks proreply, we need them to be configured for every stage of node transition. So, multipath disks must be configured for bootstrap/provision stage as well as on deployed nodes too. | 09:54 |
| evgenyl | agordeev: got it, do I understand correctly, that pluggable do-actions with flexible flows will help to solve the problem? | 09:56 |
| agordeev | evgenyl: no, i don't think so, flexible flow is not related to that at all. it's not clear who is in charge of performing this multipath configuration step. | 09:59 |
| agordeev | evgenyl: definitely, a chicken and egg prob here. nailgun-agent only reports the facts about the system. Who will configure the disks which it is going to be report? I don't have an answer. | 10:00 |
| evgenyl | agordeev: but if I create a plugin with do_multipath_configuration, and if I can add execution of this action at any stage, shouldn't it solve the problem? I mean the creator of multipath plugin probably knows when it has to be configured. | 10:00 |
| *** openstackgerrit has quit IRC | 10:02 | |
| *** openstackgerrit_ has joined #openstack-bareon | 10:03 | |
| *** openstackgerrit_ has quit IRC | 10:03 | |
| agordeev | let me think. afair, node attributes become locked from updates at some point. So, we need to create multipath disks before that, so nailgun will take into account miltipath disks too and will generate partitioning layout accordingly. | 10:06 |
| agordeev | evgenyl: yes, do_multipath_configuration action makes sense. This action should be executed somewhere between discovery and provisioning of a node. And the changes of multipath.conf should be delivered to provisioned node prior the first booting into the target os. Sounds, like target initramfs/initrd image must be rebuilt too to reflect these changes. | 10:12 |
| *** openstackgerrit has joined #openstack-bareon | 11:53 | |
| *** openstackgerrit has quit IRC | 11:54 | |
| *** openstackgerrit_ has joined #openstack-bareon | 11:54 | |
| *** openstackgerrit_ is now known as openstackgerrit | 11:55 | |
| *** openstackgerrit has quit IRC | 11:59 | |
| *** openstackgerrit has joined #openstack-bareon | 12:07 | |
| sylwesterB | guys: data-pipelines ver. 0.0.1 https://review.openstack.org/#/c/274653/ | 13:36 |
| sylwesterB | spec* | 13:36 |
| evgenyl | sylwesterB: cool, thanks | 14:13 |
| evgenyl | sylwesterB: have you figured out what is wrong with CI? | 14:14 |
| evgenyl | sylwesterB: I mean in your patch for stevedore discovery | 14:14 |
| sylwesterB | After retrigering it several times and couple of random failures I gave up and worked on spec | 14:36 |
| evgenyl | sylwesterB: so you need some help with it? | 14:37 |
| evgenyl | sylwesterB: seems like retrying doesn't help. | 14:37 |
| evgenyl | sylwesterB: since master is in a good shape and working. | 14:37 |
| sylwesterB | does the guys from CI can still retrigger jobs? | 14:37 |
| evgenyl | sylwesterB: I think they can retrigger Fuel CI job. | 14:38 |
| evgenyl | sylwesterB: actually you can do it by pressing "rebase" | 14:38 |
| sylwesterB | let me run them locally once again | 14:39 |
| evgenyl | sylwesterB: have you seen the error "AssertionError: 200 != 202" it's pretty strange :) | 14:39 |
| evgenyl | sylwesterB: looks like some bug in the master :) | 14:39 |
| sylwesterB | damn it they passing locally | 14:41 |
| sylwesterB | also there were some other error before | 14:41 |
| sylwesterB | sec | 14:41 |
| sylwesterB | https://bugs.launchpad.net/fuel/+bug/1540313 | 14:42 |
| openstack | Launchpad bug 1540313 in Fuel for OpenStack "[fuel-web] randomly failing test test_put_handler_with_one_node" [High,Confirmed] - Assigned to Fuel Python Team (fuel-python) | 14:42 |
| sylwesterB | evgenyl: I rebased it | 14:43 |
| sylwesterB | evgenyl: and we will see | 14:43 |
| evgenyl | sylwesterB: btw, I didn't get where is a fix where Igor was talking about https://review.openstack.org/#/c/260453/16/nailgun/nailgun/extensions/manager.py , he suggested to fetch all extensions on startup time, but here we continue fetching extensions on each callbacks call. | 14:49 |
| sylwesterB | evgenyl: I've changed it to be created only once | 15:00 |
| sylwesterB | evgenyl: but then wild circular imports appeard | 15:00 |
| sylwesterB | making the extensions loading inside a functions prevents from that | 15:01 |
| evgenyl | sylwesterB: hm, are you sure? If you implement get_extensions_manager to get EXTENSION_MANAGER and set it if it's None. | 15:02 |
| sylwesterB | evgenyl: Do you want me to use "global" ? | 15:03 |
| sylwesterB | :( | 15:04 |
| evgenyl | sylwesterB: that was the point Igor said "maybe move it on global level" so you do it once for entire application and don't call it each time. | 15:04 |
| evgenyl | ikalnitsky: am I correct that you wanted it to be set globally and only once? | 15:05 |
| ikalnitsky | evgenyl: yeah, | 15:06 |
| ikalnitsky | i mean, that it's not cool that we will create plugin instances each time your function is called | 15:07 |
| ikalnitsky | think global in this case would solve the problem. | 15:07 |
| sylwesterB | evgenyl: ikalnitsky which one? http://paste.openstack.org/show/485610/ | 15:07 |
| ikalnitsky | sylwesterB: first one looks good to me. | 15:08 |
| sylwesterB | the first one causes circular imports, the second use 'glova' | 15:08 |
| evgenyl | sylwesterB: I would vote for second. | 15:08 |
| evgenyl | sylwesterB: it's easier to mock | 15:08 |
| sylwesterB | global* | 15:08 |
| ikalnitsky | circular imports ? | 15:08 |
| sylwesterB | ikalnitsky: because we're loading extensions in 'nailgun.extensions.manager'. In 'nailgun.extensions.__init__' we have ' from nailgun.extensions.manager import something'. And in extensions like volume_manager we have 'from nailgun.extensions.base import BaseExtension' -> circular | 15:10 |
| ikalnitsky | sylwesterB: weird :( | 15:12 |
| sylwesterB | nothing wierd here :P | 15:12 |
| ikalnitsky | honestly, it doesn't matter to me much which variant will be used. :) | 15:12 |
| sylwesterB | ikalnitsky: OK, so evgenyl We can leave it as it is, or use 'global' | 15:14 |
| evgenyl | sylwesterB: lets do global with a comment, why it was done this way. | 15:16 |
| sylwesterB | OK :( | 15:16 |
| evgenyl | sylwesterB: you don't like the solution? If yes, suggest something better not to run discovery every time. | 15:16 |
| sylwesterB | evgenyl: I tried with several approaches like classes, lazy initialization but everyone of them caused circural import | 15:19 |
| sylwesterB | evgenyl: the only argument I have | 15:19 |
| sylwesterB | evgenyl: is that the ExtensionManager object get created several times, but extensions are loaded only once due to python cache | 15:19 |
| sylwesterB | gets* craeted | 15:19 |
| evgenyl | sylwesterB: hmm, are you sure? As far as I know it scans all egg packages every time, and it may take some time... | 15:20 |
| sylwesterB | evgenyl: the first place to check is sys.modules which contails all previosly imported modules | 15:22 |
| sylwesterB | it's our 'cache' | 15:22 |
| sylwesterB | if it's not there, it goes further | 15:23 |
| evgenyl | sylwesterB: are you talking about implementation of stevedore or the way it works in python, because in stevedore implementation there is a cache per extension manager instance, not a global one https://github.com/openstack/stevedore/blob/master/stevedore/extension.py#L145-L151 | 15:25 |
| sylwesterB | I was talking about 1. | 15:26 |
| sylwesterB | damn | 15:26 |
| sylwesterB | I meant I was talking about how python works | 15:26 |
| sylwesterB | So it's imported only once | 15:27 |
| sylwesterB | but lookup for endpoint happen all the time ;? | 15:27 |
| sylwesterB | :/ | 15:27 |
| evgenyl | agordeev: sync | 15:29 |
| evgenyl | sylwesterB: trying to find it in setup tools code, which is used to get this info. | 15:30 |
| openstackgerrit | Aleksandr Gordeev proposed openstack/bareon: [WIP] Introduce helpers for do actions https://review.openstack.org/272690 | 18:08 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!