| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-04 | |||
| 11:55:17 | johnthetubaguy | so I really should get some food, my brain is failing me | |
| 11:58:07 | gmann | it mainly separate the current admin from project operation. i mean current project admin would not be able to perform new system level admin operation unless token is scoped with system. | |
| 11:58:31 | gmann | if deployment choose to enforce the scope_type | |
| 12:00:37 | gmann | i still feel reader ability makes these changes more useful otherwise operator can still add project member with system scope and lie to nova/oslo. | |
| 12:06:07 | johnthetubaguy | gmann: yeah, maybe we just do this in one shot... going to think on that over lunch | |
| 12:06:47 | johnthetubaguy | yaawang: thank you for explaining your use case, I think if we rename the image properties and flavor extra specs slightly, I am happy. | |
| 12:07:01 | johnthetubaguy | yaawang: I have added a suggestion on your spec | |
| 12:07:32 | gmann | johnthetubaguy: ok, will catch with you ( or on gerrit) tomorrow. thanks for review and detail discussion. | |
| 12:08:49 | yaawang | johnthetubaguy: Thanks, will look later... | |
| 12:48:16 | amyltsev | Hello, could someone advice, can I have name of volumes which were created during creation instances with volume creation, like the instance name? | |
| 12:59:55 | kashyap | sean-k-mooney: On 'virtio-blk' vs. 'virtio-scsi', I'd say you got it the other way round: 'virtio-scsi' was designed to address the limitations of 'virtio-blk' | |
| 13:01:16 | sean-k-mooney | kashyap: virtio-scsi is generally slower as it has to emulate a scsi contoller | |
| 13:01:55 | kashyap | sean-k-mooney: In _some_ workloads 'virtio-scsi' is slower, in others, it outperforms 'virtio-blk' | |
| 13:02:29 | yonglihe | sean-k-mooney: Hi | |
| 13:03:02 | sean-k-mooney | yonglihe: hi | |
| 13:03:25 | sean-k-mooney | kashyap: in anycase we are defaulting to sata so its not really that relevent | |
| 13:03:42 | yonglihe | I'm finding you that NUMA stuff api spec | |
| 13:03:44 | sean-k-mooney | kashyap: i normally only use virtio-scsi when im using ceph | |
| 13:03:59 | kashyap | sean-k-mooney: Sure, but I wanted to point out that correction | |
| 13:04:02 | kashyap | Yep, noted | |
| 13:04:23 | kashyap | sean-k-mooney: Also most new features are implemented on 'virtio-scsi'-only; due to the difficulty to extend 'virtio-blk' | |
| 13:05:18 | yonglihe | sean-k-mooney: Hope you have time ,thanks. https://review.opendev.org/#/c/658716/ spec "show-server-numa-topology" | |
| 13:05:52 | sean-k-mooney | kashyap: yes i know. i do follow the qemu/kvm development too not quite as closely as you but enought to know where to look this up when i need too | |
| 13:06:10 | kashyap | (Nod) | |
| 13:09:15 | sean-k-mooney | the storage subsystem in qemu/kvm is one i have looked into a few times but its also the first thing i swap out of memory :) | |
| 13:10:09 | kashyap | sean-k-mooney: Hehe, I spent far too much time following and playing with the Block Layer | |
| 13:10:18 | kashyap | And _still_ I swap out routinely | |
| 13:11:40 | yonglihe | Paste "clean up orphan instances" here, need review : https://review.opendev.org/#/c/627765/ | |
| 13:12:42 | sean-k-mooney | yonglihe: i just responded to your question on v2 and ill review v4 after i grab a cup of coffee. | |
| 13:13:04 | lyarwood | kashyap: https://github.com/openstack/nova/blob/2ea6e6f8db9fc6cecf389cacdd0d82d8226b99fb/nova/conf/libvirt.py#L714 - Any idea why we don't set defaults for hw_machine_type? | |
| 13:13:32 | kashyap | lyarwood: We set for AArch64 and s390x; but not for x86_64 | |
| 13:13:40 | sean-k-mooney | yonglihe: claning up instance not listed in the db can be dangous in some cases | |
| 13:14:04 | sean-k-mooney | ill try to review that also but how are you validiating that openstack created the instnce | |
| 13:14:19 | sean-k-mooney | are you checking for the metadata we add in the domian xml? | |
| 13:14:22 | yonglihe | I create a out of band vm | |
| 13:14:35 | kashyap | lyarwood: We don't set for x86_64, because we don't have enough information for that. | |
| 13:15:01 | kashyap | lyarwood: That's what this spec is supposed to handle: https://review.openstack.org/#/c/631154/ ("WIP: Gracefully handle QEMU machine types for guests") | |
| 13:15:03 | lyarwood | kashyap: I don't even see a default listed in that section | |
| 13:15:04 | sean-k-mooney | yonglihe: to be clear my concern is we allow people to run non openstack manged vms on openstack compute nodes. so your orpahn patch should not break that usecase | |
| 13:15:25 | lyarwood | kashyap: ah right | |
| 13:15:35 | kashyap | lyarwood: We choose the defaults for non-x86_64 in the method you just moved: get_machine_type() | |
| 13:15:47 | kashyap | I even added a NOTE there :-) | |
| 13:15:48 | kashyap | if caps.host.cpu.arch in (obj_fields.Architecture.ARMV7, | |
| 13:15:48 | kashyap | obj_fields.Architecture.AARCH64): | |
| 13:15:48 | kashyap | mach_type = "virt" | |
| 13:15:58 | kashyap | Likewise, for s390x | |
| 13:16:29 | yonglihe | sean-k-mooney: if it's dangers in any way, we should address that. for the none OS vms, some ones need this to clean up and some one does not. the default action now is noop. | |
| 13:17:24 | lyarwood | kashyap: right sorry I'm specifically talking about the hw_machine_type option itself | |
| 13:17:33 | lyarwood | kashyap: and the fact that option doesn't actually have a default | |
| 13:17:36 | sean-k-mooney | yonglihe: right but what im suggesting is we shoudl chacke the domain xml to confim if it contains the metadata we add with the instacne uuid/flavor/image and other info were we say this vm was created by nova | |
| 13:17:59 | lyarwood | kashyap: I assumed it did and that caused loads of tests to fail as the final lookup would use that config option and return None | |
| 13:18:01 | sean-k-mooney | yonglihe: if that info is not present then we should not reap the vm as it was not create by nova | |
| 13:18:32 | kashyap | lyarwood: Even for the config option *itself*, we don't set default as we don't have enough information about the guest OS | |
| 13:18:35 | yonglihe | sean-k-mooney: seems like a good point and we need that. | |
| 13:19:04 | lyarwood | kashyap: ack understood | |
| 13:19:05 | kashyap | lyarwood: That's why we delegate setting default machine type to orchestrators. | |
| 13:19:41 | yonglihe | sean-k-mooney: you may want to comment this to the patch and i gonna address that. -:) | |
| 13:20:06 | sean-k-mooney | yonglihe: that will driver dependent but i think it makes sense to have a call to the driver to retrun the set of possible ophean instances and then for the compute manager to ask the driver to reap them. | |
| 13:20:12 | sean-k-mooney | sure ill add it to the review | |
| 13:22:45 | mriedem | lyarwood: bauzas: dansmith: can we get these stein backports in so i can do a release? https://review.opendev.org/#/q/topic:bug/1830747+status:open+branch:stable/stein | |
| 13:23:10 | bauzas | mriedem: ack I can take a look | |
| 13:23:18 | yonglihe | sean-k-mooney: driver specific is spitted out, there is 2 patches on set. find the orphan seems like logic belong to compute but checking the metadata is definitely driver's scope. | |
| 13:25:50 | sean-k-mooney | yonglihe: well i woudl expect the driver to be the thing that check what intances are running on the host and provide a kwarg to allow filtering to just vms it created. | |
| 13:26:29 | sean-k-mooney | but i wouuld expect the compute manager to be the thinkg that calls that and descided if it should reap or not based on the policy set in the config | |
| 13:27:04 | sean-k-mooney | well i guess its a periodic task but the point is i would expect the fucntion exectued by the periodic task to be driver independent | |
| 13:27:24 | dansmith | mriedem: yes | |
| 13:29:28 | lyarwood | thanks dansmith | |
| 13:32:53 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Noop CantStartEngineError in targets_cell if API DB not configured https://review.opendev.org/663030 | |
| 13:34:45 | yonglihe | sean-k-mooney: anyway there is a new API need added to driver layer. and i agree it should decouple with driver in some way. now it's not the way you prefer. but it's driver's choice to implement or not. | |
| 13:41:29 | yaawang | johnthetubaguy: Hi, I've replied your suggestion, is it correct? https://review.opendev.org/#/c/651681 | |
| 13:45:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Make nova-next archive using --before https://review.opendev.org/661002 | |
| 13:47:16 | openstackgerrit | Merged openstack/nova-specs master: Amend count-quota-usage-from-placement to reflect implementation https://review.opendev.org/662130 | |
| 13:47:22 | johnthetubaguy | yaawang: opps, your question points out I explained my idea badly, I will reply in the review soon | |
| 14:03:46 | yaawang | johnthetubaguy: Thanks, I'll look it tomorrow because my timezone is UCT+8 :) | |
| 14:04:12 | johnthetubaguy | yaawang: no problem, have a good evening/night! | |
| 14:07:00 | sean-k-mooney | gibi: mriedem forgot to push my comments but the reason the vgpu spec only provides soft affitnity curenly is that dansmith ask to reduce the scope to that case so yes part of it need to be updated but in v1 and v2 it proposed multiple affintiy polices | |
| 14:07:30 | sean-k-mooney | gibi: mriedem which is why the oringal use case refer to enforcing numa affinity | |
| 14:12:08 | mriedem | sean-k-mooney: ok -1 to clean that up then to avoid confusion | |
| 14:47:22 | openstackgerrit | Merged openstack/nova stable/stein: Add regression recreate test for bug 1830747 https://review.opendev.org/662574 | |
| 14:47:27 | openstack | bug 1830747 in OpenStack Compute (nova) stein "Error 500 trying to migrate an instance after wrong request_spec" [High,In progress] https://launchpad.net/bugs/1830747 - Assigned to Matt Riedemann (mriedem) | |
| 14:52:49 | openstackgerrit | Merged openstack/python-novaclient master: Bump openstackdocstheme to 1.30.0 https://review.opendev.org/662905 | |
| 16:09:30 | yaawang | johnthetubaguy: Thanks for your commet. | |
| 16:10:15 | efried | kashyap: you and yaawang have been talking about cpu model list. Would you be okay if we restored the spec and let yaawang take over convincing the world it has legs? | |
| 16:10:22 | yaawang | mriedem_away: Could you take a look at this spec, please. https://review.opendev.org/#/c/651681 | |
| 16:10:24 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Use SATA bus for cdrom devices when using q35 machine type https://review.opendev.org/663011 | |
| 16:10:24 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type https://review.opendev.org/662887 | |
| 16:10:27 | lyarwood | mdbooth / kashyap / artom ; ^ finally got through all of the tests, it's pretty horrific so if someone has a better way I'm all ears :) | |
| 16:11:48 | mdbooth | lyarwood: Looking now. | |
| 16:12:05 | mdbooth | Ouch, test_driver.py! | |
| 16:13:38 | artom | lyarwood, we'd want to backport this, right? | |
| 16:13:58 | lyarwood | yup | |
| 16:14:00 | artom | The thing is, it's hard to know if another approach would have less collateral damage without actually trying it | |
| 16:14:22 | artom | Because backporting this in its current form will be a pain, I suspect | |
| 16:14:35 | mdbooth | artom: I don't think we need to backport further than Stein though, right? | |
| 16:14:51 | artom | mdbooth, true | |
| 16:14:52 | lyarwood | it's actually clean at the moment | |
| 16:14:56 | lyarwood | to stable/stein | |
| 16:14:58 | artom | Whoa... | |
| 16:15:03 | lyarwood | somehow | |
| 16:15:11 | mdbooth | Quick, land it! | |