| *** tetsuro has joined #openstack-nova | 00:05 | |
| *** ivve has quit IRC | 00:06 | |
| *** tetsuro_ has quit IRC | 00:07 | |
| *** tbachman has joined #openstack-nova | 00:19 | |
| *** jawad_axd has joined #openstack-nova | 00:31 | |
| *** jawad_axd has quit IRC | 00:35 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-admin-password policy https://review.opendev.org/701642 | 00:51 |
|---|---|---|
| *** yedongcan has joined #openstack-nova | 00:52 | |
| *** brinzhang has joined #openstack-nova | 01:00 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-agents policies https://review.opendev.org/701644 | 01:02 |
| *** portdirect has quit IRC | 01:02 | |
| *** tetsuro has quit IRC | 01:04 | |
| *** tetsuro has joined #openstack-nova | 01:04 | |
| *** tetsuro has quit IRC | 01:08 | |
| *** TxGirlGeek has quit IRC | 01:08 | |
| *** Liang__ has joined #openstack-nova | 01:10 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-agents policy https://review.opendev.org/701645 | 01:11 |
| *** slaweq has joined #openstack-nova | 01:11 | |
| *** slaweq has quit IRC | 01:17 | |
| *** tetsuro has joined #openstack-nova | 01:17 | |
| *** zhanglong has joined #openstack-nova | 01:20 | |
| *** tetsuro_ has joined #openstack-nova | 01:22 | |
| *** gyee has quit IRC | 01:23 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-agents policies https://review.opendev.org/701648 | 01:24 |
| *** tetsuro has quit IRC | 01:26 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-agents policy https://review.opendev.org/701649 | 01:30 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-aggregates policies https://review.opendev.org/701651 | 01:34 |
| *** jangutter has quit IRC | 01:42 | |
| *** jangutter has joined #openstack-nova | 01:42 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-aggregates policy https://review.opendev.org/701652 | 01:43 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-aggregates policies https://review.opendev.org/701654 | 01:48 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-aggregates policy https://review.opendev.org/701656 | 01:53 |
| *** mriedem has joined #openstack-nova | 01:53 | |
| *** tetsuro has joined #openstack-nova | 02:00 | |
| *** tetsuro_ has quit IRC | 02:04 | |
| *** mriedem has quit IRC | 02:05 | |
| *** lvbin02 has joined #openstack-nova | 02:07 | |
| Liang__ | nick LiangFang | 02:08 |
| *** Liang__ is now known as LiangFang | 02:08 | |
| *** tonyb has quit IRC | 02:10 | |
| *** tinwood has quit IRC | 02:10 | |
| *** lvbin01 has quit IRC | 02:10 | |
| *** lvbin02 is now known as lvbin01 | 02:10 | |
| *** tinwood has joined #openstack-nova | 02:12 | |
| *** xek_ has joined #openstack-nova | 02:22 | |
| *** xek has quit IRC | 02:23 | |
| *** jangutter_ has joined #openstack-nova | 02:28 | |
| *** jangutter has quit IRC | 02:30 | |
| *** brinzhang_ has joined #openstack-nova | 02:31 | |
| *** brinzhang has quit IRC | 02:34 | |
| openstackgerrit | Matt Riedemann proposed openstack/nova stable/train: Create instance action when burying in cell0 https://review.opendev.org/701279 | 02:48 |
| *** tetsuro has quit IRC | 03:07 | |
| *** slaweq has joined #openstack-nova | 03:11 | |
| *** slaweq has quit IRC | 03:16 | |
| *** sapd1_x has joined #openstack-nova | 03:39 | |
| *** psachin has joined #openstack-nova | 03:42 | |
| *** tetsuro has joined #openstack-nova | 03:59 | |
| *** udesale has joined #openstack-nova | 04:03 | |
| *** nweinber__ has joined #openstack-nova | 04:08 | |
| *** nweinber__ has quit IRC | 04:19 | |
| *** sapd1_x has quit IRC | 04:27 | |
| *** bhagyashris has joined #openstack-nova | 04:37 | |
| *** mkrai has joined #openstack-nova | 05:10 | |
| *** slaweq has joined #openstack-nova | 05:11 | |
| *** slaweq has quit IRC | 05:16 | |
| *** links has joined #openstack-nova | 05:21 | |
| *** mkrai has quit IRC | 05:28 | |
| *** mkrai has joined #openstack-nova | 05:30 | |
| *** ociuhandu has joined #openstack-nova | 05:31 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #openstack-nova | 05:34 | |
| *** ociuhandu has quit IRC | 05:35 | |
| *** udesale has quit IRC | 05:40 | |
| *** zhanglong has quit IRC | 06:27 | |
| *** ratailor has joined #openstack-nova | 06:28 | |
| *** zhanglong has joined #openstack-nova | 06:29 | |
| *** rcernin has quit IRC | 06:32 | |
| *** ivve has joined #openstack-nova | 06:44 | |
| *** ileixe has quit IRC | 06:56 | |
| *** ileixe has joined #openstack-nova | 06:59 | |
| *** dpawlik has joined #openstack-nova | 07:07 | |
| *** udesale has joined #openstack-nova | 07:12 | |
| *** jawad_axd has joined #openstack-nova | 07:19 | |
| *** ileixe has quit IRC | 07:33 | |
| *** ileixe has joined #openstack-nova | 07:40 | |
| *** damien_r has joined #openstack-nova | 07:44 | |
| *** zhanglong has quit IRC | 07:48 | |
| *** zhanglong has joined #openstack-nova | 07:49 | |
| *** slaweq has joined #openstack-nova | 07:52 | |
| *** damien_r has quit IRC | 07:55 | |
| *** damien_r has joined #openstack-nova | 07:55 | |
| *** damien_r has quit IRC | 07:58 | |
| *** maciejjozefczyk has joined #openstack-nova | 08:02 | |
| *** pcaruana has joined #openstack-nova | 08:02 | |
| *** ratailor_ has joined #openstack-nova | 08:04 | |
| *** rpittau|afk is now known as rpittau | 08:06 | |
| *** ratailor has quit IRC | 08:06 | |
| *** zhanglong has quit IRC | 08:06 | |
| *** damien_r has joined #openstack-nova | 08:17 | |
| *** tkajinam has quit IRC | 08:18 | |
| *** tosky has joined #openstack-nova | 08:25 | |
| *** slaweq_ has joined #openstack-nova | 08:29 | |
| *** tesseract has joined #openstack-nova | 08:30 | |
| *** slaweq has quit IRC | 08:31 | |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Revert InstancePCIRequest change when live migration aborted https://review.opendev.org/701684 | 08:31 |
| *** udesale has quit IRC | 08:32 | |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353 | 08:33 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066 | 08:33 |
| *** links has quit IRC | 08:35 | |
| *** trident has quit IRC | 08:37 | |
| *** trident has joined #openstack-nova | 08:39 | |
| *** links has joined #openstack-nova | 08:40 | |
| *** tetsuro has quit IRC | 08:43 | |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Revert InstancePCIRequest change when live migration aborted https://review.opendev.org/701684 | 08:47 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353 | 08:49 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066 | 08:49 |
| *** jraju__ has joined #openstack-nova | 08:49 | |
| *** links has quit IRC | 08:49 | |
| *** ivve has quit IRC | 08:56 | |
| *** jraju__ has quit IRC | 09:03 | |
| *** ralonsoh has joined #openstack-nova | 09:03 | |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Revert InstancePCIRequest change when live migration aborted https://review.opendev.org/701684 | 09:09 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353 | 09:09 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066 | 09:09 |
| *** udesale has joined #openstack-nova | 09:11 | |
| *** LiangFang has quit IRC | 09:12 | |
| *** ociuhandu has joined #openstack-nova | 09:15 | |
| *** awalende has joined #openstack-nova | 09:18 | |
| *** ociuhandu has quit IRC | 09:19 | |
| *** abhishekk has joined #openstack-nova | 09:34 | |
| *** slaweq_ has quit IRC | 09:38 | |
| *** ratailor__ has joined #openstack-nova | 09:41 | |
| *** ratailor_ has quit IRC | 09:44 | |
| *** ociuhandu has joined #openstack-nova | 09:44 | |
| *** ociuhandu has quit IRC | 09:45 | |
| *** tetsuro has joined #openstack-nova | 09:45 | |
| *** ociuhandu has joined #openstack-nova | 09:48 | |
| *** martinkennelly has joined #openstack-nova | 09:49 | |
| *** slaweq_ has joined #openstack-nova | 09:50 | |
| *** ociuhandu has quit IRC | 09:53 | |
| *** ivve has joined #openstack-nova | 10:02 | |
| *** tetsuro has quit IRC | 10:05 | |
| *** ratailor__ has quit IRC | 10:07 | |
| *** abhishekk has quit IRC | 10:07 | |
| *** ratailor has joined #openstack-nova | 10:08 | |
| *** ociuhandu has joined #openstack-nova | 10:14 | |
| *** ociuhandu has quit IRC | 10:15 | |
| *** ociuhandu has joined #openstack-nova | 10:16 | |
| *** abhishekk has joined #openstack-nova | 10:16 | |
| *** ociuhandu has quit IRC | 10:21 | |
| *** ociuhandu has joined #openstack-nova | 10:22 | |
| *** ociuhandu has quit IRC | 10:27 | |
| *** ociuhandu has joined #openstack-nova | 10:47 | |
| *** yedongcan has left #openstack-nova | 10:49 | |
| *** xek__ has joined #openstack-nova | 10:51 | |
| *** ociuhandu has quit IRC | 10:52 | |
| *** xek_ has quit IRC | 10:54 | |
| *** brinzhang has joined #openstack-nova | 10:54 | |
| *** dtantsur|afk is now known as dtantsur | 10:55 | |
| *** ociuhandu has joined #openstack-nova | 10:55 | |
| *** mkrai has quit IRC | 10:55 | |
| *** brinzhang_ has quit IRC | 10:57 | |
| *** ociuhandu has quit IRC | 10:58 | |
| *** ociuhandu has joined #openstack-nova | 10:59 | |
| *** ratailor has quit IRC | 11:04 | |
| *** ratailor has joined #openstack-nova | 11:05 | |
| *** tetsuro has joined #openstack-nova | 11:07 | |
| *** cyclaw has quit IRC | 11:09 | |
| *** ociuhandu has quit IRC | 11:12 | |
| *** gentoorax has joined #openstack-nova | 11:12 | |
| *** udesale has quit IRC | 11:12 | |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Revert InstancePCIRequest change when live migration aborted https://review.opendev.org/701684 | 11:16 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Use common server create function for qos func tests https://review.opendev.org/701353 | 11:16 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066 | 11:17 |
| *** rpittau is now known as rpittau|bbl | 11:18 | |
| *** lbragstad has quit IRC | 11:20 | |
| *** lbragstad has joined #openstack-nova | 11:23 | |
| *** tbachman has quit IRC | 11:47 | |
| *** dviroel has joined #openstack-nova | 11:47 | |
| *** ociuhandu has joined #openstack-nova | 11:48 | |
| 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 |
| openstackgerrit | sean mooney proposed openstack/os-vif master: optimise tempest testing https://review.opendev.org/701607 | 11:48 |
| *** jangutter_ is now known as jangutter | 11:49 | |
| *** ociuhandu has quit IRC | 11:52 | |
| lyarwood | is there an .ics for the nova meeting? | 11:54 |
| sean-k-mooney | yes its on the meeting site one sec ill see if i can get the link | 11:55 |
| sean-k-mooney | http://eavesdrop.openstack.org/#Nova_Team_Meeting | 11:55 |
| lyarwood | ah ha! thanks sean-k-mooney | 11:56 |
| *** ociuhandu has joined #openstack-nova | 11:58 | |
| *** ociuhandu has quit IRC | 12:00 | |
| *** ociuhandu has joined #openstack-nova | 12:02 | |
| *** ociuhandu has quit IRC | 12:07 | |
| *** mgariepy has joined #openstack-nova | 12:11 | |
| *** tetsuro has quit IRC | 12:15 | |
| 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:16 |
| *** bhagyashris_ has joined #openstack-nova | 12:17 | |
| luyao | stephenfin, artom: I also need your help me to polish the spec. Thanks in advance. :D | 12:18 |
| *** bhagyashris has quit IRC | 12:19 | |
| sean-k-mooney | luyao: im still not conviced that usign the migration_context is better but i wont block on it. | 12:26 |
| *** brinzhang_ has joined #openstack-nova | 12:28 | |
| *** brinzhang has quit IRC | 12:31 | |
| *** brinzhang has joined #openstack-nova | 12:31 | |
| alex_xu | sean-k-mooney: whatever we need migration_context to persistent the allocation for the dest node | 12:33 |
| *** brinzhang has quit IRC | 12:33 | |
| alex_xu | sean-k-mooney: using migrate_data just sounds like we have one more place for the dest allocation info | 12:34 |
| *** brinzhang has joined #openstack-nova | 12:34 | |
| *** brinzhang_ has quit IRC | 12:34 | |
| 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:34 |
| alex_xu | sean-k-mooney: why we want to remove move claims? we just add them for live migration | 12:35 |
| 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:35 |
| *** brinzhang has quit IRC | 12:35 | |
| 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 |
| *** brinzhang has joined #openstack-nova | 12:36 | |
| 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:36 |
| alex_xu | sean-k-mooney: emm...I need figure out what different between move clain and pci claim | 12:39 |
| sean-k-mooney | the pci tracker has 3 state for the devices | 12:39 |
| luyao | sean-k-mooney: vpmem need numa support, so it's ok in numa live migraion I think | 12:40 |
| sean-k-mooney | basically avaiable allocated and in uses | 12:40 |
| alex_xu | sean-k-mooney: both them are reconcile by rt.update_available_resource? | 12:40 |
| 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 |
| sean-k-mooney | the pci magnager work a littel differently | 12:41 |
| alex_xu | and pci manager persistent the claim | 12:41 |
| sean-k-mooney | yes | 12:42 |
| alex_xu | vpmem need persistent also | 12:42 |
| 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 |
| alex_xu | and vpmem totally depends on instance.resources and instance.migration_context | 12:42 |
| sean-k-mooney | ya. for vpmem at the moment i guess you have no other choice | 12:43 |
| alex_xu | no vpmem claim persistent in instance.resources and instance.migration_context | 12:43 |
| alex_xu | yea | 12:43 |
| 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 |
| *** bhagyashris__ has joined #openstack-nova | 12:44 | |
| *** dosaboy has quit IRC | 12:44 | |
| *** bhagyashris__ is now known as bhagyashris | 12:44 | |
| alex_xu | we still have RT at that time? | 12:44 |
| alex_xu | I don't vision about that | 12:45 |
| 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 |
| alex_xu | s/don't vision/don't have vision' | 12:45 |
| *** dosaboy has joined #openstack-nova | 12:45 | |
| sean-k-mooney | i expect that we will always have the RT since plamcent does not handel assingment | 12:45 |
| alex_xu | +1 | 12:46 |
| *** bhagyashris_ has quit IRC | 12:46 | |
| sean-k-mooney | i just think the RT will do less work over time. | 12:47 |
| alex_xu | yea, that i can imagine | 12:48 |
| sean-k-mooney | it partly why i was hoping the move/rebiuld/noop/live-migration claim would eventury be removed | 12:49 |
| sean-k-mooney | i was hoping we could simply what it does over time to not need them | 12:49 |
| *** jawad_axd has quit IRC | 12:50 | |
| alex_xu | ok, i see | 12:51 |
| sean-k-mooney | is the only place we store the vpmem allocation the in instance_extra table in the resouces filed | 12:57 |
| 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 | 12:58 |
| *** jawad_axd has joined #openstack-nova | 12:59 | |
| *** brinzhang_ has joined #openstack-nova | 13:00 | |
| *** zbr|rover has quit IRC | 13:00 | |
| sean-k-mooney | ah yes we model this using the generic Resocue object and the specalised vpmemdevcie metaddata | 13:01 |
| sean-k-mooney | ths is all coming back to me https://github.com/openstack/nova/blob/a4311c401b55c27321de7b282b242661af73fa34/nova/objects/resource.py#L39-L110 | 13:01 |
| *** brinzhang_ has quit IRC | 13:01 | |
| *** brinzhang_ has joined #openstack-nova | 13:02 | |
| *** nweinber__ has joined #openstack-nova | 13:02 | |
| *** Kevin_Zheng has quit IRC | 13:03 | |
| *** brinzhang has quit IRC | 13:03 | |
| alex_xu | sean-k-mooney: yes | 13:03 |
| *** huaqiang has joined #openstack-nova | 13:03 | |
| 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:04 |
| sean-k-mooney | and we endup not doing host level tracking in the db | 13:05 |
| alex_xu | yes | 13:05 |
| sean-k-mooney | ya ok so the appoch in the spec makes sense then with that context. | 13:06 |
| alex_xu | vgpu is more libvirt level tracking... | 13:07 |
| *** ratailor has quit IRC | 13:08 | |
| 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:08 |
| *** belmoreira has joined #openstack-nova | 13:16 | |
| huaqiang | 1;2C1;5C | 13:18 |
| openstackgerrit | Lee Yarwood proposed openstack/nova stable/stein: libvirt: Add a rbd_connect_timeout configurable https://review.opendev.org/669167 | 13:20 |
| *** dpawlik has quit IRC | 13:21 | |
| *** tbachman has joined #openstack-nova | 13:21 | |
| openstackgerrit | Lee Yarwood proposed openstack/nova stable/stein: Skip cpu comparison on AArch64 https://review.opendev.org/699116 | 13:21 |
| *** dpawlik has joined #openstack-nova | 13:25 | |
| *** rpittau|bbl is now known as rpittau | 13:25 | |
| *** yan0s has joined #openstack-nova | 13:28 | |
| *** ociuhandu has joined #openstack-nova | 13:32 | |
| *** brinzhang has joined #openstack-nova | 13:36 | |
| *** ociuhandu has quit IRC | 13:37 | |
| *** brinzhang_ has quit IRC | 13:40 | |
| *** ociuhandu has joined #openstack-nova | 13:48 | |
| efried | Nova meeting in 10 minutes in #openstack-meeting | 13:50 |
| *** mriedem has joined #openstack-nova | 13:51 | |
| efried | At a glance this morning it looked to me like nova-next is failing 100%. Has anyone looked at this? | 13:52 |
| efried | ...before I dig in with my non-mriedem-ness? | 13:52 |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: Add a workaround config toggle to refuse ceph image upload https://review.opendev.org/657078 | 13:53 |
| *** davidsha has joined #openstack-nova | 13:54 | |
| *** ociuhandu has quit IRC | 13:54 | |
| *** ociuhandu has joined #openstack-nova | 13:55 | |
| *** brinzhang_ has joined #openstack-nova | 13:58 | |
| efried | Nova meeting now. | 14:00 |
| *** zul has joined #openstack-nova | 14:01 | |
| efried | stephenfin, sean-k-mooney, bauzas: ^ | 14:01 |
| efried | huaqiang: ^ | 14:02 |
| efried | who else? | 14:02 |
| *** ociuhandu has quit IRC | 14:03 | |
| brinzhang_ | :) | 14:03 |
| *** ociuhandu has joined #openstack-nova | 14:04 | |
| *** eharney has joined #openstack-nova | 14:04 | |
| brinzhang_ | Can I send my questions? :P | 14:06 |
| alex_xu | brinzhang_: meeting is at #openstack-meeting channel | 14:07 |
| brinzhang_ | alex_xu: yeah, joined | 14:07 |
| efried | brinzhang_: yes, for sure. | 14:07 |
| brinzhang_ | alex_xu, efried: thanks | 14:07 |
| *** brinzhang has quit IRC | 14:10 | |
| *** brinzhang has joined #openstack-nova | 14:10 | |
| *** brinzhang has quit IRC | 14:11 | |
| *** brinzhang has joined #openstack-nova | 14:11 | |
| *** ociuhandu has quit IRC | 14:13 | |
| *** brinzhang has quit IRC | 14:16 | |
| *** brinzhang has joined #openstack-nova | 14:17 | |
| *** zbr has joined #openstack-nova | 14:17 | |
| *** brinzhang_ has quit IRC | 14:17 | |
| *** brinzhang has quit IRC | 14:17 | |
| *** brinzhang_ has joined #openstack-nova | 14:18 | |
| *** zbr is now known as zbr|rover | 14:18 | |
| *** slaweq_ is now known as slaweq | 14:26 | |
| *** bhagyashris has quit IRC | 14:27 | |
| openstackgerrit | Merged openstack/nova master: functional: Make '_IntegratedTestBase' subclass 'InstanceHelperMixin' https://review.opendev.org/689182 | 14:29 |
| bauzas | efried: sorry was on meeting | 14:30 |
| *** portdirect has joined #openstack-nova | 14:31 | |
| *** mriedem has left #openstack-nova | 14:40 | |
| *** pcaruana has quit IRC | 14:47 | |
| *** psachin has quit IRC | 14:48 | |
| *** tbachman has quit IRC | 14:54 | |
| *** jawad_axd has quit IRC | 14:55 | |
| *** awalende has quit IRC | 14:55 | |
| *** awalende has joined #openstack-nova | 14:55 | |
| *** jawad_axd has joined #openstack-nova | 14:56 | |
| *** brinzhang_ has quit IRC | 14:57 | |
| *** brinzhang_ has joined #openstack-nova | 14:58 | |
| *** jawad_axd has quit IRC | 14:58 | |
| *** jawad_ax_ has joined #openstack-nova | 14:58 | |
| *** brinzhang_ has quit IRC | 14:59 | |
| *** brinzhang_ has joined #openstack-nova | 14:59 | |
| *** awalende has quit IRC | 15:00 | |
| *** tbachman has joined #openstack-nova | 15:00 | |
| 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 |
| *** alistarle has joined #openstack-nova | 15:01 | |
| bauzas | 1:1 indeed | 15:01 |
| sean-k-mooney | although that is partly because im getting used to meeting again after the break | 15:02 |
| brinzhang_ | hah | 15:02 |
| efried | dansmith: Re specifying VCPUs in placement-ese and other stuff in hw:-ese... | 15:02 |
| 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 |
| 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 |
| *** jawad_ax_ has quit IRC | 15:02 | |
| *** pcaruana has joined #openstack-nova | 15:02 | |
| efried | point being: we're going to have to have snowflake syntax anyway, so might as well make it consistent. | 15:02 |
| sean-k-mooney | efried: you coudld infer the amoung and then have a driver specifc convetion for how to select which ones would float and whcih woudl be pinned | 15:03 |
| efried | Rather than asking people to understand which subset of placement-ese is side-effecty and which is not | 15:03 |
| sean-k-mooney | but it make the code more complex | 15:03 |
| efried | sean-k-mooney: Yes, exactly. Yes, exactly. | 15:04 |
| *** brinzhang_ has quit IRC | 15:04 | |
| efried | and also make it harder for the user to understand IMO. | 15:04 |
| *** udesale has joined #openstack-nova | 15:04 | |
| *** brinzhang_ has joined #openstack-nova | 15:04 | |
| sean-k-mooney | if i was to code the algortiom it would be balance the shared cores evenly across numa nodes then make the rest pinned | 15:05 |
| dansmith | I dunno, I'm just disappointed with the mess we've had, do have, and apparently will have | 15:05 |
| sean-k-mooney | which in a singel numa node guest means all the shared cores are fist follow by the pinned cores | 15:06 |
| dansmith | do the public clouds let you have this level of control over which cpus are pinned and to where? | 15:06 |
| sean-k-mooney | and that is because the linux kernel and proably other has a prefernce for runing some code on core 0 of each numa node | 15:06 |
| *** ociuhandu has joined #openstack-nova | 15:07 | |
| efried | sean-k-mooney: even allowing for future expansion where you can specify how many you want in each NUMA node, we could still do the math. My gripe is really about the UX. | 15:07 |
| efried | dansmith: is that a leading question? | 15:08 |
| sean-k-mooney | well today the just expose flaver with either pinning on or off or numa nodes. but you can configure this via the image too | 15:08 |
| dansmith | efried: it's an honest one.. we used to have a shared value of "abstraction means not getting to turn every knob" | 15:08 |
| efried | Isn't "our competitor can't do X, and neither can we, so let's make X possible so we're better than our competitor" how progress is made? | 15:09 |
| efried | dansmith: and that abstraction still exists. You can still put up a flavor with no extra specs and get a VM. We're not taking away that simplicity. | 15:09 |
| dansmith | efried: the same argument goes fo "some vendor shows up with a P2V'd ancient appliance that requires a specific hardware topology and we spent years trying to implement that instead of actually competing on something that matters" | 15:09 |
| sean-k-mooney | so as an operate i can create a flavor with 8 cores and pinnnge and then as a user i can upload an image the says make the vm have 1 socket and, 2 thread per core, and 1 nuam node please | 15:10 |
| efried | dansmith: I dig. But NUMA isn't going away. | 15:10 |
| efried | and edge tuning is like the big thing, isn't it? | 15:10 |
| dansmith | efried: no, numa isn't, that's not the point.. whether or not we need to provide this level of control over what the topology looks like instead of just providing a sane one with the asks we were given is. | 15:11 |
| *** brinzhang_ has quit IRC | 15:11 | |
| dansmith | efried: mostly because of legacy appliances afaik :) | 15:11 |
| efried | if a good-enough VM was good enough, sure. | 15:11 |
| efried | but in edge IIUC you need to be able to squeeze every cycle out of your hardware, no? | 15:12 |
| sean-k-mooney | well if we were to provide a sane topology by default we would have to change our curren policy of 1 cpu socket per vcpu | 15:12 |
| sean-k-mooney | but i get what you mean | 15:12 |
| dansmith | that's not generally the reason they need to strictly control the topology.. it seems like the reason, but it's often not :) | 15:12 |
| sean-k-mooney | sane default would be nice | 15:12 |
| efried | I think we have sane defaults, don't we? | 15:12 |
| dansmith | anyway, I'm not trying to stop the train on those grounds, | 15:12 |
| sean-k-mooney | efried: i would not call the cpu toplogy nova generates sane | 15:13 |
| efried | heh | 15:13 |
| efried | well, it could be | 15:13 |
| dansmith | I'm more looking for a signpost in the distance of what level of abstraction others have chosen | 15:13 |
| sean-k-mooney | if you have a 16 VCPU guest it will give you a guest with 16 cpu socket each wtih a 1 core 1 thread cpu | 15:13 |
| sean-k-mooney | and for software licence that chages per socket that is expensive | 15:14 |
| sean-k-mooney | that iw why the cpu topology extra specs where added | 15:14 |
| dansmith | exactly :) | 15:14 |
| dansmith | not for perf tuning :) | 15:14 |
| sean-k-mooney | windows server used to be changed per socket not per core | 15:14 |
| dansmith | and nvidia has some similar things | 15:15 |
| sean-k-mooney | so if you are sane you would do hw:cpu_socket=1 hw:cpu_theads=2 | 15:15 |
| dansmith | and closed source P2V'd ancient telco appliances are far far worse | 15:15 |
| efried | dansmith: I think I see your point. It should be *possible* to say "give me $p pinned and $s shared, you go figure out how to distribute them" without *having* to say "I want CPUs 0,3,7 pinned and 1,2,4-6 shared". | 15:15 |
| dansmith | efried: pretty much | 15:15 |
| sean-k-mooney | efried: yes so that is what we wanted to discuss in the meeting when we said count vs mask | 15:15 |
| efried | But I would argue that, if you care about a pinned vs shared split, you care enough about performance that having to do the extra syntax isn't a big jump. | 15:16 |
| dansmith | there's also the device-to-numa affinity which I understand is important, so that your nic is affined to your dedicated cpus | 15:16 |
| efried | mm | 15:16 |
| sean-k-mooney | dansmith: that is out of scope of this spec but yes that is a factor | 15:16 |
| dansmith | certainly you know I'm not arguing that operators of multi-billion-dollar clouds shouldn't have to write 255 characters of ascii syntax for this right? | 15:17 |
| dansmith | sean-k-mooney: no, I know, I was just commenting that I know asking for the abstract isn't enough | 15:17 |
| dansmith | sean-k-mooney: or rather, asking for his abstract example | 15:17 |
| sean-k-mooney | so if we take numa as an example | 15:17 |
| sean-k-mooney | we actully support both | 15:17 |
| sean-k-mooney | if you do hw:numa_nodes=2 | 15:18 |
| sean-k-mooney | and say nothing esle we devied the cpu and ram evenly between the numa nodes | 15:18 |
| sean-k-mooney | but you can also use hw:numa_cpu.0=2 .... to speciy the numa of cpus or ram per numa node | 15:18 |
| sean-k-mooney | most peopel jsut hw:numa_nodes and let nova do it | 15:19 |
| *** ociuhandu has quit IRC | 15:19 | |
| sean-k-mooney | i guess the diffferen with numa id they can detect the cpu and ram in the gues via the kernel jsut as if it was real hardware | 15:19 |
| *** ociuhandu has joined #openstack-nova | 15:20 | |
| sean-k-mooney | pining vs floaing is a qualtive change ranter then quantative so if they care about that then need another openstack sepcifc way to determin that | 15:20 |
| *** tbachman has quit IRC | 15:21 | |
| sean-k-mooney | the primary use case for this by the way that im aware of is for realtime guests where they want all the realtime cores to be pinned and the non realtime managment core to be floating so that they can get the most desity out of a host | 15:22 |
| dansmith | efried: so I guess to close, | 15:22 |
| dansmith | efried: my preference (and what I thought we were moving towards) was a future where resource (amounts) are specified in placement syntax, and topologies and the like are assigned sanely. Tweaks to how those look (like I really need this thing pinned here) would be hw:things but where the hw: is the optional | 15:23 |
| dansmith | meaning, usually you just ask for the amount of stuff you want and we give it to you in a sane arrangement which is fine for most people, | 15:23 |
| dansmith | and hw:tweak your way to a specific arrangement if that's important | 15:24 |
| dansmith | a more clear delineation of which thing does what | 15:24 |
| *** ociuhandu has quit IRC | 15:24 | |
| *** ociuhandu has joined #openstack-nova | 15:24 | |
| dansmith | with the hw: being the primary, then I'm not sure how you know when you do or don't or can't specify some resource count as well | 15:24 |
| *** dave-mccowan has quit IRC | 15:25 | |
| dansmith | but anyway, I grok the complexity on both sides and I'm sure both will have warts | 15:25 |
| sean-k-mooney | i could see that working if we had a speartion between the placment query and the resouces*:* element in the extra specs | 15:25 |
| efried | We're very close to agreeing here. I want the clear delineation to be that placement-ese syntax doesn't have side effects. That's the same delineation as you describe in *most* cases. | 15:25 |
| dansmith | well, in what I said above, asking for PCPUS:2 would get you two pinned cpus, which I think you're describing as a side effect | 15:26 |
| sean-k-mooney | dansmith: in your world would you see the need to supprot the number group syntax in the flavor for example | 15:26 |
| dansmith | sean-k-mooney: I will totally admit that I don't (ever) have the resource group numbering quagmire swapped into my head, but I assume yeah, you might need an extension to placement syntax to group those things if that's what you mean | 15:27 |
| dansmith | resources:2:PCPUS=2 I assume | 15:28 |
| *** ociuhandu has quit IRC | 15:28 | |
| sean-k-mooney | the numbered sysntax means that all resouce requst in that group must come from the same RP | 15:28 |
| sean-k-mooney | so if you have resources:2:PCPUS=2,MEMORY_MB=1024 | 15:29 |
| dansmith | ack | 15:29 |
| sean-k-mooney | then you need 2 pinned cpus and 1G of memory form the same resouce provider | 15:29 |
| dansmith | yeah, I dunno, that's encoding a little bit of topology into the placement syntax, | 15:29 |
| sean-k-mooney | so if you use that and we move to numa in placmenet it will break | 15:29 |
| *** mkrai has joined #openstack-nova | 15:29 | |
| dansmith | where we should be able to parse the hw: things and alter the actual things we ask placement for inside nova I think | 15:30 |
| efried | dansmith: exactly ^ | 15:30 |
| sean-k-mooney | yes so if you only used the unmbered syntax | 15:30 |
| sean-k-mooney | and had the hw:* things tweek the toplogy i can see it working | 15:30 |
| efried | The existing (unsuffixed) placement syntax is already pretty complicated to understand. Trying to add group identifiers to that will make it worse. | 15:30 |
| sean-k-mooney | as nova can alter it interally | 15:30 |
| efried | and then you have to understand *how* we model numa in placement | 15:31 |
| sean-k-mooney | well we already support grouping of bothe the resouce and trait requests | 15:31 |
| dansmith | sean-k-mooney: right, so I'd say do that.. placement syntax for totals, hw syntax for details, let nova alter what we ask placement for based on any tweaks you asked for | 15:31 |
| efried | and how group identifiers correspond to that. | 15:31 |
| dansmith | efried: I totes don't understand how current placement syntax is hard to understand | 15:31 |
| sean-k-mooney | dansmith: ya i could see that working as we aready alter stuff with the prefilters now | 15:31 |
| efried | dansmith: maybe you're too close to it | 15:32 |
| sean-k-mooney | dansmith: its complicated if you use the numbered groups | 15:32 |
| sean-k-mooney | if you dont ist not that bad and its consitent | 15:32 |
| *** tbachman has joined #openstack-nova | 15:32 | |
| *** udesale has quit IRC | 15:33 | |
| dansmith | sean-k-mooney: but we don't use numbered groups in the flavor placement syntax today right? | 15:33 |
| sean-k-mooney | your are forced to use the groups today if you want to apply trait requirement to specific resouces | 15:33 |
| sean-k-mooney | dansmith: we do | 15:33 |
| efried | I think we support it, yes | 15:33 |
| sean-k-mooney | well you can use them | 15:33 |
| efried | we just don't have many use cases that need it today. | 15:33 |
| efried | perhaps... none? | 15:34 |
| dansmith | efried: well, I've had to explain it a few times and it has always been really nice, but okay | 15:34 |
| dansmith | okay, I didn't know we even supported the group numbering today | 15:34 |
| sean-k-mooney | it was added so you could say these traits are for my nic and these other traits are for my cpu | 15:34 |
| sean-k-mooney | but since we dont have traiats that apply to mulple resouce classes today? do we? i dont think its stictly required | 15:35 |
| dansmith | sean-k-mooney: is the reason we need that an artifact of how placement works or something? | 15:35 |
| dansmith | because I would think that with no traits that apply to both cpus and nics that wouldn't be a thing I need to specify | 15:35 |
| efried | dansmith: I get what you're saying. For most cases, the placement-ese syntax isn't any more complicated than the hw:-ese syntax. I'm asserting that we will for sure need the latter, and understanding *both* is harder than understanding *one* of them. | 15:35 |
| sean-k-mooney | well you cant do resocues:<resouce class>=X; <traits for that RC> | 15:35 |
| sean-k-mooney | so you have to do resources1:PCPU traits1=AVX=required | 15:36 |
| dansmith | efried: I'm saying I think placement syntax (not including groups) is simpler and more consistent than hw syntax and is easier to understand as a whole DSL on that basis | 15:36 |
| sean-k-mooney | where the sufix 1 in this case pairs the trait and request group | 15:36 |
| efried | sean-k-mooney: which only matters if we have multiple providers, which today is only the case for VGPU and bandwidth. | 15:37 |
| efried | right? | 15:37 |
| dansmith | efried: and I'm also saying that I can understand the language of placement syntax in a few minutes, but never learn the taxonomy that is hw: without docs always in front of me | 15:37 |
| sean-k-mooney | yes | 15:37 |
| efried | dansmith: ack | 15:37 |
| sean-k-mooney | although i thory it would matter for cinder volumes too with sharing providers | 15:37 |
| efried | in theory, yes. in theory it also matters for numa. | 15:38 |
| sean-k-mooney | but ya its only imporant for nested resouce providres or sharing | 15:38 |
| sean-k-mooney | if we have 1 RP per compute then you never need grouping | 15:38 |
| sean-k-mooney | with no nesting or sharing | 15:39 |
| *** mriedem has joined #openstack-nova | 15:40 | |
| efried | We've done all this work to support nesting and grouping primarily for numa and shared storage. Only in train did we get to a point where placement is powerful enough to do what we want for numa. And in this release we've landed a couple of patches to make nova use those placement microversions. | 15:40 |
| sean-k-mooney | dansmith: if we removed supprot for the group syntax then it would make hw:* been used for congriuation and resouce: be used for quantity much simpler | 15:40 |
| efried | so we're making progress. | 15:40 |
| efried | but the last jump, modeling numa in placement from nova, is going to be really hard. | 15:40 |
| dansmith | sean-k-mooney: ack | 15:41 |
| efried | I would be fine with that fwiw. | 15:41 |
| efried | though it would technically be removing functionality that | 15:41 |
| efried | ...that we've already released with | 15:42 |
| efried | even if it's pretty unlikely anyone is using it. | 15:42 |
| sean-k-mooney | well yes but we have depreacated things in the past. | 15:42 |
| efried | yeah | 15:42 |
| efried | this becomes relevant for cyborg too btw. | 15:42 |
| sean-k-mooney | i think there are 3 distinct things. Resocues:* for quantiy, hw:* for configuration and traits:* for capablities | 15:43 |
| alex_xu | i guess nobody using group now | 15:43 |
| efried | and, dansmith, is a good example of where we could (but I really don't want to) use placement-ese to have side effects. | 15:43 |
| sean-k-mooney | at the moment we allow hw:* to be renderd into resouces:* and traits:* | 15:43 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: Avoid PlacementFixture silently swallowing kwargs https://review.opendev.org/701754 | 15:43 |
| dansmith | efried: cyborg is a good example of side effects? | 15:44 |
| efried | like programming bitstreams | 15:44 |
| dansmith | efried: isn't the bitstream specified in the device profile in cyborg? | 15:44 |
| efried | yes. | 15:45 |
| sean-k-mooney | dansmith: i think it a metadata key on the guest image | 15:45 |
| efried | no (at least not yet) | 15:45 |
| sean-k-mooney | the type of accelerator is definetly in the device profiel | 15:45 |
| dansmith | I think the bitstream is too | 15:45 |
| sean-k-mooney | the important thing is its not in the nova flavor | 15:45 |
| dansmith | efried: I'm not sure what you mean exactly by cyborg would be a good example of side effects (affecting the bitstream we use?) | 15:46 |
| efried | in the future we want to "prefer" hosts that have an accel with the desired bitstream already on them. In that case the placement request would us preferred=BITSTREAM_XXX. But we don't want to expose trait:BISTREAM_XXX=preferred in the flavor extra specs. | 15:47 |
| dansmith | efried: are you saying that if cyborg represented possible devices that could be composed by programming a, say, gzip bitstream into a fpga as a resource in placement that asking for that thing would cause you to get one? | 15:47 |
| efried | kind of thing. | 15:47 |
| sean-k-mooney | well vgpus is a example of Resources:vGPU=1 haveing an effect of actully provision a gpu for the guest | 15:47 |
| dansmith | that's maybe a next-level leap from what I'm saying, | 15:47 |
| dansmith | but it's also a much more user/ops-friendly way of stitching high level functions together | 15:48 |
| *** TxGirlGeek has joined #openstack-nova | 15:48 | |
| dansmith | i.e. instead of plugging low-level nova into low-level cyborg, you define an abstract thing in cyborg which becomes a high-level resource in nova that you just ask for by symbolic name, | 15:48 |
| efried | YES | 15:48 |
| dansmith | which is more what I think we should be shooting for, compared to the former | 15:48 |
| dansmith | you say YES, but I feel like you were arguing NO a minute ago, so I'm confused | 15:49 |
| efried | Today the way we model resources in placement is very similar to the way nova thinks of them | 15:50 |
| sean-k-mooney | how about this. for the mix cpu case. we could say that if you do VCPU:2,PCPU:6 we will generate the topogy for you but you can override it with hw:gust_pinned_cpus | 15:50 |
| efried | so just understanding placement syntax is enough | 15:50 |
| sean-k-mooney | but you could just set hw:guest_pinned_cpus too | 15:50 |
| efried | but very soon (numa modeling, cyborg) we will have to model in placement in ways that are less intuitive | 15:51 |
| efried | if we continue to support placement-ese in that future, it will required the user to understand that extra translation | 15:51 |
| efried | I'm just suggesting we hide that translation in nova. | 15:51 |
| dansmith | but then we have to invent syntax for everything no? | 15:52 |
| efried | we already have that syntax | 15:52 |
| sean-k-mooney | no only if we want to expose contol over that translation | 15:52 |
| dansmith | efried: we've already invented new syntax for "please include me an accelerator by the name of X" | 15:53 |
| dansmith | efried: if that was a placement resource, we wouldn't have had to do that, but we did and now sundar is inspecting internal flavor details of this bespoke syntax everywhere | 15:53 |
| openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Add recreate test for bug 1855927 https://review.opendev.org/701756 | 15:53 |
| openstack | bug 1855927 in OpenStack Compute (nova) "_poll_unconfirmed_resizes may not retry later if confirm_resize fails in API" [Low,In progress] https://launchpad.net/bugs/1855927 - Assigned to Matt Riedemann (mriedem) | 15:53 |
| openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Ensure source service is up before resizing/migrating https://review.opendev.org/701757 | 15:53 |
| dansmith | efried: and we will have to invent new syntax when we want to ask it to be hung on a specific numa node I think too right? | 15:54 |
| dansmith | so we'll have two unique things for accelerators: which one and how to attach | 15:54 |
| sean-k-mooney | dansmith: well that would only work if each resouce class is only owned by 1 project | 15:54 |
| sean-k-mooney | nova already "owns" the VGPU resouce class | 15:55 |
| dansmith | wat | 15:55 |
| sean-k-mooney | so that would mean we woudl have to have a seperate CYBORG_VGPU resouce class for cyborg manged VGPUs | 15:55 |
| efried | naw | 15:55 |
| dansmith | we're assigning ownership of *classes* now? | 15:56 |
| efried | per-project ownership is at the RP level. | 15:56 |
| sean-k-mooney | dansmith: to use the vgpu support in nova today you set resouce:vgpu=1 | 15:56 |
| dansmith | I thought only instances of RPs were owned | 15:56 |
| efried | ^ | 15:56 |
| dansmith | yeah what efried said | 15:56 |
| *** TxGirlGeek has quit IRC | 15:56 | |
| openstackgerrit | Merged openstack/nova master: Do not reschedule on ExternalNetworkAttachForbidden https://review.opendev.org/694179 | 15:56 |
| openstackgerrit | Merged openstack/nova master: nova-net: Remove firewall support (pt. 3) https://review.opendev.org/700511 | 15:56 |
| sean-k-mooney | well yes but how would you know in the resouce:vgpu=1 if libvirt or cyborge shoudl handel that request | 15:56 |
| openstackgerrit | Merged openstack/nova stable/rocky: Add functional recreate test for bug 1852610 https://review.opendev.org/698108 | 15:57 |
| openstack | bug 1852610 in OpenStack Compute (nova) rocky "API allows source compute service/node deletion while instances are pending a resize confirm/revert" [Medium,In progress] https://launchpad.net/bugs/1852610 - Assigned to Matt Riedemann (mriedem) | 15:57 |
| openstackgerrit | Merged openstack/nova stable/rocky: Add functional recreate revert resize test for bug 1852610 https://review.opendev.org/698110 | 15:57 |
| dansmith | sean-k-mooney: libvirt handles it in both cases eventually, but that's my point about all of this | 15:57 |
| *** TxGirlGeek has joined #openstack-nova | 15:57 | |
| dansmith | sean-k-mooney: we should have the user ask for what they want, not what they want how they think it's plumbed today | 15:57 |
| dansmith | because if we move vgpu handling completely to cyborg in the future, | 15:58 |
| dansmith | the syntax shouldn't have to change, the users shouldn't have to know how the cloud is doing that behind the scenes, etc | 15:58 |
| dansmith | we're supposed to be an abstraction, not just an API | 15:58 |
| sean-k-mooney | yes i agree with that in principal. and yes libvirt will provide it in either case where it is invetoried by the livbrit driver or cyborg | 15:58 |
| efried | Yes, we had to invent syntax for cyborg, and we'll have to extend existing syntax for numa. IMO that's not a bad thing. | 15:59 |
| efried | IF we could reasonably use placement syntax for everything, that would be okay, but that is not going to be possible. | 15:59 |
| efried | So we're going to need the snowflake syntax no matter what. | 15:59 |
| efried | So when it comes to choosing between using placement syntax in an awkward way, or inventing a new fit-for-purpose custom syntax, I vote for the latter. | 15:59 |
| efried | Currently we have ways to use the placement syntax mostly-not-awkwardly, which is where we're conflicting. | 15:59 |
| sean-k-mooney | part of the proably however was if i wanted 2 fpga with differet bit stream i might need to select different devices to be compatible | 15:59 |
| efried | I feel like we're repeating at this point. | 15:59 |
| efried | I need to run to a meeting. BBIAB | 16:00 |
| sean-k-mooney | that 2 devices with different requirements lead to the need for use to model each request as a seperate request group with different traits | 16:00 |
| dansmith | sean-k-mooney: right, today that will add a third permutation of the cyborg syntax to my point above | 16:00 |
| sean-k-mooney | so it would force the grouping syntax if we jsut use the placeemtn stuff directly | 16:01 |
| sean-k-mooney | well not on the nova side it woudl jsut eb 2 device profiles | 16:01 |
| sean-k-mooney | but yes i could | 16:01 |
| dansmith | sean-k-mooney: I'm saying today there is only one flavor key which is "_the_ device profile" in cyborg | 16:02 |
| sean-k-mooney | yes | 16:02 |
| dansmith | if you need to add more in the future, like we will for hot-attach, then we'll be adding something _else_ | 16:02 |
| sean-k-mooney | ya | 16:02 |
| *** ivve has quit IRC | 16:02 | |
| *** gyee has joined #openstack-nova | 16:03 | |
| *** tbachman has quit IRC | 16:03 | |
| sean-k-mooney | i know its not a sexy thing but i kind of do feel like maybe next cycle it would be good to try and rationalise this and write down how we envision this evolveing | 16:04 |
| *** canori01 has quit IRC | 16:04 | |
| sean-k-mooney | e.g. taking all the feature we have like this and trying to express them in with placement for resouces and hw:* for tweeks ectra and see what that looks like | 16:05 |
| sean-k-mooney | at lest when it comes to numa i think we need to do that for cpus and memory before doing numa in placmenet | 16:06 |
| *** jawad_axd has joined #openstack-nova | 16:07 | |
| *** mlavalle has joined #openstack-nova | 16:07 | |
| dansmith | there goes sean-k-mooney promising to do stuff "next cycle" :) | 16:08 |
| dansmith | but yes, I thought we were a lot more unified on the plan obviously | 16:08 |
| dansmith | and after this conversation, it feels more like "eff it, just invent new stuff each time" | 16:09 |
| *** jawad_ax_ has joined #openstack-nova | 16:09 | |
| *** jawad_axd has quit IRC | 16:09 | |
| openstackgerrit | Victor Coutellier proposed openstack/nova-specs master: Non-admin user can filter their instances by AZs https://review.opendev.org/701763 | 16:13 |
| alistarle | Hi, I was waiting for the #open-discussion part of the meeting but seems there was not today | 16:13 |
| alistarle | I have reported a blueprint about the ability for non admin to filter server by availability zone, I was very surprised that it is an admin only one : https://blueprints.launchpad.net/nova/+spec/non-admin-filter-instance-by-az | 16:14 |
| alistarle | @efried review my code and suggest me to talk about it in the meeting today, in case there will need a spec for that, but waiting for the open discussion I have written the spec :) | 16:15 |
| *** slaweq has quit IRC | 16:17 | |
| *** Sundar has joined #openstack-nova | 16:17 | |
| dansmith | alistarle: if it's an api change, then it needs to be a spec | 16:18 |
| alistarle | It is not really an api change, as everything are already available, it is just about allowing non-admin user to do something restricted to admin | 16:18 |
| dansmith | alistarle: az is a thing that is exposed to users in general, so filtering on it is probably okay, but some thought will need to be given because of things like cells | 16:18 |
| alistarle | But thanks, at least I have not wrote the specs for nothing ;) | 16:19 |
| dansmith | oh I see | 16:19 |
| dansmith | I'm still not sure it doesn't require a microversion bump, fwiw | 16:20 |
| alistarle | That's why in the code, @efried was not sure about requiring a new microversion or not, as it does not really change something in the API | 16:20 |
| dansmith | gmann: ^ | 16:21 |
| alistarle | I agree with you, in my opinion it is not required | 16:22 |
| melwitt | hm, I'd have thought that would just be to add a new policy item, not a need a new microversion | 16:22 |
| dansmith | melwitt: well, looking at the code around the change, I dunno | 16:22 |
| alistarle | There is already a policy item available, as explained in the alternative in the specs, for it does not really fit the needs | 16:22 |
| dansmith | the way non-admin search params are handled, everything is very specific | 16:22 |
| dansmith | melwitt: also, unless the user gets a 401 when they try to use it now, a microversion is the only signaling method that they can expect it to work | 16:23 |
| alistarle | Or it fit too much the need I would say ^^ | 16:23 |
| dansmith | alistarle: your assertion that policy changes during upgrade are hard is no longer valid, I think, | 16:24 |
| dansmith | since the policy file is just what you want to change, not the full list | 16:24 |
| dansmith | and if it is, your vendor is doing it wrong | 16:24 |
| alistarle | Hmm ok fine, but what about giving too much right to customer ? | 16:25 |
| dansmith | I'm not sure what that means | 16:25 |
| alistarle | They can filter on everything then, not only AZ | 16:26 |
| melwitt | oh, hm. when os_compute_api:servers:allow_all_filters was added it wasn't a new microversion https://github.com/openstack/nova/commit/7c56588647be64a2248b1f37d40369765bc6b977 and I thought you couldn't otherwise know to expect it to work | 16:26 |
| alistarle | And I really think some filter must stay admin only by default | 16:26 |
| dansmith | melwitt: hmm, is that a boolean just "you can use all filters or not" ? | 16:27 |
| melwitt | so based on that, I thought adding something like os_compute_api:servers:allow_az_filter and default it to admin-only would be in the same vein | 16:28 |
| dansmith | melwitt: the reason I'm not sure is because of all of these filters are added specifically by microversion: https://review.opendev.org/#/c/701609/3/nova/api/openstack/compute/servers.py | 16:28 |
| *** ociuhandu has joined #openstack-nova | 16:28 | |
| dansmith | melwitt: that's not what is being proposed, fwiw | 16:28 |
| alistarle | Hmm yes, but why not just allowing user to do it by default ? As AZ are a public exposed thing | 16:28 |
| melwitt | dansmith: yeah it's boolean. looking at your link now | 16:28 |
| dansmith | melwitt: ack, okay so that's not precise enough to just add the az filter for people, but I get your point on the microversion thing | 16:29 |
| melwitt | dansmith: ohhhh, I see now | 16:29 |
| dansmith | melwitt: enabling that would appear to enable a bunch of new filters for non-admins without a microversion, but those are still covered by the microversion in which they were addd | 16:29 |
| sean-k-mooney | dansmith: :) on internal call but i would like to look at this before next cycle but want to look at porting the legacy jobs and finish the image metadata prefiler before stratign anything new | 16:30 |
| dansmith | melwitt: it's just that the way the code is laid out, it seems like what filters a user can expect is very tied to microversion, hence my punt to gmann | 16:30 |
| *** mkrai has quit IRC | 16:30 | |
| dansmith | melwitt: especially since that method clearly says "this is just the non-admin search filters" | 16:31 |
| melwitt | alistarle: I had been thinking so as not to cause an undetectable change in api behavior upon upgrade but yeah I guess if az's are public across the board you're saying why not just change it. in that case I think yeah you'd need a microversion to signal the switch? | 16:31 |
| dansmith | melwitt: it could be that admins can filter on anything and that gets passed straight to the db, which is how that used to work, so just enabling it by name for the non-admins would be adding a new documented public filter, which would be a microversion | 16:31 |
| melwitt | dansmith: yeah, I think I see your point now | 16:33 |
| *** slaweq has joined #openstack-nova | 16:34 | |
| alistarle | I think that was efried point too here in the code : https://review.opendev.org/#/c/701609/ | 16:34 |
| efried | more or less, yes | 16:37 |
| *** ociuhandu has quit IRC | 16:38 | |
| *** slaweq has quit IRC | 16:40 | |
| alistarle | Ok so should I wait for review in the specs or you think It's is not required and work directly on the code ? | 16:41 |
| efried | alistarle: You can work on the code if you want, but obviously we won't consider merging it until/unless the spec is approved. | 16:42 |
| efried | I think this makes sense, though, and should be very simple even with the microversion change. I wouldn't expect it to be controversial. | 16:42 |
| dansmith | yup | 16:43 |
| alistarle | Great news :) So I will look at your comment about the tests I can add waiting for your reviews then ;) | 16:44 |
| sean-k-mooney | efried: oh by the way stephen is on PTO which is why he did not get time to review that last night | 16:45 |
| efried | ahh, thanks for the info sean-k-mooney | 16:45 |
| efried | alistarle: do you know how to make a microversion? | 16:46 |
| alistarle | Hmmm, not at all :/ | 16:48 |
| alistarle | Is there a documentation somewhere ? | 16:48 |
| efried | yes | 16:49 |
| efried | stand by | 16:49 |
| efried | alistarle: https://docs.openstack.org/nova/latest/contributor/microversions.html | 16:52 |
| *** N3l1x has joined #openstack-nova | 16:52 | |
| efried | Also, if you like to learn/work by example, you could look at previous changes that introduce new microversions. | 16:52 |
| efried | alistarle: For example, if you git blame the file you're messing with | 16:54 |
| efried | https://review.opendev.org/#/c/701609/3/nova/api/openstack/compute/servers.py | 16:54 |
| efried | you'll find that L1280-1 were added via I46edd595e7417c584106487123774a73c6dbe65e / https://review.opendev.org/#/c/648662/ | 16:54 |
| efried | That does more than you need, but it includes a microversion bump. | 16:54 |
| alistarle | Ok good, thanks for the resources ! | 16:55 |
| efried | btw, if you find incorrect or outdated information in the doc while you're working on this, please also propose corrections to the docs :) | 16:55 |
| *** tbachman has joined #openstack-nova | 16:55 | |
| *** TxGirlGeek has quit IRC | 16:56 | |
| alistarle | I will work on that then, seems to be far more change than the original change | 16:56 |
| dansmith | alistarle: the microversion bump will dwarf your actual change, for sure | 16:59 |
| dansmith | but that's how our api versioning scheme works, so the size tradeoff isn't an argument to avoid doing it | 16:59 |
| *** damien_r has quit IRC | 16:59 | |
| alistarle | No problem, I totally agree with that :) | 17:00 |
| efried | alistarle: to summarize the reason for needing a microversion, in this context: API consumers need to be able to discover whether they should expect this filter to work or not. And the mechanism for discovering that is by seeing whether a particular microversion is supported. | 17:01 |
| *** tesseract has quit IRC | 17:01 | |
| efried | especially in this case where prior to your fix (IIUC) we'll silently ignore the AZ filter, the consumer would have no good way of knowing whether it worked or not. | 17:02 |
| *** dtantsur is now known as dtantsur|afk | 17:03 | |
| dansmith | other than inspection in the detail case, but yeah | 17:03 |
| dansmith | if they're filtering by az, then O(n) inspection is probably going to be bad if it didn't work :) | 17:03 |
| efried | hence "good" | 17:04 |
| dansmith | yep | 17:05 |
| alistarle | @efrie | 17:05 |
| alistarle | @efried yes I understand better the microversion need now | 17:05 |
| *** tosky has quit IRC | 17:05 | |
| *** ociuhandu has joined #openstack-nova | 17:06 | |
| *** tosky has joined #openstack-nova | 17:06 | |
| efried | cool | 17:06 |
| *** gentoorax is now known as cyclaw | 17:07 | |
| gibi | efried: I'm +2 on the vtpm spec https://review.opendev.org/#/c/686804 | 17:08 |
| efried | gibi: thanks. Sounds like stephenfin is PTO, hopefully he'll push it when he returns. | 17:09 |
| efried | sean-k-mooney: any idea when he's back? | 17:09 |
| *** ociuhandu has quit IRC | 17:16 | |
| sean-k-mooney | am i belive tuesday so if gibi is +2 and you adresss his nits i think you can proceed without him | 17:18 |
| *** alistarle has quit IRC | 17:18 | |
| sean-k-mooney | or bauzas could bug him to take a look they when he show up at his place | 17:18 |
| sean-k-mooney | they are going skieing so if there is an acident we could be down two cores | 17:19 |
| sean-k-mooney | i remember thing in the flight back to hetrown form the first vancouver ptg that there were at least 8 cores and sevel other active comunity member on that flight | 17:20 |
| *** evrardjp has quit IRC | 17:33 | |
| *** evrardjp has joined #openstack-nova | 17:34 | |
| *** TxGirlGeek has joined #openstack-nova | 17:35 | |
| *** martinkennelly has quit IRC | 17:35 | |
| *** rpittau is now known as rpittau|afk | 17:44 | |
| *** eharney has quit IRC | 17:44 | |
| *** jawad_ax_ has quit IRC | 18:04 | |
| *** davidsha has quit IRC | 18:05 | |
| *** ociuhandu has joined #openstack-nova | 18:07 | |
| *** Sundar has quit IRC | 18:07 | |
| gmann | dansmith: melwitt efried yeah I agree that if we are changing the filters for admin/non-admin without policy it need microversion otherwise even it is restriction or extensions of allowed filters will cause interop issue. | 18:12 |
| dansmith | ++ | 18:12 |
| efried | thanks gmann | 18:12 |
| gmann | but i thought new policy 'os_compute_api:servers:allow_all_filters' solve the filtering issue for non-admin and operator can do that way. | 18:13 |
| gmann | but if changing policy is not preferable then we can reiterate on non-admin filters and may be we may find some filters which we should allow for them. so +1 on spec to iterate on those not just AZ. | 18:14 |
| openstackgerrit | Eric Fried proposed openstack/nova master: DNM: Test granular tempest changes for bug 1844568 https://review.opendev.org/701794 | 18:15 |
| openstack | bug 1844568 in tempest "[compute] "create_test_server" if networks is undefined and more than one network is present" [Medium,In progress] https://launchpad.net/bugs/1844568 - Assigned to Eric Fried (efried) | 18:15 |
| efried | ralonsoh: ^ | 18:15 |
| *** ociuhandu has quit IRC | 18:15 | |
| efried | gmann: that approach was problematic, see the patches | 18:15 |
| efried | I think tldr it gave too much power | 18:16 |
| dansmith | efried: gibi: I want to work on our marriage instead of just fight all the time: https://review.opendev.org/#/c/701796/ | 18:16 |
| *** ociuhandu has joined #openstack-nova | 18:16 | |
| dansmith | (see that and below) | 18:16 |
| efried | dansmith: I read that as "f'ing default" | 18:17 |
| dansmith | I think _fn is a fairly common suffix for function, but if you want something else that's fine | 18:18 |
| dansmith | it's short | 18:18 |
| efried | no, it's good, I was just joshing around. | 18:18 |
| dansmith | default_callback or default_function are both long to specify in a class defintion | 18:18 |
| dansmith | okay | 18:18 |
| dansmith | remember the therapist said to be direct in our communication to avoid misunderstandings | 18:19 |
| dansmith | especially in front of the children | 18:19 |
| dansmith | anyway, this'll require an ovo release before we can use either of these, and I don't even know how that happens these days, but I think we'll be able to reparent things like your new request classes, | 18:20 |
| dansmith | and get them the default behavior you want | 18:20 |
| *** ociuhandu has quit IRC | 18:21 | |
| efried | dansmith: I'm not sure I understand how this differs from using the existing syntax, considering the deepcopy we've identified previously. It looks like it might let you do extra things during the initialization that a deepcopy wouldn't account for; but afaict nobody is asking for that? | 18:21 |
| dansmith | efried: which are you talking about? | 18:21 |
| dansmith | the default_fn one? | 18:22 |
| efried | default_fn, yes. | 18:22 |
| efried | Oh, you said "below", I was waiting for another link in IRC. Looking at the other patch now.... | 18:22 |
| dansmith | the reason I actually wrote that one is more so you can provide a class than a function | 18:23 |
| openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: DNM: Test global tempest changes for bug 1844568 https://review.opendev.org/701799 | 18:23 |
| openstack | bug 1844568 in tempest "[compute] "create_test_server" if networks is undefined and more than one network is present" [Medium,In progress] https://launchpad.net/bugs/1844568 - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) | 18:23 |
| ralonsoh | efried, ^^ | 18:23 |
| *** ociuhandu has joined #openstack-nova | 18:23 | |
| efried | ralonsoh: ack | 18:23 |
| dansmith | yes, it'll still get deepcopy'd for compat, but not knowing that detail, it's more intuitive for just providing a callable thing like a class and having it instantiated | 18:24 |
| dansmith | you know, I actually might be able to eliminate the deepcopy if you provide a _fn, | 18:24 |
| dansmith | if I make the default wrapper do the deepcopy | 18:24 |
| efried | as long as that wouldn't break anyone already relying on the deepcopy... | 18:25 |
| dansmith | yeah, that's what we need to avoid, so I was just going to punt on it | 18:26 |
| dansmith | but I'm not sure it'd be legit to be relying on that subtle of a detail | 18:26 |
| sean-k-mooney | ralonsoh: is that to deal with the fact that somethins there are multile network and in somecase we race there creation if we change concurancy > 2 | 18:26 |
| ralonsoh | sean-k-mooney, yes | 18:26 |
| efried | sean-k-mooney: trying to tackle the "Multiple networks found" CI errors that are making 80% of our CI runs fail. | 18:27 |
| sean-k-mooney | ok in some cases where you are using tempest without floating ip we still need to be able to specify a network for the tempset clietn to be abel to ssh in on | 18:27 |
| sean-k-mooney | i assume that will still work | 18:27 |
| *** ociuhandu has quit IRC | 18:27 | |
| ralonsoh | sean-k-mooney, yeah, from the neutron channel | 18:28 |
| ralonsoh | http://paste.openstack.org/show/788211/ | 18:28 |
| efried | I think that's what we're trying to find out | 18:28 |
| efried | possibly "can be made to work" | 18:28 |
| sean-k-mooney | well its more we support using tempest on real clouds for interop testing in that case we suppro specify a public network where you vm can directly create ports instead of using fip | 18:30 |
| sean-k-mooney | im jsut making sure that if we create network for the compute test we can still support that when we need too | 18:30 |
| sean-k-mooney | i can move to the neuton channel by the way if that makes more sense | 18:30 |
| sean-k-mooney | i dont in prinsipal see an issue with createing a network for each trest although i know that some clould like rackspace used to have neutron but not allow tenant to call the api | 18:31 |
| efried | See, I don't understand any of that, and don't especially want to take the time to learn it. I just want to make our CI not fail for reasons unrelated to the code being tested. | 18:35 |
| sean-k-mooney | https://github.com/openstack/tempest/blob/97052fae121174b9d6daa51684c03f730dc74683/tempest/config.py#L303-L309 | 18:35 |
| sean-k-mooney | im refering to this config option by the way | 18:35 |
| efried | dansmith: added a comment in https://review.opendev.org/#/c/701795/ | 18:36 |
| efried | I like where this is going, thank you. | 18:36 |
| sean-k-mooney | and there is also a seperate config for ssh verification | 18:36 |
| sean-k-mooney | https://github.com/openstack/tempest/blob/97052fae121174b9d6daa51684c03f730dc74683/tempest/config.py#L831-L834 | 18:36 |
| dansmith | efried: yep, replying | 18:36 |
| efried | sean-k-mooney: I did notice that we're doing this explicit network setup in a different method, prepare_instance_network, based on some other conf options. | 18:37 |
| efried | but understanding what those conf options mean, and why certain tests would want to do that but others wouldn't... again, deeper than I want to go. | 18:38 |
| sean-k-mooney | well to be clear i have not fully groked what ralonsoh is change yet | 18:39 |
| ralonsoh | groked? | 18:40 |
| sean-k-mooney | i just know that there are some case where always createing neutron network might be an issue | 18:40 |
| sean-k-mooney | ralonsoh: formed a complete understanding of | 18:40 |
| sean-k-mooney | https://en.wikipedia.org/wiki/Grok | 18:40 |
| *** maciejjozefczyk has quit IRC | 18:41 | |
| ralonsoh | sean-k-mooney, maybe we can do the opposite: in those cases where the network creation is an issue, we can disable it | 18:42 |
| sean-k-mooney | well the idea fo the fixed network was so you could execute test in an enve where the network were precreated. in that case you wont have the multiple network isue anyway | 18:43 |
| sean-k-mooney | so if that config is defiend you would be able to jsut not create teh network and use the one set in the config | 18:43 |
| ralonsoh | agree | 18:44 |
| sean-k-mooney | for the ssh verificaiton im also wondering if you need to create a router too? instead of an isolated network? | 18:45 |
| *** tosky has quit IRC | 18:48 | |
| *** mgariepy has quit IRC | 18:59 | |
| sean-k-mooney | efried: ralonsoh i left a comment on the review. i think in general this would make sense just would need someone more familar to check this wont break things | 19:00 |
| sean-k-mooney | another example of when you need to use fixed netowrkisn is usign tempest with ironic and flat netorkign. so its not just for rackspace. | 19:01 |
| sean-k-mooney | that said you can deploy ironic with neutron netorks too but i still dont know how common that is | 19:01 |
| *** eharney has joined #openstack-nova | 19:01 | |
| dustinc | dansmith: Is there a chance that you can check this out and maybe wf+1? It is just a small update to the Provider Config File spec. https://review.opendev.org/#/c/693414/ | 19:16 |
| *** bbowen has quit IRC | 19:16 | |
| *** zul has quit IRC | 19:20 | |
| *** bbowen has joined #openstack-nova | 19:21 | |
| *** henriqueof1 has quit IRC | 19:22 | |
| *** pcaruana has quit IRC | 19:35 | |
| *** ociuhandu has joined #openstack-nova | 19:42 | |
| *** ralonsoh has quit IRC | 19:44 | |
| *** ociuhandu has quit IRC | 19:47 | |
| *** openstackgerrit has quit IRC | 19:59 | |
| *** damien_r has joined #openstack-nova | 20:07 | |
| *** slaweq has joined #openstack-nova | 20:07 | |
| *** damien_r has quit IRC | 20:10 | |
| *** openstackgerrit has joined #openstack-nova | 20:14 | |
| openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Add recreate test for bug 1855927 https://review.opendev.org/701756 | 20:14 |
| openstack | bug 1855927 in OpenStack Compute (nova) "_poll_unconfirmed_resizes may not retry later if confirm_resize fails in API" [Low,In progress] https://launchpad.net/bugs/1855927 - Assigned to Matt Riedemann (mriedem) | 20:14 |
| openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: Ensure source service is up before resizing/migrating https://review.opendev.org/701757 | 20:14 |
| *** lchabert has quit IRC | 20:35 | |
| *** dpawlik has quit IRC | 20:35 | |
| *** lchabert has joined #openstack-nova | 20:36 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-agents policies https://review.opendev.org/701648 | 20:41 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-agents policy https://review.opendev.org/701649 | 20:42 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing os-assisted_volume_snapshots policies https://review.opendev.org/701835 | 20:51 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-assisted_volume_snapshots policy https://review.opendev.org/701837 | 20:58 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in os-assisted_volume_snapshots policies https://review.opendev.org/701840 | 21:02 |
| *** eharney has quit IRC | 21:05 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in os-assisted_volume_snapshots policy https://review.opendev.org/701841 | 21:08 |
| *** ivve has joined #openstack-nova | 21:09 | |
| *** awalende has joined #openstack-nova | 21:12 | |
| *** awalende has quit IRC | 21:16 | |
| dansmith | efried: still around? | 21:40 |
| efried | yes | 21:40 |
| dansmith | efried: I think you're missing my point on the defaulting stuff, and mashing together the default_fn thing with the object mix-in | 21:41 |
| dansmith | they're not really related, as you'll note the mixin has nothing to do with the default_fn thing | 21:41 |
| efried | yeah, I get that they could be separate. I'm just not sure there's a reason to do that. | 21:41 |
| dansmith | the latter is just syntactic sugar in most cases, aside from the fact that the latest patch avoids copying everything all the time | 21:41 |
| dansmith | they're wholly separate | 21:42 |
| dansmith | default_fn has nothing to do with whether or not it's applied implicitly at init time | 21:42 |
| efried | I understand that | 21:42 |
| dansmith | okay | 21:43 |
| efried | but still think there's value in smashing them together. | 21:43 |
| dansmith | do you understand that I don't want to mix default-on-init into objects that are representative of row-based data structures on the other side of an rpc pipe? | 21:43 |
| efried | Yes. | 21:43 |
| efried | um, I think I do | 21:44 |
| efried | I don't think I'm suggesting otherwise. | 21:44 |
| dansmith | your latest reply seems to disagree | 21:44 |
| efried | as long as we're talking about object as opposed to class | 21:44 |
| efried | I don't think a class def of a field needs to be tied to every case where an instance of that class is used in a parent object | 21:45 |
| efried | like with nullable, where we're saying a particular instance of that class is tied to a db column that's either nullable or not. | 21:46 |
| efried | (I get that that's not all it says, but that was its impetus) | 21:46 |
| dansmith | um | 21:47 |
| dansmith | maybe you're focusing on objects that are included as fields on another object specifically? | 21:47 |
| efried | yes, that's exactly what I'm doing. | 21:47 |
| dansmith | hang on, ups | 21:48 |
| dansmith | so, I the inner object getting the behavior we want is cool, but not if it breaks the outer objects or the whole system | 21:49 |
| *** nweinber__ has quit IRC | 21:49 | |
| dansmith | and making a single field default-on-init is what I don't want to do | 21:49 |
| dansmith | which is why keying the default-on-init on the default_fn=<callable> isn't okay, IMHO | 21:50 |
| efried | I thought "making a single field default-on-init" is exactly what we *did* want to do. It indicates that we know that field isn't backed by a db column, among other things, and we want the convenience of being able to count on it being set without having to default it explicitly or have it autovivify. | 21:51 |
| dansmith | no, it's precisely what I don't want | 21:53 |
| *** bbowen has quit IRC | 21:53 | |
| dansmith | I just finished reading your reply and replied, that we definitely don't need a subclass-per-type like you surmised | 21:54 |
| *** bbowen has joined #openstack-nova | 21:54 | |
| efried | I'm playing with it now, and I think it's helping me understand the distinction you're making. | 21:54 |
| efried | gimme a couple minutes... | 21:54 |
| *** xek__ has quit IRC | 21:55 | |
| dansmith | right, so RequestSpec could become fully ephemeral IMHO | 21:56 |
| efried | okay, so really what the bottom patch does is make __init__(): obj_set_defaults() sanctioned behavior | 21:57 |
| dansmith | which means RequestSpec(NovaObject) becomes RequestSpec(EphemeralObject), and your default request_level_params gets applied at start | 21:57 |
| dansmith | yes | 21:57 |
| dansmith | categorically if inheriting from the mixin, that's the point | 21:57 |
| dansmith | "this object is one of those that doesn't represent database columns and therefore can behave defaultly" | 21:58 |
| dansmith | basically, anything that does not have NovaPersistentObject in its MRO would be okay to make ephemeral I think | 21:58 |
| efried | ...and RequestLevelParams itself would also inherit from EphemeralObject, so that its root_required/root_forbidden fields woul default at that same time? | 21:58 |
| dansmith | that ^ is our mixin for hard database affinity, although we couldn't be quite that sweeping | 21:58 |
| dansmith | yes | 21:59 |
| efried | We could do this just as easily in nova; but we want to do it in ovo to kind of send a message about preferred usage?? | 22:01 |
| dansmith | I guess we could do the init defaulting part yeah | 22:02 |
| efried | Could do it in nova as a stopgap until we can suck in the ovo release | 22:02 |
| dansmith | yup | 22:02 |
| efried | and I can see making an infrastructure that poisons use of obj_set_defaults in __init__ unless inheriting from Ephemeral | 22:02 |
| efried | ...to enforce the paradigm | 22:03 |
| dansmith | I thought it was going to involve a little more mucking with obj_set_defaults() than it did, but I was also planning both of these together | 22:03 |
| dansmith | efried: we can test for it in test_objects I think | 22:03 |
| dansmith | efried: instantiate every object (like we do) and make sure that unless it inherits from that mixin, nothing is set after init | 22:03 |
| efried | well, that doesn't prove obj_set_defaults wasn't invoked. I was thinking about making obj_set_defaults set a flag or something, then we can check for that flag in the test | 22:04 |
| dansmith | well, we have (or had)objects in the past that didn't use set_defaults, but just set them explicitly in __init_ | 22:05 |
| efried | Is that also a bad thing? | 22:05 |
| dansmith | just "self.foo = None" or something in __init__ | 22:05 |
| efried | I would think that would be okay. | 22:05 |
| dansmith | it's the exact same thing, except less obvious, so.. yes? | 22:05 |
| efried | it's just the blanket obj_set_defaults we want to avoid | 22:05 |
| dansmith | it's the *exact* same outcome :) | 22:05 |
| dansmith | you make it sound like it's just an arbitrary rule... the reason for the rule is because of the clobbering of columns | 22:06 |
| *** maciejjozefczyk has joined #openstack-nova | 22:07 | |
| efried | which is never ever desirable? | 22:07 |
| dansmith | for a row-based object, never ever | 22:08 |
| dansmith | and without a system in place, people see and copy examples, which is why we have a few in the tree | 22:08 |
| dansmith | any time I or mriedem would catch it in review, we'd get it taken out, but things slip through, | 22:08 |
| dansmith | then people see that example, figure it's okay, etc | 22:09 |
| efried | yeah, I get it. So, an enforcing test. | 22:09 |
| dansmith | so what I'm trying to say is let's make it a little more obvious, you can only do this if you inherit from ephemeral, but you better not be row-based | 22:09 |
| dansmith | all our objects used to be basically 1:1 mappings for the db, but over time we've grown a lot more of these general purpose ones, so it used to be easy to say "you can never ever do this" | 22:10 |
| efried | really, we could do the test without introducing any new semantics. Course, that would mean actually fixing the existing violations, immediately. Which we can put off if we introduce the new semantics. | 22:10 |
| efried | so, I dig. | 22:10 |
| dansmith | you mean we can do the test now and fix the instances we have, right? | 22:11 |
| dansmith | that's true, but I think the point here is, it's legit to want sane defaulting for certain types of objects so let's open the door but in a controlled way | 22:11 |
| dansmith | so anything in tree that does this now either should be inheriting from the new base, or their __init__ behavior needs be to cleaned up | 22:11 |
| efried | I mean: | 22:12 |
| efried | If we set up the test now, we have to fix the existing objects that violate the rule | 22:12 |
| efried | but | 22:12 |
| efried | If we set up the Ephemeral infrastructure, we can just blindly make those objects inherit from it so we're no worse off than we were before, and fix them "later", but new work will have to be compliant | 22:12 |
| *** maciejjozefczyk has quit IRC | 22:12 | |
| dansmith | well, I don't want to blindly do it, I want to examine each case, but there aren't that many that I know of (other than notifications I think) | 22:13 |
| dansmith | but otherwise yes | 22:13 |
| efried | okay, I'm on board. | 22:13 |
| dansmith | no reason to fix them only to open the door to the thing a patch later | 22:13 |
| *** N3l1x has quit IRC | 22:13 | |
| dansmith | So tomorrow I will copy that into nova, work on the test and see where we are | 22:14 |
| efried | just since it's in my head, would it make sense for the long-term solution to instead use a class variable on VersionedObject, EPHEMERAL=False, which ephemeral subclasses could override to True? | 22:15 |
| efried | instead of a mixin | 22:15 |
| dansmith | doing that means you could have an ephemeral parent and be non-ephemeral yourself, which would be bad | 22:16 |
| dansmith | or the opposite | 22:16 |
| dansmith | you saw my reply that nova things will not need to mixin themselves right? | 22:17 |
| dansmith | there will be a base class in base.py which mixes in and then you'll inherit from that once | 22:17 |
| dansmith | and that means we can always isinstance(thing, NovaEphemeral) to know its true nature | 22:18 |
| *** slaweq has quit IRC | 22:19 | |
| efried | as opposed to self.EPHEMERAL. But yeah, the possibility of flipping back and forth in nested subclasses is a reasonable argument against that. | 22:19 |
| dansmith | yeah I just mean you can't really fake your parentage easily | 22:20 |
| efried | though this way you can still do that, but you can only flip *to* ephemeral, and you can only do it once. | 22:20 |
| efried | unless we just don't define the mixin at all. Make NovaEphemeral a subclass of NovaObject. | 22:21 |
| efried | anyway, details. | 22:21 |
| dansmith | yeah, just being a class variable makes it changeable at runtime, vs an essential quality of the thing | 22:22 |
| dansmith | what's the argument for it being a class variable? | 22:22 |
| dansmith | less formality, maybe, but I'm going for formality here | 22:22 |
| efried | "efried doesn't like mixins"? | 22:22 |
| dansmith | oh I don't really either, but I think I was asked to make those qualities mixins because that's how python libraries do things like this without affecting interfaces as much | 22:23 |
| efried | makes it tough to figure out what's happening | 22:23 |
| efried | ye gods, have you seen the openstacksdk project? | 22:23 |
| dansmith | yep, totally agree, which is why the one class that does the mixin in base and then you single-inherit from that, knowing its done right | 22:24 |
| dansmith | mixin heaven? | 22:24 |
| efried | every class has like a dozen mixins, and it's freaking impossible to understand where you go when you invoke a method | 22:24 |
| dansmith | yeah, I'm totally with you on that | 22:24 |
| dansmith | when this was all code in nova there was a lot less mixing going on | 22:24 |
| efried | mixins, and proxy shims, and dynamic construction, and ... | 22:24 |
| dansmith | but it's a library now, so.. | 22:25 |
| *** bbowen has quit IRC | 22:32 | |
| *** bbowen has joined #openstack-nova | 22:32 | |
| *** TxGirlGeek has quit IRC | 22:36 | |
| *** rcernin has joined #openstack-nova | 22:57 | |
| *** abaindur has joined #openstack-nova | 22:58 | |
| *** mriedem has left #openstack-nova | 22:58 | |
| *** tbachman has quit IRC | 23:01 | |
| *** tkajinam has joined #openstack-nova | 23:05 | |
| *** slaweq has joined #openstack-nova | 23:20 | |
| *** slaweq has quit IRC | 23:25 | |
| *** dviroel has quit IRC | 23:28 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!