Earlier  
Posted Nick Remark
#openstack-nova - 2018-06-18
15:20:26 dansmith because if we weren't going to change anything (option 1) then it wouldn't matter
15:20:34 mriedem and sam was a proxy for all openstack operators worldwide
15:21:17 bauzas stephenfin: sorry can't help, was in another room AFAIR
15:21:53 mriedem so dhcp_domain takes precedence if set
15:22:06 mriedem as noted inline, some people set that to '' to skip all that logic and just use the server hostname provided by the user
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

Earlier   Later