08:00:10 #startmeeting vitrage 08:00:11 Meeting started Wed Dec 5 08:00:10 2018 UTC and is due to finish in 60 minutes. The chair is ifat_afek. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:00:14 The meeting name has been set to 'vitrage' 08:00:22 Hi :-) 08:00:32 Nice day :) 08:00:49 \o/ 08:03:19 #topic Status and updates 08:03:36 There are new guidelines regarding the cycle-with-intermediary release mode 08:03:47 In order to use this model, we must release at least twice each cycle, and more specifically we must release before the second milestone on January 7th 08:04:03 An alternative is to switch to cycle-with-rc release mode, where we need to publish one or more release candidates at the end of the cycle 08:04:12 I think we should stay with our current release mode of cycle-with-intermediary, and decide on the best time to publish a release 08:04:14 Hi 08:04:20 What do you say? 08:06:52 hi 08:07:05 I think it is better to release sooner then later if possible 08:07:23 to include latest improvemnts 08:07:46 e0ne: Hi. I was talking about the change of the release mode policy. we should either release before Jan 7th, or switch to cycle-with-rc release mode. Any prefernce? 08:07:51 idan_hefetz: I agree 08:08:26 And I feel that it’s a good time to release. We should just wait for the Prometheus configuration fix that mnajjar is working on 08:08:28 ifat_afek: hi. I don't have strong opinion on this yet 08:08:45 what is the real difference ? 08:08:53 BTW, we should also release Rocky once we have the Prometheus fix 08:09:02 ifat_afek: +1 08:09:02 how each option will affect us ? 08:09:35 If we stay with the current mode, we must release at least twice. First time until Jan 7th. If we switch, we just need to tag a release candidate at the end of the cycle 08:10:00 I’m not so sure what is better, but I tend to release soon and remain in our current release mode 08:10:13 Which is cycle-with-intermediary 08:10:42 ok, i got same feeling like you ifat_afek 08:11:04 I have no other updates. I was sick part of the week, so didn’t finish the Nova versioned notifications yet 08:11:41 Anyone else? 08:11:54 yea 08:12:07 I have a new commit regarding optimization of runtime and memory use for API calls. 08:12:15 In topology i rewrote some of the code that creates the graph, so to avoid calling unnecessary copy() on the graph. 08:12:16 nothing from me this week. I worked on other projects:( 08:12:43 idan_hefetz: I'm sorry, I didn't have a time to test your patch :( 08:12:54 And in vitragea-pi i added garbage collector configuration to collect more often 08:13:12 e0ne: no worries, i'll try to share my results :) 08:13:21 idan_hefetz: great 08:13:48 This change is almost ready, just have a few comments from eyal and ifat 08:14:06 #link https://review.openstack.org/#/c/619623/ 08:14:40 After that i have some more cool improvements :) 08:15:01 So stay tuned... 08:15:54 :) 08:16:23 I will update 08:16:35 I want to force the use of networkxx 2.0 08:16:42 eyalb: +1 08:16:47 but I am not sure other projects are ready 08:17:03 there is this bug https://bugs.launchpad.net/diskimage-builder/+bug/1718576 08:17:05 Launchpad bug 1718576 in Vitrage "Handle networkx 2.0 update" [High,In progress] - Assigned to Anna Reznikov (annarez) 08:17:11 to handle networkx 08:17:16 eyalb: I think it’s good for us, but not sure how it might affect other projects that might be installed together with Vitrage 08:17:23 some project are still in progress 08:17:36 but I am not sure it is updated 08:17:49 eyalb: Are they all still using launchpad? maybe we should check StoryBoard 08:17:50 eyalb: https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L81 contains 2.2, so it's the version which is used on gates 08:17:52 vitrage for example is ready but it says in progress 08:18:18 #link https://storyboard.openstack.org/#!/story/1718576 08:18:34 Vitrage status is updated here, but no other projects 08:18:59 also I couldn't find an rpm with this version for redhat or centos 08:19:07 so we need to talk to rdo guys 08:19:21 I found for fedora 08:19:26 You mean an rpm with networkx 2.0? 08:19:32 yes 08:19:44 And your motivation is to simplify our code? 08:19:47 eyalb: ubuntu bionic contains 1.11 08:19:48 so if I fix the rpm spec it will probably fail 08:20:10 the latest ubuntu has networkx 2 08:20:33 so i dont know what is the procedure here 08:21:01 eyalb: http://paste.openstack.org/show/736690/ 08:21:02 Maybe we can ask the requirements team 08:21:23 ifat_afek: if there is 2.2 in the upper-constraints, we can use that version 08:22:05 ifat_afek: unfortunately, we can't always use versions form rpm/deb packages 08:22:11 the only problem is with the packaging 08:22:20 eyalb: I agree 08:22:56 eyalb: usually, vendors make packages based on global requirements and upper-constraints 08:24:18 for ubuntu 18.10 there is networkx 2.1.1 08:24:33 https://packages.ubuntu.com/search?keywords=python-networkx 08:24:58 in our clouds we use only LTS versions 08:25:52 so we need to wait with this patch ? 08:25:56 and we build packages if they are not presented in ubuntu repos 08:26:41 eyalb: I already +1'ed on it. we can't wait for distros in this case. we have to force vendors/distros to get new packages 08:27:57 #link https://review.openstack.org/#/c/622293/ 08:28:20 ok 08:28:39 +1 08:28:55 so for now we will just force the use of networkx 2 but leave the code comptible with networkx 1 08:29:25 once all the vendors have the networkx 2 packages we will remove the code for networkx 1 08:29:54 eyalb: it doesn't make sence, because we won't test with 1.x once your patch will be landed 08:31:04 we dont test it now in the gate 08:31:10 if something is not tested, sooner or later it will be broken for sure 08:32:06 eOne: so what is your suggestion ? 08:32:34 drop 1.x support 08:32:55 but then it will break all the vendors 08:33:08 it should not 08:33:09 until they have a 2.0 package 08:33:37 vendors will create 2.x package once they will build packages for Stein 08:34:00 older versions must not be affected 08:34:39 and I do understand all the vendors pain with packaging 08:35:09 ok 08:35:38 e0ne: but when will vendors build the Stein packages? now or in April? what if we release Vitrage now? 08:36:06 ifat_afek: it depends on vendors, I can't answer you 08:36:26 So maybe it is safer to make the change near the end of the Stein cycle? 08:36:28 in our case, we build packages after the release 08:36:47 but RedHat and Ubuntu could do it much faster 08:37:25 ifat_afek: IMO, it's safer to get such changed earlier to get more time for testing and packaging 08:38:02 I’m just not sure that I understand the effect of having a Vitrage release now without packaging support 08:38:41 ifat_afek: there could be some issues with Vitrage Stein and networkx 1.x 08:38:55 ifat_afek: we've got 2.2 in global-requirements 08:39:16 ifat_afek: so it's good to get the version from global requirements 08:39:31 ifat_afek: so all openstack components will use the same library 08:39:56 ifat_afek: it's extremely important if you install services from packages on the same node 08:40:15 ifat_afek: unfortunately, everybody doesn't use containers now :( 08:40:51 #link https://docs.openstack.org/project-team-guide/dependency-management.html#why-do-we-have-a-global-requirements-list 08:41:59 e0ne: ok, I guess I’m convinced 08:42:14 :) 08:42:34 Any other issue for today’s meeting? 08:44:01 Have a nice day :-) 08:44:10 bye 08:44:12 see you next week 08:44:24 bye 08:44:31 #endmeeting