Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-04
10:22:01 kashyap Thx.
10:22:35 johnthetubaguy gmann: yeah, the steps bit is a bit out of date now I think
10:24:10 johnthetubaguy gmann: I just added comments on the first 100 lines, going to keep going now
10:24:30 gmann johnthetubaguy: thanks, checking..
10:32:16 yaawang johnthetubaguy: Hi, could you please taking a look at the auto-converge/post-copy spec? I have replied your commets. https://review.opendev.org/#/c/651681/
10:33:37 johnthetubaguy yaawang: ah, I meant to follow up with your spec, will have a look
10:34:44 yaawang johnthetubaguy: Great
10:36:59 johnthetubaguy yaawang: sorry, I think I miss-understood your use case
10:37:29 johnthetubaguy yaawang: could you describe to me why a workload prefers auto converge vs post copy?
10:37:42 johnthetubaguy is it the slowing down of the guest it wants to avoid?
10:37:59 johnthetubaguy or the pausing of the guest it want's to avoid
10:38:19 gmann johnthetubaguy: to be clear on DB check change. currently we check hard coded is_admin for few place which is going to be change to check if requested token is scoped to system.
10:38:35 johnthetubaguy gmann: but... is_admin is set via policy
10:38:56 gmann johnthetubaguy: yes, by checking is_context_admin which internally check admin role
10:39:47 johnthetubaguy gmann: I think thinking we can hardcode to context.system_scope == "all" for the DB check, probably needs a new name though
10:39:49 yaawang johnthetubaguy: Ok, please wait...
10:40:02 johnthetubaguy yaawang: no problem
10:40:58 gmann johnthetubaguy: yeah. something like that and then set is_system or something on context like ^^
10:41:34 gmann johnthetubaguy: updated my local copy of spec with your comments till L100. waiting for next
10:44:20 johnthetubaguy gmann: yeah, I think so... the key bit in the ordering is to allow us to implement the System Reader role, without breaking the project_id protection. i.e. the role:admin no longer works for list servers in all projects
10:44:32 johnthetubaguy really just talking out loud to check my thinking there
10:46:34 yaawang johnthetubaguy: If the compute node enable auto-converge, it will slow down CPU and memory I/O to make it easy to live-migrate to other compute node.
10:46:39 yaawang johnthetubaguy: But it means all vms on the compute node will use auto-converge during live-migration even the vm can live-migrate to other compute node without auto-converge/post-copy.
10:46:57 yaawang johnthetubaguy: For some applications(such as scientific computing applications) is sensitive to performance reduce or memory I/O error, these vms do not want to use auto-converge/post-copy during live-migration.
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

Earlier   Later