| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-19 | |||
| 14:22:36 | jaypipes | efried: ok, cool thank you sir. | |
| 14:24:43 | efried | jaypipes sahid: Warning, treated as error: /home/efried/Neo/nova-specs/doc/source/specs/queens/approved/sriov-trusted-vfs.rst:166:Footnote [5] is not referenced. | |
| 14:25:03 | efried | Couldn't repro that other thing, though. | |
| 14:25:18 | jaypipes | efried: hey, thanks for doing that research. appreciated. | |
| 14:25:27 | efried | yahyoubetcha. | |
| 14:28:28 | sdague | jaypipes: did efried figure the whole thing out? | |
| 14:28:39 | jaypipes | sdague: seems he did indeed. | |
| 14:28:43 | jaypipes | sdague: sorry for the bother. | |
| 14:28:50 | efried | sdague No, I haven't found where sphinx is missing a param to a log message. | |
| 14:29:02 | efried | sdague See http://logs.openstack.org/22/485522/3/check/build-openstack-sphinx-docs/3402883/job-output.txt.gz#_2017-10-19_08_16_47_666988 | |
| 14:29:09 | efried | That didn't hit when I built locally. | |
| 14:29:18 | jaypipes | efried: but you identified the thing that's causing an error in the spec itself. | |
| 14:29:39 | efried | Yeah. Though interestingly, when I rebuilt with tox -r, it passed. | |
| 14:29:46 | efried | which is... weird. | |
| 14:29:57 | sdague | sunspots | |
| 14:30:52 | sean-k-mooney | mriedem: hi well we could do the allocation in the scheduler also i just want them to happen before we call to the compute node. | |
| 14:31:46 | sean-k-mooney | mriedem: if you want neutorn to do it the i would make that allocations be part of the bind port. | |
| 14:31:50 | efried | sean-k-mooney mriedem Have we considered doing the allocation from neutron at port binding time | |
| 14:31:54 | efried | yeah, THAT. | |
| 14:32:08 | mriedem | yeah that's what i suggested in the spec | |
| 14:32:12 | efried | Then we close the window for races between [port binding succeeds] and [allocation fails] | |
| 14:32:26 | sean-k-mooney | efried:i was looking a at that code today | |
| 14:32:38 | mriedem | the port binding could fail as a result of the allocation failing, but then it's all managed within neutron | |
| 14:32:43 | cdent | i also think neutron should do the allocation | |
| 14:33:03 | efried | Cool. And the `consumer` of the allocation is who? The port or the instance? (My vote is the port.) | |
| 14:33:17 | sean-k-mooney | efried: we can do it as an else to https://github.com/openstack/neutron/blob/1b3f982914d82494c63ac4fee405bf4972d2db32/neutron/plugins/ml2/managers.py#L748 | |
| 14:33:21 | cdent | that’s what is currently suggested on the spc, no? | |
| 14:33:34 | cdent | (that == port) | |
| 14:33:57 | efried | It wasn't clear to me in the spec. | |
| 14:33:58 | dansmith | allocation of what class? | |
| 14:33:59 | sean-k-mooney | cdent: proably i have been in a meeting for the last little bit and have not looked at the lates version | |
| 14:34:29 | cdent | sean-k-mooney: I dumped some thoughts on ps13 and then a new version happened which isn’t hugely different | |
| 14:34:52 | efried | dansmith Yeah. At least the "bandwidth" - but that's a future thing. The network interface resource, whatever that is. E.g. a VF or OVS port. | |
| 14:34:54 | sean-k-mooney | dansmith: allocation of bandwidth or vifs | |
| 14:34:58 | cdent | efried: are we talking about the same spec (I’m talking about the network bandwidth rp one) | |
| 14:34:59 | efried | ^ | |
| 14:35:07 | dansmith | ah, bandwidth | |
| 14:35:18 | efried | cdent We're mostly talking about the 'new neutron port binding api' spec | |
| 14:35:23 | dansmith | that means the scheduler can't pick a host with suitable bandwidth for the migration though right? | |
| 14:35:24 | efried | cdent but bleeding into the bw rp one. | |
| 14:35:33 | sean-k-mooney | cdent: cool ill re read. if the neutron folks are oke with it ill update it shortly | |
| 14:36:00 | dansmith | or for a new build for that matter | |
| 14:36:02 | cdent | efried: that one is somewhere in the my “next” queue | |
| 14:36:04 | sean-k-mooney | efried: yes these two are tightly coupled in some respects | |
| 14:36:13 | efried | dansmith Can pick it, but wouldn't allocate it. | |
| 14:36:37 | dansmith | efried: == resource race == fail | |
| 14:36:50 | sean-k-mooney | dansmith: it can do a first pass without knowing the network backend and then we do the port bind in the conducto before casting to the compute | |
| 14:36:54 | mriedem | gibi: this is very simple if you can take a look https://review.openstack.org/#/c/512626/ | |
| 14:37:00 | efried | How do we get around a race *somewhere*? | |
| 14:37:08 | sean-k-mooney | dansmith: we might be able to do it in the schduler but have not look to see where yet | |
| 14:37:08 | gibi | mriedem: looking... | |
| 14:37:27 | dansmith | sean-k-mooney: efried: that gets us a two-phase commit of allocations and we have to rollback from those both and then reschedule.. avoiding that is the whole point of doing this in the scheduler | |
| 14:37:58 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migrate from 'ip' commands to 'pyroute2' https://review.openstack.org/484386 | |
| 14:38:00 | efried | Yeah, definitely don't disagree with that. But we're also doing a "bind early, fail early" thing with the port. | |
| 14:38:02 | sean-k-mooney | dansmith: well thats one of the reasons i want nova to do the claim instead of neutron | |
| 14:38:49 | efried | So either we [bind early, allocate late] and have the race there, or [bind early & allocate network stuff early, allocate non-network stuff late] and have the race there. | |
| 14:39:08 | efried | I guess the former is cleaner. | |
| 14:39:13 | mriedem | tbc, the 'use neutron port binding API' spec is really not the same thing here, has nothing to do with allocations - it's about using port binding during live migration | |
| 14:39:13 | dansmith | um | |
| 14:39:19 | mriedem | we should have probably renamed that spec title :) | |
| 14:39:27 | mriedem | the bw provider one is the thing talking about claims | |
| 14:39:41 | mriedem | the call i setup in 20 minutes is about the live migration spec, not the bw provider one | |
| 14:39:46 | dansmith | yeah, I'm clearly missing some context from the bw one since I'm thinking about the live migration one | |
| 14:39:57 | mriedem | yes people are blurring them | |
| 14:40:02 | efried | mriedem Regardless, there needs to be a stake in the ground about who's the consumer of the nw resource, who does the allocation, and when. | |
| 14:40:03 | dansmith | effing people | |
| 14:40:26 | mriedem | efried: that doesn't have to be decided for https://review.openstack.org/#/c/375580/ | |
| 14:40:28 | efried | Unless the vif isn't a resource.... | |
| 14:40:30 | mriedem | the call in 20 minutes is for ^ | |
| 14:40:47 | mriedem | because i can actually see that getting done in queens | |
| 14:40:53 | mriedem | i can't see bw provider getting done in queens | |
| 14:41:04 | mriedem | it's dependent on at least 3 other things and we're unclear on the design still | |
| 14:43:22 | sean-k-mooney | mriedem: idealy though we would use the same workflow for spawning a new instance as we do for moving an instance | |
| 14:43:39 | sean-k-mooney | mriedem: interms of when and where we claim resouces | |
| 14:44:33 | mriedem | i don't disagree, but today we aren't claiming anything in placement for networking | |
| 14:44:57 | sean-k-mooney | mriedem: how did you sent that invite by the way? it went straight into my calander and i dont see the email at all | |
| 14:46:19 | sean-k-mooney | mriedem: well we are for routed networks correct? | |
| 14:46:27 | sean-k-mooney | mriedem: or is that done by neutron? | |
| 14:46:59 | mriedem | sean-k-mooney: nova doesn't do anything for routed networks yet | |
| 14:47:09 | sean-k-mooney | ok that must be in nova so. | |
| 14:47:12 | mriedem | that was related to johnthetubaguy's prep for network-aware scheduling thing | |
| 14:47:16 | sean-k-mooney | *neutron | |
| 14:47:22 | mriedem | neutron is doing something yes | |
| 14:48:18 | johnthetubaguy | the only bit nova does is not error when a port has no ip if its on a routed network | |
| 14:49:23 | dansmith | heh | |
| 14:49:29 | dansmith | the only thing nova does is not explode | |
| 14:49:30 | sean-k-mooney | just pinging mlavlle on the neutron channel to see if he is oke with doing the claim in the port bind. if so ill update the neutron and nova spec to reflect that | |
| 14:49:41 | dansmith | sean-k-mooney: hold up dude, | |
| 14:49:58 | dansmith | we should have a discussion, because I think we're missing something important if we do it that way | |
| 14:50:32 | sean-k-mooney | dansmith: im not going to update anything untill after the call | |
| 14:50:38 | dansmith | okay | |
| 14:50:40 | sean-k-mooney | i just want to get his initall reaction | |
| 14:51:33 | sean-k-mooney | if its a non starter from a neutron perspective that is good to know :) | |
| 14:56:02 | mriedem | again, the primary purpose of the call is about the live migration spec, not the bw provider spec, | |
| 14:56:06 | mriedem | if there is time i'm sure we can get into that | |
| 14:57:13 | sean-k-mooney | mriedem: right be we still need to decide on where to do the port bind and activate the binding for the live migration too so we can regenerate the xml if needed | |
| 14:58:08 | sean-k-mooney | mriedem: for example vhost-user socket path changes or you migrate form linux bridge to ovs | |
| 15:02:42 | mriedem | johnthetubaguy: were you going to join? | |
| 15:02:57 | mriedem | https://hangouts.google.com/hangouts/_/calendar/bWF0dHJpZWQyMkBnbWFpbC5jb20.6jrqpj946jj56uo6dsuj4gnmjj | |
| 15:02:57 | johnthetubaguy | mriedem: ah, I didn't get the invite / behind on mail | |