| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-14 | |||
| 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 | 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:19 | mriedem | and really can/should only support N-1 at most lockstep upgrades between nova/cinder and nova/neutron, | |
| 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 | aspiers | melwitt: thanks! | |
| 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: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 | mriedem | jangutter: so going back to what i asked earlier http://paste.openstack.org/show/737315/ - is that correctly capturing the plan? | |
| 16:06:00 | jangutter | mriedem: or scale up -> this is the twelve-point plan for world domination, we have everything in hand. | |
| 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: [WIP] Enable rebuild for instances in cell0 https://review.openstack.org/570203 | |
| 16:07:27 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova master: Add instance hard delete https://review.openstack.org/570202 | |
| 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 | mriedem | my enthusiasm for this spec will disappear however :) | |
| 16:23:03 | spatel | sean-k-mooney: morning.. | |
| 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: Record requester in the InstancePCIRequest https://review.openstack.org/625310 | |
| 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:24 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311 | |
| 16:56:02 | mriedem | dansmith: i think you will very much enjoy this bug fix while you're here https://review.openstack.org/#/c/619061/ | |
| 16:56:03 | mriedem | fixes the pg job, | |
| 16:56:10 | mriedem | should improve our cell mapping query by project_id code | |
| 16:56:25 | mriedem | signed off by zzzeek himself | |
| 16:56:26 | melwitt | mriedem, dansmith: should we... adjust the spec deadline because of the holidays? it kinda sucks that there's so much unactionable time between now and the deadline | |
| 16:56:31 | dansmith | mriedem: I think you very much don't know what I enjoy, apparently | |
| 16:56:51 | mriedem | dansmith: oh but there is stuff about camping and dirty cartoons in it | |
| 16:56:56 | dansmith | melwitt: the holidays come the same time every year, so I don't think this is much of a surprise | |
| 16:56:58 | dansmith | mriedem: ORLY | |
| 16:57:29 | melwitt | I don't think it's a surprise, but anyway, was just a thought | |
| 16:57:31 | dansmith | melwitt: and we've had a lot of time open for spec review, I'm not sure that extending the deadline is going to change that | |
| 16:57:31 | mriedem | melwitt: i say leave it - people have plenty of actionable time for months leading up to the freeze | |
| 16:58:10 | melwitt | ok, fair enough | |
| 16:58:29 | mriedem | melwitt: what you could do is sort out what from the bucket is stuff we should actually focus on before the freeze, and then get that out to the ML | |
| 16:58:52 | mriedem | because there is likely lots of cruft, but a few that just need another +2 or are things we should focus on in stein yet | |
| 16:58:55 | dansmith | melwitt: sorry I should have thrown a smiley on the end of that.. meant to sound snarky, not dickly :) | |
| 16:59:06 | dansmith | mriedem: ++ | |
| 16:59:21 | dansmith | help focus the last week of reviews in jan | |
| 16:59:25 | mriedem | at this point i'm mostly looking to get the amd sev and jan's thing in | |
| 16:59:33 | mriedem | i mean for things i'm actively reviewing | |