| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-19 | |||
| 16:11:09 | gtema | that is for sure. I am still thinking how we can enable testing in the new repo | |
| 16:11:11 | sshnaidm | they are out of sync.. | |
| 16:11:31 | sshnaidm | gtema, we have pep and old ci job there in patches | |
| 16:11:44 | sshnaidm | later we'll need to work on that more of course | |
| 16:12:10 | sshnaidm | I think we agreed also not to change anything in 2.9 | |
| 16:12:25 | sshnaidm | for not to sync them manually | |
| 16:12:38 | gtema | well, 2.9 is out in the wild anyway, so we can't change anything there | |
| 16:12:57 | sshnaidm | gtema, I mean via github PRs to ansible upstream | |
| 16:13:05 | sshnaidm | or via backports | |
| 16:13:17 | gtema | yes | |
| 16:13:34 | sshnaidm | next: Should we move modules with keeping history? | |
| 16:13:44 | gtema | there is anyway currently nobody watching for PRs (while I see there are discussions from the PR-contributors) | |
| 16:14:09 | sshnaidm | gtema, well, I submitted a few patches in last months | |
| 16:14:15 | gtema | I, personally, see no need in that, but also not object in keeping history | |
| 16:14:24 | gtema | I know | |
| 16:14:29 | sshnaidm | I'd like to keep the history tbh is possible | |
| 16:14:36 | sshnaidm | s/is/if/ | |
| 16:14:54 | sshnaidm | it helps to understand the logic of changes | |
| 16:14:58 | gtema | yeah, this is nice "if" | |
| 16:15:19 | gtema | but anyway for history you can always refer to Ansible itself | |
| 16:15:27 | sshnaidm | gtema, right | |
| 16:15:41 | sshnaidm | - Should we move now and not to wait till Jan? | |
| 16:15:56 | sshnaidm | I think it's obvious we need to wait | |
| 16:16:00 | gtema | hmm, | |
| 16:16:15 | gtema | from what I see there are currently nobody except us here now | |
| 16:16:22 | sshnaidm | we will need gundalow that is in PTO to make changes in Ansible itself, botmeta etc | |
| 16:16:28 | gtema | and we "agreed" to do this beginning of Jan | |
| 16:16:32 | sshnaidm | yeah | |
| 16:17:20 | gtema | let's better wait for Jan. I don't want to touch this now and instead enjoy calm time at work | |
| 16:17:30 | sshnaidm | agree | |
| 16:17:35 | sshnaidm | - python 2-3 compatibility | |
| 16:17:51 | gtema | this is nice | |
| 16:17:56 | sshnaidm | I think pabelanger wrote about it: technically should follow ansible engine, which is p26 / py27 / py35 / py36 / py37 / py38 | |
| 16:18:00 | gtema | we just "dropped" py2 tests in sdk | |
| 16:18:12 | sshnaidm | or maybe not pabelanger.. people, put your names please in etherpad notes! | |
| 16:18:25 | gtema | but in ansible modules themselves I don't think we have some weird stuff | |
| 16:19:03 | sshnaidm | gtema, that's interesting, if Ansible runs on 2.7 and openstacksdk supports 3 only | |
| 16:19:11 | gtema | so actually technically saying we can't guarantee anymore, that any new SDK release will support py2 | |
| 16:19:26 | gtema | ansible runs on py3 as well | |
| 16:19:46 | sshnaidm | gtema, I take the worst case when somebody run it on 2.7 host | |
| 16:19:56 | gtema | and sdk<=0.39.0 guarantee py2 compat | |
| 16:20:14 | gtema | it will work now | |
| 16:20:28 | sshnaidm | gtema, we won't freeze sdk reqs I think | |
| 16:20:33 | gtema | but not guaranteed to be working with SDK=0.40.0 | |
| 16:20:59 | gtema | no, we only have a dep in modules themselves | |
| 16:21:07 | sshnaidm | so I think we may not to support 2.7 hosts.. | |
| 16:21:10 | gtema | as min_version | |
| 16:21:54 | gtema | with just 12 days left until EOL - we need to push people. And we still do this gently | |
| 16:22:15 | gtema | we havn't started removing support for py2, we just stopped verifying it | |
| 16:22:54 | gtema | and I know myself how it is - myself having still platforms with py2 only | |
| 16:23:14 | gtema | so we will definitely not start in the near future in SDK to drop py2 compat things | |
| 16:23:16 | sshnaidm | gtema, well, yeah, and ansible claims for 2.6 support btw | |
| 16:23:24 | sshnaidm | it will be interesting | |
| 16:24:09 | gtema | I'm tired of those crappy things. Let's just leave it as it is and enjoy watching what will happen | |
| 16:24:20 | sshnaidm | gtema, :D | |
| 16:24:36 | sshnaidm | I'll try to wrap up | |
| 16:24:59 | sshnaidm | and get some ansible folks opinions maybe, would be great to get rid off 2.7 of course | |
| 16:25:26 | sshnaidm | any other topics to discuss? | |
| 16:26:02 | gtema | actually not for me. I am "waiting" for the release/test jobs | |
| 16:26:13 | sshnaidm | ok, great | |
| 16:26:13 | gtema | I think this should be addressed next | |
| 16:26:27 | sshnaidm | yeah, | |
| 16:26:48 | sshnaidm | but this is in the new year | |
| 16:27:01 | sshnaidm | thanks all! | |
| 16:27:13 | gtema | wlcm | |
| 16:27:21 | sshnaidm | #endmeeting | |
| 16:27:23 | openstack | Meeting ended Thu Dec 19 16:27:21 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:27:24 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-19-16.05.html | |
| 16:27:25 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-19-16.05.txt | |
| 16:27:26 | openstack | Log: http://eavesdrop.openstack.org/meetings/api_sig/2019/api_sig.2019-12-19-16.05.log.html | |
| 16:27:45 | gtema | elmiko, to your previous question of cancelling meeting next week - I think it realy makes sense | |
| 16:28:45 | gtema | me and dtantsur are definitely having holidays, I think you guys as well | |
| 16:32:38 | elmiko | yes | |
| 16:33:06 | elmiko | i was just thinking about sending an email to let the community know. we don't get many visitors, but just in case. | |
| 16:33:16 | gtema | agree | |
| 16:33:28 | elmiko | also, we should probably re-evaluate whether we should even host an office hour. i don't think we've had any serious issues in months | |
| 16:33:57 | elmiko | at this point we could handle all questions via the mailing list, and if something like this current discussion (ansible) comes up, we can always schedule something. | |
| 16:34:11 | elmiko | but, i'll leave that debate for 2020 ;) | |
| 16:34:13 | gtema | you are right | |
| 16:34:17 | gtema | sure | |
| 16:36:43 | elmiko | if don't see you online, have a nice holiday and joyous new year gtema =) | |
| 16:37:02 | gtema | thanks elmiko, you too a very nice holidays | |
| 17:01:08 | Shrews | gtema: your recent comment on https://review.opendev.org/687304 confuses me | |
| 17:02:08 | Shrews | PS4 used assertRaises() but you -1'd that because the exception message was not checked, which requires using testtools.ExpectedException. I don't understand your recommendation to go back to assertRaises() | |
| 17:02:16 | gtema | if we don't need to check the message content itself why not to have self.assertRaises(SDKException, sot.remove_interface, sess, **body) | |
| 17:02:28 | gtema | it is shorter and doesn'T require additional import | |
| 17:02:31 | Shrews | yes, but see your previous -1 :) | |
| 17:02:58 | gtema | aaaah, it was so long ago | |
| 17:03:25 | gtema | if we do not check the message (what would be nice) - we can have shorter form. | |
| 17:03:39 | gtema | but even if we do this - there is no need for import testtools | |
| 17:03:55 | Shrews | i think we all agree on that, but the other form is needed to satisfy your request to check the message | |
| 17:04:13 | gtema | beah | |
| 17:04:25 | gtema | this is anyway not done | |
| 17:04:31 | Shrews | yes it is | |
| 17:04:46 | Shrews | the 'msg' variable is the expected message | |
| 17:04:57 | Shrews | ExpectedException(type, msg) | |
| 17:04:58 | gtema | ah, ok | |
| 17:05:06 | gtema | sorry, overseen it - long day | |
| 17:09:32 | Shrews | no worries :) | |
| 17:11:00 | gtema | ok, hacking "project-cleanup" into SDK, so brain is in a quite weird state | |