Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-14
15:52:34 mriedem i guess there isn't an image property for the config drive format,
15:52:45 aspiers I didn't see one
15:52:54 mriedem we could certainly add that, seems weird that it's per-host config and not per-instance
15:52:55 aspiers it looks hardcoded to me
15:53:02 mriedem it's a config option
15:53:06 aspiers right
15:53:37 mriedem i'd like to avoid conditional logic on the type by adding things like "if SEV use vfat" etc
15:53:55 aspiers yes I agree
15:54:17 aspiers don't want to introduce any more snowflake code than strictly necessary
15:54:51 aspiers mriedem: but it made me wonder, is there any good reason why x86_64 is the only architecture still using ide for configdrive?
15:54:57 mriedem jangutter: i thought the spec said that for the new composable interface stuff there wouldn't be version changes on the object model
15:55:05 aspiers I looked at the git commit history and it seemed to be just a legacy thing
15:55:15 mriedem aspiers: idk, it could just be really old code
15:55:23 mriedem i'm not really familiar with that though, mdbooth might be more help
15:55:42 aspiers originally it was x86_64 only, and later other archs were added which couldn't use ide
15:55:50 aspiers so yeah, I think it's just really old code
15:56:14 aspiers but even if so, I'm guessing changing it would break some guests which are maybe expecting the config drive to be IDE
15:56:30 mriedem maybe,
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...?

Earlier   Later