Posted	Nick	Remark
#openstack-nova - 2017-09-03
23:35:19	openstackgerrit	Tetsuro Nakamura proposed openstack/nova master: Do not set vcpu_pin elements when virt_type=qemu https://review.openstack.org/465160
23:58:44	openstackgerrit	Hesam Chobanlou proposed openstack/nova master: Update docs to include standardization of VM diagnostics https://review.openstack.org/500408
#openstack-nova - 2017-09-04
00:03:52	openstackgerrit	Hesam Chobanlou proposed openstack/nova master: Update docs to include standardization of VM diagnostics https://review.openstack.org/500408
00:06:36	openstackgerrit	Hesam Chobanlou proposed openstack/nova master: Update docs to include standardization of VM diagnostics https://review.openstack.org/500408
00:31:08	openstackgerrit	Chris Dent proposed openstack/nova master: WIP: [placement] POST /allocations to set allocations for >1 consumers https://review.openstack.org/500073
00:31:09	openstackgerrit	Chris Dent proposed openstack/nova master: Move project_id and user_id to Allocation object https://review.openstack.org/500410
00:57:07	openstackgerrit	Takashi NATSUME proposed openstack/nova-specs master: Update a URL https://review.openstack.org/489028
01:25:53	openstackgerrit	Jackie Truong proposed openstack/python-novaclient master: Add trusted_certificates parameter https://review.openstack.org/500396
01:49:18	openstackgerrit	Jianghua Wang proposed openstack/nova master: XenAPI: deprecate image handler class path option https://review.openstack.org/497201
01:58:18	openstackgerrit	Tetsuro Nakamura proposed openstack/nova master: fix server creation error using az name with ':' https://review.openstack.org/490722
06:14:06	openstackgerrit	Jackie Truong proposed openstack/python-novaclient master: Microversion 2.54 - Add trusted_certificates param https://review.openstack.org/500396
06:24:59	openstackgerrit	Ildiko Vancsa proposed openstack/nova master: Tweak connection_info translation for the new Cinder attach/detach API https://review.openstack.org/493324
06:24:59	openstackgerrit	Ildiko Vancsa proposed openstack/nova master: Add attachment_complete call to volume/cinder.py https://review.openstack.org/493323
06:25:00	openstackgerrit	Ildiko Vancsa proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
06:25:02	abhi89	melwitt: can you please review https://review.openstack.org/#/c/485121/
06:47:03	openstackgerrit	Takashi NATSUME proposed openstack/nova master: Update contributor guide for Queens https://review.openstack.org/500454
07:20:15	jichen	alex_xu: thanks a lot
07:20:28	alex_xu	jichen: np
07:26:38	openstackgerrit	Merged openstack/nova master: doc: link to placement api-ref and history docs from main index https://review.openstack.org/498977
07:30:46	openstackgerrit	Merged openstack/nova master: doc: link to versioned notification samples from main index https://review.openstack.org/500081
07:40:22	maciejjozefczyk	tonyb: Hello Tony, Do you have a minute to look at https://review.openstack.org/#/c/494974/ ? Its already merged down to pike.
07:47:25	gibi	good morning nova
08:06:10	stephenfin	o/
08:34:07	openstackgerrit	Thomas Bechtold proposed openstack/nova master: Handle deleted instances when refreshing the info_cache https://review.openstack.org/398308
08:41:06	bauzas	good morning Novaers
08:58:30	openstackgerrit	Thomas Bechtold proposed openstack/nova master: Handle deleted instances when refreshing the info_cache https://review.openstack.org/398308
09:01:24	openstackgerrit	Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add plugin names as constants. https://review.openstack.org/500111
09:38:29	sean-k-mooney	stephenfin: o/
09:38:54	sean-k-mooney	stephenfin: just looking at https://review.openstack.org/#/c/480616/
09:39:42	sean-k-mooney	stephenfin: well at https://bugs.launchpad.net/nova/+bug/1698010 in general
09:39:43	openstack	Launchpad bug 1698010 in OpenStack Compute (nova) "neutron-based instances should not use the nova-network 'dhcp_domain' option" [High,In progress] - Assigned to Stephen Finucane (stephenfinucane)
09:41:08	openstackgerrit	Stephen Finucane proposed openstack/nova master: Assume neutron auto_allocate extension's enabled https://review.openstack.org/480674
09:41:08	openstackgerrit	Stephen Finucane proposed openstack/nova master: Add '_has_dns_extension' function https://review.openstack.org/480675
09:41:09	openstackgerrit	Stephen Finucane proposed openstack/nova master: Add '_has_qos_queue_extension' function https://review.openstack.org/500010
09:47:08	sean-k-mooney	stephenfin: if i recall correctly my do not return an fqdn comment was related to the fact that _get_hostname should return a hostname not an fqdn which is what it actully does today
09:48:42	stephenfin	sean-k-mooney: Yup, that's what I was thinking
09:49:05	stephenfin	sean-k-mooney: I've posted the question to openstack-dev. You might take a look if you get a chance
09:51:12	sean-k-mooney	stephenfin: by the way i would have to check but i thikn the dns extention has an fqdn field in it wihc would allow you to skip the compostion your are doing in https://review.openstack.org/#/c/480616/5/nova/api/metadata/base.py and just use the precaluated value. if returning an fqdn is the correct action for _get_hostname as it is used today
09:51:42	stephenfin	sean-k-mooney: Oh, really? Good to know. Can you stick that in the review, if you haven't done so?
09:52:50	sean-k-mooney	am sure though it would likely change the earlier revies so you stored the fqdn but ill check an leave a review comment to that effect
09:53:01	stephenfin	(y)
09:54:13	sean-k-mooney	stephenfin: https://docs.openstack.org/mitaka/networking-guide/config-dns-int.html the relevent part is about a tenth of the way down
09:54:16	sean-k-mooney	| dns_assignment | {"hostname": "my-port", "ip_address": "10.0.1.3", "fqdn": "my-port.example.org."} |
09:54:18	sean-k-mooney	| dns_name | my-port
09:58:33	stephenfin	:548
10:10:52	sean-k-mooney	:548?
10:14:22	openstackgerrit	Stephen Finucane proposed openstack/nova master: WIP! metadata: Don't use nova-net DNS values with neutron https://review.openstack.org/480616
10:14:23	openstackgerrit	Stephen Finucane proposed openstack/nova master: Store dns_domain value from neutron https://review.openstack.org/480676
10:22:33	openstackgerrit	Stephen Finucane proposed openstack/nova master: doc: Add contents page https://review.openstack.org/498820
10:22:33	openstackgerrit	Stephen Finucane proposed openstack/nova master: docs: Rename cellsv2_layout -> cellsv2-layout https://review.openstack.org/498821
10:22:34	openstackgerrit	Stephen Finucane proposed openstack/nova master: doc: Add configuration index page https://review.openstack.org/498818
10:22:34	openstackgerrit	Stephen Finucane proposed openstack/nova master: doc: Cleanup of existing index pages https://review.openstack.org/498819
10:22:35	openstackgerrit	Stephen Finucane proposed openstack/nova master: doc: Add user index page https://review.openstack.org/498817
10:25:36	stephenfin	sahid: RE: https://review.openstack.org/#/c/472633/, I still don't agree, I'm afraid. I'm not blocking it but I can't +2
10:25:49	stephenfin	Think my comments are still valid
10:29:05	sean-k-mooney	stephenfin: sahid eek im not sure https://review.openstack.org/#/c/472633 is a good idea
10:29:40	stephenfin	sean-k-mooney: Do tell?
10:30:17	sean-k-mooney	stephenfin: sahid looked memory cannot be swapped out by the kernel even when the host is running out of memory. the limit is there to prevent a memory leak in the guest or a malitious guest form exauxting the host memory and crashing the host
10:31:18	sahid	sean-k-mooney: yes we know that, but we don't have any way to compute the necessary amount of memory needed by QEMU
10:31:57	sean-k-mooney	we can put a better upper bound then infinity though
10:32:21	sahid	sean-k-mooney: like which one?
10:33:01	sean-k-mooney	its rather arbitry but memory request + 1G would be better. the hard limit is there to account for qemu overhead. 1G is overkill but again better the infinity
10:33:52	sahid	sean-k-mooney: not sure that is make sense since that 1G can run out of memory
10:34:26	sean-k-mooney	sahid: its true it can but only if the reserved memory on the host is less then 1 GB
10:35:17	sahid	yes but you also are adding a limit which can make the process to be killed for any reason
10:35:56	sean-k-mooney	sahid: well if the host is really running out of memory even with locked memory the OOM killer willl possibly do that anyway
10:36:08	sahid	are you sure that 1G is enought for QEMU if running a virtual machine of 128GB?
10:36:27	sahid	ans what about 256GB?
10:36:50	sahid	basically we try to follow with that patch what libvirt is doind right now
10:37:01	sean-k-mooney	sure not but it is a qusteion that i would like to ask the qemu comunity to comment on or make it a config option rather then a hardcoded limit
10:37:06	sahid	this patch is fixing a bug in older version of libvirt
10:37:38	openstackgerrit	Merged openstack/nova master: doc: fix online_data_migrations option in upgrades doc https://review.openstack.org/500124
10:38:50	sahid	sean-k-mooney: https://www.redhat.com/archives/libvir-list/2017-March/msg01092.html
10:39:40	sean-k-mooney	9Yetabytes is likely too much. 1G might be too small but im not convicned of that.
10:40:07	sean-k-mooney	sahid: yes the "Use with extreme care" bit is why im not sure its a good idea to do this by default with locked memory in openstack
10:40:31	sean-k-mooney	ill be back soon have to go to scrum
10:42:05	sahid	sean-k-mooney: it's the current behavior with newer version of libvirt, that patch is fixing an issue for older version. since we do not have any way to compute the necessary amount of memory needed by QEMU we can't arbitrary set a limit
10:59:57	kashyap	mdbooth: When you get a moment, this is in your wheelhouse. Would appreciate your view - https://review.openstack.org/#/c/498983/
11:00:34	mdbooth	Why does that ring a bell?
11:05:49	sean-k-mooney	sahid: if the intent of the path is just to match the bevavior of new libvirt i guess that is ok. can you add a release not with a security section thoguh for this in https://review.openstack.org/#/c/472633
11:06:52	sean-k-mooney	sahid: incidentally what happens today if you just dont set the hardlimit in the xml at all?
11:09:17	sahid	sean-k-mooney: libvirt is going to add it for you
11:10:03	sahid	sean-k-mooney: seems reasonable to have a reno note yes, let me update the patch
11:10:12	sean-k-mooney	sahid: and for new libvirt its unlimited and old it used to add a gig memKB = virDomainDefGetMemoryTotal(def) + 1024 * 1024;
11:11:41	sean-k-mooney	ok if there is no other way to calulate a safe hard limit the i guess this is the best we can do
11:12:06	sahid	sean-k-mooney: not sure to have understand, for old libvirt that is not set at all where it's something mandatory when memory is locked on host
11:12:27	sahid	for new libvirt it's set when you do not have specifically set it in domain XML
11:13:06	sahid	sean-k-mooney: yeah, thanks.. let me update the patch to add a reno note and see if that is going to make moving things
11:13:29	sean-k-mooney	oh i taught the hard_limit was optional for some reason... any way the effect of your patch is to make the behavior the same regradless of the libvirt you are using
11:13:52	sahid	exactly
11:14:23	sean-k-mooney	well from a debuging perspecitve that alone is a good thing
11:44:41	sean-k-mooney	stephenfin: i need to check the placement code again but currently when making a placement alocation can i say which specific resouce from a resouce pool i am allocating
11:46:09	sean-k-mooney	stephenfin: i.g. for a 8 core cpu can i allocate core 1 and 7 to a vm or can i only allocate 2 cores to a vm? with nested resouce providers that is.
11:46:39	sean-k-mooney	stephenfin: i belive we will be able to do the former correct
11:53:39	openstackgerrit	Balazs Gibizer proposed openstack/nova stable/pike: reno: mention that customer resource are not supported https://review.openstack.org/500521
11:59:41	ps_jadhav	gegelio
12:22:30	openstackgerrit	OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/500011
12:41:02	stephenfin	sean-k-mooney: Sorry - was gone for lunch
12:41:52	stephenfin	sean-k-mooney: To the best of my recollection, you won't be able to do anything as specific as that. We won't be doing things like handling PCI-NUMA affinity in placement - that'll all remain a compute-node level operation
13:06:57	kashyap	stephenfin: Crazy nit - I accidentally noticed -- you asked for lower-casing of Nova here. Shouldn't the 'N' in Nova always be in caps? - https://review.openstack.org/#/c/476188/3/doc/source/user/serial_console.rst

Earlier   Later