Tuesday, 2019-10-29

*** ccamel has joined #openstack-sdks00:02
*** camelCaser has quit IRC00:04
*** tobiash has quit IRC00:08
*** tobiash has joined #openstack-sdks00:11
*** aspiers has quit IRC00:35
*** goldyfruit___ has quit IRC01:17
*** ricolin has joined #openstack-sdks03:57
*** Luzi has joined #openstack-sdks06:38
*** gtema has joined #openstack-sdks07:33
*** gtema_ has joined #openstack-sdks07:38
*** gtema has quit IRC07:41
*** slaweq has joined #openstack-sdks07:42
*** gtema_ has quit IRC07:42
*** gtema has joined #openstack-sdks07:48
*** gtema_ has joined #openstack-sdks08:00
*** gtema has quit IRC08:02
*** gtema_ has quit IRC08:15
*** gtema has joined #openstack-sdks08:15
*** gtema_ has joined #openstack-sdks08:16
*** dayou has quit IRC08:26
*** dayou has joined #openstack-sdks08:32
*** ralonsoh has joined #openstack-sdks08:44
*** jpena|off is now known as jpena08:51
*** jpich has joined #openstack-sdks08:54
*** dtantsur|afk is now known as dtantsur08:55
*** gtema_ has quit IRC08:58
*** Luzi has quit IRC09:07
*** Luzi has joined #openstack-sdks09:22
*** cdent has joined #openstack-sdks09:32
*** cdent has quit IRC10:02
openstackgerritRiccardo Pittau proposed openstack/openstacksdk master: Add reset_interfaces argument to patch_node  https://review.opendev.org/68941410:16
openstackgerritRiccardo Pittau proposed openstack/openstacksdk master: Add reset_interfaces argument to patch_node  https://review.opendev.org/68941410:18
*** cdent has joined #openstack-sdks10:38
openstackgerritDirk Mueller proposed openstack/cliff master: Revert "Pin cmd2 back to <0.9 on all versions"  https://review.opendev.org/69184110:54
*** cdent has quit IRC11:18
*** cdent has joined #openstack-sdks11:30
openstackgerritMerged openstack/openstacksdk master: Increase dogpile version for Py3.7 compatibility  https://review.opendev.org/69168011:55
*** goldyfruit___ has joined #openstack-sdks12:15
*** goldyfruit___ has quit IRC12:20
*** jpena is now known as jpena|lunch12:29
*** cdent has quit IRC12:37
*** gtema has quit IRC12:49
*** enriquetaso has joined #openstack-sdks13:01
*** dave-mccowan has joined #openstack-sdks13:05
*** jpena|lunch is now known as jpena13:19
*** goldyfruit___ has joined #openstack-sdks13:26
*** mriedem has joined #openstack-sdks13:29
*** gtema has joined #openstack-sdks13:41
*** goldyfruit_ has joined #openstack-sdks13:53
*** Luzi has quit IRC13:55
*** goldyfruit___ has quit IRC13:55
openstackgerritEric Fried proposed openstack/python-openstackclient master: Remove redundant OpenStackShell.prepare_to_run_command  https://review.opendev.org/69186513:57
efrieddtroyer, mordred: Easy one ^13:57
*** cdent has joined #openstack-sdks14:08
dtroyerefried: not necessarily easy, there were reasons that exists, and at the moment I don't recall if all of those reasons are gone yet.  They should be but I wouldn't bet dinner on it right now14:22
efrieddtroyer: I linked the superclass impl in there14:23
efriedAt least from what I can tell, it's doing the same thing. And you said yourself (in the TODO) that it could be removed after 1.4.0 :P14:23
efriedBut anyway, this is why we have reviews...14:23
dtroyerThen it should be good, but consider the author14:24
*** slaweq has quit IRC14:54
*** slaweq has joined #openstack-sdks14:55
*** slaweq has quit IRC14:55
*** slaweq has joined #openstack-sdks14:55
*** enriquetaso has quit IRC14:59
*** cdent has quit IRC15:27
*** umbSublime has joined #openstack-sdks15:40
umbSublimewith a connection object is it possible to specify the api microversion. Something equivalent to conn.compute.get('/os-hypervisors?with_servers=true', microversion='2.53')15:44
*** slaweq has quit IRC15:49
efriedumbSublime: Yes, all the methods (including the REST primitives like .get(), .put(), etc.) should take a microversion kwarg. Let me double check how it's spelled...15:49
umbSublimeefried: sorry I wasn't really clear, my example works15:51
efriedoh, you want to specify the default microversion for the connection so you don't have to put in the kwarg every time?15:52
umbSublimeMy question was more, is this possible with for example  conn.compute.hypervisors()15:52
* efried looks...15:52
*** gtema_ has joined #openstack-sdks15:53
*** slaweq has joined #openstack-sdks15:54
efriedumbSublime: I was wrong, the non-primitives don't take a microversion. You can set the default microversion on the proxy though.15:55
umbSublimeIs that something I setup when creating the connection15:56
* umbSublime never used the proxy15:56
efriedSorry, conn.compute is the proxy15:56
efriedSo it should definitely work like:15:57
efried  conn.compute.default_microversion = XXX15:57
*** mgariepy has quit IRC15:57
efriedBut there's probably a prettier way to do it, via config or something.15:57
umbSublimeAhh I see, thanks15:57
*** cdent has joined #openstack-sdks15:58
efrieddtantsur: do you have that answer off the top ^ ?15:58
umbSublimeand what about the 'with_servers=True', I see it works with .get, but with .hypervisors() it get's ingored.15:58
umbSublimeI pass it as a kwarg on .hypervisors()15:58
dtantsurI suspect something like default_compute_microversions15:58
*** goldyfruit___ has joined #openstack-sdks15:59
dtantsurhowever, if you need to set it for e.g. conn.compute.hypervisors, then somebody is doing it wrong: other we or you :)15:59
*** mgariepy has joined #openstack-sdks15:59
dtantsuropenstacksdk is expected to use the latest microversions it knows. if it doesn't - it's a bug.15:59
dtantsurif it does, then changing the default won't help you15:59
efrieddtantsur: Didn't mordred just fix something for that?15:59
dtantsurmaybe, I haven't been following closely the last couple of weeks16:00
umbSublime"somebody is doing it wrong" -> most likely me16:00
dtantsurumbSublime: it may help if you describe the problem you're facing16:00
efriedhttps://review.opendev.org/#/c/685999/ implies we weren't getting the compute microversion we were expecting.16:01
*** goldyfruit_ has quit IRC16:01
umbSublimedtantsur: I have a meeting coming, up but I'll be back with the deets16:01
efriedumbSublime: What version of keystoneauth are you using?16:02
efriedit's possible that without https://review.opendev.org/#/c/685042/ you're getting 2.1 instead of 'latest'.16:04
efrieddtantsur: ^16:04
dtantsuryeah, this may be the cause16:05
dtantsurthese microversions, never liked them :)16:05
efriedumbSublime: So you may want to make sure you have ksa 3.18.0 (it looks like the Train fix hasn't merged yet)16:06
efriedand see if that fixes the issue16:06
efriedumbSublime: As for `with_servers`, that was added in the 2.53 microversion of the compute API, but we might not have brought SDK up to parity yet.16:07
efriedumbSublime: You should propose a patch to add that :P16:13
openstackgerritEric Fried proposed openstack/python-openstackclient master: DNM: CI check  https://review.opendev.org/69191016:23
*** enriquetaso has joined #openstack-sdks16:40
openstackgerritMerged openstack/openstacksdk master: Add support for Node tainted field  https://review.opendev.org/69075516:41
*** jpena is now known as jpena|brb16:45
*** gtema_ has quit IRC16:51
umbSublimeefried: I'm using keystone v3. As for the microversion I get from the proxy how can i check this? i can only see 'version=2' in vars(conn.compute)17:13
umbSublimev3.11 for ksa17:14
*** jpena|brb is now known as jpena17:24
*** gtema has quit IRC17:28
*** gmann is now known as gmann_afk17:29
*** gmann_afk is now known as gmann17:35
*** dtantsur is now known as dtantsur|afk17:41
*** jpich has quit IRC18:15
*** jpena is now known as jpena|off18:30
*** senrique_ has joined #openstack-sdks18:40
mriedemdtroyer: can we get this simple osc change in https://review.opendev.org/#/c/691039/ to unblock novaclient 16.0.0 from being in u-c https://review.opendev.org/#/c/690097/18:40
*** enriquetaso has quit IRC18:42
*** ralonsoh has quit IRC19:08
*** senrique__ has joined #openstack-sdks19:33
*** senrique_ has quit IRC19:36
*** cdent has quit IRC19:39
efriedmriedem: something changed between then and now, osc isn't building: https://review.opendev.org/#/c/691910/20:38
efriedso your patch won't clear the gate, is my point.20:38
mriedembut not just mine, any you're saying20:38
efriedAnd btw, I have no idea what's going on there. I can't repro "locally"20:38
efriedyes, noticed it on one of mine, seemed unrelated, so I put that up to confirm.20:39
efriedmebbe you can do your logstash thing and find the culprit?20:39
* mriedem does his thing20:40
mriedemmy guess is some py2/3 thing was dropped/released20:40
mriedemhttp://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22TypeError%3A%20Unicode-objects%20must%20be%20encoded%20before%20hashing%5C%22%20AND%20tags%3A%5C%22console%5C%22&from=7d isn't super useful20:42
*** gtema has joined #openstack-sdks20:42
efriedI guess it wouldn't be, since nobody's been building anything in osc except for me.20:43
mriedemwell, could be openstack-requirements for a dependency20:43
mriedembut i'm not seeing anything obvious20:43
efriedbut it shows that whatever it is only affects python-openstackclient.20:44
mriedemthis hashlib library that's blowing up here https://github.com/openstack/python-openstackclient/blob/4bde9af89251431791fc8d69fe09d5e17a8fba8f/openstackclient/tests/functional/compute/v2/test_agent.py#L24 hasn't changed in forever on pyi20:44
mriedemhttps://zuul.opendev.org/t/openstack/build/49ff6a5645554095b3fb51bce497aff5/log/tox/functional-0.log hmm is that in the standard lib now?20:44
mriedemthis job must use py36?20:45
efrieddid that job recently cut over to py3?20:45
mriedemthat's my guess20:45
efriedwell, its incarnation in python-openstackclient didn't, so unless it has an ancestor that did...20:45
mriedemthat's entirely possible, parent projects are moving to py3 in ussuri20:46
mriedemseems ok https://opendev.org/openstack/devstack/src/branch/master/.zuul.yaml#L56620:47
mriedemparent: multinode20:48
efried...which is abstract, whatever that means.20:49
mriedemmeans it just has to be extended i think20:49
efriedwell, yeah20:50
efriedbtw, attempting to run simply tox -e functional on my devstack node deadlocks.20:50
mriedemi don't see anything recent in openstack-zuul-jobs that looks related20:50
mriedemor devstack20:50
*** gtema has quit IRC20:51
mriedemthe job does have USE_PYTHON3=False in it20:51
mriedemso it should be using py220:51
efriedbut isn't?20:51
*** gtema has joined #openstack-sdks20:52
mriedemlooks like it's using py3 https://zuul.opendev.org/t/openstack/build/49ff6a5645554095b3fb51bce497aff5/log/job-output.txt#3063220:52
mriedem$ /usr/bin/python3 -m virtualenv --no-download --python /usr/bin/python3 functional20:53
efriedI'll push a fix.20:53
efried...without for the moment caring that we "should be running py2". Because we really shouldn't.20:53
*** gtema has quit IRC20:53
mriedemi think you just need to put USE_PYTHON3: True in here https://github.com/openstack/python-openstackclient/blob/master/.zuul.yaml#L7620:54
efriedbut the problem is that it *is* using py3 and md5().update() needs an encoded string.20:54
mriedemwell, a quick fix would be setting basepython = python2 in the tox.ini functional env i think if the job isn't using py3,20:55
openstackgerritEric Fried proposed openstack/python-openstackclient master: Fix functional tests for py3  https://review.opendev.org/69198020:56
mriedembut if the parent is now using py3, yeah idk what's going on there that changed20:56
efriedmriedem: That ought to fix at least that error, we'll see if something else crops up.20:56
efrieddtroyer: FYI: TL;DR: python-openstackclient builds broke some time between 10/24 and this morning when the functional jobs somehow got cut over to py3. Fixing via https://review.opendev.org/69198020:57
efriedactually, I can narrow it down further. I have a successful build Oct 28 19:31 (that's US Central time)20:59
mordredefried: how did we manage to break builds?20:59
efriedmordred: haven't figured that out yet.21:00
efriedAs far as mriedem and I can tell, "something" cut over to py321:00
efriedIf this build is running py2, that'll be confirmed: https://zuul.opendev.org/t/openstack/build/ad5f0ee04fed4285b9f5429debd9b32d/log/job-output.txt21:00
*** dtruong has quit IRC21:01
openstackgerritPierre Prinetti proposed openstack/python-openstackclient master: versions: Fix 'versions show' help message  https://review.opendev.org/68640821:01
*** dtruong has joined #openstack-sdks21:01
efriedI'm not good at definitively determining whether a job is running under py2 or py3, but afaict that one is py2, and today's broken ones are py321:02
mordredefried: that one seems to be py2 - I see a bunch of false for use python3 - and an uninstall of python3 package21:02
efriedsome zuul ancestor somehow cut over to py3 overnight21:02
efriedbut mriedem and I couldn't find it.21:03
efriednow - the right thing of course is for python-openstackclient to be testing under py3 anyway.21:03
mordredI mean- luckily that patch from you isn't super big21:03
efriedthose jobs should have probably been (cloned or) cut over yonks ago.21:03
efriedwell, not yet :)21:03
mordredI assume that patch is perfect and complete21:04
efriedI haven't been able to run the suite locally at all, so just have to wait for zuul to tell us whether that's all that's required to cut over.21:04
efriedmordred: actually, since you're here with your godlike powers, perhaps you could set that node up to hold when/if it fails so we can get in there and iterate?21:05
openstackgerritPierre Prinetti proposed openstack/python-openstackclient master: versions: Fix 'versions show' help message  https://review.opendev.org/68640821:05
efriedstill queued at the moment...21:05
mordredefried: yeah - one sec21:08
mordredefried: k. autohold placed21:10
openstackgerritEric Fried proposed openstack/python-openstackclient master: Fix 'versions show' helps & docs  https://review.opendev.org/69198921:26
mriedemefried: see http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010430.html - just hit the ML, but says that openstackclient needs to support py27 for swift21:29
mriedemosc isn't a library though so i'm not sure about all that21:30
mordredwait - yeah. doesn't make sense that keystonemiddleware would need openstackclient21:30
mriedemi'm replying21:30
mordredI just checked - osc is not a dep of keystonemiddleware21:31
mriedemi'm guessing it just means devstack + osc for testing swift, but osc doesn't need to be py2 for that21:33
*** senrique__ has quit IRC21:37
efriedmriedem: FWIW 'openstackclient' and 'python-openstackclient' are different projects. It's likely they meant the latter even though they said the former. And in any case the former isn't a dep.21:38
mordredneither should be a dep21:38
efriedjust to add further depth to the confusion.21:38
mordredand if either are, we should fix that :)21:38
efriedmordred: http://zuul.openstack.org/stream/d39bf114ffc943c8b28a5c602395b10b?logfile=console.log I could be wrong, but this appears to be running under py2???21:39
efriedis it possible that certain CI nodes are running py3 by default, so if this job doesn't say anything, it gets whatever it happens to land on??21:41
efriedand all four of the runs previously noted just happened to get lucky?21:41
mordredit really shouldn't be - we use the same images across all clouds21:41
efriedmm. So maybe I just don't know what I'm looking at. But I saw lots of "pyXX doesn't match your env" messages fly by.21:42
mordredwell - this is complicated - because there's the devstack install - and then there's the tox venv inside of which the functional tests run21:42
efriedokay, I'll stfu until it gets a bit further.21:43
mordredlooks like the tox file should have been running functional tests themselves in py3 for a while now21:44
mordredso - this will be fun to understand :)21:44
mriedemwithout basepython set in tox.ini i'm guessing you get whatever node you land on21:45
mriedemso it's probably good to be explicit and switch those functional jobs over to py321:46
mriedemand set USE_PYTHON3=True in the zuul job def21:46
mordredwell - basepython is set in tox ...21:46
mordredbut yeah - we should set USE_PYTHON3=True anyway21:46
mordredjust because21:46
mriedemi mean basepython isn't set in https://github.com/openstack/python-openstackclient/blob/master/tox.ini#L621:47
mriedemor https://github.com/openstack/python-openstackclient/blob/master/tox.ini#L7021:47
mordredit's totally set in my local copy - what's up with that?21:47
mordredah. BWAHAHAHA21:48
mordredhttps://review.opendev.org/#/c/686590/ <-- that was on the tip of my local checkout :)21:49
*** slaweq has quit IRC21:52
*** mordred has left #openstack-sdks21:59
*** mordred has joined #openstack-sdks21:59
mordredefried: am I in the right channel? my irc client somehow split this channel into two different buffers and I'm confused ...22:00
efriedmordred: I see you, but was switched out and haven't read anything in the last 18 mins or so. Catching up...22:00
efriedmordred: beaut. and as you can see, it failed the same jobs the same way22:02
efriedmordred: so basically, you discovered this problem three weeks ago and didn't say anything.22:03
mordredefried: neat!22:03
efriedmy patch got past the previous point okay. It's failing some tests tho, so being able to iterate on the node will be useful. However, I likely will have to bail before then. Is it legit to hold the node until tomorrow?22:04
*** goldyfruit___ has quit IRC22:04
*** mriedem has quit IRC22:06
mordredyah. point me at your key though22:22
mordredefried: I believe the default node hold timeout is 24h22:22
*** goldyfruit___ has joined #openstack-sdks22:35
*** slaweq has joined #openstack-sdks22:49
*** slaweq has quit IRC22:54
*** senrique__ has joined #openstack-sdks23:20
*** goldyfruit___ has quit IRC23:45
*** goldyfruit___ has joined #openstack-sdks23:48
*** senrique__ has quit IRC23:54

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!