Earlier  
Posted Nick Remark
#openstack-nova - 2021-07-06
16:29:24 gibi gmann: ack
16:30:21 gmann thanks
16:34:41 sean-k-mooney brb
16:36:58 stephenfin gmann: Apologies for inflicting unnecessary pain on you there. The warning seemed like the only way to get people to use the new thing, but it is very noisy to be fair
16:37:16 stephenfin i.e. https://github.com/openstack/oslo.policy/blob/3.7.0/oslo_policy/policy.py#L1538
16:37:57 gmann stephenfin: yeah, I am updating all the current usage for those warning https://review.opendev.org/q/topic:%22fix-oslo-policy-warnings%22+(status:open%20OR%20status:merged)
16:38:34 gmann stephenfin: and once we merge all these then I am thinking to convert it to error from oslo side so that all the DeprecatedRule usgae in new RBAC work will be proper
16:39:03 opendevreview Merged openstack/nova-specs master: Repropose "vm-boot-with-unaddressed-port" spec https://review.opendev.org/c/openstack/nova-specs/+/793199
16:49:00 sean-k-mooney ralonsoh: stephenfin: https://review.opendev.org/c/openstack/nova/+/799680 so it looks that os-vif patch works well
16:49:25 sean-k-mooney i modified the nova live migration and grenade jobs to use it
16:50:16 ralonsoh sean-k-mooney, do you think we need to add more testing? to add more tempest tests?
16:50:21 ralonsoh just for the spec
16:51:29 sean-k-mooney i think the exising jobs can be configured to cover the different cases. e.g. we can test ovn with per port bridges in nova-livemigration but use ml2/ovs with iptables in nova-livemigration-ceph
16:52:02 sean-k-mooney ralonsoh: i would hope that neutron has a live migration jobs too where it can be enabled.
16:52:11 ralonsoh sean-k-mooney, btw, I think you should add neutron dependency to this patch
16:52:23 sean-k-mooney on the os-vif side i may add a grenade job
16:52:35 sean-k-mooney ralonsoh: against which patch? the spec?
16:52:43 ralonsoh this nova patch
16:53:09 sean-k-mooney sorry can you rephase that
16:53:12 ralonsoh changing when we send the plugged event
16:53:15 ralonsoh but of course
16:53:22 ralonsoh we need Nova to accept this
16:53:32 ralonsoh nevermind
16:53:34 sean-k-mooney oh right that is a sperate change
16:53:46 ralonsoh ok, I'll push Neutron patch first
16:54:10 sean-k-mooney the corrent nova behavior is to just not wait for ovn in prelive migration
16:54:26 ralonsoh exactly and wait for the port plug event
16:54:28 sean-k-mooney so once your neutron patch is up we can add a nova one that will make it start waiting
16:55:24 sean-k-mooney ping me when the neutorn patch is up if you would like me to write the nova one. its should not be that hard but i probaly will not get to it until monday
16:55:45 ralonsoh sean-k-mooney, sure, tomorrow
16:58:26 sean-k-mooney ralonsoh: no worries its getting late for you
17:26:53 stephenfin sean-k-mooney: https://review.opendev.org/c/openstack/os-vif/+/798055 looks pretty good. If you've time to address my comments tonight I'll +2 in the AM
17:28:19 sean-k-mooney stephenfin: am i want to poc something else this evening but ill adress it tomorow
17:35:43 opendevreview Merged openstack/placement master: Fix oslo policy DeprecatedRule warnings https://review.opendev.org/c/openstack/placement/+/799418
18:16:30 opendevreview Merged openstack/nova master: Fix oslo policy DeprecatedRule warnings https://review.opendev.org/c/openstack/nova/+/799422
18:52:39 opendevreview Merged openstack/os-vif master: update os-vif ci to account for devstack default changes https://review.opendev.org/c/openstack/os-vif/+/798038
#openstack-nova - 2021-07-07
03:31:52 opendevreview wangzhenmeng proposed openstack/nova master: Three CPU parameters, mode, model and vendor_id, are added to flavor, some guest os do not support new CPU, so you need to specify a specific CPU when starting. https://review.opendev.org/c/openstack/nova/+/796986
03:34:35 opendevreview wangzhenmeng proposed openstack/nova master: Add CPU parameters to flavor https://review.opendev.org/c/openstack/nova/+/796986
09:24:55 ralonsoh hi folks, do you know what I need to set in libvirt for live-migration?
09:25:00 ralonsoh I'm having this error:
09:25:01 ralonsoh libvirt.libvirtError: Secret not found: no secret with matching uuid '70447a0f-443f-4b30-a154-c75706973e08'
09:25:38 sean-k-mooney[m] are you using ceph
09:25:49 sean-k-mooney[m] normally you do not need to set anything in libvirt
09:26:00 ralonsoh yes I configured ceph
09:26:07 ralonsoh I'll check it again
09:26:27 sean-k-mooney[m] you need to configure the ceph key ring as a secret but the devstack plugin does that for you
09:26:27 ralonsoh (maybe not in the second compute node...)
09:27:18 ralonsoh yeah, I think I didn't configure ceph in the second compute node
09:27:20 ralonsoh thanks!
09:28:17 sean-k-mooney[m] https://opendev.org/openstack/devstack-plugin-ceph/src/branch/master/devstack/lib/ceph#L244
09:28:41 sean-k-mooney[m] that is what adds the user key ring as a secret
09:28:59 sean-k-mooney[m] so you could just do that or restack the compute
09:29:41 sean-k-mooney[m] you also need to copy over the ceph.confirm
09:29:49 sean-k-mooney[m] *ceph.conf
09:30:01 ralonsoh sean-k-mooney[m], btw, I think slaweq made a good point on https://review.opendev.org/c/openstack/neutron-specs/+/799198/3/specs/xena/ovn-auxiliary-port-bridge-live-migration.rst#51
09:30:06 ralonsoh I'm checking this now
09:31:07 sean-k-mooney[m] ovn must handel that or we cannot support live migration with ovn
09:31:50 ralonsoh I know
09:33:34 sean-k-mooney[m] so from my point of view we should either ignore that and if it cause any issue file it as a bug with ovn or we disable live migration when you use ovn. we are not actually changing the behaviour although we are extending the time its in that state
09:33:52 sean-k-mooney[m] today the port exits on the source and dest for a period of time its just shorter
09:34:10 ralonsoh sean-k-mooney[m], in OVN we don't have, for example, the concept of multiple port binding
09:34:23 ralonsoh and could be difficult to introduce it
09:35:03 ralonsoh could be possible, just an idea, to monitor this multiple port binding
09:35:16 ralonsoh and provide routing for the older one
09:35:28 ralonsoh when the scr port is deleted, the destination port will prevail
09:35:41 ralonsoh this will also prevent errors if the migration fails
09:35:47 ralonsoh anyway, this is not supported
09:37:28 sean-k-mooney[m] this is not related to multiple port bindings
09:37:46 sean-k-mooney[m] this willl happen with just libvirt and ovn without openstack
09:37:46 ralonsoh I was making a parallelism
09:37:51 ralonsoh with OVN backend
09:38:12 ralonsoh this is what OVN should support or something similar
09:38:30 sean-k-mooney[m] ovn needs to monitor the packets
09:38:47 ralonsoh what for?
09:38:53 sean-k-mooney[m] and when it receives new packets on the dest host swap that to to the primary port
09:39:13 ralonsoh could be an idea yes
09:39:18 sean-k-mooney[m] basically if need to activate the dest port when it receives the mac learning RARP packets
09:39:25 ralonsoh but should be aware of the multiple port locations
09:39:32 sean-k-mooney[m] yes
09:39:42 ralonsoh in any case, this is very similar to what we have now
09:39:58 sean-k-mooney[m] anyway in post-copy mode the vm today is potentially in this state for several minutes
09:40:03 ralonsoh that means OVN will configure the backend when the VM is unpaused
09:40:07 sean-k-mooney[m] so this is not new to this spec
09:40:53 ralonsoh in any case, I didn't think about this problem
09:41:21 ralonsoh and now I don't see what's the benefit using this feature
09:41:38 sean-k-mooney[m] ya but its not related to any of the change we are making and it happens already today without them so while we should bring it up with the ovn team
09:41:48 sean-k-mooney[m] its not a blocker for this change
09:42:16 ralonsoh but it is a relevant OVN behavior change we need to document in the spec
09:42:26 sean-k-mooney[m] its not
09:42:32 sean-k-mooney[m] this already happens today
09:42:54 sean-k-mooney[m] so its not a behaviour change
09:43:01 ralonsoh right
09:43:20 ralonsoh in any case, to make this work properly, we need this OVN change
09:43:26 ralonsoh of course
09:43:32 ralonsoh the feature is still valid
09:43:35 ralonsoh and the spec
09:43:57 sean-k-mooney[m] perhaps. if ovn is installing teh correct flows on the dest in this sate
09:44:11 sean-k-mooney[m] then the only issue we have is with packets getting sent to the vm right
09:44:34 ralonsoh yes
09:44:42 sean-k-mooney[m] ovn proably should be mirroring the packet flow to both ports

Earlier   Later