Posted	Nick	Remark
#openstack-nova - 2017-04-25
16:06:56	openstackgerrit	Matt Riedemann proposed openstack/nova master: 2.43: Remove Location header from createImage and createBackup responses https://review.openstack.org/455443
16:07:29	mriedem	sdague: https://review.openstack.org/#/c/457181/
16:07:30	mriedem	for 2.44
16:07:39	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Add snapshot id to the snapshot notifications https://review.openstack.org/453077
16:07:39	openstackgerrit	Balazs Gibizer proposed openstack/nova master: explain payload inheritance in notification devref https://review.openstack.org/453667
16:07:51	sdague	mriedem: loking
16:08:32	openstackgerrit	Matt Riedemann proposed openstack/nova master: 2.45: Remove Location header from createImage and createBackup responses https://review.openstack.org/455443
16:09:42	jaypipes	sdague: done
16:11:21	openstackgerrit	Gábor Antal proposed openstack/nova master: Transform instance.volume_attach.error notification https://review.openstack.org/455801
16:14:01	sdague	mriedem: done
16:14:09	sdague	mriedem: one issue on your 2.45 patch I think
16:14:16	sdague	if you want to go look, just left review comments
16:17:29	mriedem	ok
16:19:02	mriedem	replied, i can make a change
16:20:00	sdague	mriedem: cool
16:25:04	efried	mriedem These, whenever you get a moment: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/powervm-nova-compute-driver+is:mergeable
16:25:32	efried	please and thanks
16:25:38	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Add snapshot id to the snapshot notifications https://review.openstack.org/453077
16:25:52	openstackgerrit	Balazs Gibizer proposed openstack/nova master: explain payload inheritance in notification devref https://review.openstack.org/453667
16:28:06	openstackgerrit	Matt Riedemann proposed openstack/nova master: 2.45: Remove Location header from createImage and createBackup responses https://review.openstack.org/455443
16:28:10	mriedem	sdague: ^
16:34:46	sdague	mriedem: you want to also assert the body is empty? We probably should have done that before
16:35:04	sdague	which I was thinking, but apparently forgot to write
16:35:59	mriedem	i suppose i can do that
16:36:54	sdague	just so that the 2.45 code doesn't slip back into there
16:37:15	sdague	then, I'm +2 for reals
16:44:22	openstackgerrit	Matt Riedemann proposed openstack/nova master: 2.45: Remove Location header from createImage and createBackup responses https://review.openstack.org/455443
16:44:24	mriedem	sdague: done ^
16:54:37	openstackgerrit	Gábor Antal proposed openstack/nova master: Add json style checking for sample notifications https://review.openstack.org/443677
16:55:12	openstackgerrit	Eric Fried proposed openstack/nova master: WIP/PoC: nova.utils.get_service_url(group) https://review.openstack.org/458257
16:55:52	efried	mordred jaypipes johnthetubaguy If y'all have a few minutes, I'd like to chat about the direction of this ^^
16:56:04	jaypipes	efried: yuppers. it's on my list for today.
16:56:34	efried	jaypipes Cool; just updated with some fixes, did some live testing, and I think it's working the way I want, as far as it goes.
16:57:01	efried	Before I get any further, I've got some outstanding questions.
16:57:04	johnthetubaguy	efried: yeah, my take was lets make all the bits of Nova consistent in our usage, where possible, but it looks like mordred has some alternative ideas
16:57:29	efried	johnthetubaguy I think I've isolated mordred's alternatives down to the guts of one private method.
16:57:29	johnthetubaguy	efried: I am about to go and make my dinner in a few mins though, could answer some quick questions
16:57:47	efried	What I gathered was that those suggestions involved pieces that weren't quiiite ready for primetime usage.
16:57:58	johnthetubaguy	efried: I got a similar vibe
16:57:59	efried	So I tried to make it easy for us to swap those in as/if/when they become ready.
16:58:10	johnthetubaguy	sounds like a good way forward, on the face of it
16:58:35	johnthetubaguy	if we could look like we will use the same config for both approaches, that would be good
16:58:53	efried	johnthetubaguy Oh, yeah, pretty sure that's the deal.
16:58:59	efried	But mordred may refute :(
16:59:16	johnthetubaguy	I think the config being consistent was my worry
16:59:21	johnthetubaguy	right now we are all over the place
16:59:22	efried	Please note (my) review comments on older patch sets, which enumerate some of my questions/concerns. Also some in the code comments & commit message.
16:59:24	openstackgerrit	Kaitlin Farr proposed openstack/nova master: Parse algorithm from cipher for ephemeral disk encryption https://review.openstack.org/446072
17:00:11	efried	johnthetubaguy Course, the "all over the place" conf opts will need to be addressed individually, but I think I have a neat approach for handling that.
17:00:27	efried	might be a bit too "out there"...
17:02:43	openstackgerrit	Dan Smith proposed openstack/nova master: WIP: De-complicate some of the instance delete path https://review.openstack.org/458636
17:02:44	openstackgerrit	Dan Smith proposed openstack/nova master: Make target_cell() yield a new context https://review.openstack.org/458635
17:02:44	openstackgerrit	Dan Smith proposed openstack/nova master: Move to proper target_cell calling convention https://review.openstack.org/458634
17:02:46	openstackgerrit	Dan Smith proposed openstack/nova master: Clean up ClientRouter debt https://review.openstack.org/444487
17:02:47	openstackgerrit	Dan Smith proposed openstack/nova master: DNM: Canary test against multi-cell devstack https://review.openstack.org/458537
17:03:37	johnthetubaguy	efried: I added some comments, not sure if they help
17:03:43	efried	johnthetubaguy Thanks, looking...
17:03:49	openstackgerrit	Kaitlin Farr proposed openstack/nova master: Remove deprecated keymgr code https://review.openstack.org/439855
17:10:56	openstackgerrit	John Garbutt proposed openstack/nova master: Add description to policies in floating_ip files https://review.openstack.org/459791
17:37:41	openstackgerrit	Sumedh Degaonkar proposed openstack/nova master: Adds 'sata' as a valid disk bus for qemu and kvm hypervisors https://review.openstack.org/459794
18:14:50	openstackgerrit	Matt Riedemann proposed openstack/python-novaclient master: 2.43: Deprecate novaclient /os-hosts usage https://review.openstack.org/459496
18:50:23	cfriesen	I'm updating the "flavor info in instance details" commit, and trying to figure out how to handle the new flavor dict in api-ref/source/servers.inc in terms of references to api-ref/source/parameters.yaml. Anyone have suggestions on how to handle the fact that the "flavor" field will now be a dict?
18:54:13	mriedem	cfriesen: so this right? https://github.com/openstack/nova/blob/master/api-ref/source/parameters.yaml#L2192
18:54:32	mriedem	cfriesen: they are both dicts
18:54:37	mriedem	so type is still going to be 'object'
18:54:44	mriedem	cfriesen: you could handle it one of two ways i think,
18:55:27	mriedem	1. keep flavor_server and wordsmith the hell out of the description to explain that before microversion x it's a dict with id and links keys, after microversion x it's a dict with a set of other fields
18:55:59	mriedem	2. put max_version on flavor_server to effectively cap it, and add a new parameter with min_version to introduce the new parameter description
18:56:23	openstackgerrit	Rick Bartra proposed openstack/nova master: Add policy granularity to the Flavors API https://review.openstack.org/449288
18:56:29	mriedem	cfriesen: the thing is we're probably going to want to also explain, with param descriptions, the fields in the server['flavor'] dict
18:56:56	mriedem	those would be separate paramaters, like https://github.com/openstack/nova/blob/master/api-ref/source/parameters.yaml#L2192
18:57:29	mriedem	flavor_ephem_disk, flavor_disk, flavor_is_public, etc
18:57:47	mriedem	cfriesen: just some thoughts, sdague might have opinions on this too
18:57:55	mriedem	personally i'd lean to ward option 2
18:57:59	mriedem	*toward
18:59:41	openstackgerrit	Rick Bartra proposed openstack/nova master: Add policy granularity to the Flavors API https://review.openstack.org/449288
19:05:30	mriedem	dansmith: i'm not sure if we want nullable=True on this build_request.tags field https://review.openstack.org/#/c/459569/1/nova/objects/build_request.py@53
19:05:36	mriedem	but i don't remember the rules
19:06:44	mriedem	it's not for the instance object i guess
19:06:47	mriedem	and this should probably mirror that
19:10:51	cfriesen	mriedem: okay, thanks. will proceed assuming option 2
19:13:16	cfriesen	mriedem: can I have two different "flavor_server" parameters in parameters.yaml, one with a min_version and the other with a max_version? or do I need a separately-named parameter?
19:13:30	mriedem	cfriesen: they have to have unique names
19:13:57	cfriesen	mriedem: okay, so maybe something like "flavor_server_dict"?
19:14:07	mriedem	should also be careful about changing the existing parameter in case it's used somewhere you don't expect, which isn't changing as part of your microversion
19:14:16	mriedem	flavor_server is a dict already though
19:14:20	cfriesen	true
19:14:24	mriedem	assuming you have microversion 2.46,
19:14:32	mriedem	maybe flavor_server_2_46?
19:14:49	mriedem	which matches the min_version you'll have on it
19:15:18	cfriesen	sure. the last one in is 2.43, are there others in progress for 2.44 and 2.45?
19:16:18	mriedem	yes
19:16:35	mriedem	https://review.openstack.org/#/c/455443/
19:17:34	cfriesen	kay...will adjust it.
19:18:47	cfriesen	why 2_46 instead of 2.46?
19:19:15	mriedem	can you have . in the name?
19:19:38	cfriesen	no idea. :)
19:20:01	cfriesen	I see this: - security_group.name: name
19:20:22	cfriesen	I'm easy either way
19:20:59	mriedem	security_group.name is the label in the docs

Earlier   Later