| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-04-06 | |||
| 10:26:44 | dtantsur | mrhillsman: what operating system are the jobs run on? | |
| 10:26:46 | mrhillsman | yeah cdent i actually need to take a week or two to just read through the docs again and really digest and play around with things | |
| 10:27:01 | mrhillsman | ubuntu xenial | |
| 10:27:21 | cdent | yeah, cargo culting and copy pasting can only get one so far :) | |
| 10:27:52 | mrhillsman | if you have some requests please post as issue here - https://github.com/theopenlab/openlab | |
| 10:28:20 | mrhillsman | i.e. you guys only do ubuntu i want some centos devstack | |
| 10:28:26 | mrhillsman | idk | |
| 10:28:34 | mrhillsman | just an example | |
| 10:29:55 | dtantsur | oh, ubuntu has rust packaged, nice! | |
| 10:51:49 | dtantsur | mrhillsman: do I need to use https://github.com/theopenlab/openlab-zuul-jobs/blob/master/roles/copy-files-on-node/tasks/main.yml to get the results posted? | |
| 10:55:47 | mrhillsman | i do not believe so, that should be inherited | |
| 10:58:15 | dtantsur | mrhillsman: okay. let's see how https://github.com/dtantsur/rust-openstack/pull/18 goes | |
| 10:58:39 | mrhillsman | ++ | |
| 11:03:47 | mrhillsman | i could be wrong, but i do not think it will run with .zuul.yaml and zuul.d | |
| 11:04:17 | mrhillsman | i'm seeing warnings | |
| 11:04:19 | mordred | mrhillsman: yah - ou're right | |
| 11:04:26 | mrhillsman | and zuul has not started | |
| 11:04:33 | dtantsur | \o/ | |
| 11:04:35 | mrhillsman | there's the man with confirmation :) | |
| 11:04:35 | mordred | just move .zuul.yalm to zuul.d/project.yaml or something similar | |
| 11:04:57 | dtantsur | mrhillsman: while I'm fixing that, is it possible to add openlab to the formal list of github checks? | |
| 11:05:08 | dtantsur | so that it does not show all green while the CI is running? | |
| 11:06:04 | mrhillsman | it should not be showing all green while the ci is running | |
| 11:06:06 | dtantsur | also, is it possible for me to see logs while it's running? | |
| 11:06:12 | mrhillsman | yep | |
| 11:06:18 | dtantsur | mrhillsman: it shows all green after Travis is done.. | |
| 11:06:30 | dtantsur | ah wait, no it appeared | |
| 11:06:34 | dtantsur | s/no/now/ | |
| 11:06:46 | dtantsur | probably it did not show because I screwed up the files :) | |
| 11:07:36 | mrhillsman | :) | |
| 11:07:44 | dtantsur | mordred: your review won't hurt on https://github.com/dtantsur/rust-openstack/pull/18 ;) | |
| 11:24:43 | openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: Add methods to get all of the version data https://review.openstack.org/559154 | |
| 11:35:00 | openstackgerrit | Doug Hellmann proposed openstack/keystoneauth master: add lower-constraints job https://review.openstack.org/555625 | |
| 11:39:18 | openstackgerrit | Doug Hellmann proposed openstack/cliff master: add lower-constraints job https://review.openstack.org/555405 | |
| 13:04:45 | openstackgerrit | Doug Hellmann proposed openstack/cliff master: add lower-constraints job https://review.openstack.org/555405 | |
| 13:43:41 | openstackgerrit | Colleen Murphy proposed openstack/keystoneauth master: add lower-constraints job https://review.openstack.org/555625 | |
| 14:26:53 | dtantsur | mrhillsman: JFYI the first tests got merged in master :) https://github.com/dtantsur/rust-openstack/pull/18 | |
| 14:27:47 | mrhillsman | very nice ;) | |
| 14:40:02 | openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: Add methods to get all of the version data https://review.openstack.org/559154 | |
| 14:50:54 | dtantsur | mrhillsman: hmm, the CI does not fire on https://github.com/dtantsur/rust-openstack/pull/20 for some reason, do you know why? | |
| 14:55:08 | mrhillsman | looking | |
| 15:06:54 | mrhillsman | not sure what happened but fixed | |
| 15:07:16 | mrhillsman | i commented a recheck and it is working | |
| 15:10:05 | openstackgerrit | Jens Harbott (frickler) proposed openstack/openstacksdk master: WIP: Add functional tests for Neutron DNS extension https://review.openstack.org/559068 | |
| 15:11:18 | dtantsur | mrhillsman: yep, thanks! I'll take a note to recheck tests if they don't run | |
| 16:04:20 | _alastor_ | Does the openstacksdk "connect" factory function not support Python2? | |
| 16:05:07 | _alastor_ | On Ubuntu using 0.12.0 I can connect to my devstack instance using python3 and openstacksdk, but when using python2 I get an attribute error for "connect" | |
| 16:07:33 | _alastor_ | http://paste.openstack.org/show/718613/ | |
| 16:46:26 | mordred | _alastor_: it SHOULD work in python2 - but looking | |
| 16:46:51 | mordred | _alastor_: that pip freeze command might be just running in python3 for you | |
| 16:46:58 | mordred | _alastor_: try "python2 -m pip freeze" | |
| 16:47:47 | _alastor_ | mordred: got the same 0.12.0 version running pip freeze that way | |
| 16:49:32 | mordred | hrm. that's very strange - there's nothing magic about that function | |
| 16:50:15 | mordred | _alastor_: trying to reproduce the issue locally ... | |
| 16:50:27 | mordred | (or find other things for you to try so we can figure out what's wrong) | |
| 16:51:07 | _alastor_ | Ubuntu 16.04, devstack sha: 4dde3b8b7cf0a0ea96a9b8fe8cb1de8cfa97250e | |
| 17:01:34 | mordred | _alastor_: not that it helps you - but fwiw, http://paste.openstack.org/show/718614/ | |
| 17:02:31 | mordred | _alastor_: you might also try print(openstack.__file__) and print(openstack.version.__version__) just to make sure there isn't something really weird going on with paths | |
| 17:03:32 | _alastor_ | Definitely something weird. Python thinks that openstack is a built-in | |
| 17:04:14 | _alastor_ | http://paste.openstack.org/show/718615/ | |
| 17:10:54 | _alastor_ | The python2 version is pointing at the correct dist-packages module: '/usr/local/lib/python2.7/dist-packages/openstack' | |
| 17:11:11 | _alastor_ | And all the files appear to be present, but python insists on non fully loading it | |
| 17:18:22 | _alastor_ | Reinstalling openstacksdk didn't fix it | |
| 17:20:09 | _alastor_ | Installing openstacksdk in a python2 virtualenv fixes the problem, but it still doesn't explain why the system openstacksdk is messed up | |
| 17:20:59 | _alastor_ | Nothing was done on this system except installing Devstack, copying a few Cinder driver files and running Tempest | |
| 17:44:35 | johnsom | mordred I want to get on that version discovery issue, but the docs are still TODO: https://specs.openstack.org/openstack/api-wg/guidelines/discoverability.html Do you have a link or pointer to what I need to fix for Octavia? | |
| 18:05:20 | dtruong | morded, I added a senlin devstack job in https://review.openstack.org/#/c/555762/ to run senlin functional test. | |
| 18:05:22 | dtruong | However the senlin-api service fails to connect to keystone with SSL error: http://logs.openstack.org/62/555762/7/check/openstacksdk-functional-devstack-senlin/2de7149/controller/logs/screen-sl-api.txt.gz#_Apr_06_01_27_32_527646 | |
| 18:05:40 | dtruong | Is there anything that I missed in the senlin job definition? | |
| 18:10:49 | mordred | johnsom: best thing I've got is the example dicts here: http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery | |
| 18:11:15 | johnsom | Ah, ok, thanks for the pointer! | |
| 18:11:55 | mordred | johnsom: tl;dr - the links entry is what octavia is missing right now | |
| 18:12:08 | johnsom | Ok | |
| 18:12:21 | mordred | johnsom: it just needs a single entry with your /v2 endpoint in it | |
| 18:12:32 | mordred | and then you should be all set! | |
| 18:13:11 | mordred | johnsom: if you get a patch, we should do a depends-on with an openstacksdk patch that removes the octavia workaround | |
| 18:13:59 | mordred | _alastor_: I'm having a similar but not *quite* the same issue myself, with the same symptoms - works in a virtualenv, has issues non-venv | |
| 18:14:11 | johnsom | Ok, yeah, ping me with it. I can use that as a test case too. However it will likely be later today before I have something. I pivoted to another project. | |
| 18:14:12 | mordred | _alastor_: I don't have answers yet, but clearly this is a big problem | |
| 18:14:42 | mordred | johnsom: let's just circle back to it early next week maybe - I got up super early today and am almost done for the day | |
| 18:14:59 | johnsom | Sounds good. Have a good weekend | |
| 18:15:49 | mordred | you too! | |
| 18:16:06 | _alastor_ | mordred: Ok, I'm both glad and sad it's not a unique issue :) | |
| 18:16:45 | mordred | _alastor_: me too - I really would have preferred it if your machine was just weird :) | |
| 18:21:54 | gtmanfred | mordred: when you have time, i would like to talk about this https://storyboard.openstack.org/#!/story/2001794 We have just released our new cloud driver for salt-cloud that uses shade, but are running into this race condition with one of our customers | |
| 18:50:33 | ssurana | Hey Guys! need some more reviews on https://review.openstack.org/#/c/558461/ thanks! | |
| 18:53:09 | mordred | gtmanfred: yes - I'd love to talk about that - I'm not 100% here at the moment, so maybe I can catch you on Monday | |
| 18:53:23 | gtmanfred | That would work perfectly! | |
| 18:53:37 | mordred | gtmanfred: fwiw - there are two mechanisms shade uses for doing auto floating ips - one of them is safe for multi-process use, the other is not | |
| 18:53:59 | gtmanfred | cool, i might need to just switch to the safe one, because right now I am only using create_server | |
| 18:54:03 | gtmanfred | with wait=True | |
| 18:54:46 | gtmanfred | yeah, we have updated the customer that we are going to work with upstream to get this fixed, so we are clear for a bit on my end. | |
| 18:54:46 | mordred | gtmanfred: gotcha. so - lemme dig up the part that does the safe mechanism | |
| 18:54:51 | gtmanfred | :+1: | |
| 18:55:02 | mordred | sweet | |
| 18:56:20 | gtmanfred | Thanks! | |
| 18:56:34 | mordred | gtmanfred: ok. the code isn't friendly to link to - the tl;dr is - rather than doing create floating ip + attach floating ip - if you find the neutron port that is assocated with the target fixed ip on the server, you can pass that port to the create floating ip call - and if you do, neutron will create-and-attach the floating ip -so it'll never be in a state where another process can find it and try | |
| 18:56:36 | mordred | to attach it | |
| 18:57:48 | mordred | gtmanfred: I'll see if I can't write up a little something about it that would be more readable than attempting to trade the shade logic itself (which is a bit crazier than one would like) | |
| 18:59:52 | gtmanfred | that would be awesome! thanks! take your time, I can wait till monday if you need | |