Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-14
15:27:04 jangutter mriedem: the spec does not cover the actual process of doing the backwards-incompatible changes.
15:27:06 mriedem and kuryr-k8s has a problem b/c they have plugins https://github.com/openstack/kuryr-kubernetes/blob/master/setup.cfg#L26
15:27:11 mriedem as does the agilio one
15:28:25 mriedem ooo does kuryr-k8s actually do vif translation too? https://github.com/openstack/kuryr-kubernetes/blob/master/setup.cfg#L36
15:28:45 mriedem https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/os_vif_util.py#L303
15:29:27 mriedem well, maybe that's closer to our os_vif_util
15:29:45 mriedem https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py
15:30:58 jangutter mriedem: The plan, during Stein is to use the new interfaces only for new plugins. (If I understand correctly).
15:32:04 mriedem will there be a new plugin as of https://review.openstack.org/#/c/567148/ ?
15:32:32 jangutter mriedem: in fact, enforcing the new interfaces on existing plugins (with the hairy backlevel code) is something I tried and Jay said "let's don't do that".
15:32:55 jangutter mriedem: yes and no - that plugin will be the os-vif yank out of the vrouter vif type.
15:33:43 jangutter mriedem: and no, the dominoes have not fallen, and the tag has not gotten applied to https://github.com/Juniper/contrail-nova-vif-driver/ yet.
15:34:01 mriedem by vrouter you mean this? https://github.com/Juniper/contrail-nova-vif-driver/blob/208f0d51b6e0c1c44771e96c062588a40491b09d/setup.py#L30
15:34:13 jangutter mriedem: yep - the very same.
15:34:38 mriedem so that's going to move into it's own plugin repo or something?
15:34:46 mriedem i don't know what "yank out" means here
15:34:49 jangutter mriedem: nope, it's going to be in-tree there.
15:34:58 mriedem ?
15:34:58 mriedem and why was jay opposed to backward compat
15:35:02 jangutter mriedem: https://blueprints.launchpad.net/nova/+spec/vrouter-os-vif-conversion
15:35:12 mriedem b/c it's trouble for the sake of a versioned interface that isn't going over the wire?
15:36:01 jangutter mriedem: https://review.openstack.org/#/c/572081/8/os_vif/objects/vif.py@272
15:36:02 mriedem oh i see so vrouter is still legacy
15:36:04 mriedem https://review.openstack.org/#/c/571325/6/nova/virt/libvirt/vif.py
15:36:19 mriedem unless contrail? confused...
15:36:32 jangutter mriedem: YOU ARE NOT THE ONLY CONFUSED PERSON!
15:37:03 jangutter mriedem: from what I could piece together, vrouter used to be there, then they gained vhost-user support and added ANOTHER vif.
15:37:19 jangutter mriedem: that VIF got added as an os-vif plugin.
15:37:39 jangutter mriedem: and 'vrouter' was left behind.
15:37:45 jangutter mriedem: alone and unloved.
15:38:18 mriedem so the vrouter stuff in nova legacy vif code is unused b/c if you have the contrail plugin loaded, we'll load that up first and *not* need to fallback to the legacy vif code,
15:38:32 mriedem if you do'nt have the contrail os-vif plugin installed on the system, we will use the legacy vrouter fallback
15:39:52 jangutter mriedem: the contrail plugin (as is) only does vhost-user (DPDK) plugging, not tap plugging that 'vrouter' needs.
15:40:34 jangutter mriedem: current contrail / tungsten / kernel solutions _still_ use the Nova path :-(
15:44:38 mriedem so, in stien, os-vif will add the new composable object model things, do a major release,
15:44:46 mriedem nova depends on that and starts to use it for new plugin support,
15:45:04 mriedem there will be the old and new os-vif interfaces for a full release (S->T)
15:45:08 mriedem in that time,
15:45:16 mriedem existing plugins will need to move over to the new model,
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 aspiers almost certainly require extra documentation though, and possibly extra requirements on any images which need to work with SEV+configdrive.
15:49:40 mriedem pinning how? where?
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 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:56:49 aspiers one of our qemu/libvirt gurus recommends virtio-scsi
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

Earlier   Later