Friday, 2019-02-22

*** vishwanathj has joined #openstack-nova00:01
*** tbachman has joined #openstack-nova00:02
*** dave-mccowan has joined #openstack-nova00:04
*** wolverineav has joined #openstack-nova00:04
*** hongbin has quit IRC00:06
*** sdake_ has quit IRC00:08
*** wolverineav has quit IRC00:10
*** slaweq has joined #openstack-nova00:11
*** wolverineav has joined #openstack-nova00:12
openstackgerritMerged openstack/nova stable/queens: Note the aggregate allocation ratio restriction in scheduler docs  https://review.openstack.org/62354700:14
*** agopi has joined #openstack-nova00:15
*** slaweq has quit IRC00:16
*** wolverineav has quit IRC00:17
*** s10 has quit IRC00:22
*** sdake has joined #openstack-nova00:24
openstackgerritTakashi NATSUME proposed openstack/nova master: Add description about sort order in API ref guideline  https://review.openstack.org/62728200:30
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py  https://review.openstack.org/56615300:30
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove deprecated 'os-server-groups' policy  https://review.openstack.org/63367200:31
*** tbachman has quit IRC00:31
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove deprecated 'flavors' policy  https://review.openstack.org/63366400:31
openstackgerritTakashi NATSUME proposed openstack/nova master: Add descriptions of numbered resource classes and traits  https://review.openstack.org/62149400:31
openstackgerritTakashi NATSUME proposed openstack/nova-specs master: Fix warnings in the document generation  https://review.openstack.org/63115000:32
*** lbragstad has quit IRC00:35
*** zhubx007 has quit IRC00:37
*** zhubx007 has joined #openstack-nova00:37
*** lbragstad has joined #openstack-nova00:39
*** igordc has joined #openstack-nova00:43
*** READ10 has quit IRC00:49
*** wolverineav has joined #openstack-nova00:50
*** ileixe has joined #openstack-nova00:53
*** markvoelker has joined #openstack-nova00:53
*** dave-mccowan has quit IRC00:53
*** gyee has quit IRC00:54
*** macza has quit IRC01:04
*** tbachman has joined #openstack-nova01:16
*** takamatsu_ has joined #openstack-nova01:26
*** markvoelker has quit IRC01:26
*** takamatsu has quit IRC01:26
*** mlavalle has quit IRC01:36
*** sdake has quit IRC01:44
*** sdake has joined #openstack-nova01:45
*** sdake has joined #openstack-nova01:46
*** wolverineav has quit IRC02:01
*** Dinesh_Bhor has joined #openstack-nova02:04
*** _fragatina has quit IRC02:11
*** slaweq has joined #openstack-nova02:11
*** hamzy has joined #openstack-nova02:15
*** slaweq has quit IRC02:15
*** erlon__ has quit IRC02:19
*** markvoelker has joined #openstack-nova02:23
*** bhagyashris has joined #openstack-nova02:24
*** wolverineav has joined #openstack-nova02:25
openstackgerritYI-JIE,SYU proposed openstack/nova stable/rocky: Remove deprecated nova-consoleauth reference from doc  https://review.openstack.org/61405502:25
openstackgerritmelanie witt proposed openstack/nova master: Add user_id field to InstanceMapping  https://review.openstack.org/63335002:27
openstackgerritmelanie witt proposed openstack/nova master: WIP Add online data migration for populating user_id  https://review.openstack.org/63335102:28
openstackgerritmelanie witt proposed openstack/nova master: WIP Add get_counts() to InstanceMappingList  https://review.openstack.org/63807202:28
openstackgerritmelanie witt proposed openstack/nova master: WIP Count instances from mappings and cores/ram from placement  https://review.openstack.org/63807302:28
openstackgerritmelanie witt proposed openstack/nova master: Use instance mappings to count server group members  https://review.openstack.org/63832402:28
openstackgerritmelanie witt proposed openstack/nova master: Populate InstanceMapping.user_id during migrations and schedules  https://review.openstack.org/63857402:28
*** wolverineav has quit IRC02:29
*** wolverineav has joined #openstack-nova02:31
*** sdake has quit IRC02:32
*** wolverineav has quit IRC02:33
*** sdake has joined #openstack-nova02:34
*** sdake has quit IRC02:38
*** sdake_ has joined #openstack-nova02:39
*** ccamacho has quit IRC02:48
*** lbragstad_ has joined #openstack-nova02:54
*** lbragstad has quit IRC02:55
*** markvoelker has quit IRC02:57
*** whoami-rajat has joined #openstack-nova02:57
*** takashin has left #openstack-nova03:00
*** sdake_ has quit IRC03:03
*** psachin has joined #openstack-nova03:04
alex_xuartom: efried sorry, I only can say give a try. probably try to find out a time in weekend03:06
*** sdake has joined #openstack-nova03:10
alex_xuartom: efried and I definitely can't spell the full name of NUMA, so :)03:13
openstackgerritMerged openstack/nova stable/queens: Fix destination_type attribute in the bdm_v2 documentation  https://review.openstack.org/62687503:16
*** Kunpeng has joined #openstack-nova03:18
*** janki has joined #openstack-nova03:20
*** bryan_stephenson has joined #openstack-nova03:27
*** sdake has quit IRC03:33
* bryan_stephenson I have forked the nova repo and am editing /openstack/nova/tree/master/doc/source/user/support-matrix.ini to document a new feature we are adding. How do I test render this to check that it is OK? Simply rendering the companion .rst file does not work.03:34
openstackgerritMerged openstack/nova stable/pike: Fix destination_type attribute in the bdm_v2 documentation  https://review.openstack.org/62687603:34
openstackgerritMerged openstack/nova stable/pike: De-dupe subnet IDs when calling neutron /subnets API  https://review.openstack.org/63248003:35
*** _fragatina has joined #openstack-nova03:40
alex_xubryan_stephenson: tox -e docs03:44
*** cfriesen has quit IRC03:50
openstackgerritSundar Nadathur proposed openstack/nova master: WIP: Add Cyborg device profile groups to request spec.  https://review.openstack.org/63124303:51
openstackgerritSundar Nadathur proposed openstack/nova master: WIP: Create and bind Cyborg ARQs.  https://review.openstack.org/63124403:51
openstackgerritSundar Nadathur proposed openstack/nova master: WIP: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML.  https://review.openstack.org/63124503:51
*** bryan_stephenson has quit IRC03:51
openstackgerritMerged openstack/nova stable/queens: Do not dump all instances in the scheduler  https://review.openstack.org/62982203:53
openstackgerritMerged openstack/nova stable/queens: Fix os-simple-tenant-usage result order  https://review.openstack.org/63251603:53
*** udesale has joined #openstack-nova03:53
*** markvoelker has joined #openstack-nova03:54
*** Dinesh_Bhor has quit IRC03:55
*** _fragatina has quit IRC03:57
*** _fragatina has joined #openstack-nova03:57
*** Dinesh_Bhor has joined #openstack-nova04:00
*** slaweq has joined #openstack-nova04:11
*** ileixe has quit IRC04:13
*** tetsuro has joined #openstack-nova04:14
*** ileixe has joined #openstack-nova04:15
*** slaweq has quit IRC04:16
*** cfriesen has joined #openstack-nova04:17
*** wolverineav has joined #openstack-nova04:20
*** wolverineav has quit IRC04:24
*** markvoelker has quit IRC04:27
*** abhishekk has joined #openstack-nova04:43
*** Dinesh_Bhor has quit IRC04:47
*** lpetrut has joined #openstack-nova04:49
openstackgerritMerged openstack/os-vif master: Add function "has_table_columns" to OVSDB implementation API  https://review.openstack.org/63496704:54
*** Dinesh_Bhor has joined #openstack-nova04:54
*** _fragatina has quit IRC05:05
*** slaweq has joined #openstack-nova05:11
*** slaweq has quit IRC05:15
*** ratailor has joined #openstack-nova05:21
*** markvoelker has joined #openstack-nova05:24
*** lpetrut has quit IRC05:25
*** gmann has quit IRC05:28
*** pbing19 has joined #openstack-nova05:31
openstackgerritYongli He proposed openstack/nova master: Adds the server group info into show server detail API.  https://review.openstack.org/62147405:33
*** ociuhandu has joined #openstack-nova05:36
*** ociuhandu has quit IRC05:40
openstackgerritMerged openstack/nova master: Fill the RequestGroup mapping during schedule  https://review.openstack.org/61952805:42
openstackgerritMerged openstack/nova stable/rocky: Don't emit warning when ironic properties are zero  https://review.openstack.org/60857305:42
openstackgerritYongli He proposed openstack/nova master: Add server subresouce topology API  https://review.openstack.org/62147605:47
*** lpetrut has joined #openstack-nova05:54
*** markvoelker has quit IRC05:58
*** pbing19 has quit IRC05:58
openstackgerritFan Zhang proposed openstack/nova master: Retry after hitting libvirt error VIR_ERR_OPERATION_INVALID in live migration.  https://review.openstack.org/61227205:59
*** pbing19 has joined #openstack-nova06:02
openstackgerritAsmita Singh proposed openstack/python-novaclient master: Handle unicode multi-byte characters  https://review.openstack.org/63294206:02
*** abhishekk has quit IRC06:06
*** _fragatina has joined #openstack-nova06:07
*** _fragatina has quit IRC06:24
*** pbing19 has quit IRC06:26
*** mdbooth_ has quit IRC06:35
*** pbing19 has joined #openstack-nova06:35
*** Luzi has joined #openstack-nova06:41
*** sridharg has joined #openstack-nova06:42
*** sunnaichuan has quit IRC06:51
*** ratailor has quit IRC06:53
*** ratailor has joined #openstack-nova06:53
*** markvoelker has joined #openstack-nova06:55
*** sdake has joined #openstack-nova06:59
*** pbing19 has quit IRC06:59
*** pbing19 has joined #openstack-nova07:00
openstackgerritYury Kulazhenkov proposed openstack/nova master: remove deprecated os_brick import from ScaleIO driver  https://review.openstack.org/63859207:03
*** slaweq has joined #openstack-nova07:11
*** igordc has quit IRC07:12
*** Dinesh_Bhor has quit IRC07:13
*** ivve has joined #openstack-nova07:14
*** Dinesh_Bhor has joined #openstack-nova07:15
*** Pbing has joined #openstack-nova07:15
*** slaweq has quit IRC07:15
*** pbing19 has quit IRC07:17
*** stakeda has joined #openstack-nova07:20
*** dpawlik has quit IRC07:28
*** markvoelker has quit IRC07:28
*** sdake has quit IRC07:33
*** dpawlik has joined #openstack-nova07:39
*** ShilpaSD has quit IRC07:48
openstackgerritLuyao Zhong proposed openstack/nova master: object: Add pmem_namespaces field to the NUMACell obj  https://review.openstack.org/63454707:51
openstackgerritLuyao Zhong proposed openstack/nova master: object: Add virtual_pmems fields to the InstanceNUMACell obj  https://review.openstack.org/63454807:51
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Enable driver configures PMEM namespace when initiating libvirt driver  https://review.openstack.org/63454907:51
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Update PMEM namespaces info and usage  https://review.openstack.org/63455007:51
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: report pmem namespaces resources by provider tree  https://review.openstack.org/63455107:51
openstackgerritLuyao Zhong proposed openstack/nova master: API: parse pmem related flavor extra spec  https://review.openstack.org/63455207:51
openstackgerritLuyao Zhong proposed openstack/nova master: scheduler: translate virtual pmems request to placement request group  https://review.openstack.org/63455307:51
openstackgerritLuyao Zhong proposed openstack/nova master: update _numa_fit_instance_cell for the support of virtual_pmems  https://review.openstack.org/63455407:51
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: boot VM with vpmems and cleanup vpmems when destroying  https://review.openstack.org/63455507:51
openstackgerritLuyao Zhong proposed openstack/nova master: support VM resizing with vpmem data migration  https://review.openstack.org/63455607:51
openstackgerritya.wang proposed openstack/nova master: Select cpu model from a list of cpu models  https://review.openstack.org/63783407:52
*** belmoreira has quit IRC07:54
*** ratailor has quit IRC07:57
*** ratailor has joined #openstack-nova07:58
*** belmoreira has joined #openstack-nova08:05
*** lbragstad_ has quit IRC08:07
*** slaweq has joined #openstack-nova08:08
*** awalende has joined #openstack-nova08:12
*** tkajinam has quit IRC08:13
*** Pbing has quit IRC08:13
openstackgerritYongli He proposed openstack/nova master: Adds the server group info into show server detail API.  https://review.openstack.org/62147408:17
*** tssurya has joined #openstack-nova08:18
*** sdake has joined #openstack-nova08:18
*** tesseract has joined #openstack-nova08:20
*** yaawang has joined #openstack-nova08:24
*** markvoelker has joined #openstack-nova08:25
*** cdent has joined #openstack-nova08:30
*** mdbooth has joined #openstack-nova08:32
*** jiaopengju has quit IRC08:54
*** dtantsur|afk is now known as dtantsur08:58
*** markvoelker has quit IRC08:59
*** cfriesen has quit IRC09:07
*** ociuhandu has joined #openstack-nova09:10
*** panda|ruck|off is now known as panda|ruck09:24
*** sdake has quit IRC09:26
openstackgerritMark Goddard proposed openstack/nova stable/queens: Don't emit warning when ironic properties are zero  https://review.openstack.org/60861109:27
*** cdent has quit IRC09:31
*** tetsuro has quit IRC09:33
*** snevi has joined #openstack-nova09:33
*** jaosorior has quit IRC09:33
*** ivve has quit IRC09:34
*** jaosorior has joined #openstack-nova09:35
*** cdent has joined #openstack-nova09:36
*** yan0s has joined #openstack-nova09:41
*** helenaAM has joined #openstack-nova09:46
*** stakeda has quit IRC09:47
stephenfinlyarwood: Could you do me the honours? https://review.openstack.org/63691809:47
stephenfinHonour?09:47
stephenfinHmm...09:47
*** stephenfin is now known as finucannot09:48
openstackgerritBalazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations  https://review.openstack.org/63795509:50
openstackgerritBalazs Gibizer proposed openstack/nova master: cache neutron ports in heal allocation  https://review.openstack.org/63820709:50
*** bhagyashris has quit IRC09:55
*** markvoelker has joined #openstack-nova09:56
openstackgerritBalazs Gibizer proposed openstack/nova master: Follow up for I0c764e441993e32aafef0b18049a425c3c832a50  https://review.openstack.org/63851709:57
*** lyarwood is now known as lyaaaaarwood09:59
lyaaaaarwoodfinucannot: will do09:59
*** dtantsur is now known as dtantsur|brb10:01
*** takamatsu_ has quit IRC10:04
*** gibi is now known as giblet10:04
*** takamatsu has joined #openstack-nova10:05
openstackgerritYongli He proposed openstack/nova master: Add server subresouce topology API  https://review.openstack.org/62147610:22
*** Dinesh_Bhor has quit IRC10:23
*** takamatsu_ has joined #openstack-nova10:23
*** ileixe has quit IRC10:24
*** takamatsu has quit IRC10:24
yongliheHi, jaypipes,  you might want to comment  https://review.openstack.org/#/c/621474/21,  you working on that spec so much.  And thanks.10:25
*** Dinesh_Bhor has joined #openstack-nova10:25
*** markvoelker has quit IRC10:28
*** sridharg has quit IRC10:30
*** rcernin has quit IRC10:31
*** sridharg has joined #openstack-nova10:43
*** moshele has joined #openstack-nova10:47
*** takamatsu_ has quit IRC10:48
*** takamatsu has joined #openstack-nova10:49
openstackgerritLuyao Zhong proposed openstack/nova master: object: Add pmem_namespaces field to the NUMACell obj  https://review.openstack.org/63454710:51
openstackgerritLuyao Zhong proposed openstack/nova master: object: Add virtual_pmems fields to the InstanceNUMACell obj  https://review.openstack.org/63454810:51
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Enable driver configures PMEM namespace when initiating libvirt driver  https://review.openstack.org/63454910:51
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Update PMEM namespaces info and usage  https://review.openstack.org/63455010:51
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: report pmem namespaces resources by provider tree  https://review.openstack.org/63455110:51
openstackgerritLuyao Zhong proposed openstack/nova master: API: parse pmem related flavor extra spec  https://review.openstack.org/63455210:51
openstackgerritLuyao Zhong proposed openstack/nova master: scheduler: translate virtual pmems request to placement request group  https://review.openstack.org/63455310:51
openstackgerritLuyao Zhong proposed openstack/nova master: update _numa_fit_instance_cell for the support of virtual_pmems  https://review.openstack.org/63455410:51
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: boot VM with vpmems and cleanup vpmems when destroying  https://review.openstack.org/63455510:51
openstackgerritLuyao Zhong proposed openstack/nova master: support VM resizing with vpmem data migration  https://review.openstack.org/63455610:51
*** ccamacho has joined #openstack-nova10:54
*** erlon has joined #openstack-nova10:54
*** ccamacho has quit IRC10:54
*** takamatsu has quit IRC10:54
*** takamatsu has joined #openstack-nova10:58
*** udesale has quit IRC10:59
openstackgerritAndrey Volkov proposed openstack/nova master: Check hosts have no instances for AZ rename  https://review.openstack.org/50920611:04
*** macza has joined #openstack-nova11:09
openstackgerritSurya Seetharaman proposed openstack/nova-specs master: Support adding the reason behind a server lock  https://review.openstack.org/63862911:09
*** sdake has joined #openstack-nova11:11
*** tosky has joined #openstack-nova11:12
*** macza has quit IRC11:14
openstackgerritStephen Finucane proposed openstack/os-vif master: docs: Add API docs for VIF types  https://review.openstack.org/63700911:21
openstackgerritStephen Finucane proposed openstack/os-vif master: docs: Add API docs for profile, datapath offload types  https://review.openstack.org/63839511:21
openstackgerritStephen Finucane proposed openstack/os-vif master: docs: Start using sphinx.ext.autodoc for VIF types  https://review.openstack.org/63840411:21
openstackgerritStephen Finucane proposed openstack/os-vif master: doc: Use sphinx.ext.todo for profile, datapath offload types  https://review.openstack.org/63840511:21
*** markvoelker has joined #openstack-nova11:25
*** Dinesh_Bhor has quit IRC11:38
*** priteau has joined #openstack-nova11:46
*** tbachman has quit IRC11:48
*** gmann has joined #openstack-nova11:49
*** Dinesh_Bhor has joined #openstack-nova11:55
*** Dinesh_Bhor has quit IRC11:57
*** erlon_ has joined #openstack-nova11:58
*** markvoelker has quit IRC11:59
*** erlon has quit IRC11:59
*** moshele has quit IRC11:59
*** janki has quit IRC12:01
*** sdake has quit IRC12:03
*** _fragatina has joined #openstack-nova12:03
*** sdake_ has joined #openstack-nova12:04
*** dpawlik has quit IRC12:16
*** udesale has joined #openstack-nova12:16
*** dpawlik has joined #openstack-nova12:23
openstackgerritMichal Arbet proposed openstack/nova master: Fix python3 compatibility of rbd get_fsid  https://review.openstack.org/63522012:26
*** priteau has quit IRC12:31
*** dtantsur|brb is now known as dtantsur12:35
*** ivve has joined #openstack-nova12:35
openstackgerritArtom Lifshitz proposed openstack/nova-specs master: Clarify upgrade situation in NUMA live migration  https://review.openstack.org/63865312:38
openstackgerritArtom Lifshitz proposed openstack/nova master: Remove _legacy_dict methods  https://review.openstack.org/63621012:38
openstackgerritArtom Lifshitz proposed openstack/nova master: Add migration param to check_can_live_migrate_destination  https://review.openstack.org/63460512:38
openstackgerritArtom Lifshitz proposed openstack/nova master: Introduce live_migration_claim()  https://review.openstack.org/63566912:38
openstackgerritArtom Lifshitz proposed openstack/nova master: Use live_migration_claim() to check dest resources  https://review.openstack.org/63460612:38
openstackgerritArtom Lifshitz proposed openstack/nova master: New objects to transmit NUMA config from dest to source  https://review.openstack.org/63482712:38
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: Make dest send NUMAMigrateData to the source  https://review.openstack.org/63482812:38
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: update NUMA-related XML on the source  https://review.openstack.org/63522912:38
openstackgerritArtom Lifshitz proposed openstack/nova master: [WIP] Drop MoveClaim in rollback_live_migration_at_destination  https://review.openstack.org/63865412:38
*** priteau has joined #openstack-nova12:39
*** ccamacho has joined #openstack-nova12:39
*** ratailor has quit IRC12:45
*** liuyulong has joined #openstack-nova12:49
*** _pewp_ has quit IRC12:51
*** _pewp_ has joined #openstack-nova12:52
*** markvoelker has joined #openstack-nova12:56
*** ociuhandu has quit IRC13:01
*** tbachman has joined #openstack-nova13:06
*** pbing19 has joined #openstack-nova13:07
*** pbing19 has quit IRC13:08
*** pbing19 has joined #openstack-nova13:09
*** mriedem has joined #openstack-nova13:10
*** panda|ruck is now known as panda|lunch13:10
*** dave-mccowan has joined #openstack-nova13:18
*** pbing19 has quit IRC13:20
*** sambetts_ has quit IRC13:21
*** sambetts_ has joined #openstack-nova13:24
*** udesale has quit IRC13:25
*** markvoelker has quit IRC13:28
*** jmlowe has quit IRC13:30
*** moshele has joined #openstack-nova13:33
*** psachin has quit IRC13:35
*** hamzy has quit IRC13:35
mriedemgiblet: some questions in https://review.openstack.org/#/c/569459/13:37
*** cfriesen has joined #openstack-nova13:38
*** hamzy has joined #openstack-nova13:40
*** awaugama has joined #openstack-nova13:41
gibletmriedem: thanks, I will check it soon13:41
*** moshele has quit IRC13:41
*** udesale has joined #openstack-nova13:41
gibletmriedem: I've also looked into the Selection object usage instead of querying placement about allocations. It is easy so I will push a fup13:42
gibletmriedem: I also thinking about storing the provider_summaries in the Selection object to avoid the trait query as well13:42
gibletit is a bit more code as it needs a version bump on the Selection object13:42
*** dave-mccowan has quit IRC13:43
*** artom is now known as temka13:43
*** moshele has joined #openstack-nova13:43
*** agopi has quit IRC13:44
*** dave-mccowan has joined #openstack-nova13:44
mriedemgiblet: yeah that's why in my fup i said short-term optimization (cache) and long-term (provider summary traits -> Selection object)13:44
mriedemgiblet: as for reading the allocations off the Selection.allocation_request, jaypipes did warn yesterday that if that request format changes, it could break your code (but we have the version of the format so i guess we could deal with that when the time comes, if it comes)13:45
mriedemtoday the allocation request mirrors the response, which was a smart move looking back (thanks cdent)13:45
*** moshele has quit IRC13:45
openstackgerritAdam Spiers proposed openstack/nova master: Add detection of SEV support from QEMU/AMD-SP/libvirt on AMD hosts  https://review.openstack.org/63385513:46
cdentdon't that me, thank "HTTP API BEST PRACTICES"... or something13:46
openstackgerritMerged openstack/nova stable/queens: Migrate nova v2.0 legacy job to zuulv3  https://review.openstack.org/62057813:46
gibletmriedem: noted the possible format change. I can put a NOTE to the allocation_request field definition to warn the future developer13:46
openstackgerritMerged openstack/nova stable/queens: tox: Don't write byte code (maybe)  https://review.openstack.org/63691813:46
mriedemkashyap: this looks like a new one for the gate http://logs.openstack.org/48/631948/9/check/tempest-full-py3/e2ae3fb/controller/logs/screen-n-cpu.txt.gz?level=TRACE#_Feb_21_17_24_48_56268913:48
gibletmriedem: will there be separate Selection object for each instance created in the same multi-create request? or in other words can I use a non ovo field on the Selection object as a trait cache?13:48
mriedemselections are 1:1 with the requested instances we're building yes13:49
mriedembecause the 10th instance in the request could have a different primary and alternate hosts b/c the first 9 consumed all of the resources on some other hosts13:49
gibletmriedem: OK, then I need a separate cache13:49
*** ccamacho has quit IRC13:50
mriedemyeah - there are already some caches used in schedule_and_build_instances13:50
mriedemfor host mappings and az queries13:50
gibletmriedem: ahh I see. That is a pattern I can follow13:50
*** ccamacho has joined #openstack-nova13:51
*** sdake_ has quit IRC13:51
gibletmriedem: do we handle re-schedule during multi-create in a special way or is it the same re-schedule code path? We have to call _fill_provider_mapping for the re-schedule too13:51
mriedemsame as single instance13:52
mriedemthe reschedule just gets 1 instance13:52
mriedema list of 1 i should say13:52
mriedemthat is rpc cast from compute here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L202413:53
gibletmriedem: then the cache would not work for re-schedule but the Selection object based soluton would work as re-schedule gets the Selection object too13:53
mriedemwe don't need the cache for reschedule since it's 1 instance13:54
mriedemthe cache is more for multi-create13:54
*** agopi has joined #openstack-nova13:54
mriedembut yeah again, short and long term optimizations13:54
gibletif half of a multi-create hit the same faulty compute then we got a bunch of re-schedule at the same time13:54
gibletbut anyhow I will do a local cache for Stein as time is sort13:55
mriedemexactly13:55
gibletmriedem: thanks for the help!13:55
mriedemSelection object change to stash the traits will be an rpc change13:55
mriedemnp13:55
gibletmriedem: good point about the rpc change. I don't want to start that 2 weeks before FF13:56
mriedemand i dont want to have to think about it right now either :)13:56
*** mlavalle has joined #openstack-nova13:56
*** agopi_ has joined #openstack-nova13:58
gibletmriedem: mentioning RPC change. Does the extension of InstancePCIRequest ovo also needs an rpc bump, here? https://review.openstack.org/#/c/625310/2313:58
mriedemthe object version bump is the rpc change13:59
gibletmriedem: then we still have this rpc change in the bandwidth series unfortunately13:59
mriedemsure i think that's fine - it's at least code you've already tested / demo'ed yeah?14:00
*** agopi has quit IRC14:00
mriedemi'd like to avoid *new* complexity with 2 weeks left14:00
gibletmriedem: I've tested that code in the functional env. Not demoed yet as that code was not ready for the last demo in Berlin14:01
gibletI agree to avoid new complexity added. heal allocation is still not finished and that has its own complexity14:02
gibletI need to run some downstream errands, brb14:03
*** dave-mccowan has quit IRC14:05
*** lbragstad_ has joined #openstack-nova14:05
*** lbragstad_ is now known as lbragstad14:07
mriedemdansmith: you want to make sure this is ok https://review.openstack.org/#/c/636210/ - i think it's just removing dead code at this point14:10
*** panda|lunch is now known as panda14:13
aspiersmriedem, efried: the capabilities patch makes adding an SEV capability extremely easy! in case you're curious: https://github.com/aspiers/nova/commit/sev-trait14:15
aspiersI can't submit to Gerrit yet because it depends on two patches which are not dependent on each other14:15
*** sdake has joined #openstack-nova14:17
*** _pewp_ has quit IRC14:18
*** _pewp_ has joined #openstack-nova14:20
*** panda is now known as panda|rcuk14:21
*** panda|rcuk is now known as panda|ruck14:21
*** dpawlik has quit IRC14:23
*** priteau has quit IRC14:25
*** markvoelker has joined #openstack-nova14:25
*** eharney has joined #openstack-nova14:25
mriedemcool, that's kind of the idea14:27
mriedemyou could break that down by moving the capabilities to the driver instance level rather than the class14:27
mriedemi think that would fix an issue i had in libvirt driver tests with the multiattach stuff14:27
aspiersisn't that what I did?14:28
* aspiers is confused14:28
mriedemyou did, but in the same patch that adds the amd sev capability14:28
mriedemanyway nvm14:28
aspiersoh, in a separate patch14:28
aspiersyeah, I did wonder about that14:28
aspiershappy to split it out! if you think it's worth it14:28
mriedemit's fine to leave it14:29
aspiersI'll do it :)14:29
aspiersah, I remember my thinking now14:29
aspiersthis is only required for drivers with dynamic capabilities, right?14:29
aspiersbut I missed the fact that multiattach is already dynamic14:30
aspierssmaller patches -> easier quicker reviews14:30
aspiersso I'll do it14:30
openstackgerritMerged openstack/nova master: Follow up for I0c764e441993e32aafef0b18049a425c3c832a50  https://review.openstack.org/63851714:37
*** awalende has quit IRC14:37
*** awalende has joined #openstack-nova14:38
*** dave-mccowan has joined #openstack-nova14:38
*** bnemec is now known as beekneemech14:39
aspiersmriedem: done https://github.com/aspiers/nova/compare/sev-deps...aspiers:sev-trait14:39
*** priteau has joined #openstack-nova14:40
mriedemaspiers: so why are these in github and not gerrit?14:40
aspiersmriedem: because they depend on two unmerged patches which are not dependent on each other14:41
mdboothlyaaaaarwood: I think this needs a refactor into a separate test class: https://review.openstack.org/#/c/637527/14:41
aspiersmriedem: so I can't submit them in a series, because that would introduce an artificial dependency14:41
aspiersand AFAIK Depends-On is only for cross-repo dependencies14:42
mriedemwhat are the other 2 patches?14:42
aspiershttps://review.openstack.org/#/c/538498/ and https://review.openstack.org/#/c/633855/14:43
aspiersthey are mentioned in the commit message14:43
*** awalende has quit IRC14:43
sean-k-mooneyaspiers: it works withing the same repo too but when its in teh same repo it makes more sense to rebase on top of the patch14:43
mriedemaspiers: your sev stuff can be rebased on top of https://review.openstack.org/#/c/538498/ yes?14:43
aspierssean-k-mooney: agreed14:43
*** sdake has quit IRC14:43
mdboothaspiers: The practical solution is to have the artificial dependency.14:43
mriedemyeah i'd just stack these all up14:43
mriedemwith https://review.openstack.org/#/c/538498/ at the bottom14:43
aspiersmriedem, mdbooth: OK I'm totally fine with that if you guys are, thanks14:43
mriedemand then https://review.openstack.org/#/c/633855/14:43
mriedemand then the stuff that sets the capability14:44
aspiersyup14:44
aspierswill do now14:44
dansmithmriedem: done14:45
mdboothaspiers: If you find that a patch which isn't on the bottom gets +2s you can always rebase it to the bottom. If it's a clean rebase you'll retain the +2s and it can merge.14:45
aspiersmdbooth: nice tip, thanks14:45
mdboothaspiers: It's not great, but it's kinda ok and doesn't usually come up that much.14:45
aspiersI suspect Gerrit 2.16 will handle this better, as I mentioned the other day14:46
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Don't emit warning when ironic properties are zero  https://review.openstack.org/60861114:46
*** sdake has joined #openstack-nova14:46
aspiersOh, that wasn't in this channel14:46
*** dklyle has quit IRC14:46
*** david-lyle has joined #openstack-nova14:46
lyaaaaarwoodmdbooth: pretty sure you can migrate between two backends on the same host14:46
lyaaaaarwoodmdbooth: that's what I've been testing locally at least14:47
lyaaaaarwoodmdbooth: they don't need to be different c-vols14:47
aspiersAh, it was :-) mdbooth: in case you missed it: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-02-12.log.html#t2019-02-12T22:08:5614:47
lyaaaaarwoodmdbooth: https://developer.openstack.org/api-ref/block-storage/v3/index.html?expanded=migrate-a-volume-detail#migrate-a-volume - when the docs talk about migrating to a host they mean hostname@backend where hostname can be the same host still.14:50
mdboothlyaaaaarwood: Isn't that retype?14:52
kashyapmriedem: Looking ... my IRC proxy dropped me off of Freenode14:53
kashyapmriedem: Did you file a bug yet?  Or shall I?14:53
*** hongbin has joined #openstack-nova14:54
lyaaaaarwoodmdbooth: https://developer.openstack.org/api-ref/block-storage/v3/index.html?expanded=migrate-a-volume-detail,complete-migration-of-a-volume-detail,retype-a-volume-detail#retype-a-volume - that's a totally different API14:54
lyaaaaarwoodmdbooth: where you can do the same thing, just with types that have backends defined in them.14:55
lyaaaaarwoodmdbooth: and again they take the form of hostname@backend14:55
lyaaaaarwoodmdbooth: so you can migrate between backends on the same host14:55
lyaaaaarwood^ sorry retype14:55
*** efried is now known as fried_rice14:56
openstackgerritAdam Spiers proposed openstack/nova master: Change LibvirtDriver.capabilities to an instance variable  https://review.openstack.org/63867714:56
mdboothlyaaaaarwood: So retype and migrate are literally identical operations, just with different semantics for specifying the source and dest?14:56
mriedemkashyap: https://bugs.launchpad.net/nova/+bug/181732414:56
openstackLaunchpad bug 1817324 in OpenStack Compute (nova) "Intermittent "Failed to start libvirt guest: libvirt.libvirtError: monitor socket did not show up: No such file or directory" failures in the gate" [Undecided,Confirmed]14:56
lyaaaaarwoodmdbooth: yeah pretty much14:57
kashyapThanks14:57
mdboothlyaaaaarwood: I don't understand, tbh.14:57
openstackgerritAdam Spiers proposed openstack/nova master: Add detection of SEV support from QEMU/AMD-SP/libvirt on AMD hosts  https://review.openstack.org/63385514:58
*** markvoelker has quit IRC14:59
kashyapmriedem: On your comment in the bug; for that failure, the interesting stuff won't be in the QEMU guest log; it would be in the libvirt <-> QEMU interactions log (which the Gate captures)14:59
lyaaaaarwoodmdbooth: with migrate you provide the host (hostname@backend) you want to migrate to. With retype you provide a type you'd like to migrate to that can optionally contain a host (hostname@backend) extra spec that moves the volume14:59
mriedemkashyap: i looked in the libvirtd log and didn't really see anything interesting15:00
mriedemkashyap: besides stuff like it created the monitor for that instance and events weren't getting handled, something like that15:00
openstackgerritAdam Spiers proposed openstack/nova master: Add new "supports_amd_sev" capability to libvirt driver  https://review.openstack.org/63868015:01
kashyapNod; /me still downloading the log15:01
*** ccamacho has quit IRC15:01
*** jmlowe has joined #openstack-nova15:02
*** _pewp_ has quit IRC15:03
*** _pewp_ has joined #openstack-nova15:04
*** mchlumsky has quit IRC15:08
fricklermriedem: anything I can do to help with https://bugs.launchpad.net/nova/+bug/1815082 ?15:09
openstackLaunchpad bug 1815082 in OpenStack Compute (nova) ""DBNonExistentTable: (sqlite3.OperationalError) no such table: services" when starting nova-metadata under uwsgi" [Medium,In progress] - Assigned to Matt Riedemann (mriedem)15:09
fricklerI'm also wondering whether this may be a duplicate actually https://bugs.launchpad.net/devstack/+bug/181401615:09
openstackLaunchpad bug 1814016 in devstack "Subnode required CELLSV2_SETUP=superconductor to be explicitly set" [Undecided,New]15:09
*** mchlumsky has joined #openstack-nova15:10
mriedemfrickler: ah i forgot about that15:15
*** Luzi has quit IRC15:16
*** _pewp_ has quit IRC15:17
fricklermriedem: o.k., I'm assuming I did my part of the job, then. ;)15:17
mriedemwell n-api-meta is hitting conductor http://logs.openstack.org/77/635577/2/check/tempest-full/152e5bc/controller/logs/screen-n-api-meta.txt.gz#_Feb_08_16_53_34_57298015:18
mriedemi think15:18
*** udesale has quit IRC15:18
mriedembut it seems that the conductor it's hitting isn't up yet15:18
*** Sundar has joined #openstack-nova15:19
mriedemwe start n-api-meta here15:20
mriedemhttp://logs.openstack.org/77/635577/2/check/tempest-full/152e5bc/controller/logs/devstacklog.txt.gz#_2019-02-08_16_52_32_21515:20
fricklerhttp://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/nova#n109615:20
fricklerthat's in start_nova_rest, way before _conductor, yes15:20
mriedemyeah n-super-cond is started here:15:21
mriedemhttp://logs.openstack.org/77/635577/2/check/tempest-full/152e5bc/controller/logs/devstacklog.txt.gz#_2019-02-08_16_52_36_72115:21
fricklerprobably n-api-meta should idle a bit and retry15:21
*** sdake has quit IRC15:21
fricklereven if we fix the order in devstack, we can't assume deployers will fine tune this everywhere15:22
mriedemstart_nova_rest is kind of weird - it starts nova-network as well which has always needed conductor to start first15:22
kashyapmriedem: Oops: I think it is due to two 'pty' consoles getting reated...see lines 87-97 (from the n-cpu log): http://paste.openstack.org/show/745736/15:22
* kashyap will dig further after two meetings15:23
*** sdake has joined #openstack-nova15:23
mriedemkashyap: would that be due to your recent version bump change?15:23
mriedemwhich messed with the console code?15:23
kashyapYes, very much likely :-(15:23
kashyapI fixed the s390x case, and I didn't see this at all in normal runs15:23
kashyapSigh15:23
kashyapThis seems to be 'isa-serial'-related15:24
mriedemsomething something risk of doing this at the end of a release...15:24
*** priteau has quit IRC15:27
*** mrch_ has quit IRC15:28
kashyapYeah, I know what you mean.  I made at least 3 folks to review, including the last person who reworked that code15:28
*** mrch_ has joined #openstack-nova15:28
kashyapI'll work towards fixing it as quickly as I can.15:28
*** jangutter has quit IRC15:30
*** jobewan has joined #openstack-nova15:31
mriedemfrickler: i think we're hitting the wrong conductor maybe15:31
mriedemfrickler: conductor is effectively started at 16:52:4015:32
mriedemn-super-cond that is15:32
mriedemn-api-meta times out at 16:53:3415:32
mriedemnote there is a 60 second rpc_response_timeout on that db query15:32
*** david-lyle is now known as dklyle15:33
mriedemproblem is i'm not exactly sure which conductor n-api-meta is trying to hit15:33
mriedemneed to push a change to dump the config on startup before trying to hit the db15:35
kashyapmriedem: Okay, one thing eliminated: that XML bit is a red-herring; it's not the cause.15:36
kashyap(And the patch for consoles is still correct.)15:36
*** mrch_ has quit IRC15:37
kashyap(The seemingly two consoles is due to a silly backward compantbiility thing in libvirt)15:37
openstackgerritMatt Riedemann proposed openstack/nova master: Set the conductor indirection API when running nova-metadata under uwsgi  https://review.openstack.org/63557715:40
openstackgerritMatt Riedemann proposed openstack/nova master: Dump config options on wsgi startup earlier  https://review.openstack.org/63869115:40
*** _pewp_ has joined #openstack-nova15:40
*** dklyle has quit IRC15:43
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: tox: Don't write byte code (maybe)  https://review.openstack.org/63691915:43
*** david-lyle has joined #openstack-nova15:43
kashyapmriedem: Do you know if these Ubuntu machines are using AppArmour?15:47
*** lbragstad is now known as elbragstad15:47
sean-k-mooneykashyap: its installed by default so proably15:48
mriedemkashyap: that's a question for infra15:49
*** jmlowe has quit IRC15:49
kashyapOkay15:51
kashyapTalking to a libvirt dev, the core problem is QEMU failed to start, and consequently failed to create the socket.15:51
kashyapNow trying to determine why15:51
*** markvoelker has joined #openstack-nova15:56
kashyapsean-k-mooney: Thanks15:57
*** jmlowe has joined #openstack-nova16:02
*** belmoreira has quit IRC16:08
gibletmriedem: regarding your comments in https://review.openstack.org/#/c/569459/67/nova/network/neutronv2/api.py16:10
gibletmriedem: i did not consider live-migration or other server move operation there16:11
gibletmriedem: I think  _update_port_binding_for_instance() needs to change when we enable server move operations16:11
*** hemna has joined #openstack-nova16:11
gibletmriedem: the RP uuid fulfilling a port's allocation will definitly change when we move the server to another host16:12
kashyapmriedem: BTW, so this kind of completely silent failure is typically caused due to SELinux/AppArmour denials16:18
kashyapBut that's rather difficult to debug in OpenStack envs...16:19
*** yan0s has quit IRC16:19
kashyapI'd be interested if this is reproducible at all -- should get to know it is by Monday16:19
*** jaypipes is now known as leakypipes16:20
openstackgerritMatt Riedemann proposed openstack/nova master: Log why rescheduling is disabled  https://review.openstack.org/63869916:21
openstackgerritMatt Riedemann proposed openstack/nova master: Remove misleading comment from _move_operation_alloc_request()  https://review.openstack.org/63870016:21
mriedemleakypipes: dansmith: some fun from the past ^16:21
*** mrch_ has joined #openstack-nova16:25
sean-k-mooneykashyap: wouldnt that show up in the audit.log16:26
kashyapsean-k-mooney: No idea what AppArmour does; let me see, though16:27
kashyapI know how to troubleshoot SELinuz16:27
sean-k-mooneyboth used to show up in demesg then they moved to journalctl but were also loged to the audit.log under /var/log i think16:28
*** markvoelker has quit IRC16:28
*** agopi_ is now known as agopi16:29
sean-k-mooneythis is also a kernel bug in ubuntu 18.04 that causes nested virt to not work but if that iss the issue the core dump in dmesg telegraphfs the issue rather quirckly.16:31
*** macza has joined #openstack-nova16:31
kashyapsean-k-mooney: Where is the audit.log here: http://logs.openstack.org/48/631948/9/check/tempest-full-py3/e2ae3fb/controller/logs/16:32
sean-k-mooneykashyap: this is the ubuntu issue https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177318416:32
openstackLaunchpad bug 1773184 in linux (Ubuntu Bionic) "Starting a KVM guest in a guest (nested VM) crash the kernel" [High,Triaged]16:32
* kashyap is blnd16:32
dansmithbland?16:32
dansmithblonde?16:32
kashyap:D16:32
kashyapGot dansmithed ... s/blnd/blind :D16:33
sean-k-mooney i dont think its copied16:33
kashyapLet me check with Clark16:33
gibletmriedem: replied to your question in https://review.openstack.org/#/c/56945916:34
kashyapsean-k-mooney: BTW, upstream KVM list has a huge nested virt patch series; so no idea if that fixes16:35
kashyapsean-k-mooney: I've seen that stack trace, though16:35
sean-k-mooneykashyap: i have it https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1773184 on one of my servers byt the way so i know that iss an issue with the ubunut cloud images. that said i think its realteded to my bios/microcode16:35
openstackLaunchpad bug 1773184 in linux (Ubuntu Bionic) "Starting a KVM guest in a guest (nested VM) crash the kernel" [High,Triaged]16:35
sean-k-mooneykashyap: well for me swaping out the vanial 4.20 kernel in the l1 guest allowed the l2 guest to boot16:36
sean-k-mooneyif i use centos on the same host for the l1 guest spanwnign the l2 guest crashes the l1 guest and it reboot16:36
kashyapOkay, my cardinal rule when setting up nested virt for dev envs: ensure L0, L1 (and even L2) kernels to be as similiar (and as newer as they can)16:37
openstackgerritBalazs Gibizer proposed openstack/nova master: Use Selection object to fill request group mapping  https://review.openstack.org/63871116:37
sean-k-mooneyi was useing the same kernel for l0 and l1 originally16:37
kashyapsean-k-mooney: The test combination explosion is one of the difficult things16:37
sean-k-mooney with a cirros image for l216:38
sean-k-mooneyya16:38
*** imacdonn has quit IRC16:38
dansmithmriedem: got it16:38
*** imacdonn has joined #openstack-nova16:38
sean-k-mooneyi honestly have never had issue with nested vert in the past16:38
kashyapsean-k-mooney: The "past" is a fuzzy word.  Precisely for these reasons I used to track all the kernel bugs I filed for nVMX: https://kashyapc.fedorapeople.org/kernel-kvm-bugs.txt16:40
kashyap(They're all fixed, though.  And it hasn't been updated in ages)16:40
*** gyee has joined #openstack-nova16:40
mriedemthe more i dig into https://bugs.launchpad.net/nova/+bug/1790204 the more it's a spec at this point16:45
openstackLaunchpad bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged]16:45
mriedemi imagine this is all dead code since queens or at least rocky https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L14016:47
sean-k-mooneykashyap: let me rephsase this is the first time i have ever personally it a nested vert bug in the 5-6 years i have used nested virt by defualt16:47
mriedembecause we should never have to double up allocations on the same consumer (instance) during scheduling since we moved the allocations on the source node to the migration record,16:47
*** itlinux has joined #openstack-nova16:47
mriedemexcept maybe evacuate...16:47
kashyapsean-k-mooney: Ah, okay. :-)16:48
melwitto/16:49
*** mgariepy has joined #openstack-nova16:53
*** agopi is now known as agopi|lunch|trav16:54
*** agopi|lunch|trav has quit IRC16:55
*** evrardjp is now known as gatersaregonnaga16:58
cdentfried_rice: my turn to ask you for a reminder:16:59
*** gatersaregonnaga is now known as evrardjp17:00
cdentresource provider A represents a compute node, currently idle17:00
cdentthird part system makes allocations against that compute node (consuming capacity in placement but not in _reality_)17:00
cdentthe compute node will or will not correct that?17:01
cdentI feel like we've gone back and forth on that a bit and I forget where we are now17:01
cdentI'd just test it, but I currently have no cloud17:02
fried_ricecdent: If the allocation is made against a real instance UUID, I think nova will "heal" it at some point. Otherwise, we don't muck with allocations that aren't related to instances afaik.17:03
openstackgerritStephen Finucane proposed openstack/nova master: docs: Dedupe controller install guides  https://review.openstack.org/63871517:03
openstackgerritStephen Finucane proposed openstack/nova master: docs: Dedupe compute install guides  https://review.openstack.org/63871617:03
* cdent nods at fried_rice 17:04
fried_ricecdent: mriedem might have to weigh in on the circumstances under which healing occurs at all. It may be just at the behest of a nova-manage command.17:04
cdenti've managed to make myself curious enough that I'm going to go spin up the devstack17:04
fried_ricecdent: Now, oob inventory/trait/agg changes against providers owned by the compute node will definitely be "healed" next time upt runs.17:05
fried_ricewhich actually may not be as soon as we would like - was having this conversation with aspiers the other day.17:05
cdentyeah, to inventory/trait stuff17:06
cdentwhat's the issue on the "soon"?17:07
*** erlon_ has quit IRC17:07
*** dtantsur is now known as dtantsur|afk17:08
*** erlon has joined #openstack-nova17:08
*** imacdonn has quit IRC17:08
mriedemthere is no auto-healing of allocations by nova-compute17:09
kashyapmriedem: I think I found the sucker in my case; spent the last hour-ish duking aroud the system.  This looks suspicious:17:09
kashyap---17:09
kashyapFeb 21 17:14:13 ubuntu-bionic-inap-mtl01-0002851272 kernel: traps: qemu-system-x86[31240] general protection ip:5600cbedaf78 sp:7f2dba1ebf00 error:0 in qemu-system-x86_64[5600cb81c000+8d2000]17:09
kashyap---17:09
mriedemcdent: fried_rice: coincidentally, read the commit message on https://review.openstack.org/#/c/638700/ for a history lesson17:10
aspierscdent: IIUC, the sync from provider tree to placement is essentially one way, so if something gets removed from placement then it won't get replaced until the provider cache is reset17:10
fried_ricecdent: It came up when aspiers was fixing the "automatic traits from capabilities" patch https://review.openstack.org/#/c/538498/17:10
fried_ricebecause one of the test scenarios needs to be: "user" adds or removes a compute-owned capability trait; compute restores it.17:10
fried_riceBut we enabled switching off periodic refresh. So that might never happen.17:10
cdentmriedem: I read that a bit earlier today and the aforementioned lack of brain made all the characters move around17:10
aspierscdent: https://review.openstack.org/#/c/538498/15/nova/tests/functional/test_servers.py@229417:11
mriedemtl;dr while we had computes older than pike, the compute service would overwrite instance allocations created by the scheduler17:11
*** helenaAM has quit IRC17:11
cdentI'm confused by this notion of user removes compute-owned capability trait. I'm guessing that "don't do that" is considered insufficient?17:12
fried_ricecdent: yeah :)17:12
mriedemusers most often probably don't know what they should and shouldn't do17:12
aspierscdent: it's due to this optimisation https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L104717:12
*** tbachman_ has joined #openstack-nova17:13
cdenti guess I was hoping for "most users probably don't know how to delete a trait"17:13
aspierscdent: see also https://pasteboard.co/I1Tbzp2.png (which is linked from the commit message)17:13
mriedemcdent: if any code is going to mess with your externally mucked allocation stuff, it's like this https://github.com/openstack/nova/blob/27617ee1931b3240dbd0ad4c7d8ffd64cc202bc9/nova/compute/resource_tracker.py#L124117:13
mriedemcdent: which would get you an INFO message https://github.com/openstack/nova/blob/27617ee1931b3240dbd0ad4c7d8ffd64cc202bc9/nova/compute/resource_tracker.py#L129317:14
cdentmriedem: yeah, was just looking at that method17:14
cdentaspiers: yeah, that's why I was trying to suggest that the os-traits should grow bigger, faster17:14
fried_ricemriedem: we still haven't solved the resize-to-same-host doubling though, right?17:14
*** tbachman has quit IRC17:15
*** tbachman_ is now known as tbachman17:15
aspierscdent: makes sense17:15
fried_ricemriedem: which is what your last paragraph is talking about17:15
fried_ricecdent: It doesn't matter if they're in os-traits or not.17:16
cdentthey can't be deleted if they are in os-traits17:16
cdent(that was all I was getting at, nothing more)17:17
fried_ricenot deleted from placement; deleted from the compute node.17:17
aspiersI think they can be deleted from a resource provider17:17
fried_riceyeah17:17
fried_riceaspiers worded it better, "delete from placement" is too vague.17:17
aspiersjust not from global traits list17:17
cdentoh, from the rp, I see17:17
cdentyeah, just don't do that :)17:18
aspiersfried_rice: the ambiguity only just became clear in my head ;-/17:18
aspiershence why it's still present in that Venn diagram I just linked17:18
cdentI honestly think that we need to make the system break when people break it17:18
cdentnot try to fix it for them17:18
aspiersshit, actually that diagram is wrong isn't it :-/17:18
cdentwe want failures to show as soon as possible17:19
cdentnot be in a situation where every 5 minutes system a removes a trait and every 7th minute something puts it back17:19
aspiersyeah I'm totally OK with the "if you do that you get to keep all the broken pieces" approach17:19
aspiersgood point17:19
mriedemfried_rice: yes, i look at this bug every couple of weeks and then fall into a pit of depression17:20
mriedembecause all solutions out of this bug are bad17:20
fried_ricemriedem: Seems like if you're removing that piece of the comment, you should add a TODO to fix that bit. Assume there's a bug associated with it, yah?17:21
mriedemfried_rice: see the related bug at the bottom of the commit message17:21
mriedemi thought about adding something like, NOTE(mriedem): This actually causes bug 1790204. - but the fix for that bug might not actually involve changing that code17:22
openstackbug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged] https://launchpad.net/bugs/179020417:22
mriedemi can add it if it's helpful though17:22
mriedemalso, having said that, i don't think we hit that code on resize anymore17:22
mriedemsee, "(10:47:20 AM) mriedem: i imagine this is all dead code since queens or at least rocky https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L140"17:23
mriedemthat's only called if the instance consumer has allocations prior to scheduling, which it shouldn't for resize https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L159517:23
mriedembecause we swapped those to the migration record in conductor prior to calling the scheduler17:23
mriedemi think _move_operation_alloc_request only happens during evacuate now17:24
mriedemand you thankfully can't evacuate to the same host :)17:24
sean-k-mooneywe will proably get a bug request for that at some point17:24
sean-k-mooneybut its true17:24
sean-k-mooneyand it should never be possible17:25
fried_ricecan we prove it and just remove the code path?17:25
mriedemyou can't evacuate to a host that is down17:25
mriedemand you can't evacuate while the service is up17:25
mriedemfried_rice: we can't remove it because of evacuate17:25
*** markvoelker has joined #openstack-nova17:25
fried_ricenot the method, just that condition, right?17:26
fried_ricemaybe I misunderstood what you said.17:26
mriedemcurrent design ideas on the resize to same host bug is in https://bugs.launchpad.net/nova/+bug/1790204/comments/1417:27
openstackLaunchpad bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged]17:27
fried_riceI thought you said: you can only hit this method during evacuate, and you can't evacuate to same host, so `elif not new_rp_uuids` should never happen17:27
mriedemwhich is built on an earlier comment from leakypipes17:27
mriedemoh yeah this https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L17217:27
mriedemumm, i think that's probably true17:27
mriedemso rather than me remove that comment, just remove the code17:28
*** tosky has quit IRC17:28
fried_ricemeaning L169-179 can be reduced to L170-17117:28
fried_ricebut only if we can prove that we only call this method for evacuate.17:28
mriedemi'll fart with it17:28
mriedemany opinions on the brain dump in https://bugs.launchpad.net/nova/+bug/1790204/comments/14 are also appreciated17:29
openstackLaunchpad bug 1790204 in OpenStack Compute (nova) "Allocations are "doubled up" on same host resize even though there is only 1 server on the host" [High,Triaged]17:29
mriedembecause there have been several "what if we did this?" talking to myselfs in that bug report by now17:29
cdenta) i'm glad mriedem is looking into this and playing the what if game, b) i'm sad that we have some many what ifs in this part of the code, c) let's rewrite the whole thing!17:32
mriedemif we rewrote the whole thing, we'd just (d) regress some other shit corner case we didn't think about17:32
mriedemthe retrospective on this is probably that we are not good about testing at-capacity hosts17:33
mriedemour functoinal tests are always building and migrating to hosts with near infinite capacity17:33
cdentregressions is how we create new contributors :D17:33
mriedemour public cloud ops team is super anal about packing as much as possible, so that's how they noticed this17:35
melwittany new contributors want to write at-capacity test coverage? :P17:36
mriedemwell we have https://review.openstack.org/#/c/619123/ for this bug at least17:36
melwitt(either way, we need it)17:36
mriedemnot really sure we have new contributors17:37
mriedemwe have old grizzled contributors17:37
melwittyeah. I was just kidding17:37
mriedemaspiers is new i guess17:37
mriedemfull of hope17:37
mriedem(new to nova)17:37
melwitthaha (it's true)17:37
temkaSo you're saying we should break him by making him convert mox to mock?17:37
mriedemno i never suggested anyone do that17:38
mriedemi actively lobbied against that17:38
mriedemto no avail17:38
cdenttoo old. too grizzled. to no avail.17:38
temkamriedem, btw, I think we need to put the brakes on https://review.openstack.org/#/c/636210/9 for now - the changed unit tests are failing in the patch above it: http://logs.openstack.org/05/634605/16/check/openstack-tox-lower-constraints/83c2d08/testr_results.html.gz17:38
temkaIs my -W enough?17:38
mriedemnope17:39
mriedemyou'll have to change the commit message or something to pull it from zuul17:39
kashyapmriedem: Since you politely implied `git blame` on the version bump patch ... :-) I'd want to certinly tell you that the failure was _not_ related to it.17:39
openstackgerritArtom Lifshitz proposed openstack/nova master: [DERP] Remove _legacy_dict methods  https://review.openstack.org/63621017:40
openstackgerritArtom Lifshitz proposed openstack/nova master: Add migration param to check_can_live_migrate_destination  https://review.openstack.org/63460517:40
openstackgerritArtom Lifshitz proposed openstack/nova master: Introduce live_migration_claim()  https://review.openstack.org/63566917:40
openstackgerritArtom Lifshitz proposed openstack/nova master: Use live_migration_claim() to check dest resources  https://review.openstack.org/63460617:40
openstackgerritArtom Lifshitz proposed openstack/nova master: New objects to transmit NUMA config from dest to source  https://review.openstack.org/63482717:41
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: Make dest send NUMAMigrateData to the source  https://review.openstack.org/63482817:41
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: update NUMA-related XML on the source  https://review.openstack.org/63522917:41
openstackgerritArtom Lifshitz proposed openstack/nova master: [WIP] Drop MoveClaim in rollback_live_migration_at_destination  https://review.openstack.org/63865417:41
*** cdent has quit IRC17:41
mriedemkashyap: ok ok17:41
kashyapI just spent 2 hours talking to the QEMU guys to carefully go through all the logs.  I've got a couple of nice action items for DevStack, though :-)17:41
kashyapI'll write a comment from the investigation.  And see if a "trend" shows up on Monday.  (1 failure is not a trend :D)17:42
*** _fragatina has quit IRC17:42
*** takamatsu_ has joined #openstack-nova17:48
*** takamatsu has quit IRC17:48
*** sridharg has quit IRC17:48
aspiershaha17:51
* temka pesters against non-deterministic dict ordering BS17:51
aspiersmriedem: I wish I could say I'm young and naive but I'm just ... naive17:51
mriedemkashyap: logstash is also behind so i'm not sure if it's rare or new17:51
*** jmlowe has quit IRC17:51
melwittdansmith: as one of the primary reviewers on the spec, you might fancy reviewing the patch for ironic conductor groups. has one +2 already https://review.openstack.org/63500617:52
dansmithguhhhh17:52
dansmithit's friday, don't make me work17:52
aspiersOK it's time for the weekend. Thanks all for your help, catch you next week o/17:52
temkadansmith, don't be so edgy17:52
melwitthaha17:52
* dansmith groans17:53
kashyapmriedem: Yeah, I saw your comment on indexing; I'm really curious now, after all the time I spent tongiht17:53
kashyapmriedem: Monday I should get to know I suppose, if there's a pattern17:53
*** snevi has quit IRC17:53
kashyapdansmith: You'll like this: https://basecamp.com/books/calm17:54
*** sdake has quit IRC17:54
openstackgerritStephen Finucane proposed openstack/nova-specs master: Add 'flavor-extra-spec-image-property-validation' spec  https://review.openstack.org/63873417:54
openstackgerritMatt Riedemann proposed openstack/nova master: Remove misleading code from _move_operation_alloc_request()  https://review.openstack.org/63870017:54
mriedemfried_rice: ^17:54
mriedem"It Doesn't Have to Be Crazy at Work (if you work in the EU"17:55
*** betherly has joined #openstack-nova17:56
*** sdake has joined #openstack-nova17:56
kashyapLOL17:58
*** markvoelker has quit IRC17:59
kashyapWell ... it is always "hustle" if you make it a hustle :D17:59
kashyap(That book is written by Americans :D)  One of them is a Rails co-founder.  They _really_ know what they're talking about.17:59
*** betherly has quit IRC18:01
*** igordc has joined #openstack-nova18:01
kashyap)  The Rails part is to note that it's written by a developer, and not some "tech journalist"18:01
kashyapAnyhow, /me --> dinner and air18:01
*** wolverineav has joined #openstack-nova18:01
*** takamatsu_ has quit IRC18:03
*** tssurya has quit IRC18:05
*** mriedem is now known as mriedem_lunch18:05
*** takamatsu_ has joined #openstack-nova18:06
*** dave-mccowan has quit IRC18:15
*** whoami-rajat has quit IRC18:27
*** wolverineav has quit IRC18:28
*** wwriverrat has quit IRC18:29
*** wolverineav has joined #openstack-nova18:31
*** wolverineav has quit IRC18:32
*** wolverineav has joined #openstack-nova18:32
*** _fragatina has joined #openstack-nova18:32
openstackgerritArtom Lifshitz proposed openstack/nova master: Remove _legacy_dict methods  https://review.openstack.org/63621018:33
openstackgerritArtom Lifshitz proposed openstack/nova master: Add migration param to check_can_live_migrate_destination  https://review.openstack.org/63460518:33
openstackgerritArtom Lifshitz proposed openstack/nova master: Introduce live_migration_claim()  https://review.openstack.org/63566918:33
openstackgerritArtom Lifshitz proposed openstack/nova master: Use live_migration_claim() to check dest resources  https://review.openstack.org/63460618:33
openstackgerritArtom Lifshitz proposed openstack/nova master: New objects to transmit NUMA config from dest to source  https://review.openstack.org/63482718:33
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: Make dest send NUMAMigrateData to the source  https://review.openstack.org/63482818:33
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: update NUMA-related XML on the source  https://review.openstack.org/63522918:33
openstackgerritArtom Lifshitz proposed openstack/nova master: [WIP] Drop MoveClaim in rollback_live_migration_at_destination  https://review.openstack.org/63865418:33
*** mdbooth_ has joined #openstack-nova18:33
temkamriedem_lunch, fixed https://review.openstack.org/#/c/636210/11 when you're back18:34
temkaOr actually dansmith, you wanna handle it?18:34
dansmithtemka: what was the issue?18:35
*** betherly has joined #openstack-nova18:35
temkaThere's a field called connection_info_json that's a string, but was being printed the way a dict would18:36
temkaSo I was trying and failing to assert equality between two dicts when they were actually strings18:36
temkaOr rather, I was asserting about their containing dicts, and sometimes the JSON would be in the wrong order and compare false18:37
*** mdbooth has quit IRC18:37
temkaAnd I was trying to fix it by treating the JSON like a dict, when I should have just loads and compared that18:37
*** macza has quit IRC18:38
dansmithah, Is ee18:38
sean-k-mooneyi have no other context of this but just looking a dmesg after a kernel update i noticed this18:39
sean-k-mooney"capability: warning: `privsep-helper' uses deprecated v2 capabilities in a way that may be insecure"18:39
*** betherly has quit IRC18:40
sean-k-mooneyconsidering this is an an all in one containerised deployment i have no idea which privsep-help that might be but i have never noticed this before18:41
temkadansmith, cheers!18:41
*** _alastor_ has quit IRC18:43
*** agopi has joined #openstack-nova18:45
dansmithfried_rice: I just -1d this that you had +2d.. not sure if you know the answer to my concern, but: https://review.openstack.org/#/c/63500618:48
*** lpetrut has quit IRC18:51
*** markvoelker has joined #openstack-nova18:56
*** lpetrut has joined #openstack-nova19:07
*** macza has joined #openstack-nova19:10
*** macza has quit IRC19:10
*** macza has joined #openstack-nova19:11
dansmithjroll: ^19:13
jrolly u so mean19:14
dansmithman, I've deleted like three non-PC joke responses to that19:15
jrollheh19:16
jrolldansmith: even worse, I agree with you19:19
jrollI'll respin monday morning19:19
dansmithYASS19:19
*** Kunpeng has quit IRC19:22
*** mriedem_lunch is now known as mriedem19:25
*** tbachman has quit IRC19:25
mriedemtwizzlers really needs to rethink their packaging because the smashed together brick of licorice that you have to destroy the bag to get 1 rope from is frustrating19:25
jrollyou need fresher twizzlers yo19:26
mriedemdoes not exist19:26
mriedemand by destroying the bag, you guarantee staleness within 48 hours19:26
temkaSolution: eat the whole bag.19:27
mriedemin progress19:27
dansmithlol19:28
*** markvoelker has quit IRC19:28
*** sdake has quit IRC19:31
*** wwriverrat has joined #openstack-nova19:36
melwittlol, it's so timely that you said that. I got the SAME problem earlier this week19:39
melwittand their "resealable" bag design cannot be opened without destroying the bag19:39
sean-k-mooneyits a secret conspiacy to get you to get them allin in one go so you have to buy more19:40
melwittprobably19:40
melwittI put the tattered bag and brick into a gallon size ziplock freezer bag. nailed it19:40
*** _fragatina has quit IRC19:41
*** tesseract has quit IRC19:41
*** itlinux has quit IRC19:41
*** dave-mccowan has joined #openstack-nova19:43
*** tbachman has joined #openstack-nova19:48
*** nicolasbock has joined #openstack-nova19:50
nicolasbockHi, I am trying to understand the concept of quotas and limits. I don't quite see how they differ.19:50
melwittnicolasbock: lots of people use the words interchangeably. but there is quota usage (amount of resources being used) and quota limits (configured limit for the amount of a resource)19:56
melwittwhen people say "quotas" they usually mean quota limits19:56
nicolasbockAh, what I was thinking of are `openstack quota list` and `openstack limits show`19:57
melwittah, ok. 'openstack limits show' is probably for showing keystone unified limits (which we are not yet leveraging in nova)19:58
melwittlet me double check19:58
*** wolverineav has quit IRC19:59
*** wolverineav has joined #openstack-nova19:59
nicolasbockOk20:00
nicolasbockSo historically, limits came first and is now being unified under Keystone?20:00
melwittlooks like I'm wrong. I'm looking for what it's calling underneath20:00
nicolasbockOk20:00
melwittlimits show calls a compute api https://github.com/openstack/python-openstackclient/blob/4bde9af89251431791fc8d69fe09d5e17a8fba8f/openstackclient/common/limits.py#L9020:01
fried_ricedansmith: ack, looking.20:02
melwittnicolasbock: which is this one, which is the old school rate-limiting api https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/limits.py#L8520:03
mriedemdansmith: remind me, is a compute node for vcenter still 1:1 with the compute service host? or 1:M like ironic?20:03
mriedemis the compute node the vcenter cluster, or is a compute node an esxi host in that cluster?20:03
melwittnicolasbock: hah, it's actually for both. nice https://developer.openstack.org/api-ref/compute/?expanded=show-rate-and-absolute-limits-detail#limits-limits20:04
*** wolverineav has quit IRC20:04
nicolasbockThanks melwitt20:04
melwittso that's showing quota limits and the old rate limit part is empty20:04
melwittnow, what does 'openstack quota list' do20:04
dansmithmriedem: yeah I think the compute node is a cluster, which is multiple machines20:04
*** wolverineav has joined #openstack-nova20:04
*** erlon has quit IRC20:05
mriedembut all instances on the same compute service host point at the same compute node...20:05
dansmithmriedem: so it looks 1:1 like libvirt, not 1:N like ironic, but the 1 is actually N20:05
mriedemyeah ok20:05
melwittnicolasbock: ok, so that one does this https://developer.openstack.org/api-ref/compute/?expanded=show-a-quota-detail#show-a-quota20:06
melwittnicolasbock: two different APIs that do nearly the same thing. the 'openstack limits show' will show the quota limits and quota usage, the 'openstack quota list' will show the quota limits only20:07
nicolasbockOk20:07
nicolasbockThanks!20:07
melwittnp20:08
nicolasbockNow to the next question :)20:08
*** lpetrut has quit IRC20:08
melwittuh oh20:08
nicolasbockIf I understand this correctly, then the usage is not updated by default20:08
nicolasbockFor Pike I found `max_age` in the `[Quota]` section20:08
nicolasbockWhich defaults to `0`20:08
melwittok, that's for the old quota syncing mechanism20:09
nicolasbockI also found https://github.com/openstack/nova/blob/c8926feb2675c754048f8c7398747e3c29bfadaf/releasenotes/notes/remove-quota-options-0e407c56ea993f5a.yaml20:09
melwittin pike, we changed the way we do quota usage and count resources directly instead of tracking them in a separate table20:09
nicolasbockWhich suggests that it's deprecated20:09
*** wolverineav has quit IRC20:09
nicolasbockOk. Does that mean that I don't have to worry about this setting?20:09
melwittyes, the use of the separate table (which could get out-of-sync with actual resource consumption) and the syncing related options are deprecated and removed20:10
nicolasbockThe usage should be updated automatically?20:10
melwittright20:10
nicolasbockOk. Let me rephrase this to make sure I understand this correctly:20:10
melwittactual resource usage is counted per quota check since pike. going out-of-sync is no longer possible, so quota syncing is no longer possible20:10
nicolasbockI should look only at `openstack limits show`20:11
nicolasbockAnd it should show me the quota and the usage20:11
nicolasbockAnd it's automatically kept up to date?20:11
nicolasbockDoes that summarize the situation somewhat accurately?20:11
melwittyes, anything the API is showing was accounted for when things were changed20:11
nicolasbockCool20:12
melwittyou'll always see "reserved=0" because we no longer do the two-step reserve + commit quota dance20:12
nicolasbockWow, that's a lot easier than I thought :)20:12
melwittyou can look at either 'openstack limits show' or 'openstack quota list'. limits show seems more useful since it shows the usage too20:14
melwittI notice that quota list has some limits that are not in limits show, but those are all deprecated by now I think20:15
nicolasbockYes, that's true20:15
nicolasbockI find that listing a quota without also showing usage less helpful ;)20:15
melwittbut they pull data in the same way, so they should match where they are the same20:15
*** s10 has joined #openstack-nova20:20
*** itlinux has joined #openstack-nova20:24
*** markvoelker has joined #openstack-nova20:25
*** tbachman has quit IRC20:32
*** wolverineav has joined #openstack-nova20:45
*** wolverineav has quit IRC20:50
*** itlinux has quit IRC20:51
fried_ricemriedem: Flushing oldymoldys, are you happy with the reno verbiage etc. on https://review.openstack.org/#/c/564193/ at this point?20:51
*** wolverineav has joined #openstack-nova20:56
*** markvoelker has quit IRC20:59
mriedemech idk21:00
mriedemthey should also update the image properties docs https://docs.openstack.org/glance/latest/admin/useful-image-properties.html21:00
mriedembut that's in glance so a follow up21:00
mriedemi haven't looked at that change in forever though21:00
mriedemif you're happy with it go ahead21:01
*** itlinux has joined #openstack-nova21:01
fried_ricewell, I was happy with it before you ripped into it.21:01
mriedemyou can be happy once again21:01
fried_ricek21:01
mriedemi'm currently very unhappy with most everything so don't hold for me21:01
*** itlinux has quit IRC21:02
fried_ricedone, I suppose anything egregious can be handled in a fup.21:02
mriedemso on this same host resize bug, i started down the path of, from conductor, just trying to PUT allocations for the max of the old/new flavor to see if that can fit the host,21:05
mriedembut then remembered, oh yeah the new flavor can have required/forbidden traits which could filter out the same host21:06
mriedemf me right in the eye21:06
mriedemleakypipes: ^21:06
mriedemi basically have to do a GET /a_c call from conductor and see if the same host provider is in the results21:07
mriedemand then not swap allocations21:08
edleafemriedem: that sounds like the same problem Watcher had21:08
mriedemthe ol scheduler dry run21:08
fried_ricemriedem: You can use ?in_tree with microversion 1.3121:09
mriedemthat's not a thing in stein right21:10
fried_riceCould be21:10
fried_riceI mean, it's not merged yet, and we agreed not to use it from nova if it does merge.21:10
mriedemthis change isn't making stein anyway21:11
fried_riceWe could end up resizing to same-host-but-different-providers, couldn't we.21:11
*** tosky has joined #openstack-nova21:11
mriedemsure can21:11
mriedemif there are nested providers in the new flavor then it's all f'ed either way21:11
fried_riceI don't know about f'ed. Just have to be pretty careful about which ones we allow to move and which we don't.21:12
fried_riceLike, I can see moving numa nodes, as long as all the affined resources move together.21:12
fried_riceBut I can't see moving FPGAs probably.21:12
fried_ricefor now I wouldn't remotely object to "fail if any nested/sharing in play".21:12
mriedemi think i would put a big fat "don't go down this side path if you have complex allocations" condition21:12
fried_riceyeah, that.21:13
fried_ricebbiab21:13
*** itlinux has joined #openstack-nova21:13
*** jobewan has quit IRC21:20
*** itlinux has quit IRC21:20
mriedemthis would also bypass anything that has limits to claim in the resource tracker, like numa21:21
mriedemso no numa, no complex allocations21:21
*** Sundar has quit IRC21:25
*** wolverineav has quit IRC21:26
melwitthm, I wonder why we populate the instance mapping with a cell in build_instances when it is _not_ a reschedule. build_instances method + not a reschedule = cells v1, I thought. so why update instance mapping21:27
*** wolverineav has joined #openstack-nova21:27
*** itlinux has joined #openstack-nova21:27
mriedemwe do'nt know the cell in that case until the scheduler tells us the host right?21:28
leakypipesmriedem: don't forget ye old aggregate image properties filter too. :)21:28
mriedemleakypipes: image doesn't change on resize21:28
mriedemthank f21:28
leakypipesah, yes, was thinking rebuild/evac21:28
mriedemimage doesn't change on evac either21:29
mriedemsilly pants21:29
mriedemwe need a jump to conclusions mat for these operations21:29
mriedemnew host? yes/no/maybe21:29
mriedemnew flavor? yes/no/maybe21:29
mriedemnew image? yes/no/maybe21:29
mriedemaneurysm? definitely.21:30
melwittthere's a note in the code saying that if it's a reschedule, it's already been set to a cell on the first schedule attempt https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L717-L71821:30
*** tbachman has joined #openstack-nova21:30
melwittso how can the first schedule attempt in a cells v2 env ever be calling build_instances (and not schedule_and_build_instances)21:30
mriedemmelwitt: right, so that if is False21:30
mriedemhttps://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L721 is the first time through for cells v121:31
mriedemafter picking a host, need to update the instance mapping with the cell of the selectd host21:31
mriedemelse you are rescheduling https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L73821:31
melwittI see that, but we need to update instance mapping for cells v1?21:32
mriedemwhat we need to do is delete cells v121:32
*** betherly has joined #openstack-nova21:32
melwittyes we do21:32
mriedemfor cells v1 i assume the instance mapping is updated for the same reason as v2 - to know where to pull the instance information on a GET21:33
mriedembecause if it's not in the mapping, we'd pull from the top level API DB i geuss which has the synced info21:33
melwittyeah, because code path is the same? yeah, guh21:33
mriedemhttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L244921:33
mriedemwe don't look at the mapping in that case21:33
mriedemso idk21:34
melwittok. just going through this realizing I'm not going to have a "populate instance mapping user_id" opportunity during a reschedule, at least not from any already existing instance mapping update21:34
mriedemmaybe it's for the v1 -> v2 transition21:34
mriedemwhy would you need to update the user_id during a reschedule?21:34
melwittyeah, must be21:34
mriedemwe only reschedule (from compute) in 2 cases, server create and resize21:34
melwittI don't have to, but I had been thinking use all the opportunities for setting user_id if it's not set21:35
mriedemin either of those cases, you could have already updated the instance mapping at the top21:35
mriedemi.e. https://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L16721:35
melwittyeah, once the new host is picked and saved, that should be where. I guess I missed that mapping update21:36
mriedemthe host shouldn't have anything to do with the instance mapping...21:36
mriedemyou're just looking for places that InstanceMapping.save() happens yes?21:36
mriedemhell you could do it right here and hit all move operations https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L7521:37
melwittoh wait no, during a reschedule we wouldn't update the mapping bc that's just for the cell, not the host. gah I am just confusing myself21:37
melwittyes21:37
*** wolverineav has quit IRC21:37
*** betherly has quit IRC21:37
melwittyeah, I was piggy backing on any existing save. there won't be a new save for a reschedule, is what I realized21:38
mriedemnor any move as far as i know, unless you add one to ^21:38
melwittwhich I could just punt on, but that code in build_instances made me wonder what it was for21:38
melwittyeah21:39
*** itlinux has joined #openstack-nova21:40
melwittinitially I thought, since I saw "populate_instance_mapping" in build_instances, that there was a save() to piggy back. but looking closer, there isn't21:40
*** temka has quit IRC21:40
melwittnot a big deal21:40
*** artom has joined #openstack-nova21:40
*** macza has quit IRC21:44
*** macza has joined #openstack-nova21:45
*** ivve has quit IRC21:47
*** dave-mccowan has quit IRC21:55
*** markvoelker has joined #openstack-nova21:56
*** awaugama has quit IRC22:02
melwittI wonder if I could use request specs to populate user_id instead of looking in cells at all? hmmm22:21
*** _fragatina has joined #openstack-nova22:21
*** mchlumsky has quit IRC22:21
sean-k-mooneymelwitt: https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L65-L6622:22
sean-k-mooneythe user and project ides are stored in it22:22
melwittyeah, I was noticing that in compute_api.get()22:23
melwittI'm a bit wary if there's any way it couldn't be relied on though. being that request specs are only removed at archive_deleted_rows time, I wonder if it's possible that old, unarchived things could have a null user_id22:24
melwittmaybe best not to chance it22:24
sean-k-mooneyi honest taught the scduler depending on this to look up the users limets22:25
melwittit looks at build requests, in addition to instances22:26
melwittwhich are ephemeral (only live until scheduling completes)22:26
melwittrequest specs are not looked at for any quota limit checking22:27
sean-k-mooneyhum ok22:28
sean-k-mooneyare you concured that the user may be delete and we some how have a non archived instance belonving to that user and try to look it up and get an error22:29
sean-k-mooneyor are you concured that the request spec will have a null user id22:29
*** markvoelker has quit IRC22:30
melwittnull user_id, or worse, no user_id field. I didn't look at the history of when that field was added22:30
melwittI guess "no user_id field" isn't a thing, it would be null in that case22:30
sean-k-mooneymelwitt: https://github.com/openstack/nova/commit/6e49019fae80586c4bbb8a7281600cf6140c176a22:31
*** mchlumsky has joined #openstack-nova22:31
melwittrequest spec has a wild west reputation, so I'm just not sure if I could rely on its user_id field. being that I didn't dig into it yet22:31
melwittah, wow. relatively new22:32
sean-k-mooneywell its been there since queens?22:32
melwittand no data migration, so would be null for already existing request specs when that code landed22:32
melwittyeah, I just expected it would be older than that22:33
melwittok, nevermind my request spec flighty idea22:33
sean-k-mooneywell looking at the change it look like there are check in the conductor that depend on both the user id and porject id being set22:34
mriedemfried_rice: well, i got something working for the functional regression test at least22:34
melwitthah, ok22:35
mriedemof course it's rife with TODOs and FIXMEs22:35
fried_riceneat.22:35
sean-k-mooneyi wasnt following hte context of what you were working on but it look like it will alway be none none22:35
sean-k-mooneymelwitt: you could also get the user_id out of the instance if you have that https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L122-L12322:36
*** sdake has joined #openstack-nova22:37
*** tbachman has quit IRC22:37
melwittsean-k-mooney: I'm adding user_id to InstanceMapping and need a reliable way to populate it (data migration of already existing records). and instance was the assumed way. and it occurred to me (from looking at the down cell stuff) that, request spec has user_id too, could I use that? the answer I now know is, no22:40
*** tbachman has joined #openstack-nova22:40
melwittI already wrote everything to use instance user_id, so this means no change for me22:40
sean-k-mooneyah ok22:40
*** mchlumsky has quit IRC22:43
sean-k-mooneymelwitt: you could be checky and look at the allocation for the instacne and get the user id out of the consumers table in the api db22:44
sean-k-mooneythe consumer and allocation should have been there since pike22:44
sean-k-mooneymelwitt: :) oh look like you added the consumer table in pike https://github.com/openstack/nova/commit/b9eed6a2862d0d72c77706b49d05ea588d2d81f322:51
melwittyeah, I dunno23:04
melwittthat might not work bc I need to migrate soft-deleted instances (the soft-delete API) too, since they could restored theoretically at any point in the future. and I don't think those would have allocations, as they are supposed to be gone from the user perspective and not consuming resources23:06
openstackgerritMerged openstack/nova stable/pike: Not set instance to ERROR if set_admin_password failed  https://review.openstack.org/60818023:07
melwittbesides that, it seems most reliable to use instances. we had bugs in the past with orphaned allocations in placement and deployments out there might still have some23:07
openstackgerritMerged openstack/nova stable/pike: Add functional regression test for bug 1806064  https://review.openstack.org/62393523:07
openstackbug 1806064 in OpenStack Compute (nova) pike "Volume remains in attaching/reserved status, if the instance is deleted after TooManyInstances exception in nova-conductor" [Medium,In progress] https://launchpad.net/bugs/1806064 - Assigned to Matt Riedemann (mriedem)23:07
sean-k-mooneyya i guess you have to blance the risks. if the cell is donw then using ht user form the instance will fail23:07
sean-k-mooneymelwitt: ya the instace is proably the safest whcih is why i said using the consumer recored associated with the instance allocation was a little cheaky23:08
melwittoh, cheaky? you spelled it "checky" earlier and I didn't get it :)23:09
sean-k-mooneyoh ha ya23:09
sean-k-mooneywell it shoudl be cheeky if i use the irish/uk spelling23:10
sean-k-mooneyanyway i better go. have a good weekend o/23:10
melwitthave a good weekend o/23:11
openstackgerritMerged openstack/nova stable/pike: Create BDMs/tags in cell with instance when over-quota  https://review.openstack.org/62393723:21
mriedemhmm, why do we persist RequestSpec.ignore_hosts23:22
mriedemdansmith: ^ seems dangerous yeah?23:22
mriedemjust like why we don't persist retry and requested_destination23:22
*** slaweq has quit IRC23:23
mriedemi.e. resize with allow_resize_to_same_host=false sets ignore_hosts=[instance.host], we save that, then resize again with allow_resize_to_same_host=False will always filter out the same host23:23
mriedemer allow_resize_to_same_host=True the 2nd run23:24
mriedemi know request spec is the thing everyone wants to think about at 3:30 on a friday23:24
sean-k-mooneydo we clear it on resize confirm/revert23:24
sean-k-mooneyi dont recal if we can retry a resize but perhapse that is why23:24
sean-k-mooneythat is just a guess23:25
mriedemwell, on the 2nd resize we would overwrite RequestSpec.ignore_hosts again23:25
mriedemlooks like the only other move operation that really looks at it is evacuate, and you can't evacuate to the same host anyway so ..23:26
mriedemevacuate ignores instance.host as well23:26
mriedemso i guess this is why it's not a problem23:26
*** markvoelker has joined #openstack-nova23:27
mriedemlive migrate also uses it while retrying different hosts in conductor, but doesn't persist those changes (until someone comes along and adds code to the live migration task that saves the request spec for some reason)23:27
sean-k-mooneywell it doesnt sound like there is an obvious reason to save it to the db so maybe put up a patch to and see what breaks but form the sounds of it might not be needed and might be a source of a future bug23:29
mriedemno time right now, but yeah i'm sure it would be a future bug, i.e. https://review.openstack.org/#/c/636271/23:30
mriedemthese per-operation fields on request spec keep biting us in our collective asses23:30
*** itlinux has quit IRC23:35
*** wolverineav has joined #openstack-nova23:38
*** wolverineav has quit IRC23:42
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Workaround resize to same host doubling allocations bug  https://review.openstack.org/63879123:43
mriedemleakypipes: fried_rice: ^ damn near killed me23:44
mriedemfugly as hell23:44
openstackgerritsean mooney proposed openstack/nova master: [DNM] stop storing request_spec.ignore_hosts in the db.  https://review.openstack.org/63879223:45
sean-k-mooneyi belive ^ is syantaticlly corret python. beyond that its just a reminder23:46
sean-k-mooneybut we can see if any of the ci job fall over becase of it23:46
sean-k-mooneyok im actully leaving this time o/23:47
*** mriedem has quit IRC23:52
*** tbachman_ has joined #openstack-nova23:52
*** tbachman has quit IRC23:53
*** tbachman_ is now known as tbachman23:53
*** itlinux has joined #openstack-nova23:57
*** markvoelker has quit IRC23:59

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!