Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-01
11:44:28 sean-k-mooney and i can debug it :)
11:45:31 stephenfin sean-k-mooney: Sounds like a blog :)
11:46:15 sean-k-mooney but i typically do most of my deve with nano or emacs and run the test by had out of habit
11:46:34 sean-k-mooney stephenfin: how about i raise you os-vif docs https://review.openstack.org/#/c/638058/4/doc/source/devref/vs-code.rst
11:47:28 sean-k-mooney i need to test that htis works properly for nova and ill write up somthing similar. i have mainly been using it on os-vif lately to debug the functional tests
12:27:51 aspiers hi folks, I found a bug in assertXMLEqual
12:28:14 aspiers I'm fixing it ... hopefully it won't show up other bugs in our tests
12:30:34 sean-k-mooney oh ? what was broken
12:40:36 aspiers sean-k-mooney: hard to explain briefly but will make sense when you see the review
12:40:39 aspiers (hopefully ;-)
12:41:07 aspiers of course I meant assertXmlEqual() - typo
12:53:54 aspiers I wonder why we invented our own xml differ
12:54:05 aspiers https://xmldiff.readthedocs.io/en/stable/api.html#main-diffing-api looks good to me
12:54:27 cdent <sparta>
12:55:06 aspiers maybe xmldiff didn't exist in 2012 when Kevin Mitchell wrote ours
12:55:51 sean-k-mooney aspiers: https://pypi.org/project/xmldiff/#history
12:56:22 sean-k-mooney it did but did not have its 1.0.0 release until 2018
12:56:48 sean-k-mooney it also did not have any release between 2005 and 2015
12:57:08 sean-k-mooney so it had been unmaintianed for 7 years at that point
12:57:51 aspiers ahah
12:58:24 aspiers Still a generic xml differ never really belonged in nova. I'm sure other projects could use one
12:58:28 sean-k-mooney ah it also looks like they did a complete rewrite form c to python between 0.6 and 1.0 so it an entirely different code base
12:58:33 aspiers Yes
12:58:36 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add "links" in the response of GET /servers/{server_id} for a down-cell instance https://review.openstack.org/640302
12:58:38 aspiers Maybe we should switch to that in the future
12:59:39 tssurya stephenfin: I fixed the nit in https://review.openstack.org/640302, but the +2 went off :( ,
13:00:07 tssurya thanks for the review
13:00:09 sean-k-mooney aspiers: yes perhaps. am i the only one who gets suspices of project with 100% test coverage
13:00:19 aspiers haha no you are not ;-)
13:00:27 sean-k-mooney for some reason it always make me trust them less
13:00:39 aspiers xmldiff has been around since 2001 https://github.com/Shoobx/xmldiff/blob/272300bb29b8c2d444971e8051aae7bf513cdb98/ChangeLog
13:00:53 aspiers although as you say it might not have been very palatable for many years
13:01:33 sean-k-mooney ya in anycase if its maintained and it works we could use it
13:01:55 sean-k-mooney that said i dont think the code is overly big ofr assertXmlEquals either
13:02:19 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add "links" in the response of "nova show" for a down-cell instance https://review.openstack.org/640302
13:03:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
13:04:41 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
13:11:18 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
13:13:35 giblet jaypipes: Hi! I've replied in https://review.openstack.org/#/c/625310/31/nova/objects/instance_pci_requests.py@39 If you still think we should rename then let me know and I will jump on it
13:15:01 jroll efried: alex_xu: this was rebased, want to re-approve? https://review.openstack.org/#/c/636326/
13:30:04 bauzas efried: alex_xu: jaypipes: others, I finally removed my -W because I'm not sure I can provide the fix for the problem I saw by this week
13:30:14 bauzas instead, I'll provide a documentation
13:35:45 efried jroll: done
13:36:01 efried bauzas: ack. My +2 is still on there... for now :P
13:36:02 jroll thanks
13:36:26 bauzas efried: heh thanks
13:36:31 efried jroll: you knew there was no way you were going to merge a patch at PS1.
13:37:02 jroll efried: so close though
13:46:20 yonglihe hope this would in reviewing queue -:) https://review.openstack.org/#/c/621476/
13:46:21 openstackgerrit Merged openstack/nova master: fix up numa-topology live migration hypervisor check https://review.openstack.org/635350
13:47:06 mriedem yonglihe: are you working on adding the related novaclient change for 2.70?
13:47:11 mriedem *2.71 i mean
13:50:49 yonglihe yeah, on my queue.
13:51:28 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640191
13:51:39 yonglihe by default , it could show up. i need to dig how to good fit to nova client, might be some documentation work i guss.
13:51:41 yonglihe guess
13:52:22 mriedem it should just work, but you have to at least bump the supported api version and it would be good to modify the fakes response in unit tests to show it in the output for nova show/update/rebuild
13:52:45 mriedem so this https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L28
13:52:54 yonglihe sure, got it.
13:53:12 mriedem the fake responses for unit tests are here https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/unit/v2/fakes.py
13:53:26 yonglihe nice, thanks.
13:53:52 mriedem so something like this https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/unit/v2/fakes.py#L647
13:53:55 tssurya mriedem, melwitt, dansmith: I have this very easy doc change on the archive nova-manage command just to clarify what max-rows means there: https://review.openstack.org/#/c/606995/. Please take a look at it when you have time,
13:54:10 mriedem yonglihe: you can check the requested microversion from the fake method and return the server_groups key in the response
13:54:48 mriedem like this https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/unit/v2/fakes.py#L2023
13:56:11 yonglihe mriedem: ok, thanks.
13:57:58 openstackgerrit Matt Riedemann proposed openstack/nova master: Update --max-rows parameter description for archive_deleted_rows https://review.openstack.org/606995
13:58:04 mriedem tssurya: done
14:14:27 fried_rice Hey folks, especially folks like sean-k-mooney: when we do a resize-to-same-host, do neutron ports get unbound and rebound or do we leave them alone?
14:15:10 fried_rice Sundar: ^
14:16:54 ttsiouts mriedem: I tried to address your comments in https://review.openstack.org/#/c/570203/. would be great to hear your feedback when you have the time. thanks in advance
14:17:26 sean-k-mooney fried_rice: i would have to check they proable are not but it might be resonable to require that they are
14:17:55 sean-k-mooney i dont htink we allow changing vif_model via flavor im pretty sure that is image only
14:19:16 fried_rice sean-k-mooney: I'm thinking it could be problematic for bandwidth resources, if there are paths in which we would end up binding to different providers somehow - the allocations would wind up screwy. giblet, have you already considered this?
14:19:30 sean-k-mooney am if the numa toplogy changes as part of a resize then in the future the bandwith allcoation might need to be updated
14:19:39 fried_rice sean-k-mooney: And in anticipation of cyborg, similarly, if we had to unbind and rebind accelerators.
14:20:22 sean-k-mooney fried_rice: well we hit the schudler as part of a resize so if the flavor chagned the device-profile for example in the cyborge case we defiently would need to rebind the device
14:20:27 giblet fried_rice: do you mean changing the flavor might affect the port allocation?
14:21:08 fried_rice giblet: actually I'm more concerned about the case where changing the flavor does/should *not* affect the port allocation/binding.
14:21:08 sean-k-mooney it may
14:21:40 fried_rice like, if all I do is increase VCPU, is it possible that I wind up with my vifs being swizzled?
14:21:44 Sundar sean-k-mooney: What about rebuild? It could be on same host or different host. In the former case, AFAIK, it is only a detach but not an unbind.
14:22:02 sean-k-mooney Sundar: rebuild is confied to the same host
14:22:07 sean-k-mooney Sundar: it will never do a migrate
14:23:06 Sundar sean-k-mooney: If the rebuild changes the image, and the new image has different traits, is that not a problem?
14:23:14 sean-k-mooney fried_rice: i think there are edgecses such as changin numa toplogy that might require it if you have sriov port or hardwar offload ovs or you use the numa aware vswitch feature
14:23:33 sean-k-mooney Sundar: we will fail the rebuild if its not valid for the current host
14:23:40 mriedem rebuild doesn't mess with port bindings
14:23:43 sean-k-mooney rebuilt with same image bypasses the scheduler
14:23:50 sean-k-mooney rebuilt with different hits the schduler
14:23:59 giblet does resize-to-same host is just allows but never forces the resize to keep the server on the same host
14:24:05 mriedem resize to same host calls the same methods to change port bindings, but i think the neutron api code we have doesn't do the update if the host doesn't change
14:24:26 mriedem https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L3230
14:25:17 sean-k-mooney giblet: right if the resize was invalid on the same host it would do a cold migraton to a vliad host if one exits in that case
14:27:03 sean-k-mooney mriedem: in princiable a rebind with a new image could contain tratis that may affect the neutro ports but in practice we have never need to cater for that case todate so ya for rebuild we have never needed to touch the port bindings
14:27:28 giblet fried_rice: to answer your original question server move operations (even resize on same host) are not covered by the current implementation so your question needs to be answered during Train
14:27:51 fried_rice giblet: Okay, good to know.
14:28:37 giblet fried_rice: my general idea regarding move is, to re-query resoruce request from neutron ports, include it to the scheduling. conductor will transparently handle migration allocation for ports then.
14:28:59 fried_rice giblet: It would be nice to prefer candidates where the ports don't move.
14:29:12 fried_rice which sounds like more hacked up matching.

Earlier   Later