14:02:47 #startmeeting sahara 14:02:47 Meeting started Thu Mar 7 14:02:47 2019 UTC and is due to finish in 60 minutes. The chair is tellesnobrega. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:50 The meeting name has been set to 'sahara' 14:02:53 sorry I'm late 14:03:02 o/ 14:03:08 o/ 14:04:17 #topic News/Updates 14:05:40 working on dashboard stuff and writing a candidacy statement 14:05:45 \o/ 14:06:16 I mostly focused on improving the set of jobs that we run on the gates, (v2 jobs, cleanup of dashboard jobs, jobs for the plugins, etc) 14:06:20 well written btw 14:06:35 thanks! :) 14:06:38 I'm still fighting py2 -> py3 compatibility 14:07:15 I can get in more details later 14:08:38 any more news? 14:09:10 lets move on 14:09:18 #topic APIv2 14:09:29 how are we doing for making apiv2 stable today? 14:09:38 let's go for it! 14:09:42 most of the "deploy with unversioned endpoints" patches have been merged 14:09:49 i don't see any reason not to make it stable 14:09:53 the only remaining one is for tripleo-heat-templates 14:10:08 but I'm going to start a friendly nagging campaign :) 14:10:52 jeremyfreudberg, can you write the patch to make it stable? 14:11:02 tellesnobrega: it's already there :) 14:11:08 tellesnobrega, https://review.openstack.org/#/c/582282/ 14:11:50 oh, missed it 14:12:14 +2ed 14:12:22 thanks for the hard work on it jeremyfreudberg 14:12:29 and tosky 14:12:38 my pleasure :) thanks all 14:13:22 tosky, whenever you feel like we are ready to merge it, you can do the honors 14:13:53 moving on 14:14:03 #topic Python 3 14:14:56 so, I can make sahara work with python 2 and with python 3, but not at the same time 14:15:58 and right now, I'm not sure how to get it to work 14:16:16 the issue is with how we load from pickle on the remote machine 14:16:32 on python3 it needs to read from sys.stdin.buffer 14:16:41 and on python2 it reads from sys.stdin 14:17:09 "at the same time" means a mixture? or it just means one codebase which supports both individually? 14:17:21 supports both individually 14:17:26 got it 14:18:00 I'm thinking that I may have to check the local python version running and send it as kwargs to the remote machine 14:18:39 and update the script to execute the appropriate function depending on the version 14:19:05 does that seem like a good plan? 14:21:18 if it works, yes - but how does it work? If you have python3 on the sahara server and python2 on the instance, the instance can just executed one codebase (python2) 14:22:02 I think that the remote python won't be an issue 14:22:14 I just need to get the right "connection" 14:22:26 I will give it a try and see how it goes 14:22:41 the complication comes from this cross-python communication 14:23:05 other had the same issue; looking around, I can see for example https://review.gluster.org/#/c/glusterfs/+/21320/ 14:24:34 hmm 14:24:39 I will take a look into it 14:25:47 hopefully I will be able to get it to work today 14:25:49 lets see 14:26:17 other than that, do we have any blocking issues for M3? 14:28:06 not really super-urgent, but we have two reviews for the plugins 14:28:23 which ones? 14:28:27 not python3 related (well, one of them is iirc) 14:29:08 https://review.openstack.org/#/c/634799/ should be good to go 14:29:26 i'll review that 14:29:44 thanks jeremyfreudberg 14:29:55 on https://review.openstack.org/#/c/639812/ we had an open question - the fix itself is fine, it does not introduce regressions, I was also wondering if it scales or if it makes sense to introduce a more general mechanism 14:30:28 but at this point it would be for Train or much later, if we don't want to bump the requirements so early 14:31:55 I would say lets keep this for now 14:32:04 and revisit it later 14:32:42 actually, the code as is now, is better than before, because it was simply comparing a string to int 14:32:51 making that comparison completely useless 14:34:16 yeah, in python 2 aren't all strings greater than any int? 14:34:59 yes 14:35:08 that is why it was a useless check 14:35:31 I didn't know that it was a string until I changed to python3 14:35:48 than the comparison exploded 14:37:18 why not do it as 1. try to convert to int 2. if fail, convert it to -1 14:37:47 that works too 14:38:35 avoids the py3 problem with uncomparable types. no regression if we catch the exception for casting to int. 14:38:47 does that makes sense to you tosky ? 14:39:05 i might be missing one aspect of it, so, please weigh in, tosky 14:39:27 sure, no problem 14:39:55 give that a try, then (technically it's a bug so it can be done after M3 if there isn't time) 14:40:41 I can get that in quickly 14:40:50 cool 14:41:23 I might have some good news 14:41:35 the check for sys.stdin type worked with python 2 14:41:38 let me see python3 14:42:11 anything else on this? 14:43:12 #topic M3 14:43:34 just want to double check what we need to cut on m3 14:43:55 let's please release a new saharaclient and bump the minimum for sahara-dasbhoard 14:44:00 and also ask if jeremyfreudberg wants to do the honors and make the patches 14:44:41 jeremyfreudberg, you are almost certainly the next PTL and getting the versions in is part of your job to come 14:44:51 so start early is easier later on 14:45:22 so, if you want, you can be responsible for m3 and later on for the final release 14:45:38 i'm planning to disappear awfully soon today (and won't be back till what feels like a bit late), so if there are late merged patches i won't be around to get the right hash. i can propose something for the client now, just to understand how it works 14:46:04 and i'll handle it for the final release 14:46:10 jeremyfreudberg, ok, so I can do it for m3 14:46:13 you do the final release 14:46:19 yup 14:46:28 thanks 14:46:39 ok, so new client, bump version on the dashboard 14:46:59 do we need a sahara cut? I'm still getting a hang on the new process 14:47:48 I don't remember if a release is needed for m3, but we need for sure an initial release of the plugins 14:48:02 otherwise we can't patch openstack-ansible to install them :) 14:48:55 ok, should them be tagged as beta? 14:48:57 so maybe releasing also a new pre-release for sahara core is not going to be so complicated 14:49:09 https://releases.openstack.org/reference/release_models.html 14:49:12 I don't remember which is the correct version number at this point 14:49:26 we are cycle-with-rc iirc, so we don't need m3 14:49:30 just RC 14:49:36 and final release for sahara itself 14:49:41 the plugins I'm cutting as beta 14:50:35 anything else? 14:50:55 plugins, client, bump version of client on sahara-dashboard 14:51:01 and I think that is all 14:51:22 good update on python3 14:51:42 it worked with python3 now 14:51:44 oh 14:51:50 I will send a patch 14:51:58 not just bump version of client on sahara dashboard, i think also release sahara-dashboard for m3 -- if there's a requirements bump, i think it's a courtesy to do it before feature freeze 14:51:59 do you mean the mixed python3+python2? 14:52:41 jeremyfreudberg, got it 14:52:50 jeremyfreudberg: but we can't bump the client requirement of the dashboard before releasing the client, so not for m3 14:53:28 tosky, yes, same image, ran python2 and python3 locally and the cluster became active 14:53:30 tosky, but the client will be released sooner, since I'm writing that patch separately from telles's other releases 14:55:07 jeremyfreudberg: so that depends on the speed that it will take to accept the release patch for saharaclient 14:55:43 because if we miss this week, next week it's outside M3, so maybe at that point we will go directly to RC1 14:56:29 tosky, jeremyfreudberg if it merges really soon we can bump, if not we can only deffer to RC1 14:56:39 sure 14:57:44 we are running out of time 14:58:07 https://review.openstack.org/#/c/641690/ - think i did that right 14:58:47 looks good 14:59:22 I guess we can close for the day 14:59:30 thanks everyone 14:59:46 see you all next week 15:00:04 thanks 15:00:07 #endmeeting