| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-18 | |||
| 04:26:31 | openstackgerrit | Merged openstack/nova stable/pike: libvirt: Reduce calls to qemu-img during update_available_resource https://review.openstack.org/604039 | |
| 04:26:37 | openstackgerrit | Merged openstack/nova stable/pike: libvirt: Use os.stat and os.path.getsize for RAW disk inspection https://review.openstack.org/607544 | |
| 04:49:15 | openstackgerrit | Michael Still proposed openstack/nova master: Move a generic bridge helper to a linux_net privsep file. https://review.openstack.org/620010 | |
| 04:49:16 | openstackgerrit | Michael Still proposed openstack/nova master: Move bridge creation to privsep. https://review.openstack.org/620180 | |
| 04:49:16 | openstackgerrit | Michael Still proposed openstack/nova master: Move some linux network helpers to use privsep. https://review.openstack.org/621398 | |
| 04:49:17 | openstackgerrit | Michael Still proposed openstack/nova master: Move simple execute call to processutils. https://review.openstack.org/621527 | |
| 04:49:17 | openstackgerrit | Michael Still proposed openstack/nova master: Move interface enabling to privsep. https://review.openstack.org/621528 | |
| 04:49:18 | openstackgerrit | Michael Still proposed openstack/nova master: Move setting mac addresses for network devices to privsep. https://review.openstack.org/621529 | |
| 04:49:18 | openstackgerrit | Michael Still proposed openstack/nova master: Move interface disabling to privsep. https://review.openstack.org/622150 | |
| 04:49:19 | openstackgerrit | Michael Still proposed openstack/nova master: Move binding ips to privsep. https://review.openstack.org/622151 | |
| 04:49:19 | openstackgerrit | Michael Still proposed openstack/nova master: create_veth_pair is unused, remove it. https://review.openstack.org/624226 | |
| 04:49:20 | openstackgerrit | Michael Still proposed openstack/nova master: Create specialist set_macaddr_and_vlan helper. https://review.openstack.org/624227 | |
| 04:49:20 | openstackgerrit | Michael Still proposed openstack/nova master: Move create_tap_dev into privsep. https://review.openstack.org/624228 | |
| 04:49:21 | openstackgerrit | Michael Still proposed openstack/nova master: Move set_vf_interface_vlan to be with its only caller. https://review.openstack.org/624229 | |
| 04:49:21 | openstackgerrit | Michael Still proposed openstack/nova master: Move DHCP releasing to privsep. https://review.openstack.org/624230 | |
| 04:49:22 | openstackgerrit | Michael Still proposed openstack/nova master: Convert additional IP management calls to privsep. https://review.openstack.org/624231 | |
| 04:49:22 | openstackgerrit | Michael Still proposed openstack/nova master: Move route management to privsep. https://review.openstack.org/624232 | |
| 04:49:23 | openstackgerrit | Michael Still proposed openstack/nova master: Move additional IP address management to privsep. https://review.openstack.org/624591 | |
| 04:49:23 | openstackgerrit | Michael Still proposed openstack/nova master: Move slight bonkers IP management to privsep. https://review.openstack.org/624592 | |
| 04:49:24 | openstackgerrit | Michael Still proposed openstack/nova master: Move arping to privsep. https://review.openstack.org/624593 | |
| 05:32:08 | openstackgerrit | jiang wei proposed openstack/nova master: Update host_state's limits when specified AZ https://review.openstack.org/625755 | |
| 06:34:07 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add support matrix for Delete (Abort) on-going live migration https://review.openstack.org/625781 | |
| 08:01:18 | openstackgerrit | Andrey Volkov proposed openstack/nova master: Exclude build request instance with marker from listing https://review.openstack.org/624870 | |
| 08:15:43 | openstackgerrit | Dongcan Ye proposed openstack/nova master: Reword volume snapshot create https://review.openstack.org/623456 | |
| 08:27:07 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Allow run metadata api per cell https://review.openstack.org/624612 | |
| 09:59:48 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Add workaround to cleanup instance dir when using rbd https://review.openstack.org/618478 | |
| 10:37:21 | yan0s | Hi, I have a question about host aggregates | |
| 10:37:44 | yan0s | if I create a flavor with 2 host aggregates | |
| 10:38:27 | yan0s | then launching a VM with this flavor means that the VM maybe be launched in any of the host aggregates right? | |
| 10:42:06 | openstackgerrit | Chris Dent proposed openstack/nova master: Delete the placement code https://review.openstack.org/618215 | |
| 10:50:54 | kevko | Hi, could someone advice me on strange problem ? In nova-api log we see this --> http://paste.openstack.org/show/737545/ , but if I tcpdump that request ..apache is returning 200 OK , we have apache before as proxy ... error is presented in log every 1 minute +/- , it is intermittent ... currently I can't add my own debug messages to code because of production , and in dev I can't reproduce ... any ideas ? :( | |
| 10:57:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Migrate "reboot an instance" user guide docs https://review.openstack.org/612730 | |
| 10:57:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Rework 'resize' user doc https://review.openstack.org/625878 | |
| 10:59:38 | cdent | kevko: if you can get on the host where the nova-api is running, you might try making a request to http://lb.sddc.safedx:9696/v2.0/ports?device_id=7a26201b-2551-48e7-8fa4-2fd8e16b8fe9 to see if there's some kind of network issue from there. Also, looking in the logs of whatever is running the neutron api may be informative. It looks like somewhere along the way, either at the neutron api, or something in between, is bu | |
| 11:09:03 | kevko | cdent: if I curl it ..it is ok | |
| 11:09:13 | kevko | cdent: it is intermittent issue .. | |
| 11:10:12 | cdent | kevko: next stop any log on any host in the path between things? | |
| 11:14:29 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/rocky: Fail to live migration if instance has a NUMA topology https://review.openstack.org/625880 | |
| 11:15:59 | kevko | cdent: nothing, everything is working well if i am testing with curl or client | |
| 11:16:39 | cdent | kevko: I meant that the logs for the stuff that's on the network path of that neutron client call | |
| 11:16:57 | cdent | but I'm basically pulling at straws | |
| 11:25:00 | kevko | cdent: do you mean apache or what ? | |
| 11:25:51 | cdent | the services themselves. For example neutron-api | |
| 11:31:00 | kevko | cdent: in neutron-api is 200 ok | |
| 11:41:00 | kevko | cdent: also apache is 200 ok as proxy | |
| 11:45:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 11:55:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Address nits on I08991796aaced2abc824f608108c0c786181eb65 https://review.openstack.org/614322 | |
| 11:55:40 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Address nits on I1f1fa1d0f79bec5a4101e03bc2d43ba581dd35a0 https://review.openstack.org/614323 | |
| 12:01:37 | openstackgerrit | Jie Li proposed openstack/nova master: Add compute version 37 to support volume backed server rebuild https://review.openstack.org/625893 | |
| 13:37:47 | kevko | cdent: i think it is this issue https://github.com/requests/requests/issues/4664 | |
| 14:08:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 14:32:53 | amuller | random Q of the day - neutron allows an admin to create a network in an arbitrary project ID (openstack network create --project=%s). It seems like that option doesn't exist for 'openstack server create' | |
| 14:33:28 | amuller | and I'm getting an error: "Additional properties are not allowed (u'project_id' was unexpected)" | |
| 14:33:50 | amuller | trying to write a test that uses the nova admin client to create a server in some project ID | |
| 14:33:53 | amuller | anyone know how to do that? | |
| 14:34:09 | amuller | (I need the admin client because I'm specifying the AZ) | |
| 14:45:09 | mriedem | amuller: you want an admin to create a server in another project? nova doesn't have something for that. | |
| 14:45:35 | amuller | mriedem: yeah I was starting to realize that. The inconsistency between core OpenStack projects is sometimes baffling | |
| 14:58:52 | mriedem | gibi: regarding https://review.openstack.org/#/c/567268/36/nova/compute/api.py@3673 - when we pass allocation candidates to the port binding API in compute, where do the allocation candidates come from? the Selection object from the scheduler or the port_resource_requests from the RequestSpec? i thought it was the former. | |
| 15:01:24 | mriedem | or neither? | |
| 15:01:30 | gibi | mriedem: looking | |
| 15:02:11 | mriedem | i thought the idea was nova would pass the whole allocation request to neutron per port binding b/c the allocation request could have multiple ports in it, and neutron would need to sort that out? | |
| 15:03:48 | gibi | mriedem: So for the re-schedule would need the resource request. Becase nova needs to find out (temporarly) which RP satisfies which port's request | |
| 15:04:08 | mriedem | on a reschedule nova doesn't go back through the scheduler though | |
| 15:04:45 | mriedem | the allocation request on each alternate should work for the original resource request, so i'm not sure why we'd need to recalculate it | |
| 15:04:59 | gibi | mriedem: yeah, allocation are coming from the alternates. But that alternate still needs processed to see which port fulfilled by which RP | |
| 15:05:24 | gibi | mriedem: until https://review.openstack.org/#/c/597601/ | |
| 15:06:07 | mriedem | where in the existing series does that processing happen for reschedules? | |
| 15:06:14 | mriedem | b/c i'm still confused | |
| 15:06:55 | mriedem | i didn't think it was nova's responsibiilty to know which port request is fulfilled by which RP - i thought nova just bound the port and sent the allocation request info to neutron and neutron sorted it out | |
| 15:07:01 | gibi | mriedem: simply for the bandwidth allocation no special handling is needed | |
| 15:07:19 | gibi | mriedem: to fulling the neutron port profile with a single RP, we need special mapping for re-schedule https://review.openstack.org/#/c/619529 | |
| 15:07:49 | gibi | mriedem: yeah, that mapping is the responsible of placement, but placement is freezed, so the spec is on hold | |
| 15:08:01 | gibi | mriedem: therefore, temporarly, nova does the mapping | |
| 15:09:58 | mriedem | ok i guess this just means i need to peel the onion to figure this out | |
| 15:12:25 | gibi | mriedem: at least the handling of that mapping is in small patches already | |
| 15:14:21 | mriedem | i also dumped some comments in the reschedule patch https://review.openstack.org/#/c/619529/ since it doesn't deal with resize, and we have a blocker there | |
| 15:14:35 | mriedem | which is https://review.openstack.org/#/c/582417/ | |
| 15:15:31 | mriedem | i can't figure out why our unit/functional tests with the fake oslo messaging driver and serializer fail to serialize a request spec during resize rpc cast from conductor to compute but only for that prep_resize call, not for any of the other rpc calls we make like build_and_run_instance or select_destinations, it doesn't make any sense to me | |
| 15:16:05 | mriedem | but until we have that change, the RequestSpec is gone when compute reschedules during a resize | |
| 15:18:32 | gibi | mriedem: regarding https://review.openstack.org/#/c/619529/ it only supposed to handle re-schedule during boot, since non of the server moving operations are supported at that point of the series. More specifically non of the server move operations are supproted in the current series at all | |
| 15:19:07 | gibi | mriedem: I've added https://review.openstack.org/#/c/582417/ to my list to look at | |
| 15:22:38 | mriedem | ok. if we get to the point that we can't support move operations for these types of servers/ports, we likely need to put some blocker code in place so we don't move a server and drop/break the port qos policy | |
| 15:25:41 | gibi | mriedem: I agree. We can check if there is any port attached that has resource request and reject the move. But I haven't reached the point to write the code for supporting the move so I still believe it can be done. | |
| 15:30:50 | gibi | mriedem: Do you think, would it help if I summarize the overal plan about the bandwidth impl on the ML. Describing the order of the changes, reiterating why we need the mapping calculated in nova, describing the proposal to use neutron api extension as a feature flag? | |
| 15:31:56 | mriedem | gibi: yeah maybe for anyone that hasn't started reviewing this, which seems like no one but me so far | |
| 15:32:16 | mriedem | the reverse order definitely makes it more confusing for me to get the big picture | |
| 15:32:28 | mriedem | which is why i'm asking about how the port binding request stuff is handled in compute | |
| 15:32:30 | gibi | mriedem: OK, I can write up a review guide for that series tomorrow | |
| 15:32:45 | mriedem | you probably also saw me asking about tempest integration testing in the neutron meeting too | |
| 15:33:21 | mriedem | btw, we have merged some placement specs, the code is just feature frozen for now | |
| 15:33:49 | gibi | mriedem: the order you would like to see would lead to impossible long patch series that cannot be tested on functional or higher level until the last patch that allows booting a server is merged | |
| 15:34:20 | gibi | e.g. I cannot test any move without booting a server first | |
| 15:34:56 | gibi | mriedem: I saw the tempest test question, thanks for it. We have the plan to make integration testing, but you had a good point adding that to tempest-full | |
| 15:35:42 | gibi | mriedem: I did not push for the placement spec too hard because I was time constrained and I knew that the implementation would be blocked this cycle anyhow | |
| 15:35:51 | mriedem | we have alternatives to tempest-full / integrated gate, but that would need to be thought through | |
| 15:36:09 | mriedem | i.e. we could pick up the neutron tempest plugin in our nova-next job? | |
| 15:36:19 | mriedem | but we'd likely be running a bunch of neutron-only tests which we don't want | |
| 15:36:29 | mriedem | we could maybe whitelist what we want to run though... | |
| 15:36:51 | mriedem | with the state of the gate lately, i'm not sure how keen i am on introducing more exotic networking tests to the integrated gate | |