| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-12-19 | |||
| 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 | |
| 18:20:48 | openstackgerrit | Merged openstack/openstacksdk master: Handle HTTP errors in add/remove router interface calls https://review.opendev.org/687304 | |
| 18:59:05 | gundalow | sshnaidm If you ask in #ansible-devel there should be others that can help. | |
| 18:59:35 | sshnaidm | gundalow, thanks, I think we're good, no rush | |
| 19:02:07 | gundalow | Ok | |
| #openstack-sdks - 2019-12-20 | |||
| 05:15:38 | rm_work | I'd like to add "--loadbalancer" to the `openstack availability zone list` client function ... but ... that'll mean I need to actually add octaviaclient as a dep? MAYBE? I guess I could try to weave it in to detect whether it's present or not... anyway, thoughts on the whole concept? | |
| 05:15:42 | rm_work | mordred maybe? ^^ | |
| 13:25:59 | rm_work | so much part/join spam, lol | |
| 13:26:22 | rm_work | restating: I'd like to add "--loadbalancer" to the `openstack availability zone list` client function ... but ... that'll mean I need to actually add octaviaclient as a dep? MAYBE? I guess I could try to weave it in to detect whether it's present or not... anyway, thoughts on the whole concept? would this be accepted? | |
| 13:26:53 | rm_work | (also, is this the right channel for the client?) | |
| 13:32:38 | frickler | rm_work: this is the right channel, that question I can answer easily | |
| 13:32:54 | rm_work | :D | |
| 13:33:17 | frickler | for the real question, mordred and/or dtroyer may be able to be more helpful | |
| 13:34:29 | frickler | and now that I summoned them, I'm also asking for reviews on https://review.opendev.org/679834 , that feature just merged in neutron and the OSC patch is used in it's docs https://review.opendev.org/679834 | |
| 14:00:06 | mordred | rm_work: how about use sdk for that instead of octaviaclient | |
| 14:00:47 | mordred | there's already an sdk object in osc - you can use it to do things. if the feature you need isn't in sdk - adding it is likely a good idea :) | |
| 14:01:24 | mordred | (we're wanting to migrate osc away from *client completely anyway - so adding new *client deps would be ++sad) | |
| 14:08:11 | rm_work | mordred: ah you know, i think i might already be doing that (had started working on the code) | |
| 14:08:17 | rm_work | yeah i think I am, lol | |
| 14:08:18 | rm_work | whelp | |
| 14:08:32 | rm_work | anyway, question is also about whether folks are cool with adding that to the main call there | |
| 15:00:03 | dtroyer | rm_work: that —loadbalancer option is fine as long as it doesn't add a hard dependency | |
| 15:00:58 | dtroyer | frickler: I think I can make some time for reviews later this morning… it is waaaaay overdue | |
| 15:01:31 | gtema | yey, dtroyer is back at reviewing patches | |
| 15:03:14 | gtema | one of those is https://review.opendev.org/#/c/698874/ - I would reuse this then for network and image | |
| 15:24:30 | rm_work | Cool thanks dtroyer 👍 | |
| 18:31:06 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP Lay a foundation for the project cleanup https://review.opendev.org/700219 | |
| 20:18:32 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP Lay a foundation for the project cleanup https://review.opendev.org/700219 | |
| #openstack-sdks - 2019-12-22 | |||
| 19:59:37 | openstackgerrit | Merged openstack/openstacksdk master: Add return cluster_id when query actions list https://review.opendev.org/699650 | |
| #openstack-sdks - 2019-12-23 | |||
| 09:33:59 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP Lay a foundation for the project cleanup https://review.opendev.org/700219 | |
| 14:34:20 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP Lay a foundation for the project cleanup https://review.opendev.org/700219 | |
| 16:29:31 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP Lay a foundation for the project cleanup https://review.opendev.org/700219 | |
| 20:53:43 | openstackgerrit | Merged openstack/os-service-types master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/688250 | |
| 20:53:44 | openstackgerrit | Merged openstack/os-service-types master: Blacklist sphinx 2.1.0 (autodoc bug) https://review.opendev.org/687795 | |
| 21:03:34 | openstackgerrit | Merged openstack/os-service-types master: Update the constraints url https://review.opendev.org/685556 | |
| 21:14:38 | openstackgerrit | Merged openstack/os-service-types master: Updated from OpenStack Service Type Authority https://review.opendev.org/672295 | |
| #openstack-sdks - 2019-12-24 | |||
| 06:46:11 | openstackgerrit | Merged openstack/os-service-types master: Switch to Ussuri jobs https://review.opendev.org/690859 | |