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