Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-14
15:11:58 mriedem mdbooth: like this? https://review.openstack.org/#/c/473897/
15:12:44 mriedem https://bugs.launchpad.net/devstack-plugin-ceph/+bug/1697935
15:12:44 openstack Launchpad bug 1697935 in devstack-plugin-ceph "re-enable compute shelve tests" [Undecided,In progress] - Assigned to Eric Harney (eharney)
15:12:50 mriedem mdbooth: probably want to talk to eharney
15:12:58 mriedem jangutter: sure
15:13:56 jangutter mriedem: thanks! I am trying to make the "upgrade" sequence less vague.
15:14:23 jangutter mriedem: os-vif's two bits, the plug-in and the object model, has Nova between them.
15:15:08 jangutter mriedem: so the only sane way I see to adopt the interfaced added in the object model, would be to do three updates, or two with compat code in the middle that's hard to test.
15:15:32 jangutter mriedem: os-vif object model -> nova -> os-vif plugin
15:15:52 mdbooth mriedem: Thanks
15:19:57 openstackgerrit Merged openstack/nova master: Add DownCellFixture https://review.openstack.org/614810
15:23:15 mriedem jangutter: i'm not sure that clears up anything for me
15:23:21 mriedem my understanding is,
15:23:33 mriedem we're going to ignore backward compat for os-vif object versions,
15:23:47 mriedem make some changes to add the base reference/profile stuff in os-vif,
15:23:55 mriedem release with a major version,
15:24:05 mriedem make nova depend on that major version and start using new code from the library,
15:24:10 mriedem and then....?
15:24:13 mriedem something in train?
15:24:28 mriedem meanwhile kuryr-kubernetes just eats it?
15:25:37 jangutter mriedem: for now, the new interfaces will not break backwards compatibility just yet, they're additive...
15:26:04 jangutter mriedem: you're 100% right that the problem comes when _existing_ plugins transition to use them.
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 and why was jay opposed to backward compat
15:34:58 mriedem ?
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 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

Earlier   Later