Earlier  
Posted Nick Remark
#openstack-nova - 2019-02-27
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 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:28 aspiers later we could consider calling it for other machine types
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 sean-k-mooney when i tried that a few seconds ago
14:26:57 openstackgerrit Lajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.71 https://review.openstack.org/637234
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
14:30:30 kashyap sean-k-mooney: Did you get your default filter from DevStack? (I made sure to add '1:cpu' there too)
14:30:42 sean-k-mooney yes
14:31:04 kashyap aspiers: Thanks! I've got the SEV series in my browser open.
14:31:18 kashyap ("Open in the browser" doesn't mean much, though :D)
14:31:25 sean-k-mooney at least i assume so since this was just a ubunut cloud image so anything not stadard was devstack
14:32:00 kashyap sean-k-mooney: If you got it from DevStack, you should have '1:cpu'.
14:32:07 kashyap Because I added:
14:32:08 kashyap lib/nova_plugins/functions-libvirt: local log_filters="1:libvirt.c 1:qemu 1:conf 1:security 3:object 3:event 3:json 3:file 1:util 1:cpu"
14:32:12 kashyap (In DevStack)
14:32:45 aspiers kashyap: LOL :) maybe you need this https://chrome.google.com/webstore/detail/xtab/amddgdnlkmohapieeekfknakgdnpbleb
14:32:48 sean-k-mooney kashyap: yep i have but the string in https://kashyapc.fedorapeople.org/virt/openstack/request-nova-libvirt-qemu-debug-logs.txt does not have 1:cpu
14:32:59 gibi jaypipes, efried: the fup for the bandwidth series is up-to-date and mriedem already +2 it
14:33:03 gibi https://review.openstack.org/#/c/639159/
14:33:09 jaypipes ack, on it.
14:33:14 gibi jaypipes: thanks a lot
14:33:23 kashyap sean-k-mooney: Heh, then I should update my doc :-)
14:33:34 kashyap sean-k-mooney: Okay, we're good.
14:34:05 kashyap aspiers: Haha, seems dangerous. As it destroys the illusion of productivity!
14:34:41 aspiers X-D
14:35:56 aspiers on a tangent, I wonder if I broke a world record by having 89 Chrome extensions installed
14:37:57 sean-k-mooney kashyap: looking at the libvirtd log there isnt really any useful infor there. just the same message. this is more then likely a nova issue not a libvirt one
14:39:06 jaypipes gibi: all done.
14:39:07 kashyap sean-k-mooney: Yeah, could be the way Nova is generating guest XML too
14:39:09 sean-k-mooney kashyap: this is the section fo the log around the issu http://paste.openstack.org/show/746435/
14:39:18 kashyap sean-k-mooney: Anything fun in the n-cpu.log?
14:39:55 gibi jaypipes: thanks. The rest of the series also up-to-date if you have time https://review.openstack.org/#/c/639653
14:39:58 sean-k-mooney well there was a traceback but ill check the xml that was generated on second while i grab it
14:40:55 kashyap sean-k-mooney: Thanks!
14:41:30 kashyap sean-k-mooney: Care to post the full libvirtd.log just somewhere? I'd like to see some messages above that too
14:42:04 sean-k-mooney http://paste.openstack.org/show/746436/
14:42:38 sean-k-mooney am sure i can but its got a lot of crap in it since just checked it in one of my long running dev vms
14:43:47 sean-k-mooney kashyap: looking at the xml we are not generating a pcie bus or adding a pci bridge device
14:43:55 kashyap sean-k-mooney: Ah, right; I normally just clean it up `> foo.log` and start over
14:44:36 sean-k-mooney i can truncate it can spin up another vm it will only take a second but this looks like a nova issue

Earlier   Later