| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-25 | |||
| 19:01:20 | dansmith | I was reading it wrong, it mocks the thing you said and calls hydrate from the lambda | |
| 19:01:23 | dansmith | sorry | |
| 19:03:38 | dansmith | well, in that case, like I said, I'm not sure how we'll ever get those new things into the network model if we're not running the neutronv2/api code | |
| 19:06:58 | mriedem | i think we are but with the stubbed list_ports, list_networks, show_network stuff | |
| 19:07:15 | sean-k-mooney | dansmith: this is whats in instance.info_cache.network_info if it helps http://paste.openstack.org/show/726641/ | |
| 19:08:02 | mriedem | so that does have the physical_network and tunneled network meta | |
| 19:08:40 | mriedem | melwitt: https://review.openstack.org/#/c/517921/ and below need a final +@ | |
| 19:08:41 | mriedem | +2 | |
| 19:08:48 | dansmith | mriedem: we're not running the _nw_info_build_network code | |
| 19:09:08 | melwitt | mriedem: thanks, will look | |
| 19:09:17 | mriedem | dansmith: hmm | |
| 19:09:23 | mriedem | i'm not sure why we wouldn't, i don't see anything stubbing that out | |
| 19:09:27 | dansmith | mriedem: that was my point above | |
| 19:09:30 | dansmith | and you shat upon it | |
| 19:09:31 | mriedem | oh wait, | |
| 19:09:42 | mriedem | we do have other things that stub some shit out in the nw api | |
| 19:09:51 | mriedem | and i bet that is getting stubbed in the parent test base class | |
| 19:10:23 | mriedem | in the air like you just don't care!? | |
| 19:10:52 | dansmith | like jan brady when marcia suggests the same thing she just did and now everyone thinks it's cool | |
| 19:11:58 | mriedem | ServersTestBase | |
| 19:12:03 | mriedem | fake_network.set_stub_network_methods(self) | |
| 19:12:17 | mriedem | thar she blar | |
| 19:13:13 | mriedem | so if stephenfin's test calls unset_stub_network_methods we should hit the cache rebuilder | |
| 19:14:00 | sean-k-mooney | so _nw_info_build_network is being called when weer are booting | |
| 19:14:00 | mriedem | i'm not sure why someone didn't figure this all out hours ago :P | |
| 19:14:19 | mriedem | sean-k-mooney: yes, at the end of allocate_for_instance, | |
| 19:14:26 | mriedem | but we don't get that far b/c of set_stub_network_methods | |
| 19:14:27 | sean-k-mooney | yes | |
| 19:14:37 | sean-k-mooney | its not called in the rebuild | |
| 19:15:01 | mriedem | it doesn't need to be, | |
| 19:15:14 | mriedem | b/c after the server is created, the nw info cache is persisted in the db with the instance | |
| 19:15:21 | mriedem | assuming we had something in the db, but we don't b/c of set_stub_network_methods | |
| 19:15:22 | dansmith | yep, that fixes it, I'll push this up | |
| 19:15:26 | mriedem | WOOT | |
| 19:15:49 | sean-k-mooney | dansmith: awsome :) | |
| 19:16:22 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Add additional functional tests for NUMA networks https://review.openstack.org/585385 | |
| 19:23:10 | dansmith | melwitt: mriedem: I'm assuming no cells meeting with the crunch and all | |
| 19:23:20 | melwitt | +1 | |
| 19:23:35 | mriedem | agree | |
| 19:31:49 | mriedem | oh sweet irony as soon as we approve artom's test_tagged_attachment debug patch, it fails on that test | |
| 19:31:53 | mriedem | http://logs.openstack.org/32/584032/5/check/nova-next/caee4e1/logs/testr_results.html.gz | |
| 19:39:06 | mriedem | doesn't show any of artom's new debug messages for the instance or volume | |
| 19:41:47 | sean-k-mooney | ok my server says i loged into it 12 hour and 21 minutes ago. my brain is fried so im going to call it a day. i have the functional test for dansmith updated version running local. if test_rebuild_server_network_changes still fails perhaps we should remove it given cold migrate and test_rebuild_server_no_network_changes pass | |
| 19:42:31 | dansmith | yeah the rebuild tests don't work, | |
| 19:42:35 | mriedem | dansmith: what do you want me to do re ^? otherwise i'm just watching zuul and need to book a flight to china. do we have more tests that need to be written and/or cleaned up in the patch? | |
| 19:43:15 | dansmith | I think we need the negative test | |
| 19:43:41 | mriedem | i'm not sure i know how to do that | |
| 19:43:50 | mriedem | that's where the nodes on the host are all claimed? | |
| 19:44:01 | dansmith | no, there's an easier way | |
| 19:44:12 | dansmith | jan will take a crack at it while marcia brushes her hair | |
| 19:44:33 | mriedem | alright, wfm | |
| 19:44:39 | mriedem | works. for. marcia. | |
| 19:44:58 | mriedem | oh btw i'm in full summer feather hair mode atm | |
| 19:45:09 | mriedem | but it will be shorn before denver | |
| 19:49:07 | sean-k-mooney | so ya that just finished running all the nova fuctional tests. nova.tests.functional.libvirt.test_numa_servers.NUMAServersWithNetworksTest.test_rebuild_server_network_changes is the only one that failed in dans version so its just the attch suff thats failing. | |
| 20:03:17 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Add additional functional tests for NUMA networks https://review.openstack.org/585385 | |
| 20:16:58 | artom | mriedem, wait, it failed and logged nothing at all o_O | |
| 20:19:49 | dansmith | mriedem: so you'll convert your +1 to +2 on the functional move patch? | |
| 20:21:50 | efried | Does he have to deny you three times, or something? | |
| 20:22:07 | efried | not that kind of conversion, maybe. | |
| 20:58:39 | openstackgerrit | Mathieu Gagné proposed openstack/nova master: Add support for multiple fixed-ips in metadata https://review.openstack.org/580742 | |
| 21:00:12 | mriedem | dansmith: yeah | |
| 21:00:27 | mriedem | artom: right | |
| 21:02:09 | melwitt | does anyone know anything about metadata API versions and what's valid? for the addition of 'ip_addresses' to network_data.json, it means we have a second version update this cycle and we apparently already used a date in the future 2018-08-27 https://review.openstack.org/#/c/580742/2/nova/api/metadata/base.py@77 | |
| 21:03:32 | mriedem | apparently we already did that once with NEWTON_TWO even though NEWTON_ONE was using the wrong date | |
| 21:03:44 | melwitt | what's proposed is 2018-08-27-2 which is a format we haven't done before | |
| 21:03:52 | mriedem | # correlate with OpenStack release dates, with all the changes for a given | |
| 21:03:52 | mriedem | # NOTE(mikal): think of these strings as version numbers. They traditionally | |
| 21:03:53 | mriedem | # from EC2, which this needs to be compatible with. | |
| 21:03:53 | mriedem | # required for testing purposes. We know this isn't great, but its inherited | |
| 21:03:53 | mriedem | # hidden from the listing, but can still be requested explicitly, which is | |
| 21:03:53 | mriedem | # release bundled into a single version. Note that versions in the future are | |
| 21:04:03 | mriedem | i would -1 on the fomrat | |
| 21:04:04 | mriedem | *format | |
| 21:04:24 | mriedem | # release bundled into a single version." we could lump the changes into the existing ROCKY version | |
| 21:04:24 | mriedem | # correlate with OpenStack release dates, with all the changes for a given | |
| 21:04:24 | mriedem | based on "They traditionally | |
| 21:04:42 | mriedem | which isn't CI/CD friendly, so if we cared, i'd just make the ROCKY_TWO a day later than ROCKY_ONE | |
| 21:04:48 | mriedem | i'm a big meh on either approach | |
| 21:05:10 | melwitt | okay, I was wondering about that. else we could use 2018-08-30 the actual rocky release date? I haven't been able to find examples of consumers using version strings to request versions | |
| 21:05:30 | mriedem | it says versions in the future are hidden from the listing, | |
| 21:05:38 | mriedem | so if that's true, rocky doesn't even show up today, | |
| 21:05:40 | mriedem | but would need to confirm | |
| 21:06:11 | melwitt | and it looks like this new version won't break anyone because it adds a field, doesn't change any fields. so cloud-init defaulting to latest (I think it does, based on the code) will still work with the new version with 'ip_addresses' in it | |
| 21:06:19 | melwitt | ohh, I see | |
| 21:06:34 | mriedem | i have a hell of a time ever knowing where the route code in this thing works | |
| 21:06:44 | melwitt | so rolling together should work on that basis. I didn't understand what "hidden" meant until you said that | |
| 21:07:00 | mriedem | well, i'd want to know where that hiding happens | |
| 21:07:04 | mriedem | i don't have a devstack handy to test this | |
| 21:07:09 | dansmith | right, should be rocky release date, and we shouldn't have multiple versions for rocky | |
| 21:07:26 | dansmith | I think that the date-based one is hidden, | |
| 21:07:32 | dansmith | but current takes you to it, | |
| 21:07:41 | mriedem | https://review.openstack.org/#/c/580742/2/nova/api/metadata/base.py@597 | |
| 21:07:49 | dansmith | and the idea is that until the release happens, it's not really codified as the date-based version, | |
| 21:07:51 | dansmith | so we can add stuff to it | |
| 21:07:56 | mriedem | yup, | |
| 21:07:58 | mriedem | found that code | |
| 21:10:17 | melwitt | a-ha, cool. thanks for all that info | |
| 21:12:49 | melwitt | fyi mgagne ^ (backscroll for more context on the latest review comment) | |
| 21:13:46 | mgagne | melwitt: so no new metadata api version and call it a day? | |