| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-22 | |||
| 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 | |
| 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 | |