Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-22
13:42:14 efried cdent Series is a bit wobbly at this point, but kinda starts here: https://review.openstack.org/#/c/520313/
13:42:16 rgerganov efried, the doc string of provider_tree.update_inventory says that it will update the generation or the RP which I find strange
13:42:19 efried cdent (That's the xen one)
13:42:29 cdent thanks efried
13:42:35 efried rgerganov The *placement* side will update the generation, yes.
13:43:27 efried cdent Here's where they actually implement update_provider_tree, which just calls the helpers in the other couple of patches in the "series": https://review.openstack.org/#/c/521041/4/nova/virt/xenapi/driver.py
13:43:46 efried rgerganov There has been some confusion (not least on my part) about how the generation works.
13:44:06 cdent efried: in this case the question is why is update_inventory accepting a generation param?
13:44:28 efried sean-k-mooney Here's mgoddard's series on ironic traits: https://review.openstack.org/#/c/508116/
13:44:53 efried cdent We have to send the generation as we know it back to the placement API so it can detect concurrent updates.
13:45:12 cdent efried: yes, but doesn't the tree already know it?
13:46:15 efried cdent rgerganov I do a GET, and receive inventory at generation 1. Joe-Bob's server over there does a GET and receives the same inventory, generation 1. Now Joe-Bob does a PUT with a new version of the inventory, which is now at generation 2. When I do my PUT, my payload would blow away Joe-Bob's.
13:46:46 efried So the solution: I send "generation 1" when I do my PUT, and placement says, "whoah, I'm at generation 2, 409".
13:47:03 efried So I have to re-GET so I can make sure my updates to the inventory are still valid in the context of Joe-Bob's.
13:47:08 efried Can you dig it, dogg?
13:47:51 openstackgerrit Alex Xu proposed openstack/nova master: placement: support traits in allocation candidates API https://review.openstack.org/535642
13:47:51 openstackgerrit Alex Xu proposed openstack/nova master: placement: using the dict format for the allocations https://review.openstack.org/536083
13:47:52 openstackgerrit Alex Xu proposed openstack/nova master: placement: enable required traits from the flavor extra specs https://review.openstack.org/536085
13:48:11 cdent efried: so here https://review.openstack.org/#/c/536348/1/nova/virt/vmwareapi/driver.py the expectatin is that gen = provider_tree.generation ?
13:48:12 alex_xu gibi: cdent yikun_ ^ updated
13:48:22 cdent thanks alex_xu will look soon
13:48:30 alex_xu cdent: thanks
13:49:37 efried ohh, cdent sorry, I was thinking of report client's update_inventory_for_provider_or_whatever_it's_called.
13:49:47 efried cdent Why does ProviderTree.update_inventory take a generation.
13:49:48 efried One sec.
13:50:17 efried cdent rgerganov It's so report client can keep its internal cache up to date.
13:50:57 efried cdent rgerganov I agree it shouldn't be required - for any of the ProviderTree update_* methods - because update_provider_tree shouldn't use it, because update_provider_tree shouldn't be talking directly to placement.
13:51:09 efried edleafe You've got the sched meeting today, yes?
13:51:33 bauzas jianghuaw: hola
13:51:46 bauzas jianghuaw: I'm hardly testing my vGPU changes for libvirt
13:51:56 bauzas jianghuaw: I saw some problems due to libvirt
13:52:11 bauzas jianghuaw: have you also tested for example suspending your instances ?
13:52:48 sean-k-mooney efried: thanks :) it will make my pm happy to know that this is well in hand. it was on our potential gaps list for a while.
13:58:28 edleafe efried: yes, scheduler meeting in 2 minutes in #openstack-nova-alt
13:58:43 efried Or #openstack-meeting-alt
13:58:51 efried Mondays
13:59:06 edleafe and lack of caffeine :(
13:59:07 bauzas nova alternative ?
13:59:09 bauzas man
13:59:26 edleafe too early to have to think clearly
14:00:04 bauzas just rename nova-alt to ciao
14:00:13 bauzas shorter FTW
14:00:28 jroll hey nova friends, the ironic rolling upgrade testing is down. while we try to track down why nova-conductor segfaults after upgrading ironic (without restarting n-cond), this patch will help us work around it by allowing nova queens to work with ironic pike (which is a good thing for users anyway). reviews would be super helpful, thank you :) https://review.openstack.org/#/c/535786/
14:01:25 sean-k-mooney bauzas: :) but its in go so obvioulsy better even though it has no epa/numa or any other kind of plathform awerness
14:01:50 bauzas shhhhhhtttttttttt
14:02:15 edleafe Scheduler subteam meeting running now in #openstack-meeting-alt
14:03:30 sean-k-mooney bauzas: by the way if its not clear i am not a ciao fan
14:03:50 bauzas sean-k-mooney: that's fine
14:04:00 bauzas sean-k-mooney: just say now you're a Kata fan :p
14:04:06 bauzas be corp, man
14:04:50 sean-k-mooney bauzas: haha well kata is a merger of clear containers and hyper right. its more of a libvirt alternitve then nova as far as i understand
14:05:11 bauzas that's at least a big question I have in mind
14:05:21 bauzas and I saw noone talking about that
14:05:33 bauzas I should learn Go, if I'm not foolish
14:06:35 sean-k-mooney reading go is not that hard, reversing the type/name order of things when writing it will drive me nuts for at least 6 months if i ever try to write it
14:07:01 edmondsw gibi finucannot think you'll be able to get to the PowerVM SEA networking patch? should be easy after the OVS one
14:07:08 edmondsw https://review.openstack.org/#/c/523216/
14:08:42 finucannot edmondsw: Sure will. Got four series on my backlog but I'm working through an emulator threads bug today. Will probably be tomorrow, I'd say
14:08:54 edmondsw finucannot thanks!
14:09:54 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: SEA https://review.openstack.org/523216
14:11:29 edmondsw ^ is just a rebase
14:22:47 lyarwood stephenfin: https://review.openstack.org/#/c/523958/ - Do you have time to go over this today? :)
14:23:13 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094
14:23:47 stephenfin lyarwood: Depends on how big it is. See above :) (tl;dr: /me side-tracked by a bug today)
14:25:47 lyarwood stephenfin: kk, pretty big but tomorrow (morning?) would be fine if that's possible
14:26:07 stephenfin lyarwood: It's top of my list
14:26:15 stephenfin Sorry edmondsw :) You're next in line
14:26:59 edmondsw stephenfin sure :)
14:29:29 sean-k-mooney stephenfin: i was talking to rodoflo eairlier regarding https://review.openstack.org/#/c/449257/ he needs to move on to yardstick work which means he wont be able to work on this before the code freeze
14:29:38 sean-k-mooney stephenfin: im going to try an pick it up
14:30:25 sean-k-mooney stephenfin: you had some changes you wanted regarding the spec dict/object can i ping you later once i have it setup locally to confirm what needs to be done
14:30:59 stephenfin sean-k-mooney: Sure can. I _think_ they make sense but I'll leave that to you to decide :)
14:31:02 sean-k-mooney stephenfin: this barly missed pike then we made a lot of change in queens so dont want it to slip to rocky if it can be avoided
14:31:26 stephenfin Agreed. I'd like to get that in, if at all possible
14:32:34 sean-k-mooney stephenfin: cool am i need to get dan smit to look at that too as he previous gave feedback re using objects
14:33:43 stephenfin sean-k-mooney: Yup, about versioning. I think the tl;dr: of it was that you can't really remove a field, even if it's unused, and type changes have to have backwards compatibility wrappers provided
14:33:58 ameeda jaypipes: are you around ?
14:35:32 sean-k-mooney stephenfin: yes he suggested synatsizing the new field form the old using a lazy loader if it was not set. i think rodlofo has that done i just want to make sure he is ok with the filed change you asked for too as i think that field existed before the patch so we cant just convert it to an object.
14:36:02 sean-k-mooney stephenfin: i need to read the patch again since its been a few weeks since i did so i may be mis remembering
14:43:27 gibi alex_xu: thanks for the update. I'm +2 on the bottom patch. I will review further in that chain soon
14:43:37 efried ameeda I believe Jay is trying to find a spot to work from at the moment.
14:44:33 gibi edmondsw: the SEA patch is on my list
14:44:53 edmondsw gibi great, tx
14:44:59 ameeda efried: hehe, so can you help me ?
14:45:15 efried ameeda Gosh, that depends. What's going on?
14:45:19 mriedem stephenfin: were you working on a nit fixes patch for the websocket proxy security series?
14:45:42 ameeda efried: can you please check this "https://review.openstack.org/#/c/526900/" and notice the scenario from the bug side ?
14:46:09 stephenfin mriedem: Yup, it merged. Lemme know if there's stuff I missed https://review.openstack.org/#/c/534368/
14:46:38 mriedem stephenfin: ah ok - was just wondering if you wanted to update that docs patch for my one comment or do it in a follow up?
14:47:37 efried ameeda Oh, this patch. Yeah, I looked it over a bit last week and accepted that it's not really in my wheelhouse, sorry.
14:47:44 stephenfin mriedem: If it's just that, I can edit on Gerrit
14:47:52 stephenfin mriedem: reply left, in any case
14:48:10 mriedem stephenfin: just edit inline and i'll +W
14:48:33 bauzas mriedem: welcome back
14:48:38 mriedem thanks
14:48:39 bauzas mriedem: for your pleasure, we have https://bugs.launchpad.net/nova/+bug/1744325
14:48:41 openstack Launchpad bug 1744325 in OpenStack Compute (nova) "If a rebuild is refused by the scheduler, the instance's imageref is not rolled back" [Critical,In progress] - Assigned to int32bit (int32bit)
14:48:57 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Document TLS security setup for noVNC proxy https://review.openstack.org/500544
14:49:19 stephenfin mriedem: Done (y)
14:49:44 mriedem bauzas: tagged for rc potential but not going to look at it for awhile

Earlier   Later