Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-12-19
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
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

Earlier   Later