Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-08
16:23:31 mriedem kashyap: yeah so i think the confirmation from danpb nails it, the first swap which is no resize is ok, but the 2nd which is the resize fails
16:23:53 mriedem med_: i can't remember the last time i've been carded since i don't drink
16:23:57 mriedem but maybe to get in
16:24:02 med_ good point.
16:24:31 mriedem lyarwood: yeah i think i thought about that test wrinkle at one point when talking with scottda about testing swap volume
16:24:48 mriedem it would be pretty simple, creating 2 volumes, where the 2nd is larger and we swap from small to big
16:25:06 kashyap mriedem: Ah, cool that you tied up that loose end with that analysis
16:25:33 mriedem edleafe: so i think the thing is all sorted out :L)
16:25:34 mriedem :)
16:25:59 edleafe mriedem: See? Bring me in, problem gets solved!
16:26:43 mriedem i do enjoy that the L3 guys from japan call me Matt-san
16:27:10 edleafe On IRC we'll call you mriedem-san from now on
16:27:55 mriedem in high school i got people to call me dave for a few weeks just because i liked the name
16:28:03 mriedem so call me dave
16:28:23 edleafe s/Matt/Dave/g
16:28:54 dansmith mriedem: weren't you a little old for such shenanigans in high school?
16:28:55 dansmith that's middle school stuff
16:30:08 artom mriedem, so https://en.wikipedia.org/wiki/David_Readman is you then?
16:31:53 mriedem dansmith: i think it was exactly the right time
16:32:35 dansmith heh
16:32:41 mriedem artom: ha, no i'm this guy http://www.swipco.org/contact-us/
16:32:47 mriedem Dave Riedemann, Housing Programs Administrator
16:33:15 mriedem under armor for a professional photo, classy
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?

Earlier   Later