| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-14 | |||
| 14:33:23 | mdbooth | Do we have a shelve/unshelve test on rbd currently? | |
| 14:37:01 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 14:37:01 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend RequestGroup object for mapping https://review.openstack.org/619527 | |
| 14:37:02 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239 | |
| 14:37:02 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fill the RequestGroup mapping during schedule https://review.openstack.org/619528 | |
| 14:37:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240 | |
| 14:37:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529 | |
| 14:37:04 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459 | |
| 14:37:04 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 14:37:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject interface attach with QoS aware port https://review.openstack.org/570078 | |
| 14:37:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reject networks with QoS policy https://review.openstack.org/570079 | |
| 14:37:06 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421 | |
| 14:37:06 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor PortResourceRequestBasedSchedulingTestBase https://review.openstack.org/624080 | |
| 14:37:07 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ensure that allocated PF matches the used PF https://review.openstack.org/623543 | |
| 14:51:09 | mriedem | mdbooth: we have a ceph job which runs tempest tests, | |
| 14:51:13 | mriedem | and tempest has shelve/unshelve tests, | |
| 14:51:16 | mriedem | so yes we should | |
| 14:52:01 | mriedem | the ceph job has been broken since the summit though | |
| 14:52:29 | mriedem | oh maybe that was fixed and just encrypted volumes are broken | |
| 14:53:12 | mriedem | ah, so, the encrypted volume tests were just recently enabled in the ceph job | |
| 14:53:12 | mriedem | https://github.com/openstack/devstack-plugin-ceph/commit/7728027cdd575f7d43c97b4b7a9345c69898c26f | |
| 15:00:03 | mdbooth | mriedem: Just about to join a meeting, but I have a suspicion it might be broken if we're using ceph clone for glance images | |
| 15:00:28 | mdbooth | Because when you go to delete the image on unshelve it fails because the backing image is still in use. | |
| 15:02:48 | jangutter | mriedem: thanks very much for your review on https://review.openstack.org/#/c/607610/ ... at the risk of really messing up your Friday, would you have a few minutes to chat about things no-one wants to chat about? | |
| 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... | |