Earlier  
Posted Nick Remark
#openstack-nova - 2019-02-27
12:58:27 sean-k-mooney how do people feel about backporting https://review.openstack.org/#/q/topic:bug/1751923+(status:open+OR+status:merged)
12:59:46 sean-k-mooney mriedemn asked me to hold off for a while a when it merged but i have a downstream customer asking for this so im wondering if i should backport upstream or not?
13:01:18 sean-k-mooney i wont get around to starting the backport untill next week but input would be welcome.
13:03:13 tssurya stephenfin: I had a small doubt here: https://review.openstack.org/#/c/634600/9 regarding the doc samples; could you confirm ?
13:09:41 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
13:13:31 sean-k-mooney tssurya: assuming you are correct that means we are missing a gate job to build the api samples
13:13:49 tssurya sean-k-mooney: yea that's what I think so too
13:14:33 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
13:14:33 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311
13:14:34 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance to make place for port healing https://review.openstack.org/637953
13:14:34 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
13:14:35 openstackgerrit Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.openstack.org/637955
13:14:35 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance (2) https://review.openstack.org/637954
13:14:36 openstackgerrit Balazs Gibizer proposed openstack/nova master: cache neutron ports in heal allocation https://review.openstack.org/638207
13:15:14 sean-k-mooney i have never actully built the api-sampels personally so i dont know the answer to your question but ya my takeaway from that question is we shoudl fix them if need and add a gate job in the same patch to prevent future regressions
13:16:34 tssurya sean-k-mooney: yea thanks
13:21:38 artom tssurya, I think the stuff under doc/ is generated automatically, don't remember how though, it's been forever since I played with that..
13:22:13 artom Hrmm, although Matt had to add them manually in his path here https://review.openstack.org/#/c/631948/
13:22:22 artom OK, I have no idea, ignore me
13:25:45 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add remove_resources_from_instance_allocation to report client https://review.openstack.org/639653
13:25:46 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
13:25:46 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421
13:25:47 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
13:25:47 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311
13:25:48 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance to make place for port healing https://review.openstack.org/637953
13:25:48 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
13:25:49 openstackgerrit Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.openstack.org/637955
13:25:49 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance (2) https://review.openstack.org/637954
13:25:50 openstackgerrit Balazs Gibizer proposed openstack/nova master: cache neutron ports in heal allocation https://review.openstack.org/638207
13:40:24 tssurya artom: oh he added them manually ?
13:41:02 tssurya I was actually trying to review this: https://review.openstack.org/#/c/621474/26 and some things seemed off when added manually like the test samples and doc samples didn't match
13:41:35 tssurya anyways thanks artom I am confused too at this point
13:46:38 mriedem tssurya: from your question in https://review.openstack.org/#/c/634600/ it sounds like a bug if you want to report one and push a fix
13:54:14 tssurya mriedem: ack will do
13:54:52 mriedem also, nice review on https://review.openstack.org/#/c/621474/
13:55:18 tssurya :)
13:58:39 gibi mriedem: fixed your comments in https://review.openstack.org/#/c/622421 and split out the report client change to a separate patch
14:00:01 gibi mriedem: the fup is also up to date https://review.openstack.org/#/c/639159
14:00:09 mriedem ok
14:01:01 gibi I have to spend the rest of the afternoon in downstream land so let's communicate via the code reviews :/
14:01:13 mriedem fare thee well
14:01:32 gibi mriedem: thanks I will try :)
14:13:31 sean-k-mooney mriedem: o/
14:14:37 mriedem ~o~
14:14:46 sean-k-mooney mriedem: i asked this before you joined today but do you still want me to hold off on backporting https://review.openstack.org/#/q/topic:bug/1751923+(status:open+OR+status:merged) upstream? i will need to start backporting them downstream next week but i would prefer to do it upstream
14:15:56 mriedem sean-k-mooney: if you're going to do the backport work anyway, can you start it upstream and then cherry pick the upstream backports for your downstream work? knowing that the upstream backports might sit awhile to bake
14:16:26 mriedem i'm not comfortable landing that on stable before it's been released on master and someone like cern or vexxhost has run them yet
14:16:37 sean-k-mooney yep i can do that. i was jsut not sure if you wanted me to avoid backporting them upstream in general
14:17:22 sean-k-mooney is it the data migrtation script that you are most concerned about or the force refesh patch in general
14:17:50 mriedem the data migration script
14:18:33 sean-k-mooney ya technically that is optional and only required for old instnaces that do not alreay have a vlue poplulated in the virtual interfaces table
14:18:45 mriedem i probably won't be comfortable with that on backports upstream until cern has run it
14:18:46 sean-k-mooney i rased that as a conern downstream too
14:18:48 mriedem since it hits all of the cells
14:19:41 aspiers kashyap: you around? I have an idea of how to move forward with getDomainCapabilities()
14:19:54 kashyap aspiers: Yes
14:19:58 kashyap aspiers: Shoot
14:20:00 sean-k-mooney ya from a down stream perspecitve we are going ot have to test this carfully for FFU also
14:20:34 aspiers I think it would be good enough for now if we call it once per arch, using the default machine type for that arch specified by hw_machine_type
14:21:27 kashyap aspiers: Yeah. How many arches is SEV supported, BTW?
14:21:28 aspiers later we could consider calling it for other machine types
14:21:28 sean-k-mooney mriedem: what im hoping to do is get the patches inplace next week so we can do some addtional testing before wew fully decided if we will apply the patch. thanks for clarifing :)
14:21:38 aspiers kashyap: only x86_64 I think
14:22:06 kashyap aspiers: Thought as much. Yeah, for now, let's go the x86_64 route, document it in the conf file / wherver appropriate
14:22:22 aspiers kashyap: so the memoized _domaincaps would be a nested dict of dicts like I mentioned the other day
14:22:28 sean-k-mooney aspiers: you can set the machive type in the image_metadata too
14:22:37 kashyap sean-k-mooney: Yes, that's what I'm getting at
14:23:01 aspiers sean-k-mooney: sure, but right now there is nothing in domain capabilities which would need to influence that
14:23:05 kashyap $ openstack image set \
14:23:06 kashyap --property hw_machine_type=x86_64=q35 Fedora-29-Template
14:23:20 kashyap aspiers: Aside, ^ have you tested the above with Git master?
14:23:50 aspiers kashyap: have I tested setting image props?
14:23:52 kashyap Yes
14:23:55 aspiers no
14:23:58 kashyap (Asking because, I got a bug report, albiet for an older release, that the above isn't working. I'm still suspicious of the bug report.)
14:24:03 aspiers ah OK
14:24:20 kashyap I asked the reporter to get me the logs, and libvirt debug log (with filters), etc. So I can see what's going on.
14:24:53 aspiers kashyap: so I'm suggesting something like (effectively) self._domaincaps['x86_64']['q35'] = <XML tree object>
14:24:54 kashyap "Seeing is believing." Because too many times I got burnt by taking the word of the bug reporter
14:25:01 aspiers haha yeah :)
14:25:08 kashyap ... only to see in the logs that they misconfigured or did a blatant no-op
14:26:09 openstackgerrit Lajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.70 https://review.openstack.org/637234
14:26:27 kashyap aspiers: BTW, just saw the comment in the review (and the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1683471)
14:26:28 openstack bugzilla.redhat.com bug 1683471 in libvirt "getDomainCapabilities claims SEV is supported for pc-i440fx-1.4 machine type" [Unspecified,New] - Assigned to libvirt-maint
14:26:47 sean-k-mooney kashyap: i got libvirtError: XML error: No PCI buses available
14:26:53 kashyap (I see you filed it yourself, though)
14:26:57 openstackgerrit Lajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.71 https://review.openstack.org/637234
14:26:57 sean-k-mooney when i tried that a few seconds ago
14:27:01 kashyap sean-k-mooney: Ah, on Git master?
14:27:07 kashyap sean-k-mooney: So something is broken :-(
14:27:15 aspiers kashyap: yes :)
14:27:24 kashyap sean-k-mooney: Can you add the log filters I noted in the second bullet here:
14:27:27 kashyap https://kashyapc.fedorapeople.org/virt/openstack/request-nova-libvirt-qemu-debug-logs.txt
14:27:37 kashyap sean-k-mooney: And then re-post the complete libvirt debug log somewhere, if you can...
14:27:41 sean-k-mooney on f77791954d8a39652ea30ccf51968886471de612 form master
14:27:46 aspiers kashyap: does that dict of dicts make sense to you? it allows for calling getDomCaps on more machine types in the future
14:28:02 aspiers and at least one per arch for now
14:29:04 kashyap aspiers: Yeah, it does make sense to me. (As we future-proofed it.)
14:29:39 aspiers kashyap: OK great, I'll update the patch to do that and test it on a real SEV machine
14:29:51 sean-k-mooney kashyap: the only difference form the default filter on ubunut is the also have 1:cpu

Earlier   Later