| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-05-07 | |||
| 10:11:15 | mordred | gtema: that's ... fun! | |
| 10:11:18 | gtema | so checking whether checksum match the one we upload might be bad | |
| 10:11:22 | mordred | yeah | |
| 10:11:47 | mordred | hrm. in that case, how does one verify the upload was good? | |
| 10:11:52 | gtema | so probably we might want to add a flag to create_image to validate the checksum | |
| 10:11:55 | mordred | yeah | |
| 10:12:15 | gtema | good, will do this now | |
| 10:12:16 | mordred | and maybe that should be a setting we plumb through to be able to be set in a vendor file | |
| 10:12:45 | gtema | yeah, for now probably just really a parameter, and later a plumb | |
| 10:12:48 | mordred | ++ | |
| 10:36:40 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.opendev.org/651534 | |
| 10:37:17 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.opendev.org/651534 | |
| 10:37:48 | gtema | so, now it is a param to create_image (validate_checksum) with default value of True | |
| 12:25:37 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.opendev.org/651534 | |
| 14:03:45 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.opendev.org/651534 | |
| 15:33:16 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.opendev.org/651534 | |
| 16:35:14 | openstackgerrit | guang-yee proposed openstack/python-openstackclient master: document the --timing option https://review.opendev.org/657640 | |
| 17:53:57 | cdent | mordred: seems horizon is not in service-types-authority. did we do that on purpose? | |
| 19:01:49 | mordred | cdent: yes - it is not an API service | |
| 19:02:08 | mordred | cdent: so there is never a need for anything to ask the keystone catalog for its endpoint | |
| 19:02:28 | mordred | that said - if there's a reason it should go in there, it's not like I'm opposed or anything :) | |
| 19:24:37 | dtroyer | mordred: what level of officialness does a project need to get listed in s-t-a? ie, StarlingX has a number of endpoints that we should canonicalize somewhere, if not in s-t-a directly then in a subclass of it I suppose… | |
| 19:26:30 | mordred | dtroyer: that's an excellent question | |
| 19:27:38 | mordred | dtroyer: for my money, I'm a bit of a maximalist on that - because I think having an agreed definition of a service type is good ... but that might be a topic to run by the openstack tc since they're currently the stewards of that repo (although manage it via delegated powers) | |
| 19:27:54 | mordred | dtroyer: I'd find it much harder to deal with additional files | |
| 19:30:47 | dtroyer | mordred: that seems mostly appropriate from the historical context. I wonder of any other ecosystems using Keystone add their own endpoints? | |
| 19:31:18 | dtroyer | It isn't totally unlike OSC tracking all plugins (that wish to be tracked) in the OSc docs since that is the friendliest place to consume that list from... | |
| 19:31:29 | mordred | yeah | |
| 19:31:50 | mordred | like - one of those times where strict lines between official and unofficial are less useful | |
| 19:32:04 | dtroyer | or official from a different mother | |
| 19:32:06 | mordred | yeah | |
| 19:32:50 | dtroyer | I think I am going to outline what I would add and start from that, use it for the basis of asking the question | |
| 19:33:17 | mordred | cool. feel free to CC me as a generally supportive human | |
| 19:33:54 | dtroyer | roger that, thanks | |
| #openstack-sdks - 2019-05-08 | |||
| 04:07:16 | adriant | mordred: I'm having some really really weird issues with using the SDK to talk to our octavia | |
| 04:07:51 | johnsom | adriant: how so? | |
| 04:07:58 | adriant | a script that used to work, now doesn't seem to (for reasons I can't figure out) and even downgrading, or upgrading SDK or keystone auth versions does nothing | |
| 04:08:00 | adriant | http://paste.openstack.org/show/751055/ | |
| 04:08:11 | adriant | johnsom: see error | |
| 04:08:55 | adriant | i'm not sure if octavia is screwed and should be returning links to version urls, or if it never did | |
| 04:11:33 | johnsom | Octavia had the links, what version of Octavia API are you using? Very old versions didn’t have links, but the newer version does. Sdk accounted for this. | |
| 04:17:43 | adriant | johnsom: we are running Queens, Octavia, which I thought had links? | |
| 04:17:53 | adriant | at least from looking at the code | |
| 04:18:12 | adriant | https://github.com/openstack/octavia/blame/master/octavia/api/root_controller.py#L56 | |
| 04:18:42 | johnsom | adriant: 2.0.3 fixed the links issue. If you are running an older version of queens I highly recommend you update to the current queens version. | |
| 04:19:36 | johnsom | Current is 2.1.0 fyi | |
| 04:20:54 | adriant | I'm just curious why this 'used' to work | |
| 04:21:01 | adriant | and now doesn't | |
| 04:21:50 | adriant | we haven't upgraded octavia for a while, and I'm fairly sure the tools we had that used the SDK to talk to it, did used to work as recently as a month or two back :( | |
| 04:21:53 | johnsom | Yeah, I don’t have an answer for that. Octavia hasn’t touched the links code in a while so not likely the issue. | |
| 04:23:59 | adriant | weird :/ | |
| 04:32:12 | adriant | johnsom: so looks like weird running a version that doesn't include links... | |
| 04:32:20 | adriant | but then why did the SDK used to work? | |
| 04:32:42 | adriant | was it updated to only expect links, or did it ever handle the non-link case? | |
| 04:32:59 | johnsom | Yeah, older versions compensated for that | |
| 04:33:08 | adriant | hmmm | |
| 04:34:17 | johnsom | I can’t speak for the sdk as I don’t track it closely. I can only talk to what we did in Octavia. | |
| 04:34:18 | adriant | any reason why it isn't capable of both cases? | |
| 04:34:32 | adriant | although I guess that's a mordred question | |
| 04:34:52 | adriant | because it's an annoying bit of backward incompatibility :( | |
| 04:35:11 | johnsom | Yeah, we fixed it in Octavia as soon as it was raised that we had an issue/bug. | |
| 04:35:12 | adriant | we plan to upgrade octavia to stein soon anyway, but still awkward | |
| 04:35:48 | johnsom | Yeah, even a queen update would probably fix you up. | |
| 04:36:44 | adriant | meanwhile I'm going to just find an old version of the SDK that still works I guess | |
| 04:36:59 | johnsom | Ok. Sorry for the trouble! | |
| 04:38:39 | adriant | I'm just curious why this code every worked... | |
| 04:38:43 | adriant | ever* | |
| 04:41:32 | adriant | and downgrading the SDK gets me a different error! :P | |
| 04:41:35 | adriant | "UnboundLocalError: local variable 'api_version' referenced before assignment" | |
| 04:43:36 | adriant | ty cdent | |
| 04:49:15 | adriant | well ok, I just can't make the SDK talk to Octavia :/ | |
| 04:55:02 | adriant | actually, johnsom, when did you add version discovery at all to Octavia? | |
| 04:56:13 | adriant | nvm, looked at the repo | |
| 04:56:14 | adriant | ages ago | |
| 04:56:17 | adriant | hmmm | |
| 04:58:20 | johnsom | Yeah, a long time ago | |
| 05:20:31 | adriant | I give up, I'll rewrite this code to use the octavia client tomorrow... | |
| 05:20:55 | adriant | if anyone has alternative ideas for me when I look at IRC tomorrow, I'd be happy to try them. | |
| 06:21:22 | adriant | HAH! 0.17.2 works! | |
| 06:27:37 | adriant | so yeah, mordred, I'd call this a regression bug. SDK ought to work with older octavia despite the lack of links in the version listing. | |
| 08:18:08 | openstackgerrit | Witold Bedyk proposed openstack/python-openstackclient master: document the --timing option https://review.opendev.org/657640 | |
| 13:06:41 | mordred | adriant: yeah - i agree - let's see if we can't figure out a fix | |
| 13:08:12 | mordred | adriant: oh - you know what ... (sorry I wasn't awake when you were encountering this ...) | |
| 13:08:44 | mordred | oh, no, nevermind. I thought there might be a one-line fix | |
| 13:16:54 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Workaround for older octavia https://review.opendev.org/657799 | |
| 13:17:13 | mordred | adriant: when you wake up ... ^^ that should fix you from a workaround perspective | |
| 13:17:37 | mordred | adriant: looking at the code, I have a few ideas of how to solve this slighly less hacky - but they'll take a few more minutes to work on | |
| 13:18:12 | gtema | mordred: just a few minutes longer? that's like immediately ;-) | |
| 13:18:19 | mordred | gtema: hehe | |
| 13:19:26 | mordred | tl;dr - I think if we refactor openstack.service_description.ServiceDescription._make_proxy a little bit, we can make it easier to override parts of the story for individual services ... in their ServiceDescription subclass | |
| 13:20:13 | gtema | what do you mean? | |
| 13:21:07 | mordred | I'm not 100% sure yet :) | |
| 13:21:15 | gtema | :D | |
| 13:24:14 | mordred | johnsom: does octavia have microversions? (doesn't look like it) - also, I see a comment in the code that indicates exposing the v1 endpoint is a security risk - does that mean it's reasonable at this point to assume v2 is the only thing we'll be talking to (in the cases where version discovery doesn't work) | |
| 13:25:32 | mordred | gtema: I *think* what I'm thniking is that we have the ServiceDescription class do the initial stuff the same for everybody - then have a method we can override on a per-service basis (but most wouldn't) - that handles "what do I do if I found the service but service discovery didn't work" | |
| 13:26:23 | mordred | but what I shoudl really do is finish that patch from above and add some tests that show the correct behavior with a linkless octavia version document | |
| 13:27:13 | gtema | yes, right. | |
| 13:28:50 | gtema | mordred: as I see we do not currently have any tests for vendor profiles. I see those are really tricky, but probably need to introduce some | |
| 13:29:22 | gtema | especially since I am preparing this vendor_hook as part of the vendors/*.json and openstack.connect(vendor_hook='') | |
| 13:32:34 | mordred | gtema: yes. we should probably make some tests | |