| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-18 | |||
| 15:22:32 | mriedem | if dhcp_domain is None, then we use the network.dns_domain (if set), else default to 'novalocal' which is the default today | |
| 15:23:07 | mriedem | so if, as an operator, i want the user-supplied name to be the hostname, i set dhcp_domain='' | |
| 15:23:18 | mriedem | if i want novalocal, i set dhcp_domain=novalocal explicitly | |
| 15:23:26 | mriedem | else i let it come from the network (if set) | |
| 15:24:08 | stephenfin | mriedem: I get that. I'm asking what the rationale for pulling it from neutron in the first place is. I haven't seen an RFE/bug open for this in the past so is it an issue? | |
| 15:24:50 | stephenfin | As opposed to just undeprecating the existing option | |
| 15:25:13 | dansmith | pulling it from neutron would be pulling it from the source of network truth | |
| 15:25:25 | dansmith | which, AFAIK, was the plan we never implemented | |
| 15:25:26 | dansmith | even still, | |
| 15:26:13 | dansmith | just undeprecating what we have could be step 1 if you just don't want to do the step 2 of honoring the neutron thing | |
| 15:27:18 | gibi | I've read the etherpad but no memories came back from this part of the session. sorry. But ^^ seems reasonable to me | |
| 15:27:53 | dansmith | doesn't L42 say "Agree: option 2" ?\ | |
| 15:28:16 | dansmith | oh, heh | |
| 15:28:18 | dansmith | cheater | |
| 15:28:26 | mriedem | heh yeah | |
| 15:28:28 | dansmith | haha | |
| 15:28:36 | mriedem | however, | |
| 15:28:53 | mriedem | i also wrote up daily session reports internally and that's the option i said we were going with | |
| 15:29:16 | mriedem | "- agreed on the direction to resolve bug | |
| 15:29:16 | mriedem | https://bugs.launchpad.net/nova/+bug/1698010 for | |
| 15:29:17 | mriedem | the nova dhcp_domain option; we'll undeprecate it, | |
| 15:29:17 | mriedem | give priority to the option if set, otherwise use | |
| 15:29:17 | mriedem | the neutron network dns_domain attribute if set, | |
| 15:29:17 | openstack | Launchpad bug 1698010 in OpenStack Compute (nova) "neutron-based instances should not use the nova-network 'dhcp_domain' option" [High,In progress] - Assigned to Stephen Finucane (stephenfinucane) | |
| 15:29:17 | mriedem | otherwise default to 'novalocal' as before" | |
| 15:29:20 | mriedem | from my trip report ^ | |
| 15:29:51 | mriedem | so i failed to make it super clear in the etherpad, i'm sorry | |
| 15:46:41 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Undeprecate the 'dhcp_domain' option https://review.openstack.org/480616 | |
| 15:52:42 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: ironic: Report resources as reserved when needed https://review.openstack.org/517921 | |
| 15:57:48 | mriedem | and we have a new rebuild test in tempest which means new cells v1 random rebuild failures | |
| 16:01:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Skip ServerShowV263Test.test_show_update_rebuild_list_server for cellsv1 https://review.openstack.org/576194 | |
| 16:01:15 | mriedem | dansmith: want to just fast approve this? ^ i've seen 2 failures from that today | |
| 16:01:40 | dansmith | k | |
| 16:02:19 | mriedem | i've also got a revert here for a change that breaks lvm in the libvirt driver https://review.openstack.org/#/c/576136/ | |
| 16:03:07 | mriedem | clearly never tested properly in the original change | |
| 16:05:20 | dansmith | +2, gibi efried stephenfin ^ | |
| 16:05:27 | dansmith | bauzas: ^ | |
| 16:05:34 | dansmith | that's a pretty bad one | |
| 16:05:49 | dansmith | mriedem: was that just failing some lvm job that doesn't vote? | |
| 16:06:05 | bauzas | dansmith: I thought reverts were fast-approved ? | |
| 16:06:16 | mriedem | dansmith: our nova-lvm job runs in the experimental queue but i don't see that was actually run on the original change, but it wouldn't be voting if it iwas, | |
| 16:06:19 | bauzas | anyway, +Wd | |
| 16:06:23 | mriedem | but that's not how i found the failure | |
| 16:06:25 | dansmith | bauzas: sure, but there are people around, so meh | |
| 16:06:52 | mriedem | i found it because the trusted certs barbican patch was failing b/c it uses lvm apparently https://review.openstack.org/#/c/515210/ | |
| 16:07:06 | mriedem | with the depends-on the revert it passes again | |
| 16:12:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Skip ServerShowV263Test.test_show_update_rebuild_list_server for cellsv1 https://review.openstack.org/576194 | |
| 16:31:23 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: ironic: Report resources as reserved when needed https://review.openstack.org/517921 | |
| 16:33:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix regression when listing build_requests with marker and ip filter https://review.openstack.org/576161 | |
| 16:33:27 | openstackgerrit | Elod Illes proposed openstack/nova master: Reject interface attach with QoS aware port https://review.openstack.org/570078 | |
| 16:35:29 | stephenfin | mriedem: What did you mean here? https://review.openstack.org/#/c/567876/ (second last comment) | |
| 16:35:55 | mriedem | ? | |
| 16:36:03 | mriedem | http://logs.openstack.org/66/575766/1/check/legacy-grenade-dsvm-neutron-multinode-live-migration/2bd7d1f/logs/screen-n-cpu.txt.gz#_Jun_15_17_06_09_888053 | |
| 16:36:04 | mriedem | ? | |
| 16:36:23 | stephenfin | mriedem: Do you mean it's working and you're happy or that it shouldn't be working because the older compute node should be rejected? | |
| 16:36:30 | mriedem | just shows that when we're doing a live migration over n-1 and n level computes, if one is file-backed memory and the other isn't, we fail as the code is doing | |
| 16:36:35 | mriedem | i'm happy | |
| 16:36:58 | stephenfin | OK, that link was what I need. I'll re-review that in the morning so | |
| 16:37:03 | stephenfin | *needed | |
| 16:38:14 | mriedem | gibi: stephenfin: thanks for hitting https://review.openstack.org/#/c/561284/ | |
| 17:03:41 | openstackgerrit | Eric Fried proposed openstack/nova master: Handle agg generation conflict in report client https://review.openstack.org/556669 | |
| 17:07:37 | openstackgerrit | Eric Fried proposed openstack/nova master: Nix unused raise_if_custom_resource_class_pre_v1_1 https://review.openstack.org/575847 | |
| 17:33:40 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Spec: Handling Reshaped Provider Trees https://review.openstack.org/572583 | |
| 17:43:13 | zcorneli | dansmith, mriedem: For the file backed memory work, when going to implement the discard option (libvirt 4.4.0+), for migration XML generation we need to pass a second value back to the source from the destination. Is there a preference toward making the existing field into an Enum (or similar) vs creating a new field for discard? | |
| 17:45:57 | mriedem | the dst_wants_file_backed_memory field? | |
| 17:46:08 | zcorneli | yes | |
| 17:46:19 | mriedem | discard is a different thing and would be a different version of the migrate data object | |
| 17:46:32 | mriedem | so probably easiest to model that as a different field | |
| 17:47:54 | zcorneli | The only reason I would have against that would be that dst_wants_file_backed_memory=False + discard=True doesn't make sense. | |
| 17:48:11 | zcorneli | And I'm not sure if there's a way (or even really a will) to validate that in the object. | |
| 17:48:28 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: DNM: Use claim context during live migration https://review.openstack.org/576222 | |
| 17:49:23 | mriedem | would either of the is_shared_* fields make sense with dst_wants_file_backed_memory? | |
| 17:49:29 | mriedem | nvm, wrong type of thing | |
| 17:49:58 | mriedem | anyway, i don't think it's that big a deal, you'd just have a comment by the discard field saying it only makes sense when dst_wants_file_backed_memory=True | |
| 17:50:12 | zcorneli | Yep, works for me. Thanks for the input | |
| 17:52:36 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Add policy rule to block image-backed servers with 0 root disk flavor https://review.openstack.org/563692 | |
| 18:01:53 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Add policy rule to block image-backed servers with 0 root disk flavor https://review.openstack.org/563700 | |
| 18:16:13 | crazik | huh, finally. all services in pike. | |
| 18:16:25 | crazik | i was a looong and hard journey | |
| 18:16:27 | dansmith | mriedem: hmm, did you know a migration record can go into "pre-migrating" state because of the resource tracker? | |
| 18:17:05 | crazik | dansmith: or other issue | |
| 18:17:11 | crazik | like DB schema mismatch | |
| 18:17:17 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Add policy rule to block image-backed servers with 0 root disk flavor https://review.openstack.org/563719 | |
| 18:17:18 | dansmith | huh? | |
| 18:17:48 | dansmith | mriedem: I mean "will go" by the way | |
| 18:17:54 | mriedem | dansmith: i'm fairly sure that's on page 374 of the nova core handbook | |
| 18:18:34 | mriedem | why, what is it breaking? | |
| 18:18:49 | dansmith | mriedem: since you updated the comment above the list of filters, I challenge the fact that you knew that :P | |
| 18:19:11 | dansmith | mriedem: well, a migration can be in pre-migrating state, and thus neither of accepted or done, | |
| 18:19:18 | mriedem | what filters? | |
| 18:19:21 | dansmith | so the source compute may not find it if it comes up at the exact time | |
| 18:19:39 | dansmith | mriedem: https://review.openstack.org/#/c/500144/ | |
| 18:19:41 | mriedem | i assume you're referring to something else, like evac on startpu | |
| 18:20:03 | dansmith | yes, that's what I'm talking about | |
| 18:21:16 | mriedem | ok yeah i guess rebuild_claim will put the migration into pre-migrating status for evac | |
| 18:21:18 | dansmith | so it will go accepted->pre-migrating -> done -> completed | |
| 18:21:20 | dansmith | yeah | |
| 18:21:34 | mriedem | sorry i didn't have the full evac migration task state in my head when writing that comment... | |
| 18:21:45 | dansmith | well, I never knew it would do that | |
| 18:21:55 | dansmith | although I wonder if it would when I wrote that, because we did rebuild_claim recently, IIRC | |