| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-18 | |||
| 13:46:46 | bauzas | mriedem: +W'aboom | |
| 13:47:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Simplify instance name generation https://review.openstack.org/516573 | |
| 13:47:17 | mriedem | bauzas: thanks | |
| 13:50:32 | alex_xu | mriedem: let me do a review on it first | |
| 14:08:38 | mriedem | tssurya: i put something together this morning https://bugs.launchpad.net/nova/+bug/1777458 | |
| 14:08:39 | openstack | Launchpad bug 1777458 in OpenStack Compute (nova) "Listing instances with a marker that is in the build_requests table and the ip/ip6 filters results in an error" [High,Triaged] - Assigned to Matt Riedemann (mriedem) | |
| 14:08:44 | mriedem | working a fix now, but have a functional test recreate | |
| 14:08:54 | tssurya | I saw it just now | |
| 14:11:09 | tssurya | oh new bug! I was checking the update here: https://review.openstack.org/#/c/575556/ | |
| 14:13:52 | tssurya | mriedem: I also have something which is a very dirty POC (without version bumps yet, see comment) : https://review.openstack.org/#/c/575996/ for the spec, however I just wanted to know if you and gibi were thinking something similar for linking the "is this cell down" to adding the uuids to the new top key. Please have a look whenever you have the time | |
| 14:14:14 | gibi | tssurya: ack | |
| 14:14:21 | tssurya | gibi: thanks | |
| 14:38:17 | vpc | can i use pxe_ssh as a driver for my ironic since my hardware is dont have ipmi | |
| 14:39:30 | artom | If it's real hardware I'm pretty you need ipmi... | |
| 14:45:46 | gibi | tssurya: I left some idea inline https://review.openstack.org/#/c/575996/ | |
| 14:45:58 | tssurya | gibi: yep, checking thanks a lot | |
| 14:47:00 | vpc | artom yes it is real hardware | |
| 14:47:26 | ZZellefr | garyk: Hi | |
| 14:47:42 | artom | vpc, so I'm no Ironic expert, but thinking about it logically, you need ipmi | |
| 14:47:55 | vpc | i have this 2 module | |
| 14:47:57 | artom | Otherwise how are you going to get an OS to run on the machine? | |
| 14:48:02 | vpc | ipmi_msghandler | |
| 14:48:08 | vpc | and ipmi_devintf | |
| 15:00:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix regression when listing build_requests with marker and ip filter https://review.openstack.org/576161 | |
| 15:00:40 | mriedem | tssurya: dansmith: melwitt: ^ | |
| 15:00:53 | mriedem | that's also regressed in queens | |
| 15:07:57 | openstackgerrit | Stephen Finucane proposed openstack/nova master: metadata: Add '[metadata] domain_name' option https://review.openstack.org/480616 | |
| 15:08:19 | stephenfin | mriedem, dansmith, <anyone else who was in the nova-neutron cross-project talk>: I took the easy out with that dhcp_domain name deprecation thing. Context in the commit message. Lemme know if you (dis)agree, please :) | |
| 15:08:59 | dansmith | mriedem: melwitt is out this week | |
| 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 | dansmith | and I don't think I heard anything in the room about changing the conf option, | |
| 15:17:01 | mriedem | yeah that's what i remember, we have a priority order | |
| 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 | "- 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 | |