| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-26 | |||
| 13:49:01 | mdbooth | dansmith: I mostly try not to :) | |
| 13:49:07 | mdbooth | It was my first commercial language | |
| 13:49:11 | dansmith | heh | |
| 13:49:35 | dansmith | it was my advisor's favorite language, so I wrote a bunch of stuff in it in college, but.. I barely remember any of it | |
| 13:49:37 | mdbooth | upvar was the worst, but I thought I'd actually found a niche for it | |
| 13:49:38 | dansmith | still have a book | |
| 13:50:10 | jaypipes | I could never used a programming language named "Tickle". | |
| 13:50:41 | mdbooth | jaypipes: It's as good as any reason | |
| 13:50:47 | jaypipes | :) | |
| 13:50:57 | mriedem | yet you watch flubber every friday night | |
| 13:50:59 | mriedem | religiously | |
| 13:51:35 | jaypipes | lmao | |
| 13:51:47 | jaypipes | mriedem: shh, don't tell anyone that./ | |
| 13:51:52 | mriedem | sorry | |
| 13:53:21 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Add reserved_host_cpus option https://review.openstack.org/460113 | |
| 13:54:25 | sfinucan | jaypipes: RE: "will it be a problem, though, until we cut a new os-vif release?" I guess it won't be, but do we want our next release to hinge on "has this feature landed in OVS"? | |
| 13:54:42 | sfinucan | there's also the chance that the feature won't land/will be different | |
| 13:54:49 | sfinucan | unlikely, in fairness, but possible | |
| 13:54:57 | jaypipes | sfinucan: le sigh... sorry, didn't realize that was the case :( | |
| 13:55:03 | jaypipes | sfinucan: k, revert it then. | |
| 13:55:21 | mriedem | kindly reminder to let me know if i should be releasing os-vif ever | |
| 13:55:25 | jaypipes | sfinucan: next time, should really be WIP'd :) | |
| 13:55:26 | mriedem | since i don't monitor it | |
| 13:55:35 | sfinucan | will do | |
| 13:55:35 | jaypipes | mriedem: ya, we know :) | |
| 13:55:41 | jaypipes | mriedem: and yes, we will. | |
| 13:55:53 | sfinucan | jaypipes: Aye | |
| 13:56:00 | sfinucan | another +2 too, mind | |
| 13:56:29 | sfinucan | :) | |
| 13:56:31 | jaypipes | sfinucan: hmm? | |
| 13:56:43 | alex_xu | mriedem: if we have wraps for the shell, 'nova --os-compute-api-version 2.44 help' will hide the shell which isn't supported anymore. Then the user can know which commands supported in the specific version | |
| 13:57:29 | sfinucan | /bug | |
| 13:57:58 | mriedem | alex_xu: does anyone do that with the CLI? | |
| 13:58:01 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257 | |
| 13:58:02 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777 | |
| 13:58:10 | jaypipes | sfinucan: doh, apologies. for some reason I thought you or sean-k-mooney had +2'd moshele's hw-tc-offload patch :( | |
| 13:58:39 | alex_xu | mriedem: not sure :( | |
| 13:58:46 | openstack | bug 1662650 in neutron "[RFE] Advance configuration of SR-IOV ports- api extension" [Wishlist,Triaged] https://launchpad.net/bugs/1662650 - Assigned to Trevor McCasland (twm2016) | |
| 13:58:46 | sfinucan | jaypipes: Oh, I heard something about bug 1662650 before. I think that guy, Trevor, talked about it in an SR-IOV meeting ages ago | |
| 13:58:56 | edleafe | jaypipes: in meetings - added to my queue | |
| 13:58:59 | jaypipes | sean-k-mooney, sfinucan: I must have confused your +2's on the dependent patches for a +2 on that one. my apologies to you both. | |
| 13:59:11 | sfinucan | jaypipes: It's all goooood | |
| 13:59:25 | jaypipes | no, it's really not... pretty bad mistake of mine :( | |
| 13:59:36 | mriedem | jbernard: i don't know what happened in https://review.openstack.org/#/c/459832/ | |
| 14:00:54 | openstackgerrit | Stephen Finucane proposed openstack/os-vif master: Revert "hardware offload support for openvswitch" https://review.openstack.org/460120 | |
| 14:01:19 | sfinucan | jaypipes: Do we need to +2 reverts? :D | |
| 14:01:26 | jaypipes | sfinucan: no, go for it. | |
| 14:02:38 | openstackgerrit | Stephen Finucane proposed openstack/os-vif master: Standardize README https://review.openstack.org/460094 | |
| 14:03:55 | sfinucan | mriedem: Thanks for the info on https://review.openstack.org/#/c/373293/ - I'd no idea what the policy around stable/* requirements bumps was | |
| 14:04:11 | mriedem | sfinucan: it's a long and sordid tale of woe | |
| 14:04:28 | mriedem | and coincidentally as a result of the TC meeting yesterday, is going to come back up real soon in the ML | |
| 14:05:21 | mriedem | sfinucan: https://docs.google.com/presentation/d/1k0mCHwRZ3_Z8zJw_WilsuTYYqnUDlY2PkgVJLz_xVQc/edit?usp=sharing | |
| 14:05:26 | mriedem | oldy but goody | |
| 14:06:16 | bauzas | yet when it does self-heal check." ? | |
| 14:06:16 | bauzas | mriedem: dansmith: jaypipes: do you remember the exact problem that I tried to solve when I wrote "Amend RT to filter out allocations for instances that don't have a host set | |
| 14:06:39 | mriedem | bauzas: that was a race that edleafe pointed out i think | |
| 14:06:51 | bauzas | mriedem: dansmith: jaypipes: the fact that we post allocations for instances that we discover, right? | |
| 14:06:58 | dansmith | the pre-scheduling race or something? | |
| 14:07:06 | bauzas | I think so | |
| 14:07:06 | sfinucan | mriedem: niiiiice | |
| 14:07:16 | bauzas | anyway, just writing the patch, comments welcome | |
| 14:07:34 | mriedem | oh right, | |
| 14:07:35 | dansmith | like, you create an instance, don't assign the host, do create allocations, and that host deletes the allocations before building because of self-heal | |
| 14:07:42 | mriedem | because instance.host isn't set until we're in the RT | |
| 14:07:45 | dansmith | yeah | |
| 14:09:39 | bauzas | dansmith: wait | |
| 14:09:56 | bauzas | so we create allocations in self-heal | |
| 14:10:06 | dansmith | and delete them | |
| 14:10:09 | bauzas | but if we can't track it, then we delete the allocations | |
| 14:10:15 | bauzas | correct | |
| 14:10:34 | bauzas | so, we should filter out to delete the allocation, or to post it ? | |
| 14:11:11 | dansmith | not sure what you mean | |
| 14:11:21 | dansmith | we should avoid deleting it if we think we should but no host is set on the instance | |
| 14:11:36 | dansmith | like instance.host==None | |
| 14:11:56 | bauzas | we delete the allocations for instances that aren't tracked | |
| 14:12:16 | dansmith | ...right | |
| 14:12:17 | bauzas | okay, so the problem is about deleting allocations | |
| 14:12:21 | dansmith | yes | |
| 14:12:23 | bauzas | lemme see the code | |
| 14:13:13 | bauzas | I mean, can't see the race | |
| 14:13:29 | dansmith | 1. conductor creates the instance in the db, instance.host=None | |
| 14:13:40 | dansmith | 2. Conductor/scheduler/whatever creates the allocations in placement | |
| 14:13:52 | dansmith | 3. Conductor gets ready to send the instance to compute to build | |
| 14:14:07 | dansmith | 4. Compute runs self heal before that happens, sees allocations it doesn't know about, deletes them | |
| 14:14:14 | dansmith | 5. Instance arrives at compute ready to build | |
| 14:14:18 | dansmith | make sense? | |
| 14:14:23 | bauzas | ah ok | |
| 14:14:25 | bauzas | yup | |
| 14:14:37 | bauzas | no races yet, but possible race after my changes, gotcha | |
| 14:14:41 | dansmith | yes | |
| 14:16:12 | mriedem | althought, | |
| 14:16:16 | mriedem | *although, | |
| 14:16:30 | mriedem | now that you say this, i'm not sure where in the code #4 happens | |
| 14:16:45 | dansmith | hang on I'll show you | |
| 14:16:56 | bauzas | unless I'm blind, the only case where we get allocations, it's per instance | |
| 14:17:04 | bauzas | and we never delete them | |
| 14:17:19 | bauzas | only if when tracking, we removed the instance uuid | |
| 14:17:21 | dansmith | I had to find this for jaypipes a couple weeks ago | |
| 14:17:48 | bauzas | which is happening because we do get the list of instances per host | |
| 14:17:51 | dansmith | https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L873-L885 | |