| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-19 | |||
| 19:27:30 | artom | dansmith, I guess I was thinking in the context of this overloading Neutron discussion | |
| 19:27:42 | cfriesen | dansmith: wouldn't you have separate conductors there too? | |
| 19:27:50 | artom | dansmith, but yeah, I'll shut up now ;) | |
| 19:27:53 | prometheanfire | mriedem: k, fyi, I think this will be blocking reqs updates on dogpile.cache | |
| 19:28:01 | dansmith | cfriesen: sure? but it's still twice the calls | |
| 19:28:17 | cfriesen | dansmith: for migrations in a single cell you could have the conductor get the data from neutron and then pass just the changed bits to both compute nodes | |
| 19:29:06 | mriedem | network-changed doesn't really have anything to do with the compute | |
| 19:29:12 | mriedem | so that one could be centralized | |
| 19:29:22 | dansmith | cfriesen: yes, you could have the api guess on all that and make those events different | |
| 19:29:32 | mriedem | network-vif-deleted and the vif plug/unplug ones call the driver so that's why they are on the compute | |
| 19:30:43 | mriedem | handling network-changed is an optimization that could be made at the top probably | |
| 19:30:48 | mriedem | but baby steps probably | |
| 19:31:38 | dansmith | mriedem: all events are handled by the computes now, so if you change that, you need to know which conductor (super or cell) to send events to, and then adding new things becomes a little less clear about where each is handled | |
| 19:32:10 | dansmith | making the operations that are happening less insanely heavy will yield much more benefit than cutting a big number in half in some situations | |
| 19:32:34 | mriedem | the former is what i'm trying to start with now yeah | |
| 19:32:40 | mriedem | by targeting the network-changed event to a single port | |
| 19:32:45 | mriedem | so we don't do the full nw info cache rebuild | |
| 19:32:48 | dansmith | yeah | |
| 19:33:01 | dansmith | I thought at one point we had a partial update thing like that | |
| 19:33:09 | dansmith | did we lose that or was it different? | |
| 19:33:20 | mriedem | not sure what you're referring to | |
| 19:33:31 | cfriesen | would it be reasonable for neutron to add more info about what exactly changed? (subnet, fixedip, floatingip, etc.) | |
| 19:33:47 | mriedem | cfriesen: maybe | |
| 19:33:54 | dansmith | we used to rebuild the whole cache every time and arosen did something to try to merge our networkinfo with just one change | |
| 19:34:27 | dansmith | cfriesen: you only get a tag in the event, but you could use that to signal what to refresh, yes, or have a different event like "floatingip-changed" | |
| 19:35:03 | cfriesen | even something like that could cut the number of neutron GETs down dramatically | |
| 19:35:03 | mriedem | https://review.openstack.org/#/q/owner:aaronorosen%2540gmail.com+status:abandoned+project:openstack/nova | |
| 19:35:10 | melwitt | dansmith: I put a lock around the cache access in https://review.openstack.org/465042 to address your comment | |
| 19:35:33 | dansmith | mriedem: no, this thing merged and caused a bunch of bugs, but I thought they all got squashed out | |
| 19:35:56 | dansmith | mriedem: anyway, not worth going to find it, it was 2013ish so just move on optimizing what we have now | |
| 19:35:57 | mriedem | dansmith: oh idk then, that would be like 3+ years ago now | |
| 19:36:00 | dansmith | yes | |
| 19:36:16 | dansmith | melwitt: I know, sorry | |
| 19:36:55 | melwitt | k, just in case you hadn't seen | |
| 19:37:04 | mriedem | anywho, i've got some patches to review which i promised (well didn't promise, but said maybe) i'd review, so going to do those first and then can cleanup this patch | |
| 19:39:01 | cfriesen | mriedem: dansmith: oh, and it turns out that once you have mriedem's "update the specific port" change, we don't really have any duplicate events for the same instance anymore | |
| 19:40:08 | mriedem | because they never were duplicates, | |
| 19:40:10 | mriedem | but nova just didn't know | |
| 19:40:12 | cfriesen | yeah | |
| 19:40:13 | mriedem | right? | |
| 19:42:25 | cfriesen | which actually means that the "vanilla" numbers for the neutron utilization would be much worse, since I had duplicate event removal in there. | |
| 19:42:46 | mriedem | do i get a large beer in denver for this? | |
| 19:42:52 | mriedem | s/beer/ginger ale/ | |
| 19:42:54 | cfriesen | oh, definitely | |
| 19:43:38 | melwitt | I don't understand why I would get "This change depends on a change that failed to merge." on a set where when I rebase it locally, I don't see any merge conflicts or auto-merging | |
| 19:43:50 | dansmith | melwitt: depends-on? | |
| 19:44:07 | melwitt | I don't think I have any but I'm checking again | |
| 19:44:42 | mriedem | melwitt: there used to be a thing with zuul where if you rebased a large series, it couldn't keep up with the stream of events, | |
| 19:44:46 | melwitt | yeah, I don't have any Depends-On. ugh, wtf | |
| 19:44:50 | mriedem | and you'd get a merge conflict, even though there wasn't one | |
| 19:44:59 | mriedem | i saw that happening on artom's series the otherday | |
| 19:45:06 | mriedem | it was fixed for months, but might be back | |
| 19:45:08 | mriedem | in black | |
| 19:45:16 | melwitt | okay, I think it's still a thing then. there's 18 patches | |
| 19:45:41 | artom | mriedem, you mean the tagged attach series? | |
| 19:45:48 | mriedem | artom: is there any other? | |
| 19:45:50 | artom | Yeah, anything but the bottom patch gives merge conflict | |
| 19:46:06 | artom | mriedem, it's a secret that I'll reveal when I'm ready | |
| 19:46:22 | melwitt | haha | |
| 19:46:23 | mriedem | artom "tagged attach" lifshitz | |
| 19:46:34 | mriedem | is your new name when i give credits in my album | |
| 19:46:48 | artom | Yey credits! | |
| 19:47:10 | mriedem | right next to seymour duncan pickups | |
| 19:47:54 | artom | So I'll be in the 'Tools' section, gotcha | |
| 19:47:59 | cfriesen | mriedem: you play guitar? | |
| 19:49:29 | mriedem | cfriesen: in the long ago | |
| 19:49:56 | mriedem | they sit in cases in a closet in the basement next to a box of books and yankee candles | |
| 19:49:57 | cfriesen | this guy makes fan-fret basses in my city...I've visited his shop: http://www.dingwallguitars.com/ | |
| 19:50:00 | mriedem | like a true suburbanite | |
| 19:51:15 | nic | Are there party hats? | |
| 19:51:22 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix live migration devstack hook for multicell environment https://review.openstack.org/458537 | |
| 19:51:23 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell on local delete https://review.openstack.org/464059 | |
| 19:52:36 | melwitt | haha, yup | |
| 19:53:58 | artom | Speaking of party, we're not doing Hawaiian-nick Friday? | |
| 19:54:04 | artom | Not that I ever did it, personally | |
| 19:57:16 | artom | Dammit, length limit cut off the last letter | |
| 20:01:40 | melwitt | wear a hawaiian shirt | |
| 20:01:42 | melwitt | and jeans | |
| 20:01:45 | melwitt | if you want to | |
| 20:01:57 | mriedem | except peter | |
| 20:02:01 | mriedem | he has to come in on saturday | |
| 20:02:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: nova-manage: Deprecate 'log' commands https://review.openstack.org/453176 | |
| 20:02:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: nova-manage: Deprecate 'host' commands https://review.openstack.org/453175 | |
| 20:02:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: nova-manage: Deprecate 'project', 'account' commands https://review.openstack.org/453174 | |
| 20:02:27 | melwitt | hah | |
| 20:07:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: nova-manage: Deprecate 'log' commands https://review.openstack.org/453176 | |
| 20:08:24 | mriedem | https://review.openstack.org/#/c/453174/ and up are easy +Ws | |
| 20:11:14 | openstackgerrit | Eric Fried proposed openstack/nova master: Adopts keystoneauth with glance client. https://review.openstack.org/412634 | |
| 20:15:36 | melwitt | mriedem: on the first and last of those, the bp isn't mentioned in the commit message. point being, I wondered if they are part of a bp that explains what's going on and why | |
| 20:16:19 | melwitt | the second one links to a non existing bp | |
| 20:16:27 | mriedem | the 2nd one's bp is completed | |
| 20:16:30 | mriedem | the os-hosts removal thing, | |
| 20:16:34 | mriedem | i noted it after that bp was completed | |
| 20:16:42 | mriedem | the series itself is a precursor to move-nova-cmds-to-cliff in queens | |
| 20:16:55 | mriedem | sfinucan wants to deprecate as much as possible from nova-manage before moving the infra for it over to cliff | |
| 20:17:03 | mriedem | making the work he needs to do in queens smaller | |
| 20:17:20 | mriedem | i asked him to remove the bp links for that though since it's not approved for pike, so would have been confusing | |
| 20:19:14 | melwitt | oh, I see. thanks | |
| 20:22:23 | mriedem | another easy one https://review.openstack.org/#/c/463065/ | |
| 20:23:06 | mriedem | and https://review.openstack.org/#/c/391060/ | |