Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-08
16:33:19 mriedem that's dave riedemann classy
16:33:31 mriedem that's mfing SW iowa classy
16:33:39 artom And lip gloss as well
16:34:03 mriedem no gloss required
16:34:13 artom You're just naturally fabulous
16:34:16 mriedem that's probably leftover bacon grease since it's iowa
16:34:33 mriedem pork and corn for every meal boys
16:34:53 artom Pork and Corn is the name of my Korn tribute band.
16:37:00 johnthetubaguy dansmith: melwitt: thinking about quota and resize
16:37:21 johnthetubaguy dansmith: melwitt: what if we only do a check when you request the resize, and actually not care about races for resize?
16:37:40 dansmith johnthetubaguy: well, that's what I meant by accept the leakiness
16:38:04 johnthetubaguy dansmith: melwitt: longer term I am tempted we just do it based on allocations in placement, so you end up needing double quota during the resize, as thats technically more accurate on the resource usage
16:38:05 dansmith johnthetubaguy: just depends on how concerned we are about people gaming that by the resize-all situation I mentioned
16:38:11 dansmith johnthetubaguy: yep
16:38:31 johnthetubaguy I was thinking about the folks that only had out enough quota for the given space they have
16:39:18 johnthetubaguy dansmith: crazy, crazy, idea, limit the number of resizes you are allowed to do at once
16:39:35 dansmith johnthetubaguy: with a quota or a static value?
16:39:48 dansmith johnthetubaguy: resizes are heavy so that's probably not a bad idea regardless
16:40:49 johnthetubaguy dansmith: I could go either way, a static conf, with the option of -1 might be enough (to save any API change for now)
16:41:22 dansmith johnthetubaguy: yeah, it's pretty much exactly like the "max parallel builds" and "max parallel migrations" confs we have now, just tenant-scoped
16:41:27 dansmith johnthetubaguy: but yeah, I like it
16:41:51 johnthetubaguy dansmith: yeah, per project rather than per host
16:41:55 dansmith yeah
16:42:00 dansmith sounds good to me
16:42:22 johnthetubaguy yeah, so check just on the way in, but limit the number you are allowed in conf
16:42:26 johnthetubaguy thats quite simple really
16:42:46 johnthetubaguy I quite like the double allocation eventually, once we have the placement thing working like that
16:43:21 sfinucan vladikr: little comment on https://review.openstack.org/#/c/430026. Happy to approve after
16:43:32 vladikr sfinucan, thanks
16:43:51 dansmith johnthetubaguy: yeah placement makes all of this easier when it gains knowledge of the project
16:43:59 dansmith johnthetubaguy: so wanna dump the above into a comment on there?
16:44:07 johnthetubaguy yup yup
16:44:12 dansmith rock on
16:45:41 sfinucan mriedem: Could I get the -2 lifted from https://review.openstack.org/#/c/345396/, please?
16:47:00 openstackgerrit Stephen Finucane proposed openstack/nova master: console: introduce basic framework for security proxying https://review.openstack.org/345396
16:47:01 openstackgerrit Stephen Finucane proposed openstack/nova master: console: introduce the VeNCrypt RFB authentication scheme https://review.openstack.org/345398
16:47:01 openstackgerrit Stephen Finucane proposed openstack/nova master: console: introduce framework for RFB authentication https://review.openstack.org/345397
16:47:02 openstackgerrit Stephen Finucane proposed openstack/nova master: console: provide an RFB security proxy implementation https://review.openstack.org/345399
16:47:15 johnthetubaguy dansmith: added a comment, double check that makes sense
16:49:04 dansmith johnthetubaguy: yep thanks
16:49:19 openstackgerrit Matthew Booth proposed openstack/nova master: fdatasync() downloaded images before use https://review.openstack.org/441246
16:49:20 openstackgerrit Matthew Booth proposed openstack/nova master: Ensure image conversion flushes output data to disk https://review.openstack.org/443230
16:50:40 mdbooth sdague: You were +2 on https://review.openstack.org/#/c/441246/. I just changed the commit message to reflect that there's a second part to the puzzle.
16:51:30 mdbooth (Also, there's a second part to the puzzle ;))
16:59:02 mriedem sfinucan: nope
16:59:07 mriedem sfinucan: the blueprint isn't approved
16:59:11 mriedem and i don't see a re-proposed spec
16:59:53 sfinucan mriedem: Ah, I only thought -2s only applied after spec approval deadline. I'll resub the spec now
17:03:59 mriedem dansmith: something else i thought about yesterday with your simple tenant usage change
17:04:09 mriedem but in get_all in the compute API we have a check for cells v1
17:04:32 dansmith mriedem: on a call, but let me think about that when I'm done
17:05:01 dansmith not sure it's as important here. the cells1 check is purely to avoid overwriting data in the replication, but here we're looking at history, so probably fine
17:05:03 dansmith anyway, biab
17:05:21 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Websockify security proxy framework https://review.openstack.org/443234
17:09:58 openstackgerrit Sujitha proposed openstack/nova master: Reduce calls to load_tags() to 0 https://review.openstack.org/435146
17:29:32 jroll so openstackclient defaults to the latest microversion, do y'all pin that or send 'latest'?
17:30:25 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/delete #1: no-ops https://review.openstack.org/438119
17:30:37 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #2: functional https://review.openstack.org/438598
17:31:10 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: power_on/off and reboot https://review.openstack.org/427380
17:32:18 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #3: TaskFlow https://review.openstack.org/438729
17:32:31 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #4: full flavor https://review.openstack.org/391288
17:32:48 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: console https://review.openstack.org/409402
17:34:54 cfriesen at the PTG a suggestion was made to add an option to the live migration request to specify "force live migration after X seconds". Was anyone planning on running with that?
17:35:54 jroll never mind my question, I found it, the answer is that it's pinned
17:36:03 mriedem jaypipes: ComputeNode.stats is where all of the virt driver capabilities dict garbage lives right?
17:37:50 raj_singh cfriesen: yes
17:38:12 raj_singh cfriesen: I have a spec https://review.openstack.org/#/c/442809/
17:38:22 mriedem claudiub: jaypipes: can you both take a look at this? https://review.openstack.org/#/c/364468/
17:38:29 mriedem claudiub: guestions in there for you wrt the hyperv driver
17:38:40 mriedem jaypipes: questions in there for you about nested resource providers and placement
17:38:45 mriedem sfinucan: ^ questions/comments inline
17:39:34 mriedem seems like the numa/pci information is something that would be fed into nested resource provider via the new get_inventory method on the virt driver
17:39:39 raj_singh cfriesen: and this https://review.openstack.org/#/c/438467/
17:39:49 mriedem so the libvirt driver could say what it's inventory of available pci devices is
17:40:21 mriedem and then the scheduler you query placement for that info and place an instance that requires pci onto one of those hosts, and for instances that don't require pci, it weighs those away from those providers
17:42:27 sean-k-mooney mriedem: looking at stpehens spec i dont know if you need driver changes so much as compute agent changes
17:42:52 mriedem compute agent?
17:42:59 mriedem we don't have a compute agent
17:43:19 sean-k-mooney n-cpu?
17:43:46 cfriesen compute server
17:43:48 sfinucan mriedem, sean-k-mooney: Might be easier show you the code :) https://review.openstack.org/#/c/379625/10
17:44:05 cfriesen make that compute service
17:44:16 mriedem sfinucan: ok that's not the compute driver
17:45:05 sean-k-mooney mriedem: right what sfinucan is proposing to change is how the pci device is selected when it lands on the compute node but i tink that should be driver independent
17:45:08 mriedem so the compute_nodes.numa_topology field has the data you need, which we get in the resource tracker
17:45:36 mriedem sean-k-mooney: i thought the point was to not land instances that don't require pci on hosts that have available pci inventory?
17:45:58 mriedem doing that calculation after we've picked the host is too late
17:46:13 sean-k-mooney mriedem: that is where the weigher comes in
17:46:36 sean-k-mooney mriedem: untill we have claims you need to do it twice
17:46:45 sfinucan mriedem: Yeah, it's two steps
17:47:00 sfinucan Step A: Don't use hosts with PCI devices if we don't need them (the weigher)
17:47:29 sean-k-mooney if you run out of server that dont have pci decices and you have to land on one that does then you should still prefer a numa node that does not have pci devices attached
17:47:35 sfinucan Step B: If we do get a host with PCI devices, avoid NUMA nodes with PCI devices if we don't need them
17:47:59 sean-k-mooney yep what sfinucan said :)
17:50:47 mriedem i'll be honest, my eyes glaze over once i see numa_fit_instance_to_host
17:53:39 sean-k-mooney mriedem: that is fair. if i didnt have to know about numa effect for my job i would happy delete it form my mind
17:55:48 sean-k-mooney sfinucan: so stepen to sergeys vis versa comment are you going to extend the weigher to also perfer numa nodes with pci devices available when they are requested or just update the comment ?
17:56:54 sfinucan sean-k-mooney: I think I'll just remove the comment and rely on balancing with CPUs
17:57:31 sean-k-mooney sfinucan: ok its a 30 second else clause with the same labmda but the order reversed to add if you wanted too
17:58:11 sfinucan sean-k-mooney: But it's another 10 minutes writing unit tests ;)

Earlier   Later