Posted	Nick	Remark
#openstack-nova - 2017-05-19
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/
20:23:38	mriedem	^ is less easy i guess
20:26:25	efried	johnthetubaguy mriedem Can I get a sense of the scope of remaining work for bp/use-service-tokens-pike?
20:26:54	efried	It appears to be at least driving https://review.openstack.org/412634 to completion - but... is that it?
20:26:55	mriedem	efried: i haven't looked
20:27:11	mriedem	i think using it for glance is the big one
20:27:20	efried	Okay, cause it looks like neutron & cinder are done.
20:27:25	mriedem	yes those were done in ocata
20:27:55	mriedem	efried: or just look at the spec :) https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/use-service-tokens.html
20:28:07	mriedem	https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/use-service-tokens.html#work-items
20:28:09	efried	mriedem Well, yeah, I did that
20:28:12	mriedem	everything in there is done except for the glance one
20:28:29	efried	Okay, just making sure I understood correctly. Thanks.
20:32:45	melwitt	mriedem: hm, that reqspec delete one, the commit message points out that it's okay to delete it even if instance destroy fails. I'm thinking of a case where destroy fails, the user decides to just keep the instance around and then things will fail if they do a resize or something that will invoke the scheduler, right?
20:33:26	melwitt	bc that reqspec will be gone
20:33:53	mriedem	melwitt: did you see the comment i just put in there?
20:34:07	melwitt	I just read it a few seconds after I typed in here heh
20:34:13	mriedem	b/c i thought about that yesterday or something
20:34:19	mriedem	but just remembered to point it out
20:34:28	mriedem	we can be sure it's gone if we do a local delete,
20:34:34	mriedem	we're less sure if we cast to the compute to delete it
20:34:39	melwitt	yeah, it feels like a bit more thought should be put into it
20:35:41	mriedem	removed my +2
20:35:53	mriedem	we could delete the reqspec if we are doing a local delete in the api,

Earlier   Later