| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-18 | |||
| 12:45:27 | gibi | sahid: +W | |
| 12:46:02 | sahid | gibi: thanks | |
| 12:46:10 | gibi | sahid: thank you for the cleanup | |
| 12:59:30 | efried | cdent: I'm sure the PowerVC guys have some idea about that. edmondsw? (The question was: "Have you explored theoretical upper limits on number of instances in/on a compute node? In vmware-land we've discovered there are some inefficiences in the way data is managed in the resource tracker that can present some problems.") | |
| 13:00:25 | cdent | the latest is that there are some deepcopy of self.stats happening which may not be required | |
| 13:02:49 | efried | cdent: You're talking about the n-cpu service choking at a certain number of VMs? | |
| 13:03:17 | cdent | efried: exhibiting less than ideal load at >N VMs | |
| 13:03:25 | cdent | sometimes choking | |
| 13:06:07 | edmondsw | efried cdent we support a max of 1000 VMs per compute node | |
| 13:06:09 | efried | cdent: Sounds like something you may want to ask CERN about. | |
| 13:06:20 | efried | edmondsw: Is that a Power limit or an OpenStack limit? | |
| 13:06:26 | edmondsw | that's a PowerVC statement | |
| 13:06:52 | edmondsw | I'm not sure all of what went into picking that number | |
| 13:07:01 | efried | okay, so really just "nothing has broken down at this point, and we don't want to commit to testing more than that, and what do you think you need more than that for anyway??" | |
| 13:07:43 | cdent | efried: what does cern have to do with this, don't they kvm? (where the hardware presents physical limits. The issue for vmware is that it is possible to have a lot of hardware in one vcenter (which is tied to one compute node) | |
| 13:07:55 | cdent | it's not the recommend form to have a lot of nodes in one vcenter, but people do | |
| 13:08:21 | cdent | problems seem to start showing up around 1500 instances (whatever the hardware) on one compute node | |
| 13:08:22 | edmondsw | cdent I was wondering how someone would ever get up to a high number of VMs in x86 land :) | |
| 13:08:22 | efried | cdent: ohh, I see. We don't have more than one hardware node per n-cpu. But our hardware nodes can be big and hold a lot of VMs. | |
| 13:09:56 | edmondsw | efried cdent maybe ask the Z guys? | |
| 13:09:57 | efried | cdent: In that sense, the only difference with kvm is that we're hosting the VMs on the hardware, not within the controller VM. | |
| 13:10:06 | efried | yeah, I was wondering about z. | |
| 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 | |