Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-02-15
15:42:36 mordred frickler: so it might be worth testing that as an approach on the fip-requiring clouds
15:43:19 mordred although then we run in to fun with clouds that have multiple private interfaces
15:44:34 cdent elmiko, dtantsur, edleafe not going to make it all
15:48:00 elmiko cdent: thanks for the heads up, you will be missed /me sniffles
15:48:19 elmiko also, you posts about the placement thingie in nova make me really curious
15:51:11 cdent elmiko: feel free to find me and ask me about whatever it is you are being curious about. When I'm not running errands (which will start soon)
15:54:29 elmiko cdent: i plan to hit you up in dublin, hopefully over brews ;)
15:54:48 cdent cool, you can meet my lovely wife too, she'll be there
15:57:50 edleafe oh, I'm *sure* she'll love to be chatting about placement
15:58:21 elmiko very cool!
15:58:25 elmiko haha
15:58:52 cdent I was trying to make excuses for two different instances of brews
16:24:37 mordred rods_, slaweq: stack is green at https://review.openstack.org/#/c/539271 finally - slaweq, I squashed the doc patch into the BaseProxy patch based on your review
16:25:07 rods_ mordred looking
16:32:47 elmiko edleafe, dtantsur, ready for review https://etherpad.openstack.org/p/api-sig-newsletter
16:39:15 SamYaple /win/win 49
16:39:32 mordred SamYaple: we see you
16:39:48 mordred SamYaple: (wanna review 539271 ?)
16:40:00 SamYaple already done
16:40:04 SamYaple but also, damn
16:41:30 SamYaple im about to switch to openstacksdk from shade internally. the testing is pretty painless so far
16:48:59 mordred SamYaple: woot!
16:49:16 edleafe elmiko: if you like my changes, ship it!
16:53:04 elmiko edleafe: love it! thanks =)
16:53:14 elmiko i wasn't sure about the -1 part, but i think you are spot on
16:58:32 edleafe elmiko: I'm not one of those "only say nice things" people
17:01:08 elmiko edleafe: yeah, i need to become better about that
17:28:52 openstackgerrit Merged openstack/python-openstacksdk master: Fix functional test about port https://review.openstack.org/544995
17:29:45 openstackgerrit Merged openstack/python-openstacksdk master: Collect tox and testr output in functional tests https://review.openstack.org/545001
17:31:55 openstackgerrit Merged openstack/python-openstacksdk master: Shift config exceptions to openstack.exceptions https://review.openstack.org/539396
17:48:44 openstackgerrit Merged openstack/python-openstacksdk master: Rename BaseProxy to Proxy https://review.openstack.org/539271
17:52:00 openstackgerrit Merged openstack/python-openstacksdk master: Generate proxy methods from resource objects https://review.openstack.org/540169
19:02:47 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Update all test base classes to use base.TestCase https://review.openstack.org/540373
19:02:47 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Update base test case to use base from oslotest https://review.openstack.org/540372
19:02:48 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Honor service type aliases from the catalog https://review.openstack.org/544356
19:04:26 mordred Qiming: ^^ ok. I think that should be working now. I apologize, it's a nasty patch to review - which is partially because the logic here SHOULD be in keystoneauth but I didn't make the cutoff for that and I'd like to backport this fix to queens
19:09:53 openstackgerrit Colleen Murphy proposed openstack/keystoneauth master: Add pep8 import order validation https://review.openstack.org/545094
19:46:58 rm_work heya
19:47:33 rm_work so, newest(?) release of openstacksdk seems to force some version discovery of endpoints that breaks on older (liberty) clouds :(
19:49:56 rm_work seems all of the 0.11.x versions
19:50:16 rm_work latest working that i have so far is a 0.9.x but i'm trying to figure out what i can test in 0.10.x
19:50:45 rm_work was 0.10.x basically skipped?
19:51:18 rm_work 0.9.19 seems to be the latest that works for me
19:53:37 openstackgerrit Merged openstack/keystoneauth master: Fix a spelling error https://review.openstack.org/541949
19:55:24 rm_work mordred: it was mentioned that you possibly were working on bits of this?
20:10:06 mordred rm_work: I am, in fact, working in a related area right now ... which service are you seeing issues with?
20:10:30 rm_work neutron specifically
20:10:32 rm_work i didn't test everything
20:10:44 rm_work `port list` is the worst
20:10:47 rm_work it just fails entirely
20:11:03 rm_work `floating ip list` prints some errors about version discovery but somehow still seems to return results
20:11:42 mordred rm_work: are you in a position where it would be easy for you to test a not-landed version of sdk?
20:11:53 rm_work prolly sure
20:12:01 rm_work I can just git-review and pip install -e
20:12:46 mordred rm_work: cool - if you git review -d 544356 ... I was just testing that octavia worked (it also doesn't have a version discovery doc)
20:13:27 mordred rm_work: and octavia is now working ... so if that state works, awesome - if not, we'll have to dig further
20:13:48 rm_work well
20:13:52 rm_work i run octavia from master
20:13:55 rm_work on my liberty cloud :/
20:14:04 rm_work so it won't test the same issue, lol
20:14:15 mordred it will not - but the port list test should be good
20:14:36 mordred rm_work: I've been testing octavia listing load balancer against the released version running in vexxhost public cloud
20:14:48 rm_work on your branch, port list fails
20:15:00 rm_work octavia lb list works tho
20:15:03 mordred rm_work: awesome! at least it's reproducible :)
20:15:19 rm_work but again, i'm on like
20:15:25 rm_work the absolute newest possible
20:15:28 mordred rm_work: so on liberty does neutron just not have a version discovery doc?
20:15:35 rm_work i think that's correct
20:15:45 rm_work which somehow was fine still in 0.9.19
20:15:51 rm_work but everything after that it explodes
20:16:03 mordred yah. major changes between 0.9.19 and 0.11
20:16:13 rm_work :(
20:16:27 mordred lemme make a local test case and figure out why that's exploding
20:17:33 mordred rm_work: if you add 'network' to the tuple on line 327 in openstack/config/cloud_region.py - does that fix port list?
20:20:09 rm_work it does not
20:20:15 mordred rm_work: oh - I have reproduced the issue locally
20:20:21 rm_work ;)
20:24:27 mordred rm_work: one more thing - can you try adding "network_api_version": "2", to openstack/config/defaults.json ?
20:24:55 mordred rm_work: I believe that will still not work foryou on liberty - but I'd like to double-check
20:24:57 rm_work in addition to the other change?
20:25:05 mordred rm_work: other change not needed
20:26:06 rm_work k, yeah, still no worky
20:26:35 mordred kk. thanks. I grok the problem and will now commence to cry for a litle while then make a fix for you
20:32:48 rm_work thanks :)
20:59:27 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Handle liberty-era neutron https://review.openstack.org/545117
21:05:36 mordred rm_work: ^^ if you have a sec, can you try that ^^ ?
21:07:45 openstackgerrit Brian Haley proposed openstack/python-openstackclient master: Add --dns-domain to 'network create' and 'network set' https://review.openstack.org/545124
21:14:28 openstackgerrit Merged openstack/keystoneauth master: Split request logging into four different loggers https://review.openstack.org/505764
21:14:30 openstackgerrit Merged openstack/keystoneauth master: Add some comments explaining split_loggers flag logic https://review.openstack.org/541066
21:16:03 rm_work mordred: seems to work! :)
21:16:12 rm_work \o/
21:16:16 mordred rm_work: woot!
21:23:05 openstackgerrit Merged openstack/keystoneauth master: Remove PYTHONHASHSEED setting https://review.openstack.org/533798
21:31:20 dasp around in openstacksdk. I can propose a solution as you suggested but I wasn't sure how deep we want to go there.
21:31:20 dasp mordred: I wanted to follow up on https://review.openstack.org/#/c/543035/. I get your point but I'm not sure that it would be sufficient - some proxies expose APIs at a given path (e.g. vip:443/glance/v2/images) and then when the API service (glance in this case) is cooperating (some allow you to define base path), the links to pages would not start with /vX. Ideally, I think keystoneauth1 is better place to handle that instead of working
21:48:43 mordred dasp: so... hrm. this is a tricky interaction between how relative paths work for http and how 'mounted' adapters deal with them clashing :(
21:50:37 mordred dasp: there isn't really anything we can do at the keystoneauth layer, as the Adapter is mounted at the versioned endpoint. if the service is returning an absolute path but not a full url in the next links, then it's running in to requests Adapter treating it as rooted on the adapter mount point rather than rooted on the base of the http target
21:51:20 mordred dasp: so we may need to do our own joining at the point where your patch is ...
21:52:49 mordred dasp: basically - if the uri returned from the pagination startswith '/' - then we need to do a urljoin on it with the service's url ... in fact, we might be able to do that unconditionally

Earlier   Later