| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-18 | |||
| 13:10:21 | efried | Pretty sure they also only use one hardware node, but not sure how many VMs they can handle. | |
| 13:10:28 | edmondsw | a lot | |
| 13:10:29 | cdent | the limits show up when the count of instances goes high, so it sounds like it would impact you guys too | |
| 13:10:34 | efried | I was kinda thinking they would typically have biggish VMs, but no reason to think that. | |
| 13:10:56 | cdent | things like syncing power state info | |
| 13:11:00 | efried | cdent: Well, it sounds like we cut you off at 1000 from a support statement standpoint, so... | |
| 13:11:22 | efried | I guess as soon as someone demands more, we'll see. | |
| 13:11:30 | cdent | are you interested in/excited by/disturbed by making that limit higher? | |
| 13:11:35 | cdent | jinxish | |
| 13:11:58 | cdent | it appears that going higher is relatively straightfoward. the limits are basically of the "oh we didn't think of that" variety | |
| 13:15:21 | efried | cdent: Oh, is there some hardcoded limit somewhere? I was getting the impression it was more of an overload. | |
| 13:19:53 | edmondsw | efried cdent I am told that PowerVC chose 1000 because PowerVM itself only supports 1000 per node | |
| 13:20:11 | efried | okay, fair enough. | |
| 13:23:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Revert "Re-using the code of os brick cinder" https://review.openstack.org/576136 | |
| 13:33:01 | openstackgerrit | Julia Kreger proposed openstack/nova master: ironic: bugfix: ensure a host is set for volume connectors https://review.openstack.org/571982 | |
| 13:33:07 | mriedem | i've moved certs validation out of the runway, it's complete | |
| 13:33:33 | mriedem | alex_xu: is https://review.openstack.org/#/c/560317/ ready for a runway slot? | |
| 13:35:46 | cdent | efried: no, no hardcoded limit (that I'm aware of). | |
| 13:35:48 | mriedem | it looks like it probably is... | |
| 13:40:41 | mriedem | bauzas: consecutive build failure weigher backport to pike is ready to go https://review.openstack.org/#/c/573248/ | |
| 13:40:43 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Deprecate 'network_manager' https://review.openstack.org/530923 | |
| 13:41:04 | bauzas | mriedem: roger. | |
| 13:41:58 | stephenfin | mdbooth, mriedem: There was a follow-up fix required for this, right? Do you recall what it was? https://review.openstack.org/#/c/524681/ | |
| 13:42:14 | stephenfin | Trying to decide whether to fix or abandon the backports I have proposed | |
| 13:42:53 | mriedem | i don't remember off the top of my head | |
| 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? | |