| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-06-12 | |||
| 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 | |
| 10:58:45 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Volume.Backup restore fixes https://review.opendev.org/665110 | |
| 10:59:58 | gtema | mordred, dtantsur: would you please go through refactoring changes. It becomes hard to keep track what is done, what not and to still keep it merge-able | |
| 11:01:28 | gtema | mordred: for the server I decided to split things up into first preparing server itself for additional stuff (https://review.opendev.org/#/c/665105/) and on top of that there would be it's integration into cloud | |
| 11:05:43 | dtantsur | will try | |
| 11:05:54 | gtema | thks | |
| 12:11:20 | dtantsur | mordred, gtema, it doesn't look like anything happened to https://github.com/ansible/ansible/pull/54463 after your comments :( | |
| 12:28:24 | gtema | dtantsur: if recheck will not help - we will need to leave shipits again. They seem to work only one week after latest test | |
| 12:28:37 | dtantsur | I see | |
| 12:38:39 | openstackgerrit | Merged openstack/openstacksdk master: Use Resource layer for network SecurityGroups https://review.opendev.org/662724 | |
| 14:20:16 | pgaxatte | hello | |
| 14:20:45 | pgaxatte | haa just found my answer in the channel banner :D | |
| 14:20:50 | pgaxatte | "Bug tracker for SDK and OSC is now at https://storyboard.openstack.org" | |
| 14:21:11 | pgaxatte | the contributing page of osc-lib is not up-to-date | |
| 14:21:13 | pgaxatte | https://docs.openstack.org/developer/osc-lib/contributor/index.html | |
| 14:23:06 | dtroyer | pgaxatte: thanks for the heads-up | |
| 14:23:09 | pgaxatte | to submit a bug related to the openstack cli, the openstack/openstacksdk in the storyboard is the right place? | |
| 14:23:20 | dtroyer | yes | |
| 14:25:38 | pgaxatte | alright thanks dtroyer ;) | |
| 15:01:59 | mordred | pgaxatte: wait - no - you want https://storyboard.openstack.org/#!/project/openstack/python-openstackclient for the CLI - openstack/openstacksdk is just for the sdk | |
| 15:09:40 | pgaxatte | mordred: alright thanks, doing that. | |
| 15:15:29 | efried | dtantsur: Thanks for starting to look at the ironicclient=>sdk in nova series | |
| 15:16:39 | dtantsur | sure thing | |
| 15:20:01 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Prepare Server to be used in cloud layer https://review.opendev.org/665105 | |
| 15:23:40 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Prepare Server to be used in cloud layer https://review.opendev.org/665105 | |
| 15:28:11 | gtema | mordred: can you please go through refactor changes, since it's hard to keep everything from merge conflicts | |
| 15:31:08 | mordred | gtema: yes - although we're packing moving over the next couple of days, so it might be a couple of days - but that stack will be the next thing I look at and I won't merge anything else before | |
| 15:31:34 | gtema | ah, ok. Thks for the headsup | |
| 15:31:58 | gtema | happy packing! | |
| 15:34:33 | pgaxatte | dtroyer, mordred: thanks for your help, the bug is here https://storyboard.openstack.org/#!/story/2005877 :) | |
| 15:57:54 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Prepare Server to be used in cloud layer https://review.opendev.org/665105 | |