Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-14
15:56:49 aspiers one of our qemu/libvirt gurus recommends virtio-scsi
15:56:49 mriedem if the guest knows what it wants for the config drive format, we should really have an image property or flavor extra spec for that
15:57:07 aspiers that sounds like a good idea ot me
15:57:10 aspiers BTW I also found https://blueprints.launchpad.net/nova/+spec/virtio-scsi-by-default
15:57:19 aspiers which is per-host
15:57:29 aspiers so maybe that could help
15:57:49 aspiers well, I guess that wouldn't affect configdrive
15:57:57 jangutter mriedem: as far as I understand (and that's a follow-on question later), changing the object hash means you _should_ bump the version. we'll be changing the hash, but deciding not to bump the version.
15:57:58 mriedem "2) VMs will be able to have more than 26 volumes attached, up to 255."
15:58:05 mriedem that overlaps with a bp melwitt is working on
15:58:12 aspiers oh, interesting
15:58:18 mriedem https://blueprints.launchpad.net/nova/+spec/conf-max-attach-volumes
15:58:21 melwitt did someone say... volumes
15:58:26 aspiers :D
15:58:48 aspiers I also found caveats here https://access.redhat.com/solutions/1758693 but not sure if they still apply
15:58:55 aspiers I don't have access to the rest of that article ;-P
15:59:34 mriedem jangutter: yes you should bump the versoin whenever you change the object model
15:59:41 mriedem like new fields, new methods, method signature changes, etc
16:00:01 mriedem however, if nothing is using the os-vif objects over the wire, it's mostly just a best practice
16:00:26 mriedem so like i said on the spec, it's not the end of the world if the rules are bent during a transition here for hte library
16:00:42 aspiers mriedem: any other configdrive experts I should poll on this? just mdbooth?
16:00:46 mriedem i.e. ultimately we get the same thing from os-vif as we do from os-brick, and os-brick is just random dicts
16:01:05 mriedem we take a thing from cinder, pass it to brick, get a dict back, pass that to cinder,
16:01:13 mriedem and the vendor backends all understand what is in their special dict
16:01:14 jangutter mriedem: yes - and Jay keeps trying to get me to say that out loud in our open-plan office.
16:01:15 mriedem same thing with os-vif
16:01:34 mriedem if this channel is our open plan office, i just said it out loud
16:01:54 mriedem it makes upgrades extremely brittle,
16:02:19 mriedem and really can/should only support N-1 at most lockstep upgrades between nova/cinder and nova/neutron,
16:02:19 aspiers If the only clean way to solve this is adding a per-image property for configdrive bus, I could submit a bp/spec for that. I guess we'd also have to decide whether that's a strict dependency on the critical path to the SEV MVP, or something which can proceed in parallel.
16:02:28 mriedem but no one has cared enough yet to take that on
16:02:43 mriedem aspiers: mikal has historically been the goto config drive person
16:02:49 aspiers gotcha, thanks
16:02:55 mriedem but you would likely have to email him
16:02:57 melwitt aspiers: fwiw there's not additional caveats on the article beyond what shows in that "preview"
16:03:04 jangutter mriedem: yes - and the trouble is that os-vif, even though it's pretty new, has already gotten some crufty bits Sean and Jay wants to clean up.
16:03:04 aspiers melwitt: thanks!
16:03:35 mriedem aspiers: that doesn't need it's own bp, it would just be a work item in your existing sev spec
16:03:45 mriedem i.e. you have two options as a deployer:
16:04:04 mriedem 1. config the host(s) to use vfat for everything, and use host aggregates to pin sev instances to those hosts (you might do this anyway as noted)
16:04:20 mriedem 2. if you mix instances on hosts (sev and non-sev), then you can add an image property to control the config drive format for the sev instances
16:05:03 aspiers yup, that makes sense
16:05:10 mriedem jay is always looking to clean up crufty bits, with fire usually
16:05:39 jangutter mriedem: so the core question is - should I cut down that section (saying - the adoption plan for these interfaces will be ironed out. Promise!)
16:06:00 jangutter mriedem: or scale up -> this is the twelve-point plan for world domination, we have everything in hand.
16:06:00 mriedem jangutter: so going back to what i asked earlier http://paste.openstack.org/show/737315/ - is that correctly capturing the plan?
16:06:16 aspiers mriedem: beginning to sound like we need yet another patchset then... I feel increasingly guilty each time I submit a new one ;-/
16:06:21 mriedem jangutter: it doesn't need to be either extreme,
16:06:45 mriedem it can be "here is the proposed high-level plan, details will be ironed out during implementation"
16:06:54 mriedem but if http://paste.openstack.org/show/737315/ is the high level plan, then throw that in the spec
16:06:58 jangutter mriedem: I think, the last line is probably going to be - we'll work with kuryr to help them during the transition.
16:07:10 mriedem ok
16:07:16 mriedem then shoot the moon i guess
16:07:26 openstackgerrit Theodoros Tsioutsias proposed openstack/nova master: Add requested_networks to RequestSpec https://review.openstack.org/570201
16:07:27 openstackgerrit Theodoros Tsioutsias proposed openstack/nova master: Add instance hard delete https://review.openstack.org/570202
16:07:27 openstackgerrit Theodoros Tsioutsias proposed openstack/nova master: [WIP] Enable rebuild for instances in cell0 https://review.openstack.org/570203
16:07:58 aspiers mriedem: regarding IDE attached volumes I'm thinking that this could just be a documented limitation, similarly to the boot disk limitation against virtio-blk
16:08:21 aspiers I don't think there are any other limitations re. volumes but still confirming that
16:08:39 jangutter mriedem: many, many, many thanks. And one more indulgence.
16:09:13 jangutter mriedem: Looking at ovo I didn't find good docs describing the effects of inheritance and composition on object versions....
16:09:29 mriedem jangutter: they probably don't exist
16:09:30 jangutter mriedem: composition's always been "use a map" or something.
16:09:44 mriedem jangutter: i will have to defer to dansmith on that
16:10:00 jangutter mriedem: before I forget all of this and have to relearn it -> where would the best place be to commit it, onto the ovo docs?
16:10:25 mriedem probably yeah
16:10:45 mriedem https://docs.openstack.org/oslo.versionedobjects/latest/user/index.html
16:11:31 jangutter mriedem: thanks, I'll jot up my notes, fall into a Christmas coma, wake up and try to figure out what this madman wrote. Thanks very very very much for braving the madness.
16:15:04 mriedem jangutter: so, are you going to update the spec at all today? or should i just approve and you'll follow up or...?
16:15:26 mriedem b/c i'm here next week but gone the week of xmas, and then back the first week of jan but out the week of jan 10
16:15:37 mriedem jan 10 is spec freeze
16:16:16 mriedem jangutter: if you're just going to follow up on the spec with clarifications and cleanups, but no major technical changes in direction, i'll just approve now and you can follow up
16:16:25 jangutter mriedem: I'm respinning today with the changes, even in a coma I have some limited brain function.
16:16:44 mriedem ok
16:17:31 jangutter mriedem: I'm not going to disappear, but I won't be on 24/7.
16:23:03 spatel sean-k-mooney: morning..
16:23:03 mriedem my enthusiasm for this spec will disappear however :)
16:23:23 mriedem i want to be this lady when i grow up https://deadspin.com/phoenix-woman-dunks-on-suns-owner-robert-sarver-at-city-1831084576
16:23:39 spatel sean-k-mooney: I am seeing these errors in my nova.log on compute node: every minute duration..
16:23:41 spatel ostack-compute-sriov-01 nova-compute:2018-12-14 11:22:22.161 40288 WARNING nova.pci.utils [req-0d87b5e4-6ece-4beb-880c-51c7c5835a66 - - - - -] No net device was found for VF 0000:03:09.0: PciDeviceNotFoundById: PCI device 0000:03:09.0 not found
16:24:23 spatel Everything working great just trying to understand WARNING mesg..
16:32:45 aspiers mriedem: BTW thanks a lot again for your continued patience and help :) I can probably submit an updated patchset in the next few hours if you think that makes sense?
16:38:51 mriedem aspiers: sure, but you're still waiting on volume-backed support test results or...?
16:39:10 lyarwood mriedem / melwitt ; https://review.openstack.org/#/c/618478/ - quick question about this workaround, is it going to need a releasenote and if so which section should I use? I'm assuming `issues` but the docs suggest that's only used towards GA.
16:39:28 mriedem other
16:39:38 lyarwood kk, I'll sort that out now.
16:39:51 aspiers mriedem: not test results - just confirmation that there are no other bus-related limitations with q35
16:40:15 mriedem lyarwood: note that my responding to you does not imply me wanting that change :)
16:40:17 aspiers mriedem: we've already proven the ide issue (although that hardly required proof)
16:41:13 lyarwood mriedem: yeah I know, I know, it's garbage...
16:41:30 mriedem lyarwood: it doesn't mean *you're* garbage though!
16:41:38 lyarwood mriedem: awww thanks
16:42:02 melwitt lol
16:45:16 dansmith mriedem: splattered some more comments on your spec if you want to try to read those before I fade into holiday
16:45:46 dansmith mriedem: I guess at this point, the plan just needs to try like real hard to get that merged the first week in january before you disappear and the spec deadline comes eh?
16:51:10 mriedem dansmith: yeah
16:51:49 dansmith well, if I don't come back next year, I wish you luck
16:51:58 mriedem thank you
16:53:23 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
16:53:23 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
16:53:24 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311

Earlier   Later