| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-06-11 | |||
| 15:33:01 | gtema | and basically there is no easy way to establish connection and state which scope you want to connect to | |
| 15:33:32 | gtema | This leads to need of having multiple connection with/without user_project_name/id and selecting appropriate | |
| 16:06:15 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: WIP Use resource layer for compute.server cloud methods https://review.opendev.org/664593 | |
| 16:09:04 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use resource layer for compute flavors https://review.opendev.org/650903 | |
| 16:52:50 | openstackgerrit | Merged openstack/openstacksdk master: Set xenapi_use_agent to "False" instead of false https://review.opendev.org/664585 | |
| 17:06:56 | openstackgerrit | Merged openstack/openstacksdk master: Add access alias (aka) for the resource attributes https://review.opendev.org/663846 | |
| 19:02:33 | mordred | remote: https://review.opendev.org/664671 Release 0.31.1 of openstacksdk | |
| 20:26:46 | efried | mordred: argh, I just saw that ^, *just* pushed a change to use 0.31.0. What was wrong with .0? | |
| 20:26:59 | efried | anything I'm going to care about? | |
| 20:30:23 | efried | mordred: Also, in case you care, I figured out why I had to bump the minimum for os-service-types to fix the lower-constraints job in nova for the "placement uses sdk" patch. If you care, read on: | |
| 20:30:24 | efried | We were previously requiring a minimum ost from before placement extraction, so placement's "project" was still "nova", so we were looking for placement's adapter creds in the [nova] section rather than the [placement] section, but because we were only at 0.30.0 we weren't raising an error at that point, just using defaults. | |
| 20:38:21 | mordred | efried: nothing you're goign to care about - it's a Rackspace public cloud profile issue | |
| 20:38:30 | efried | cool | |
| 20:38:47 | mordred | efried: ah - makes sense re: ost | |
| 21:00:34 | efried | mordred: incidentally, it looks like everything related to clouds.yaml-from-nova is going to get punted for a while. | |
| 21:10:21 | mordred | efried: ok. | |
| 21:54:14 | mriedem | dtroyer: mordred: can one of you abandon this now? https://review.opendev.org/#/c/460059/ | |
| 21:55:17 | mriedem | and https://review.opendev.org/#/c/627801/ | |
| 21:55:28 | mriedem | and https://review.opendev.org/#/c/589012/ | |
| 21:55:56 | mriedem | those are all related to the same thing that i fixed already https://review.opendev.org/#/c/659382/ | |
| 21:57:26 | dtroyer | mriedem: yes, I was planning to do that, just haven't gotten far enough down on the list | |
| 22:00:09 | mriedem | ack | |
| #openstack-sdks - 2019-06-12 | |||
| 07:53:04 | obre | mnaser: Yes. And keystone reports "no user with username found" for the request looking up the user. It seems that it only works in domains with less than 100 users; or for the 100 first users in a domain. | |
| 07:53:34 | obre | c.list_users(domain_id='<ID>', username='foo') works though! So I have a workaroung :) | |
| 07:53:42 | obre | s/ng/nd/ | |
| 07:54:00 | dtantsur | mordred: could you check https://github.com/ansible/ansible/pull/54463 please? I've realized it hasn't merged yet :( | |
| 08:26:15 | dtantsur | mordred: also, we seem to have screwed up something around version discovery: NotSupported: The baremetal service for envvars: exists but does not have any supported versions. | |
| 08:26:23 | dtantsur | this is with --os-auth-type none | |
| 08:30:11 | gtema | I do also have troubles with ver discovery | |
| 08:30:29 | gtema | and it might be really something even in ks1 | |
| 08:32:48 | dtantsur | also this is very helpful: http://paste.openstack.org/show/752794/ :( | |
| 08:45:33 | openstackgerrit | Dmitry Tantsur proposed openstack/osc-lib master: Avoid misleading error message when using auth_type=none in clouds.yaml https://review.opendev.org/664830 | |
| 08:45:35 | dtantsur | one of the fixes ^^^ | |
| 08:51:46 | dtantsur | now, it doesn't respect endpoint_override.. | |
| 09:06:38 | openstackgerrit | Dmitry Tantsur proposed openstack/osc-lib master: Corrent using auth_type=none in clouds.yaml https://review.opendev.org/664830 | |
| 09:08:47 | dtantsur | okay, this fixes ironic for me, now checking what is wrong with ironic-inspector | |
| 09:13:30 | dtantsur | mordred, dtroyer, if you have a minute ^^^ | |
| 09:16:10 | openstackgerrit | Brin Zhang proposed openstack/python-openstackclient master: openstack port create support --extra-dhcp-option https://review.opendev.org/657519 | |
| 09:17:42 | openstackgerrit | Dmitry Tantsur proposed openstack/osc-lib master: Corrent using auth_type=none in clouds.yaml https://review.opendev.org/664830 | |
| 12:31:09 | gtema | oh god, why have I started this cloud layer cleanup??? Get/Create server is like HELL with all this "additional" logic | |
| 12:55:21 | mordred | dtantsur: done and done. and yes - that one is one of the super big messes | |
| 12:55:23 | mordred | gah | |
| 12:55:32 | mordred | gtema: the second part of that was for you | |
| 12:55:48 | gtema | eehhh | |
| 12:56:19 | gtema | I just feel it is easier to throw everything away and start from scratch. I need to fix literaly every single test | |
| 12:56:24 | dtantsur | thx! | |
| 12:56:25 | mordred | sadly, booting a server is one of the hardest things to do in openstack, mostly because none of the clouds can agree on how networking should work | |
| 12:56:45 | dtantsur | nova is overrated, just use ironic! | |
| 12:56:58 | dtantsur | :D | |
| 12:57:56 | gtema | I'm serious - it's terrible | |
| 12:58:12 | mordred | yeah - it's really the primary reason of shade's existence | |
| 12:58:28 | mordred | creating servers consistently across multiple different clouds is amazingly difficult and there are a billion corner cases | |
| 12:59:04 | mordred | you'd think "I want to boot a server that I can talk to" would be a simple thing ... | |
| 12:59:23 | mordred | gtema: I can take the create server paths if they're giving you fits | |
| 12:59:23 | gtema | from the Nova API POV - it is quite easy | |
| 12:59:47 | mordred | well - not _really_ once you get to block_device_mapping_v2 | |
| 12:59:59 | mordred | but yes - it's the neutron part of the coin where things get hard | |
| 13:00:02 | gtema | I wanted to first look at get_server, but due to it's normalization it's deeply tied with create_server | |
| 13:00:12 | gtema | so everything should be done at once | |
| 13:00:36 | gtema | and while I "haven't modified much of a logic" I need to adapt tons of tests already | |
| 13:00:54 | mordred | what's changing in the tests? | |
| 13:01:05 | gtema | normalization vs native object | |
| 13:01:40 | gtema | and for Resource there is not possibility to do expand_server | |
| 13:01:41 | gtema | ... | |
| 13:02:32 | gtema | let me probably concentrate on the implementation first and then together look at the tests | |
| 13:02:38 | mordred | ah - yeah. that is a fun pickle | |
| 13:02:40 | mordred | ++ | |
| 13:02:46 | gtema | looking on them right now is a huge mess | |
| 13:03:30 | mordred | gtema: maybe we should add an "expand" method to the server resource object that does expand_server's logic and fills in extra information? would that make things any easier? | |
| 13:04:12 | gtema | well, now I am parsing addresses when they are comming in the response and fill private/public_ipv4/6 | |
| 13:04:16 | mordred | (although it's especially fun on the clouds where nova lies about the contents of addresses so we query neutron directly and replace what nova sent) | |
| 13:04:31 | gtema | the expand itself however is also making network requests | |
| 13:04:34 | mordred | yup | |
| 13:04:43 | mordred | it has to - because the data coming from nova can't be trusted | |
| 13:04:54 | gtema | so can we trust at all into addresses? | |
| 13:05:04 | gtema | not at all? | |
| 13:05:20 | mordred | the nova address info has stale cache issues in enough places that we completely gave up believing it | |
| 13:05:35 | gtema | hmmm | |
| 13:05:51 | gtema | that's sad, because in my cloud it works and I was often relying on it | |
| 13:06:01 | mordred | most of the really weird things in all of that are the result of production issues we've had | |
| 13:06:04 | gtema | but if you say so I will give it up | |
| 13:06:26 | mordred | it's a scale/load thing - depends on how heavily the cloud is loaded at the time | |
| 13:06:44 | mordred | it's not that the values are _never_ correct, it's that you don't know when they are incorrect | |
| 13:06:51 | gtema | sad. It's there exactly to give you what you need | |
| 13:06:54 | mordred | yeah | |
| 13:07:23 | mordred | but, you konw - eventual consisteny | |
| 13:07:41 | gtema | great | |
| 13:07:47 | mordred | yeah. it's totally happy making | |
| 13:08:54 | mordred | gtema: that said - I'm 100% certain that whole stack could do with a refactor, that chunks should almost certainly be rewritten or rethought - it's definitely a mess | |
| 13:09:31 | gtema | sounds good. Let's do it this way then. Time to fix things | |
| 13:09:53 | Shrews | mordred: have you seen https://review.opendev.org/664681 ? that seems like it should be an openstacksdk option, not in nodepool | |
| 13:09:58 | gtema | so for now I will skip tests and focus on the implementation then | |
| 13:11:43 | gtema | this networking ___crapppp____ | |
| 13:12:37 | mordred | Shrews: I agree - it seems similar to "default_network" and "floating_ip_source" | |
| 13:12:44 | mordred | Shrews: in fact, I believe we have an option for that already | |
| 13:14:33 | Shrews | oh, i didn't look at the actual change, just the commit msg. it's just that we aren't plumbing the ip_pool value through TO the sdk | |
| 13:15:07 | mordred | oh - we have that config option in nodepool already? | |
| 13:15:14 | Shrews | no | |
| 13:16:12 | mordred | yeah - I don't think that's needed | |
| 13:16:17 | Shrews | mordred: however, i would have thought that we'd have a 'default' value in clouds.yaml. but i guess not? | |