Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-18
15:09:26 mriedem oh that's right
15:09:50 dansmith stephenfin: I thought the easy out is just not touching what we have and undeprecating it?
15:09:52 mriedem stephenfin: easy out?
15:10:09 mriedem stephenfin: there was an agreed-to plan to fix the issue, did you or did you not follow that plan?
15:10:15 dansmith because a new thing means everyone has to change config afaict
15:11:04 stephenfin mriedem: There were two option but no clear indication which one to go for https://etherpad.openstack.org/p/YVR18-novaneutron-ops-cross-project-session
15:11:35 mriedem option 2, L35
15:11:36 dansmith I thought the clear way was identified as just leaving what we had
15:11:52 mriedem "change the dhcp_domain default to None and check that in the code; if not set, default to 'novalocal' which is the previous default; then check if network.dns_domain is set and if so, you use it, else something something use dhcp_domain...."
15:12:26 cdent something I forgot to ask in scheduler meeting: should we seek spec freeze exception on https://review.openstack.org/#/c/552105/ ? melwitt, jaypipes ?
15:12:57 stephenfin mriedem: Right, option two of two. Option one is still valid, no?
15:13:40 mriedem stephenfin: no, we agreed on option 2 during the session
15:13:56 dansmith stephenfin: even still your patch isn't option 1 either is it?
15:14:01 mriedem it's not
15:14:05 dansmith that's what I'm trying to get at
15:14:40 stephenfin dansmith: It's a variant of 1. I figured we could take the option to clean this up while we were at it, as we've done extensively in the past. "dhcp_domain" makes no sense, right?
15:15:42 stephenfin mriedem: Your recollection of that differs from mine. I don't recall anyone stating a reason _to_ enable neutron integration
15:16:27 dansmith stephenfin: my recollection matches mriedem's as well
15:16:29 stephenfin while there were a few reasons not to (it's not always available, it'll break configurations, there are multiple ways this can be configured in neutron)
15:16:43 dansmith stephenfin: right so you give it priority if it's defined
15:16:51 dansmith if not, you fall back to the conf value
15:17:01 mriedem yeah that's what i remember, we have a priority order
15:17:01 dansmith and I don't think I heard anything in the room about changing the conf option,
15:17:11 mriedem one of which is allowing using the network.dns_domain from neutron
15:18:05 stephenfin Hmm, that takes us firmly into feature territory
15:18:32 stephenfin A feature that, again, I didn't hear anyone actually ask for
15:18:53 dansmith who else was in there, gibi ?
15:19:14 mriedem i know sorrison was in the room
15:19:21 stephenfin dansmith: gibi and melwitt, I think. Not sure about bauzas
15:19:29 dansmith melwitt is out this week
15:19:40 bauzas mmm ?
15:19:47 gibi I was there but honestly I don't remember :/ reading the etherpad now to get memories back
15:19:54 mriedem "smorrison says everyone will read the release notes."
15:20:16 dansmith mriedem: right, related to giving the neutron value precedence right?
15:20:17 mriedem we likely indicated this would be a behavior change, mentioned in release notes
15:20:19 mriedem yes
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 https://bugs.launchpad.net/nova/+bug/1698010 for
15:29:16 mriedem "- agreed on the direction to resolve bug
15:29:17 mriedem otherwise default to 'novalocal' as before"
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 the neutron network dns_domain attribute if set,
15:29:17 mriedem give priority to the option if set, otherwise use
15:29:17 mriedem the nova dhcp_domain option; we'll undeprecate it,
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

Earlier   Later