| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-19 | |||
| 13:55:50 | bauzas | that's indeed a good point | |
| 13:55:57 | mriedem | like, how long does it take to cold migrate a 100GB disk vm backed by ceph? | |
| 13:56:03 | mriedem | cburgess: ^? | |
| 13:56:26 | johnthetubaguy | cdent: "nova managed" is how I like to think of that, I wish we could get out of the disk and image business altogether, long term. | |
| 13:58:32 | cdent | johnthetubaguy: yup, that would be nice. I wonder if that means we’re going to need to break away from the idea that only one thing should be writing all the allocations associated with a build? <- probably best to just store those worms back in the can for sometime later | |
| 13:59:04 | johnthetubaguy | cdent: get that lid back on :p | |
| 14:00:38 | mriedem | meeting time | |
| 14:12:10 | jaypipes | sahid: k. reviewing it again. | |
| 14:12:35 | jaypipes | sahid: see also: https://twitter.com/jaypipes/status/920739280603009024 | |
| 14:19:09 | jaypipes | sdague: around? hoping you could help me spot what the issue is with sahid's spec not passing the sphinx-docs job here: https://review.openstack.org/#/c/485522/ | |
| 14:19:18 | jaypipes | sdague: can't seem to see anything in the logs.. | |
| 14:20:32 | efried | jaypipes 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:21:01 | efried | wherezat log? | |
| 14:21:17 | efried | cause it looks like a sphinx bug masked the real problem. | |
| 14:21:35 | jaypipes | efried: well, yeah, I saw THAT. :) I'm just saying that isn't useful | |
| 14:22:02 | efried | I'll build it locally and see if I can get at the real problem. | |
| 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 | |