| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-22 | |||
| 12:56:01 | openstackgerrit | Lajos Katona proposed openstack/nova master: WIP: Add nested resources to server moving tests https://review.openstack.org/527728 | |
| 13:01:51 | openstackgerrit | Matthew Booth proposed openstack/nova master: Automatically revert resize which fails on destination https://review.openstack.org/462521 | |
| 13:06:21 | lyarwood | mdbooth: https://review.openstack.org/#/c/523958/ - Anything left to get your +1 on that? | |
| 13:07:04 | lyarwood | mdbooth: FWIW https://review.openstack.org/#/c/536350/ is testing this at the moment, I'll add a note if/when I respin the original. | |
| 13:07:25 | mdbooth | Nope. Do you think you'll address the diff comment if you respin? | |
| 13:08:02 | lyarwood | mdbooth: ah yeah, I can look at that now | |
| 13:08:18 | mdbooth | lyarwood: You can have my +1 without it, though. | |
| 13:08:47 | lyarwood | mdbooth: if you could for now, just writing up a ML post to get additional reviewers before FF | |
| 13:12:34 | mdbooth | lyarwood: kk | |
| 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: 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 | |