| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-18 | |||
| 08:41:03 | openstackgerrit | karim proposed openstack/nova master: Update scheduler to use image-traits https://review.openstack.org/576054 | |
| 08:47:12 | openstackgerrit | Merged openstack/nova stable/queens: Fix the file name of development-environment.rst https://review.openstack.org/574175 | |
| 09:02:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: placement: Make API history doc more consistent https://review.openstack.org/477478 | |
| 10:40:01 | openstackgerrit | Andrey Volkov proposed openstack/nova master: Update nova network info when doing rebuild for evacuate operation https://review.openstack.org/382853 | |
| 10:50:30 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: Initial change set of z/VM driver https://review.openstack.org/523387 | |
| 10:50:57 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver https://review.openstack.org/527658 | |
| 10:51:16 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240 | |
| 10:51:39 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340 | |
| 10:51:51 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344 | |
| 10:52:27 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: ironic: Report resources as reserved when needed https://review.openstack.org/517921 | |
| 10:55:29 | gibi | easy doc update needs a second +2 https://review.openstack.org/#/c/574890/ | |
| 10:56:06 | gibi | btw I think that is the last piece of the nova-validate-certificates bp | |
| 11:00:21 | openstackgerrit | garyk proposed openstack/nova master: Resource tracker: remove costly copy https://review.openstack.org/576099 | |
| 11:17:16 | cdent | efried: I have a question for you about powervm plans. 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. | |
| 11:29:01 | stephenfin | gibi: Done and done | |
| 11:29:09 | gibi | stephenfin: thanks and thanks :) | |
| 12:14:20 | openstackgerrit | Rajesh Tailor proposed openstack/nova master: Fix case-sensitivity for metadata keys https://review.openstack.org/504885 | |
| 12:43:17 | sahid | gibi: if you have a moment to ACK that one https://review.openstack.org/#/c/572699/ | |
| 12:43:44 | gibi | sahid: looking | |
| 12:44:41 | openstackgerrit | Merged openstack/nova master: Add trusted certs to feature support matrix docs https://review.openstack.org/574890 | |
| 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 | 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:08:22 | edmondsw | cdent I was wondering how someone would ever get up to a high number of VMs in x86 land :) | |
| 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? | |