| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-19 | |||
| 08:59:15 | openstackgerrit | jichenjc proposed openstack/nova master: remove CONF.vendordata_driver https://review.openstack.org/501510 | |
| 08:59:25 | openstackgerrit | jichenjc proposed openstack/nova master: Add description for reousrce class creation https://review.openstack.org/508083 | |
| 09:17:51 | openstackgerrit | Merged openstack/nova-specs master: Spec for service create and destroy notification https://review.openstack.org/444731 | |
| 09:34:47 | artom | legacy-grenade-dsvm-neutron-multinode legacy-grenade-dsvm-neutron-multinode : ERROR Project openstack/neutron does not have the default branch master | |
| 09:34:49 | artom | o_O | |
| 09:45:28 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: nova-manage db archive_deleted_rows is not multi-cell aware https://review.openstack.org/507486 | |
| 09:49:42 | artom | Oh god we broke archive_deleted_rows_again | |
| 10:32:37 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'move-nova-cmds-to-cliff' spec https://review.openstack.org/433603 | |
| 10:32:49 | stephenfin | bauzas: Addressed comments in ^ | |
| 10:33:23 | stephenfin | tl;dr: Migration to cliff is only part of that spec. The larger aim is "cleanup nova-* commands". The spec title is misleading but I'm stuck with it now | |
| 10:40:39 | openstackgerrit | Shoham Peller proposed openstack/nova master: Handle spawning error on unshelving https://review.openstack.org/378009 | |
| 10:59:49 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Clean up TODOs in allocations.yaml gabbit https://review.openstack.org/513057 | |
| 11:23:54 | gibi | bauzas: sorry, I was pulled into internal meeting for the whole morning. But I agree with your judgement on https://review.openstack.org/#/c/444731/8 | |
| 11:30:21 | sahid | jaypipes: hola, i just updated the vf trusted specs, basically now it's just about to pass a tag in the binding and operator will have to isolate group of hosts | |
| 11:31:36 | sahid | they were a part where you asked me to use traits for the binding, can you have a look and perhaps suggest me what you want exactly? | |
| 11:32:30 | sahid | jaypipes: here is the link https://review.openstack.org/#/c/485522/ so you don't even have to search for the pointer :) | |
| 11:41:36 | dtantsur | johnthetubaguy: mind checking https://review.openstack.org/#/c/511844/ please? | |
| 12:09:17 | bauzas | who knows IRC nick of https://www.openstack.org/community/members/profile/33046/zhenyu-zheng ? | |
| 12:12:06 | yikun_jiang | @bauzas Kevin_Zheng | |
| 12:12:17 | bauzas | yikun_jiang: ty | |
| 12:12:23 | bauzas | Kevin_Zheng: around ? | |
| 12:12:36 | bauzas | Kevin_Zheng: just about https://review.openstack.org/#/c/509326/6 | |
| 12:12:42 | cdent | bauzas: yikun_jiang beat me to it, but my usual trick is to search launchpad: https://launchpad.net/+search?field.text=zhenyu-zheng | |
| 12:13:04 | bauzas | Kevin_Zheng: if you could provide a follow-up change for all the nits, would be awesome :) | |
| 12:13:04 | Kevin_Zheng | bauzas what’s up? | |
| 12:13:26 | Kevin_Zheng | bauzas: sure I can do that | |
| 12:13:28 | bauzas | that's not urgent, but wanted to make sure you saw the points | |
| 12:13:45 | bauzas | Kevin_Zheng: thank you ! | |
| 12:14:24 | Kevin_Zheng | bauzas: np | |
| 12:14:47 | bauzas | cdent: I usually use https://www.openstack.org/community/members/ for that :) | |
| 12:15:05 | bauzas | btw, Kevin_Zheng it would be nice if you could add your nick there ^ | |
| 12:15:52 | Kevin_Zheng | I will try tomorrow:) | |
| 12:16:04 | cdent | bauzas: sure, but a combo of both sometimes gets us there | |
| 12:36:46 | openstackgerrit | Merged openstack/nova-specs master: Improve the performance of filtering instances by IP. https://review.openstack.org/509326 | |
| 12:52:01 | johnthetubaguy | dtantsur|brb: will take a look at that ASAP | |
| 13:18:17 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Use neutron's new port binding API https://review.openstack.org/375580 | |
| 13:19:33 | bauzas | mriedem: I think you made valid points on https://review.openstack.org/#/c/334732/65/specs/queens/approved/abort-cold-migration.rst but maybe we shouldn't block on those | |
| 13:21:02 | sean-k-mooney | mriedem: i dont know if you saw http://lists.openstack.org/pipermail/openstack-dev/2017-October/123776.html in your inbox. does that carify the desire workflow? | |
| 13:21:14 | bauzas | mriedem: for the virt drivers support, maybe just making sure we update https://docs.openstack.org/nova/latest/user/support-matrix.html and https://docs.openstack.org/nova/latest/user/feature-classification.html could be a starting point, nope ? | |
| 13:23:36 | gibi | bauzas, mriedem: I added some comments on the cold migration patch regarding the notification impact but as a second thought we can do the notification impact in a later spec if we don't want to block on core of the feature | |
| 13:25:03 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Network bandwidth resource provider https://review.openstack.org/502306 | |
| 13:48:24 | cdent | johnthetubaguy: yeah my allocations concern was definitely a long term thing. I don’t think it i something we need to do anything about now, but it feels like something we need in our brains. We get in the habit too often of dimissing the long term picture (because of all the usual constraints). So it was mostly just a reminder. | |
| 13:48:34 | mriedem1 | sean-k-mooney: i'm not sure that it does. your email is about the bw aware scheduling stuff. it also says you want nova to make allocations on the bw provider from conductor, but that's not really something we're wanting to do for anything else. we want allocations made in the scheduler if nova is going to make them. but i think neutron should manage the allocations for bw providers since the port is the consumer. | |
| 13:48:58 | mriedem | bauzas: i'll look again | |
| 13:49:11 | johnthetubaguy | cdent: yeah, +1 that. I was really just making sure its not a short term blocker. | |
| 13:49:49 | cdent | johnthetubaguy: *nod* we do allocate for disk that is shared, by treating it as local… | |
| 13:55:30 | mriedem | bauzas: i'm interested in knowing what type of storage backend NTT is using and the size of these disks that's causing the cold migration to take so long that a user has to submit a support ticket to an admin to abort the cold migration | |
| 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 | |