| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-18 | |||
| 08:26:34 | openstackgerrit | Jianghua Wang proposed openstack/nova master: vGPU: XenAPI: get vgpu stats from hypervisor https://review.openstack.org/512965 | |
| 08:45:01 | openstackgerrit | jichenjc proposed openstack/nova master: Refactor placement version check https://review.openstack.org/512497 | |
| 08:49:23 | openstackgerrit | Naichuan Sun proposed openstack/nova master: VGPU_support: add enabled white list https://review.openstack.org/512580 | |
| 08:57:43 | openstackgerrit | Naichuan Sun proposed openstack/nova master: VGPU_support: add enabled white list https://review.openstack.org/512580 | |
| 09:32:10 | stephenfin | sean-k-mooney, ralonsoh: Sean brought this up at the PTG, but what bus do the on-die FPGAs on recent Xeon chips hook into? QPI? | |
| 09:33:43 | ralonsoh | stephenfin: that's what I can give you now: https://www.ece.cmu.edu/~calcm/carl/lib/exe/fetch.php?media=carl15-gupta.pdf | |
| 09:34:07 | ralonsoh | stephenfin: take a look at slide 15. As you said, is QPI | |
| 09:35:18 | stephenfin | ralonsoh: Just what I wanted. Thanks! | |
| 09:44:15 | openstackgerrit | Merged openstack/nova stable/pike: Target context for build notification in conductor https://review.openstack.org/511292 | |
| 09:48:01 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: PCI NUMA Policies https://review.openstack.org/361140 | |
| 09:52:21 | openstackgerrit | Dinesh Bhor proposed openstack/nova-specs master: Schedule VM's on default host aggregate https://review.openstack.org/512990 | |
| 10:07:36 | openstackgerrit | Jianghua Wang proposed openstack/nova master: vGPU: XenAPI: get vgpu stats from hypervisor https://review.openstack.org/512965 | |
| 10:22:31 | openstackgerrit | Michael Still proposed openstack/nova master: Cleanup mount / umount and associated rmdir calls https://review.openstack.org/494423 | |
| 10:22:32 | openstackgerrit | Michael Still proposed openstack/nova master: Move lvm handling to privsep. https://review.openstack.org/495516 | |
| 10:22:32 | openstackgerrit | Michael Still proposed openstack/nova master: Move shred to privsep. https://review.openstack.org/495537 | |
| 10:22:33 | openstackgerrit | Michael Still proposed openstack/nova master: Move xend existence probes to privsep. https://review.openstack.org/495538 | |
| 10:22:33 | openstackgerrit | Michael Still proposed openstack/nova master: Move the idmapshift binary into privsep. https://review.openstack.org/495541 | |
| 10:22:34 | openstackgerrit | Michael Still proposed openstack/nova master: Move loopback setup and removal to privsep. https://review.openstack.org/495664 | |
| 10:22:34 | openstackgerrit | Michael Still proposed openstack/nova master: Move nbd commands to privsep. https://review.openstack.org/500351 | |
| 10:22:35 | openstackgerrit | Michael Still proposed openstack/nova master: Move kpartx calls to privsep. https://review.openstack.org/500354 | |
| 10:22:35 | openstackgerrit | Michael Still proposed openstack/nova master: Move blkid calls to privsep. https://review.openstack.org/500398 | |
| 10:54:54 | openstackgerrit | Merged openstack/nova master: Remove unnecessary BDM destroy during instance delete https://review.openstack.org/510635 | |
| 10:55:05 | openstackgerrit | Merged openstack/nova master: api-ref: fix server status values in GET /servers docs https://review.openstack.org/510696 | |
| 10:55:11 | openstackgerrit | Merged openstack/nova master: Update "SHUTOFF" description in API guide https://review.openstack.org/510697 | |
| 10:55:18 | openstackgerrit | Merged openstack/nova master: Fix binary name https://review.openstack.org/501359 | |
| 10:55:24 | openstackgerrit | Merged openstack/nova master: Make etree.tostring() emit unicode everywhere https://review.openstack.org/507488 | |
| 10:55:30 | openstackgerrit | Merged openstack/nova master: Modernize set_vm_state_and_notify https://review.openstack.org/499799 | |
| 10:58:35 | openstackgerrit | John Garbutt proposed openstack/nova master: Only add CUSTOM_ prefix if required https://review.openstack.org/513001 | |
| 10:59:36 | openstackgerrit | John Garbutt proposed openstack/nova master: Only add CUSTOM_ prefix if required https://review.openstack.org/513001 | |
| 11:00:25 | openstackgerrit | John Garbutt proposed openstack/nova master: Only add CUSTOM_ prefix if required https://review.openstack.org/513001 | |
| 11:08:14 | openstackgerrit | Naichuan Sun proposed openstack/nova master: VGPU_support: add enabled white list https://review.openstack.org/512580 | |
| 11:21:22 | openstackgerrit | jichenjc proposed openstack/nova master: Refactor placement version check https://review.openstack.org/512497 | |
| 11:26:21 | sean-k-mooney | stephenfin: ralonsoh technically pcie and qpi pre skylake upi + pcie from skylake on | |
| 11:27:08 | sean-k-mooney | stephenfin: ralonsoh upi is the replacement for qpi | |
| 11:30:59 | efried | gibi Ack, thanks | |
| 11:36:45 | janki | Hi. Is there a way to know which microversion of API is used in Pike? According to https://docs.openstack.org/nova/latest/reference/api-microversion-history.html, its 2.53 but API calls shows /compute/v2.1/.. | |
| 11:44:00 | openstackgerrit | Eric Fried proposed openstack/nova master: Send Allocations to spawn https://review.openstack.org/511879 | |
| 11:44:05 | efried | gibi ^ Thanks for the find. | |
| 11:44:44 | efried | janki The microversion is in an HTTP header | |
| 11:44:57 | efried | Not the endpoint URL | |
| 11:45:31 | gibi | efried: thanks. I'm +2 now | |
| 11:45:36 | efried | gibi Thanks! | |
| 11:46:07 | efried | janki In what context are you wanting to know? The nova CLI? The openstack CLI? Some external API call? | |
| 11:48:38 | janki | efried, I am running tempest with ODL + openstack Pike and this test https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_basic_ops.py fails with 404 POST http://10.29.13.2/compute/v2.1/os-floating-ips | |
| 11:49:26 | efried | janki Do you have a link to the error trace? | |
| 11:50:05 | janki | efried, nova doc says this API is deprecated from 2.36 microversion and will return 404. Pike uses microversion 2.53. How do I know which microversion is used | |
| 11:50:15 | janki | efried, https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-pike-upstream-stateful-carbon/36/tempest/tempest_results.html.gz is the traceback | |
| 11:51:01 | janki | efried, please expand the first test which says "fail" | |
| 11:51:14 | rgerganov | efried, could you please answer my last question at https://review.openstack.org/#/c/511879/7//COMMIT_MSG | |
| 11:52:38 | efried | janki You're looking for an HTTP header like: "OpenStack-API-Version: compute 2.53". If it's not there, I *think* we default to the earliest in the API. | |
| 11:52:42 | efried | rgerganov Looking... | |
| 11:54:46 | janki | efried, so API verion is 2.1 as seen in https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-pike-upstream-stateful-carbon/36/tempest/tempest.log.gz | |
| 11:55:15 | efried | janki Is it possible that the floating IP pool actually isn't there? :) | |
| 11:56:08 | janki | efried, thats my next step to debug. I first wanted to ensure the API version. I will need tempest.conf for it and searching for that file. or is it any other way I can verify? | |
| 11:57:01 | efried | janki It's not something you can set in the config file. The microversion is per API call. Looking at the log... | |
| 11:59:09 | efried | janki It looks like that header is being returned by nova (so it's not being set by the caller) only for one call in that log, and it's not the call you're concerned about because it's a 200. | |
| 11:59:26 | janki | efried, all jenkins build logs are at https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-pike-upstream-stateful-carbon/36/ | |
| 12:01:29 | efried | rgerganov Responded, sorry I missed that the first time. I would have seen it eventually :) | |
| 12:02:15 | efried | rgerganov Let me know if you want to talk it though some more. There's a lot TBD about how drivers will model their RPs, and we especially haven't talked a lot about IP addresses as generic resources. | |
| 12:02:30 | efried | rgerganov At least *I* haven't. sean-k-mooney might know more on that front. | |
| 12:03:50 | sean-k-mooney | i heard my name :) | |
| 12:04:18 | sean-k-mooney | IP adress as a generic resource? | |
| 12:04:33 | sean-k-mooney | as in like routed network today or something different | |
| 12:04:46 | janki | efried, I dont find any api call before running this test. ANy specific file I should be looking into? | |
| 12:05:21 | efried | janki I was poking around for your n-api log, haven't found it yet. Was skimming the n-cpu log, but kinda doubt I'm going to find anything useful in there. | |
| 12:05:57 | efried | sean-k-mooney Greetings. rgerganov was asking about how https://review.openstack.org/511879 would play with IP addresses. | |
| 12:05:58 | rgerganov | efried, thanks for the response, it seems that our longstanding problem with VMW shared datastores won't get fixed any time soon :) | |
| 12:06:30 | efried | rgerganov Tell me more about the problem, if you have time. Perhaps there's a nice placement-y solution... | |
| 12:06:31 | sean-k-mooney | rgerganov: i think the intent is that if you need to boot a vm on a specifc nfs share you will associate the boot request with the nfs share by modeling the nfs share as a shared resource provider and using an aggregate to associate the hosts that can connect to that share | |
| 12:07:05 | efried | sean-k-mooney ++ | |
| 12:07:24 | efried | But note that shared RPs are not in scope for Queens. | |
| 12:07:41 | efried | Though there's some code already in place that's gonna have to be trodden carefully around. | |
| 12:08:32 | sean-k-mooney | ya thats the rub. rgerganov shared resouce providers is the feature you are looking for to correctly model vmw shared datastores | |
| 12:08:39 | rgerganov | even it is a shared RP, we still need to know how to connect to it in order to use it, right | |
| 12:09:03 | rgerganov | there should be some way for virt drivers to obtain connection info | |
| 12:09:04 | sean-k-mooney | rgerganov: yes that info can be sotred in the nova-compute agents config | |
| 12:09:30 | rgerganov | sean-k-mooney, is that some kind of static data? | |
| 12:10:16 | sean-k-mooney | rgerganov: well in the case of the the storage backend for the specific compute node yes its static | |
| 12:11:07 | sean-k-mooney | for libvirt for example by default we use the filesystemd under /var/lib/libvirt but i can configure it to use an nfs share or rbd to ceph by default instead | |
| 12:12:03 | rgerganov | sean-k-mooney, I don't think this will work well for the vmware driver | |
| 12:13:25 | rgerganov | it's hard to believe that after we added so much complexity with placement, RP, allocations, etc we can't solve a simple use case with shared datastores | |
| 12:13:46 | efried | janki https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-pike-upstream-stateful-carbon/36/control_1/n-api.log.2017-10-16-060444.gz Search for 'Floating IP' - confirms that the call is using microversion 2.1. There's a policy check failure a few lines earlier, not sure if that's related. | |
| 12:14:13 | sean-k-mooney | rgerganov: well we could but be dont have the shared resouce providers code merged yet | |
| 12:14:17 | janki | efried, ya. didnot find anything useful in cpu logs | |
| 12:14:37 | efried | rgerganov Is there some kind of API endpoint that can be queried to get the details on the NFS store? | |
| 12:14:41 | janki | efried, ya. policies is 1 of the reason for 404 as per the api doc | |
| 12:14:46 | efried | rgerganov That would be another way to do it. | |
| 12:14:48 | sean-k-mooney | if we did we coudl store info such as the ip adress as a trait on the resouce provider | |
| 12:14:51 | efried | janki Oh, then maybe that's the whole problem. | |
| 12:14:58 | efried | sean-k-mooney Just so. | |
| 12:15:30 | efried | sean-k-mooney Though I'm not sure that's a great idea. More likely you would want to maintain a mapping of RP UUIDs to configs. | |
| 12:15:52 | sean-k-mooney | efried: ya the down side to that is it is a public api... | |
| 12:16:07 | rgerganov | efried, yeah, this is what I am calling "connect info" for resource provider | |
| 12:16:10 | sean-k-mooney | at least i think it is placement is now admin only correct | |
| 12:16:17 | rgerganov | maybe the right term is just "config", idk | |
| 12:16:19 | efried | A trait like CUSTOM_NFS_SHARE_IP_192_168_0_55 is a pretty hideous thought. | |
| 12:17:01 | sean-k-mooney | efried: ya at least that was not an ipv6 address ... | |
| 12:17:12 | efried | Hah, totally | |
| 12:17:59 | efried | sean-k-mooney rgerganov As with PCI devices, we would rather maintain the specifics (like PCI address) external to placement, and have the driver responsible for mapping RP UUIDs to whatever entry in that external data store. | |
| 12:18:28 | janki | efried, POST /compute/v2.1/os-floating-ips => generated 73 bytes in 180 msecs (HTTP/1.1 404) 9 headers in 378 bytes (1 switches on core 0) - "generated" in this line means HTTP package is generated and not FIP is generated right | |