| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-06-11 | |||
| 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? | |
| 13:16:21 | mordred | https://docs.openstack.org/openstacksdk/latest/user/config/network-config.html - nat_source | |
| 13:16:40 | Shrews | ah! yes | |
| 13:16:57 | Shrews | excellent | |
| 13:17:17 | mordred | Shrews: we should maybe figure out how to document those _better_ - it seems like people can never find them | |
| 13:17:37 | mordred | so while there are some docs, they're clearly not working for people | |
| 13:17:39 | Shrews | (or remember them :) | |
| 13:17:44 | mordred | hehe. yeah :) | |
| 13:21:11 | Shrews | i'll comment on that review with that doc link | |
| 15:25:16 | openstackgerrit | Matt Riedemann proposed openstack/python-openstackclient master: Add server event command documentation for compute API 2.21 https://review.opendev.org/664957 | |
| 15:41:38 | openstackgerrit | Matt Riedemann proposed openstack/python-openstackclient master: Add server add/remove volume description for microversion 2.20 https://review.opendev.org/664960 | |
| 19:16:11 | openstackgerrit | Brian Haley proposed openstack/python-openstackclient master: port: drop host-id and device-id https://review.opendev.org/664421 | |
| #openstack-sdks - 2019-06-13 | |||
| 08:55:50 | openstackgerrit | Merged openstack/openstacksdk master: Support deleting all routes in update_router https://review.opendev.org/663369 | |
| 10:22:46 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Prepare Server to be used in cloud layer https://review.opendev.org/665105 | |