Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-09
01:24:37 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-agents policies https://review.opendev.org/701648
01:30:02 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-agents policy https://review.opendev.org/701649
01:34:40 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-aggregates policies https://review.opendev.org/701651
01:43:41 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-aggregates policy https://review.opendev.org/701652
01:48:37 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-aggregates policies https://review.opendev.org/701654
01:53:29 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-aggregates policy https://review.opendev.org/701656
02:08:11 Liang__ nick LiangFang
02:48:31 openstackgerrit Matt Riedemann proposed openstack/nova stable/train: Create instance action when burying in cell0 https://review.opendev.org/701279
08:31:59 openstackgerrit Balazs Gibizer proposed openstack/nova master: Revert InstancePCIRequest change when live migration aborted https://review.opendev.org/701684
08:33:41 openstackgerrit Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066
08:33:41 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353
08:47:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: Revert InstancePCIRequest change when live migration aborted https://review.opendev.org/701684
08:49:33 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353
08:49:34 openstackgerrit Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066
09:09:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: Revert InstancePCIRequest change when live migration aborted https://review.opendev.org/701684
09:09:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066
09:09:57 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353
11:16:00 openstackgerrit Balazs Gibizer proposed openstack/nova master: Revert InstancePCIRequest change when live migration aborted https://review.opendev.org/701684
11:16:01 openstackgerrit Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353
11:17:44 openstackgerrit Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066
11:48:58 openstackgerrit sean mooney proposed openstack/os-vif master: move os-vif-ovs to be a non legacy job. https://review.opendev.org/701601
11:48:59 openstackgerrit sean mooney proposed openstack/os-vif master: optimise tempest testing https://review.opendev.org/701607
11:54:50 lyarwood is there an .ics for the nova meeting?
11:55:26 sean-k-mooney yes its on the meeting site one sec ill see if i can get the link
11:55:55 sean-k-mooney http://eavesdrop.openstack.org/#Nova_Team_Meeting
11:56:58 lyarwood ah ha! thanks sean-k-mooney
12:16:40 luyao sean-k-mooney: thanks for your comments on spec 'support live migration with vpmem' https://review.opendev.org/#/c/695863, I answered some questions you concerned, you could have a look again if you get time. :)
12:18:38 luyao stephenfin, artom: I also need your help me to polish the spec. Thanks in advance. :D
12:26:46 sean-k-mooney luyao: im still not conviced that usign the migration_context is better but i wont block on it.
12:33:42 alex_xu sean-k-mooney: whatever we need migration_context to persistent the allocation for the dest node
12:34:15 alex_xu sean-k-mooney: using migrate_data just sounds like we have one more place for the dest allocation info
12:34:55 sean-k-mooney alex_xu: well im hoping we will eventurally remove all move claims form so im not that keen on seeing more use of them
12:35:17 alex_xu sean-k-mooney: why we want to remove move claims? we just add them for live migration
12:35:47 sean-k-mooney alex_xu: no we added them for numa live migration and for sriov live migration we did it via the migration data object
12:36:11 frickler wow, that moment when, after debugging why a config option doesn't seem to take effect, you discover that is has been deprecated in juno and removed in kilo ...
12:36:26 sean-k-mooney alex_xu: we still need to decised how to reconsile them but we intentionally did not use them for sriov live migration because we did not want to have them for live migration
12:39:28 alex_xu sean-k-mooney: emm...I need figure out what different between move clain and pci claim
12:39:57 sean-k-mooney the pci tracker has 3 state for the devices
12:40:01 luyao sean-k-mooney: vpmem need numa support, so it's ok in numa live migraion I think
12:40:19 sean-k-mooney basically avaiable allocated and in uses
12:40:57 alex_xu sean-k-mooney: both them are reconcile by rt.update_available_resource?
12:41:06 sean-k-mooney for the sriov migrating we move the dest pci deives that are claiimed too allocated and then go to in use in post live migration or get freed if we fail
12:41:46 sean-k-mooney the pci magnager work a littel differently
12:41:59 alex_xu and pci manager persistent the claim
12:42:05 sean-k-mooney yes
12:42:28 alex_xu vpmem need persistent also
12:42:45 sean-k-mooney well it persist it in that in the pci_stats? table we change the state of the device and recorred it as allocated fot the specic instnace
12:42:48 alex_xu and vpmem totally depends on instance.resources and instance.migration_context
12:43:23 sean-k-mooney ya. for vpmem at the moment i guess you have no other choice
12:43:27 alex_xu no vpmem claim persistent in instance.resources and instance.migration_context
12:43:35 alex_xu yea
12:44:00 sean-k-mooney i was hoping that wew woudl reconsile the different approches in sriov migraiton and numa migration by removing the live migration claim
12:44:54 alex_xu we still have RT at that time?
12:45:02 alex_xu I don't vision about that
12:45:13 sean-k-mooney and haneling numa without building on move claims but i guess i might have to do it the other way which make sme sad but
12:45:14 alex_xu s/don't vision/don't have vision'
12:45:39 sean-k-mooney i expect that we will always have the RT since plamcent does not handel assingment
12:46:07 alex_xu +1
12:47:53 sean-k-mooney i just think the RT will do less work over time.
12:48:52 alex_xu yea, that i can imagine
12:49:39 sean-k-mooney it partly why i was hoping the move/rebiuld/noop/live-migration claim would eventury be removed
12:49:57 sean-k-mooney i was hoping we could simply what it does over time to not need them
12:51:27 alex_xu ok, i see
12:57:19 sean-k-mooney is the only place we store the vpmem allocation the in instance_extra table in the resouces filed
12:58:14 sean-k-mooney then in memeoy the resouce tracker discovers the avialabel vpmem namespaces and uses the instnace extra info to determin which ones are free and which are in use
13:01:01 sean-k-mooney ah yes we model this using the generic Resocue object and the specalised vpmemdevcie metaddata
13:01:07 sean-k-mooney ths is all coming back to me https://github.com/openstack/nova/blob/a4311c401b55c27321de7b282b242661af73fa34/nova/objects/resource.py#L39-L110
13:03:34 alex_xu sean-k-mooney: yes
13:04:55 sean-k-mooney right so i rememebr we discussed if we need to do host side tracking like we do for pci device or if im memory + instastnce level tracking was enought like we do for vgpu
13:05:20 sean-k-mooney and we endup not doing host level tracking in the db
13:05:53 alex_xu yes
13:06:54 sean-k-mooney ya ok so the appoch in the spec makes sense then with that context.
13:07:00 alex_xu vgpu is more libvirt level tracking...
13:08:44 sean-k-mooney ya i was just looking at the vpmem discovery code https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L429-L514
13:18:08 huaqiang 1;2C1;5C
13:20:46 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: libvirt: Add a rbd_connect_timeout configurable https://review.opendev.org/669167
13:21:56 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: Skip cpu comparison on AArch64 https://review.opendev.org/699116
13:50:02 efried Nova meeting in 10 minutes in #openstack-meeting
13:52:16 efried At a glance this morning it looked to me like nova-next is failing 100%. Has anyone looked at this?
13:52:35 efried ...before I dig in with my non-mriedem-ness?
13:53:42 openstackgerrit Matt Riedemann proposed openstack/nova master: Add a workaround config toggle to refuse ceph image upload https://review.opendev.org/657078
14:00:22 efried Nova meeting now.
14:01:55 efried stephenfin, sean-k-mooney, bauzas: ^
14:02:09 efried huaqiang: ^
14:02:10 efried who else?
14:03:39 brinzhang_ :)
14:06:16 brinzhang_ Can I send my questions? :P
14:07:04 alex_xu brinzhang_: meeting is at #openstack-meeting channel
14:07:25 brinzhang_ alex_xu: yeah, joined
14:07:29 efried brinzhang_: yes, for sure.
14:07:59 brinzhang_ alex_xu, efried: thanks
14:29:01 openstackgerrit Merged openstack/nova master: functional: Make '_IntegratedTestBase' subclass 'InstanceHelperMixin' https://review.opendev.org/689182
14:30:45 bauzas efried: sorry was on meeting
15:01:36 sean-k-mooney bauzas: every time you or somone else at redhat says they are sorry i was in a meeting i go crap did i miss one or was it a 1:1 :)
15:01:54 bauzas 1:1 indeed
15:02:09 sean-k-mooney although that is partly because im getting used to meeting again after the break
15:02:15 brinzhang_ hah
15:02:28 efried I don't like that personally because I think the mix of placement-ese and hw:-ese is more confusing than just hw:-ese
15:02:28 efried We could make that work, if we had to, because the hw:-ese part could impart enough information that you could infer the rest about your shared CPUs.
15:02:28 efried dansmith: Re specifying VCPUs in placement-ese and other stuff in hw:-ese...

Earlier   Later