Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-04
10:47:56 openstackgerrit Merged openstack/os-traits master: Create trait for NUMA subtree affinity https://review.opendev.org/657898
10:49:52 gmann johnthetubaguy: if deployment say scope enforcement and token is not scoped to system then yes role:admin will not be able to list all project's servers
10:50:44 johnthetubaguy yaawang: makes sense to me, but why do you want to use auto-converge for the other workloads? Maybe you just want to disable auto-converge in your cloud?
10:51:14 johnthetubaguy yaawang: also, have you seen this interesting look at live-migration, I am curious if you see the same things: https://www.berrange.com/posts/2016/05/12/analysis-of-techniques-for-ensuring-migration-completion-with-kvm/
10:51:28 gmann with system reader (because of system_scope:all in check_str) it will keep checking the system scope even enforce_scope if false. so we would not break project_id protection there
10:54:47 johnthetubaguy gmann: true, I might be worrying too much, anyways the role:admin check will break System Reader
10:58:30 yaawang johnthetubaguy: Some vms do not want to use auto-converge/post-copy, but the other can use these feature. Auto-converge/post-copy can help vm live-migrate more faster, it's good to vm which can accept the performance reduce. Disable auto-converge/post-copy means all vms can't use them, it's not a good idea to users.
11:05:38 johnthetubaguy yaawang: for the VMs that don't want post copy or auto-converge, what do they want instead? are they OK being paused for longer, so the performance is more predicable during the live-migration?
11:19:43 yaawang johnthetubaguy: Just normal live-migration without any addition option, the main point is decrease the effort of source vm's performance. If the user call force-complete API, nova will pause the vm, it may not a good idea for now :(. But there are no more good idea.
11:27:50 openstackgerrit Lee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type https://review.opendev.org/662887
11:27:51 openstackgerrit Lee Yarwood proposed openstack/nova master: DNM/WIP blockinfo: Use SATA bus for cdrom devices when using q35 https://review.opendev.org/663011
11:28:01 lyarwood mdbooth / kashyap ^ q35 hackaround as discussed, tempest is passing locally using q35 again, I'll sort the unit tests out now.
11:28:15 sean-k-mooney lyarwood: isnt that in a docs comment somewhere
11:28:21 sean-k-mooney lyarwood: e.g. you have to use sata
11:28:27 sean-k-mooney because ide is not supported
11:28:40 sean-k-mooney im pretty sure we discussed needing to do that months ago
11:28:51 sean-k-mooney im guessing your just adding it now :)
11:28:54 lyarwood not that I can see
11:29:08 lyarwood it likely came up
11:29:27 sean-k-mooney i remember talking to kasabp about it during the stien cycle
11:29:46 sean-k-mooney i was going to say before chritmas but i think it was early january
11:29:56 lyarwood right, I think the action just slipped through the cracks and we missed the impact on config drive users
11:30:13 sean-k-mooney ah ya makes sense
11:30:25 sean-k-mooney they could se hw_cdrom_bus
11:30:29 sean-k-mooney they could se hw_cdrom_bus=sata
11:30:33 sean-k-mooney as a workaourd
11:30:35 sean-k-mooney but ya
11:31:01 kashyap lyarwood: Yeah, will look
11:32:09 johnthetubaguy yaawang: so I want to support your use case, but I am really against "use post copy" and "use auto converge" as things we expose. I really want to have something that doesn't depend on how we implement it, I am adding some ideas / alternatives in the spec comments.
11:32:42 kashyap johnthetubaguy: Yeah, I see what you mean on that; me also needs to look at that spec
11:34:09 yaawang johnthetubaguy: I've replied your comment about why not only use post-copy.
11:34:16 johnthetubaguy kashyap: yeah, I found something in google's APIs that I think expresses the user intent better
11:34:42 kashyap I see; do provide a URL when you get around to it
11:34:57 openstackgerrit Ghanshyam Mann proposed openstack/nova-specs master: Policy Default Refresh spec https://review.opendev.org/547850
11:35:27 johnthetubaguy yaawang: ah... thank you, I forgot about the VM needing to reboot if you loose network connectivity with Post Copy
11:35:31 gmann johnthetubaguy: ^^ updated for current comments. i will check other review comments tomorrow.
11:37:52 johnthetubaguy gmann: thanks, sorry for the delay, too much multi-tasking... and I need to get some lunch
11:38:29 gmann johnthetubaguy: i know, how many time you need to switch the context :)
11:38:41 johnthetubaguy gmann: I am wondering if we need to split the details into two...
11:39:34 johnthetubaguy gmann: maybe this should be two specs (...ducks)
11:40:13 johnthetubaguy gmann: so first bit is admin_only and admin_or_owner with tests and better default check_str and scope_types
11:40:16 gmann johnthetubaguy: hummm you mean separate for scope and default roles ?
11:40:26 gmann ok
11:40:29 johnthetubaguy gmann: second spec is adding the Reader role support?
11:40:56 johnthetubaguy now... I know the reader role support is why we are doing it really
11:41:27 johnthetubaguy I just think we need to separate the two bits of work, as they have two different sets of thinking around how we keep it backwards compatible
11:41:35 yaawang johnthetubaguy: Pleasure, can you remove -1 on the gerrit? :)
11:41:39 johnthetubaguy I think the Reader thing is easy, once you have the other stuff in place
11:42:43 johnthetubaguy yaawang: I am still -1 the current approach though, because it talks about the specific implementation, we need to talk about what the workload needs in a way that is hypervisor agnostic... ideally that is.
11:42:44 gmann johnthetubaguy: so in first bit we will keep all GET with system_admin or project_member etc and in second we change them to reader roles
11:42:55 johnthetubaguy yaawang: I will come back with a better suggestion after I have had lunch
11:43:21 johnthetubaguy gmann: yeah, I think that is what we agreed at the PTG in terms of splitting up the patches as we improve the coverage
11:43:45 johnthetubaguy gmann: the second reader roles spec is where we need the extra granular roles too, I guess
11:44:17 gmann yeah, granular rules is needed mainly for reader capability
11:44:54 johnthetubaguy gmann: do you think that makes sense? I don't want to drag it out too much, but I think we need that split due to all test coverage and the change to the DB level check
11:45:15 johnthetubaguy gmann: so the DB level check would go with the reader change I think
11:46:17 johnthetubaguy now the customers I have really want the reader role, they don't care about the other bits, they are "just a dependency" to make things work :(
11:46:18 gmann but DB check needs to adjust with scope_type right say when we will change current admin to system_admin
11:46:36 johnthetubaguy well the DB check is only needed by the Reader rule
11:46:42 gmann i am still thinking if split can end up with 2 upgrade impact for operator.
11:46:42 johnthetubaguy I mean...
11:47:20 gmann ohk, yeah mostly GET thing
11:47:27 johnthetubaguy so I think the reader role addition has no upgrade impact... unless you happen you use the role "reader" instead of "member"
11:48:28 johnthetubaguy well, there granularity change is an impact I guess, but it only affects folks who have changed those policy rules, which should be quite a smaller number of folks
11:49:03 johnthetubaguy gmann: so maybe the best thing is keep it as one spec, but make that clear split in the spec description?
11:49:27 gmann yeah that looks much better to me.
11:50:28 gmann current spec is split for scope_type and roles. i can make it to 1. admin, admin-or-owner -> system scope, project member 2. reader role and DB checks change
11:52:55 gmann basically first bit goes more for adding scope type only with adjusted check_str and second goes for adopting default roles. hummm
11:53:52 johnthetubaguy gmann: I think the first does scope_types and check_str optionally checking for Member, and scope:project, etc
11:54:53 johnthetubaguy gmann: I think the first does scope_types and check_str optionally checking for Member, and scope:project, etc
11:55:00 johnthetubaguy hmm, maybe that's not right either
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.

Earlier   Later