Earlier  
Posted Nick Remark
#openstack-nova - 2018-01-22
13:17:45 openstackgerrit Jiri Suchomel proposed openstack/nova master: Do not multiply megabytes with 1024 to get gigabytes. https://review.openstack.org/536335
13:21:14 alex_xu cdent: thanks for https://review.openstack.org/#/c/535642/2/nova/tests/functional/api/openstack/placement/gabbits/allocation-candidates.yaml@227
13:22:16 cdent alex_xu: does it do the right thing?
13:22:35 alex_xu cdent: working on it now
13:29:32 efried Greetings all
13:29:45 efried cdent Welcome back.
13:31:17 cdent hold efried
13:31:20 cdent hola!
13:31:25 efried That too
13:31:37 cdent expect me to leave again, because I left my house, therefore any moment now will be ill
13:35:34 alex_xu cdent: I guess that required to sort the response 'GET /allocation_candidates' API also, since that API response is unorder also
13:35:35 cdent efried: is there a pending implementation of the in virt driver side of update provider tree somewhere?
13:36:00 efried cdent Xen and VMWare are both working on that.
13:36:08 cdent alex_xu: no, the idea is that whatever the order of the output, you can sort it in gabbi to alpha, and then compare with an alpha expected result
13:36:47 alex_xu cdent: ah, I got it
13:36:48 cdent efried: yeah, was looking at the VMware one this morning (with the author) and was hoping for something with more flesh on the bones
13:37:10 sean-k-mooney alex_xu: qq do you know if ironic is tagging resouce providers for ironic nodes with traits? just want to chenc if your traits work will only be consumable with nova vm based driver in queeens or if you can use traits with ironic in queens also.
13:37:21 cdent efried: because rado had some questions about the use of the 'generation' parameter in update_inventory
13:37:22 efried cdent Oh, I haven't seen the vmware one yet, though I chatted with rgerganov about it last week. Link please?
13:37:29 efried ah, okay.
13:37:40 efried Let me find the xen series, though I'm not sure it has any more "flesh"...
13:38:02 cdent efried: https://review.openstack.org/#/c/536348/
13:38:07 efried sean-k-mooney Yes, there's a series for that.
13:38:29 cdent efried: see especially the commens at https://review.openstack.org/#/c/536348/1/nova/virt/vmwareapi/driver.py
13:38:48 efried sean-k-mooney They're implementing a get_traits() driver method, which is going to be a kind of bastardized bridge between get_inventory and update_provider_tree, hopefully short-lived.
13:38:53 sean-k-mooney efried: oh ok cool. thats what i was hoping to hear. so provided the ironic discoverd or the admin applys traits to the resouce providers then it should work
13:39:17 efried sean-k-mooney I believe that's the theory. They're staying pretty close to the blueprint from what I've seen so far.
13:39:43 alex_xu sean-k-mooney: yea, efried already answer that
13:39:45 sean-k-mooney efried: ah ok so it will be ironic backend driver dependent then.
13:40:10 efried sean-k-mooney Let me find the series so you can go after the authors for specifics...
13:40:11 sean-k-mooney alex_xu: yep sound like ye have that covered :)
13:40:46 alex_xu yea, my traits works just generic thing, needs each driver to report traits
13:40:57 sean-k-mooney efried: its on i can follow up myself dont put yourself out if you dont have it to had.
13:40:58 alex_xu cdent: it works \o/
13:41:05 cdent alex_xu: yay!
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: using the dict format for the allocations https://review.openstack.org/536083
13:47:51 openstackgerrit Alex Xu proposed openstack/nova master: placement: support traits in allocation candidates API https://review.openstack.org/535642
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

Earlier   Later