Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-14
15:45:27 mriedem and then the old stuff will be dropped sometime in T with a major release of os-vif,
15:45:34 mriedem and kuryr-k8s is ok with that plan?
15:46:17 mriedem and hopefully no one is storing a serialized version of these things with the old model in a db somewhere...
15:46:32 mriedem i.e. the object model will always be recalculated at the time it's needed
15:46:53 jangutter mriedem: I don't think os-vif is needs to do a major release until we've ironed out the upgrade path -> sean-k-mooney and jaypipes will likely assign some fun stuff to me.
15:48:50 jangutter mriedem: pinning object version numbers would not break backwards compatibility?
15:49:39 aspiers mriedem: Have made some progress on your questions. More detail soon but quick summary for now is that q35 machine type doesn't support IDE which means we'll have to jump through an extra hoop or two in certain cases (configdrive defaults to iso9660 which currently means ide bus on x86_64), but given the existing virtio-scsi support I'm optimistic this won't be a big hurdle (to mix metaphors). It will
15:49:40 mriedem pinning how? where?
15:49:40 aspiers almost certainly require extra documentation though, and possibly extra requirements on any images which need to work with SEV+configdrive.
15:50:05 aspiers I think similar caveats will apply for volumes attached via IDE too
15:50:18 jangutter mriedem: i.e. not incrementing the version numbers of the objects.
15:50:57 aspiers but these caveats already apply when q35 machine type is requested via image metadata, so it's not an entirely new limitation
15:51:25 mriedem aspiers: yeah i saw that yesterday, thanks. if we're already documenting things for sev limitations, i guess saying "config drive will require vfat" which, since that's per-host today, means you'd have sev instances restricted to certain hosts - which people would probably do anyway given the reserved memory restrictions,
15:51:47 mriedem i had thought there was an image property to tell nova which config drive format to use, but i only see img_config_drive to tell nova to use config drive or not
15:51:55 mriedem maybe it's just not documented...
15:52:23 aspiers mriedem: yeah exactly, there's also the hardware requirement for SEV support they already have to consider :-)
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

Earlier   Later