16:00:54 #startmeeting api-sig 16:00:56 Meeting started Thu Jan 9 16:00:54 2020 UTC and is due to finish in 60 minutes. The chair is dtantsur. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:01 The meeting name has been set to 'api_sig' 16:01:01 #chair sshnaidm elmiko 16:01:02 Current chairs: dtantsur elmiko sshnaidm 16:01:04 yay 16:01:14 happy holidays everyone 16:01:25 welcome back to 2020 meetings.. 16:01:31 what, work again?? 16:01:42 I'm sorry, I already worked last year.. 16:01:43 dtantsur, no, to talk :) 16:01:43 hehe, ++ dtantsur 16:02:02 #link https://etherpad.openstack.org/p/openstack-ansible-modules 16:02:07 our agenda ^^ 16:02:26 #topic Need to decide finally about the strategy 16:02:32 oops 16:02:40 didn't mean it 16:02:46 there is always #undo 16:02:58 #undo topic 16:02:59 Removing item from minutes: #topic Need to decide finally about the strategy 16:03:14 it's too complicated 16:03:30 we talked and sent mails about how we need to move modules 16:03:39 I just want to be sure we're all on the same page 16:04:17 I think we stopped on moving modules to ansible SIG repo, linking with new names in Ansible repo 16:04:42 and redesigning if need with kind deprecation notices 16:04:49 right 16:04:51 is it correct ^ 16:05:13 any comments, objections ? 16:05:52 ok, let's move on 16:06:07 about freezing current modules in Ansible github repo 16:06:42 I notices we still have patches merging: https://github.com/ansible/ansible/commits/devel/lib/ansible/modules/cloud/openstack 16:07:17 so, do we have a good way to make sure we really freeze them after a moving? 16:07:35 and we move them next week when gundalow is back from PTO 16:07:39 drop permissions of cloudnull 16:07:42 mordred, stephenfin ^^ 16:07:58 gtema, :) 16:08:05 he was approving lots of PRs 16:08:23 I'll talk with cloudnull 16:08:36 but I think we need to send something to Ansible core team 16:08:41 like make it official 16:09:12 yeah, perhaps a good idea 16:09:13 yep 16:09:15 and kindly to ask to ignore patches or make their bot to print a message there 16:09:28 like "from now please use gerrit in .. blabla" 16:10:06 #action sshnaidm to send message to Ansible core team about freezing OS modules 16:10:16 (sorry, i am in and out but following along) 16:10:33 mnaser, sure 16:10:42 ok, let's move on if no objections 16:10:47 Should we move modules with keeping history? 16:10:59 i think you'll probably need some process (and an actual collection) in place before they'll actually freeze them (if they even do) 16:11:02 nope - ansible github is history 16:11:16 yeah- I think moving with history is too much work at this point 16:11:25 Shrews, we will do it after a move I think 16:11:54 I think dtantsur had some experience with keeping history, was is complicated ? 16:12:04 Dmitry Tantsur proposed openstack/os-client-config master: Add a release note for Python 2 support removal https://review.opendev.org/701761 16:12:09 hi (just listening today) 16:12:10 splitting a subtree in git is not hard 16:12:23 but submitting all the resulting patches to gerrit is going to kill our infra 16:12:36 dtantsur, ack 16:12:38 so somebody will have to (force-)push them to gerrit 16:12:46 that's what we did for ironic-tempest-plugin in the end 16:12:54 (actually, we also merged two git trees from two repos, that was fun) 16:13:05 if someone wants do to the subtree split, I can do the gerrit goo 16:13:42 any volunteers? ^ 16:14:05 c'mon, it's fun! 16:14:17 not me. I do not see any benefit 16:14:31 if no volunteers - not keeping history then 16:14:33 * dtantsur assumes gtema has something to hide in `git blame` :D 16:14:44 sshnaidm: I can do it if people find it useful 16:14:55 but I don't insist if nobody does 16:15:06 time for a poll? :) 16:15:08 I think it might be useful, but not deal-breaker 16:15:14 dtantsur - actually only very few fixes were really landed, so - nope ;-) 16:15:14 * dtantsur hasn't used the poll functionality in a while 16:15:27 dtantsur, does it have a poll? 16:15:37 #poll Should we keep the git history of the moved modules? Yes, No 16:15:50 given that it doesn't react, I might have done something wrong 16:16:02 #startpoll Should we keep the git history of the moved modules? Yes, No 16:16:47 Yes, No 16:16:50 all right, let's make it simple.. no keeping history 16:16:57 +1 16:17:12 we have things to do beside that.. 16:17:27 let's move on 16:17:38 next question - python 2/3 compatibility 16:17:49 Ansible supports from 2.6(?), but Openstack is moving to 3 completely. Should we stick to Ansible and support from 2.6/2.7? 16:18:00 * dtantsur finally remembered it was #startvote 16:18:18 if openstacksdk drops python 2, we cannot support it 16:18:23 dtantsur, we can use it for this topic ^ ) 16:18:30 haha, let's try 16:18:44 #startvote Should we let Python 2 live? Yes, No, OMG 16:18:45 Begin voting on: Should we let Python 2 live? Valid vote options are Yes, No, OMG. 16:18:46 Vote using '#vote OPTION'. Only your last vote counts. 16:18:54 OMG 16:19:01 #vote OMG 16:19:09 #vote No 16:19:41 #vote hehe 16:19:41 gtema: hehe is not a valid option. Valid options are Yes, No, OMG. 16:19:42 interesting, what gundalow thinks about it, but we'll know that only next week 16:19:45 To elaborate on my vote: we're planning something forward-looking, and Python 2 is dead today 16:19:48 # vote no 16:19:53 #vote no 16:20:18 anyone else wants to play with the vote functionality? :) 16:20:42 #vote again - no 16:20:43 gtema: again - no is not a valid option. Valid options are Yes, No, OMG. 16:20:47 gtema, dtantsur made it case sensitive :o 16:20:56 it's not case sensitive, but it requires a valid option 16:21:03 doesn't looke like that 16:21:08 #endvote 16:21:09 Voted on "Should we let Python 2 live?" Results are 16:21:10 OMG (1): sshnaidm 16:21:11 simly "no" was accepted 16:21:12 No (2): gtema, dtantsur 16:21:16 as you see ^^ 16:21:19 ah, worked 16:21:52 ok, I hope Ansible people won't be mad we break their 2.7 support.. 16:22:02 sorry - juggling two meetings - #vote no :) 16:22:14 too late 16:22:27 too late, we decided no :) 16:22:30 looks like there were no yes votes anyway :) 16:22:31 #agreed Unless gundalow objects next week, we won't keep Python 2 support 16:22:36 \o/ 16:22:42 mordred, you just want to join the winning part! 16:22:44 I mean - sdk isn't keeping python 2 support anyway 16:22:56 so, you know, don't know that these modules have much choice :) 16:23:01 :D 16:23:03 yeah, but so far we haven't stripped it off 16:23:09 this is true 16:23:14 we *have* removed testing 16:23:35 yes, that's true. But I explicitely was not starting to drop "six" 16:23:38 hehe 16:23:39 not tested == broken 16:23:52 very true ^ 16:24:18 you forgot "if" in a comparison 16:24:26 ok, I think we finished all topics from agenda, and now - open discussions 16:24:29 it's a boolean expression 16:24:52 then it should be a single "=" 16:25:11 gtema, in boolean? 16:25:14 gtema: I'm thinking in python :) 16:25:41 open discussion - what is with jobs for proper testing and releasing? 16:26:07 gtema, good question 16:26:47 I configured a job that doesn't test anything for now 16:26:48 https://review.opendev.org/#/c/698085/ 16:26:50 on opendev writing jobs should be easier 16:27:09 it's a job that always was running in ansible patches 16:27:24 everything is easy until you start doing that 16:27:32 so I'll configure it to run on current repo and it will be a start 16:28:06 we can run some tripleo jobs as well 16:28:12 should we move func tests from SDK here, or link to SDK? 16:28:33 I have a feeling that the new repo is a better place for tests 16:28:46 and basically those SDK func tests must install collection first 16:28:54 me too 16:29:03 (not this "me too") 16:29:16 gtema, and apply a patch I suppose.. 16:29:30 well, you can install collection from local 16:29:50 gtema, yeah, I think you make a tarball and then install it, iirc 16:29:53 so it's basically just "ansible-galaxy collection build && ansible-galaxy collection install" 16:29:59 exactly 16:30:00 yep 16:30:40 zuul applies patches for you 16:30:43 well, I think it will be more clear when we move it finally 16:31:06 I'm not familiar with SDK jobs 16:31:18 but do we have there something 16:31:26 that can be helpful for modules as well? 16:31:35 there are tests for modules 16:31:56 I suppose we need installed Openstack to run modules that change it 16:32:05 devstack, tripleo, whatever 16:32:06 https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/tests/ansible 16:32:10 yah - there is a module function test job that runs against devstack 16:32:24 I totally agree, those should move into the collection repo once we've got it 16:32:35 and we can still also trigger it from sdk for cross-testing 16:32:46 sure 16:33:04 essentially, it runs devstack and then runs the module tests against the api endpoint from the devstack 16:33:10 it's not COMPREHENSIVE 16:33:16 but it's a solid starting place 16:34:17 as I see there are test actions, but not verifications..? like in https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/tests/ansible/roles/keystone_domain/tasks/main.yml 16:34:29 ironic coverage can be provided by bifrost 16:34:33 right 16:34:55 sshnaidm: well, the verifications are a little implicit for now 16:35:25 that update isn't going to work if the create didn't, etc ... but we can *definitely* improve these and make them better 16:35:29 and should 16:35:46 it's been harder to improve that with the modules in ansible/ansible and the tests in openstacksdk 16:36:09 yeah, maybe using molecule will be helpful too 16:36:34 yah - maybe so - I hear you know something about that :) 16:36:34 for testing on various platforms for example 16:36:43 not definitely - you want to mess with devstack and molecule? 16:36:50 mordred, yeah, we use it heavily now 16:37:11 devstack is providing openstack cloud 16:37:28 but all tests can be wrapped in molecule 16:38:11 for last triple module I just used keystone container for testing 16:38:30 and running os_keystone_* tasks with it 16:38:42 not even whole openstack 16:38:59 the same tried with ironic dev container 16:39:30 cool 16:40:07 like - my brain doesn't necessarily know how that all hangs together, but I could imagine seeing some patches would bea . good learning experience all around 16:40:07 OK, I think we agreed to design a good testing for modules after a move 16:40:14 ++ 16:40:55 anything else in your minds? 16:41:35 OK, I think we're good for today 16:41:44 and welcome back everyone 16:41:51 happy new year! 16:42:01 +1 16:42:09 #endmeeting