Wednesday, 2019-06-12

*** markvoelker has quit IRC00:00
*** tbachman has joined #openstack-nova00:09
*** hongbin has quit IRC00:25
*** med_ has quit IRC00:40
*** rnoriega has quit IRC00:40
*** kashyap has quit IRC00:40
*** rnoriega has joined #openstack-nova00:40
*** spatel has joined #openstack-nova00:45
*** tbachman has quit IRC00:47
*** zzzeek has quit IRC00:47
*** zzzeek has joined #openstack-nova00:47
*** bhagyashris has joined #openstack-nova00:49
*** markvoelker has joined #openstack-nova00:57
openstackgerritMerged openstack/nova stable/rocky: Add regression recreate test for bug 1830747  https://review.opendev.org/66257800:58
openstackbug 1830747 in OpenStack Compute (nova) rocky "Error 500 trying to migrate an instance after wrong request_spec" [High,In progress] https://launchpad.net/bugs/1830747 - Assigned to Matt Riedemann (mriedem)00:58
openstackgerritMerged openstack/nova stable/rocky: Workaround missing RequestSpec.instance_group.uuid  https://review.opendev.org/66289500:58
*** bhagyashris has quit IRC00:59
SundarHi all, https://review.opendev.org/#/c/603955/ already has a +2 and a +1. Please review and help to close it. Thanks.01:12
*** bhagyashris has joined #openstack-nova01:15
*** bhagyashris has quit IRC01:28
*** igordc has quit IRC01:28
*** markvoelker has quit IRC01:31
*** spatel has quit IRC01:31
*** dave-mccowan has quit IRC01:34
*** boxiang has joined #openstack-nova01:34
*** Sundar has quit IRC01:39
*** dave-mccowan has joined #openstack-nova01:39
*** spsurya has joined #openstack-nova01:51
*** bbowen has quit IRC01:55
*** bbowen has joined #openstack-nova01:56
*** yikun has joined #openstack-nova01:56
*** zzzeek has quit IRC01:57
*** zzzeek has joined #openstack-nova01:58
*** itlinux has joined #openstack-nova01:59
*** BjoernT_ has quit IRC02:02
*** BjoernT has joined #openstack-nova02:02
*** BjoernT has quit IRC02:06
*** zzzeek has quit IRC02:13
*** itlinux_ has joined #openstack-nova02:14
*** zzzeek has joined #openstack-nova02:16
*** itlinux has quit IRC02:18
*** bhagyashris has joined #openstack-nova02:25
*** markvoelker has joined #openstack-nova02:27
*** yaawang has quit IRC02:33
*** yaawang has joined #openstack-nova02:34
*** Sundar has joined #openstack-nova02:45
*** hongbin has joined #openstack-nova02:47
*** itlinux_ has quit IRC02:54
*** markvoelker has quit IRC03:01
*** yaawang has quit IRC03:03
*** yaawang has joined #openstack-nova03:06
*** brinzhang has quit IRC03:11
*** boxiang_ has joined #openstack-nova03:12
*** boxiang has quit IRC03:12
openstackgerrittonybrad proposed openstack/nova master: update constraints url  https://review.opendev.org/66477103:16
*** spatel has joined #openstack-nova03:17
*** spatel has quit IRC03:22
*** cfriesen has quit IRC03:25
*** psachin has joined #openstack-nova03:29
*** takashin has joined #openstack-nova03:32
*** itlinux has joined #openstack-nova03:35
*** BjoernT has joined #openstack-nova03:36
*** itlinux has quit IRC03:36
*** dave-mccowan has quit IRC03:46
*** yikun has quit IRC03:51
*** jbernard_ has joined #openstack-nova03:52
*** jbernard has quit IRC03:52
*** BjoernT has quit IRC03:53
*** markvoelker has joined #openstack-nova03:58
*** yikun has joined #openstack-nova04:03
*** udesale has joined #openstack-nova04:16
*** markvoelker has quit IRC04:32
*** whoami-rajat has joined #openstack-nova04:51
*** sridharg has joined #openstack-nova04:53
*** pcaruana has joined #openstack-nova04:54
*** pcaruana has quit IRC04:59
*** hongbin has quit IRC05:01
*** ratailor has joined #openstack-nova05:12
*** Luzi has joined #openstack-nova05:22
*** markvoelker has joined #openstack-nova05:29
openstackgerritMerged openstack/nova master: Skip test_check_doubled_words hacking check UT  https://review.opendev.org/66462205:39
*** luksky has joined #openstack-nova05:41
*** brinzhang has joined #openstack-nova05:46
openstackgerritTakashi NATSUME proposed openstack/nova master: Fix default values in update_cell command  https://review.opendev.org/66238305:53
*** igordc has joined #openstack-nova05:58
*** markvoelker has quit IRC06:02
*** rpittau|afk is now known as rpittau06:20
*** ricolin has joined #openstack-nova06:27
*** hamdyk has joined #openstack-nova06:31
*** hjensas has quit IRC06:32
*** luksky has quit IRC06:36
*** Sundar has quit IRC06:40
*** takamatsu has quit IRC06:46
*** gibi has joined #openstack-nova06:50
*** pcaruana has joined #openstack-nova06:56
*** markvoelker has joined #openstack-nova06:59
*** guozijn has joined #openstack-nova06:59
*** bhagyashris has quit IRC07:04
openstackgerritBrin Zhang proposed openstack/nova-specs master: Support delete_on_termination in volume attach api  https://review.opendev.org/61294907:05
openstackgerritBrin Zhang proposed openstack/nova-specs master: Support for changing deleted_on_termination after boot  https://review.opendev.org/58033607:05
*** brinzhang has quit IRC07:07
*** boxiang_ has quit IRC07:07
*** brinzhang has joined #openstack-nova07:07
*** boxiang_ has joined #openstack-nova07:07
*** hjensas has joined #openstack-nova07:14
*** tesseract has joined #openstack-nova07:14
openstackgerritHarald JensÃ¥s proposed openstack/nova master: cell_mapping - wrap IPv6 address in format_url  https://review.opendev.org/66455907:17
openstackgerritBalazs Gibizer proposed openstack/nova master: Defaults missing group_policy to 'none'  https://review.opendev.org/65779607:17
*** helenfm has joined #openstack-nova07:19
*** psachin has quit IRC07:19
*** nicolasbock has joined #openstack-nova07:20
*** yaawang has quit IRC07:20
*** nicolasbock has quit IRC07:22
*** rcernin has quit IRC07:22
*** nicolasbock has joined #openstack-nova07:23
*** nicolasbock has quit IRC07:23
*** nicolasbock has joined #openstack-nova07:24
*** damien_r has joined #openstack-nova07:25
*** yaawang has joined #openstack-nova07:25
*** nicolasbock has quit IRC07:26
*** tetsuro has joined #openstack-nova07:30
*** markvoelker has quit IRC07:33
*** dtantsur|afk is now known as dtantsur07:34
*** nicolasbock has joined #openstack-nova07:34
*** slaweq has joined #openstack-nova07:36
*** takamatsu has joined #openstack-nova07:37
*** nicolasbock has quit IRC07:37
*** nicolasbock has joined #openstack-nova07:41
*** ralonsoh has joined #openstack-nova07:42
*** slaweq has quit IRC07:44
*** slaweq has joined #openstack-nova07:48
*** luksky has joined #openstack-nova07:49
*** jangutter_ has joined #openstack-nova07:53
*** jangutter has quit IRC07:56
*** ttsiouts has joined #openstack-nova07:57
*** ccamacho has joined #openstack-nova07:58
*** boxiang_ has quit IRC07:59
*** kashyap has joined #openstack-nova07:59
*** boxiang_ has joined #openstack-nova08:00
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Use SATA bus for cdrom devices when using Q35 machine type  https://review.opendev.org/66301108:00
openstackgerritLee Yarwood proposed openstack/nova master: fup: Merge machine_type_mappings into get_default_machine_type  https://review.opendev.org/66403608:01
*** takashin has left #openstack-nova08:01
lyarwoodstephenfin: ^ would you mind +W'ing these again once they pass, had to rebase to pull in https://review.opendev.org/#/c/664622/08:01
*** guilhermesp has quit IRC08:01
*** seyeongkim has quit IRC08:02
*** seyeongkim has joined #openstack-nova08:03
*** guilhermesp has joined #openstack-nova08:03
*** tetsuro has quit IRC08:13
*** ttsiouts has quit IRC08:16
*** igordc has quit IRC08:17
*** ttsiouts has joined #openstack-nova08:17
*** slaweq has quit IRC08:19
*** tetsuro has joined #openstack-nova08:19
*** ttsiouts has quit IRC08:21
*** tkajinam has quit IRC08:23
*** ttsiouts has joined #openstack-nova08:24
*** tetsuro has quit IRC08:29
*** markvoelker has joined #openstack-nova08:30
*** tetsuro has joined #openstack-nova08:30
*** boxiang_ has quit IRC08:31
*** boxiang_ has joined #openstack-nova08:31
*** mdbooth has joined #openstack-nova08:34
*** tssurya has joined #openstack-nova08:35
*** tetsuro has quit IRC08:36
*** derekh has joined #openstack-nova08:37
*** imacdonn has quit IRC08:38
*** guozijn has quit IRC08:38
*** nicolasbock has quit IRC08:38
*** imacdonn has joined #openstack-nova08:39
*** takamatsu has quit IRC08:39
*** takamatsu has joined #openstack-nova08:40
openstackgerritSurya Seetharaman proposed openstack/nova master: [WIP] Add 'power-update' external event to listen to ironic  https://review.opendev.org/64561108:49
*** jaosorior has quit IRC08:51
*** cdent has joined #openstack-nova08:58
openstackgerritBrin Zhang proposed openstack/nova master: WIP: Specify availability_zone to unshelve  https://review.opendev.org/66385108:59
*** nicolasbock has joined #openstack-nova09:00
*** markvoelker has quit IRC09:03
*** slaweq has joined #openstack-nova09:03
*** luksky has quit IRC09:04
*** slaweq has quit IRC09:09
* asettle is re-reading backscroll09:09
asettleefried, "is comprised of" is what gets you going :p love it09:09
aspiersasettle: this means you're a nova hacker now09:10
asettleI imagine that's correct, yep09:10
*** takamatsu has quit IRC09:14
*** ociuhandu has joined #openstack-nova09:17
openstackgerritBrin Zhang proposed openstack/nova master: WIP: Specify availability_zone to unshelve  https://review.opendev.org/66385109:21
openstackgerritLi Zhouzhou proposed openstack/nova stable/rocky: NumaTopolgyFilter dosen't work as expected as pci_numa_policy is 'legacy'  https://review.opendev.org/66483809:31
*** maciejjozefczyk has joined #openstack-nova09:34
*** hjensas is now known as hjensas|afk09:38
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: flatten rbd images when unshelving an instance  https://review.opendev.org/45788609:40
asettlesean-k-mooney, I should never have commented on that post. Now it's a fan fav :p09:40
openstackgerritLee Yarwood proposed openstack/nova stable/stein: Skip test_check_doubled_words hacking check UT  https://review.opendev.org/66484109:41
openstackgerritLee Yarwood proposed openstack/nova stable/stein: Fix python3 compatibility of rbd get_fsid  https://review.opendev.org/66451209:42
*** maciejjozefczyk has quit IRC09:49
*** maciejjozefczyk has joined #openstack-nova09:50
*** takamatsu has joined #openstack-nova09:51
lyarwoodmdbooth: https://review.opendev.org/#/c/457886/ - would you mind taking a look at this today if you have time09:56
mdboothlyarwood: Ack. I recall not liking it in a previous version?09:57
lyarwoodmdbooth: well as long as you're going into this with an open mind09:59
lyarwoodmdbooth: but yeah I've reworked it since then iirc09:59
mdboothlyarwood: ;)09:59
mdboothlyarwood: I saw.09:59
*** markvoelker has joined #openstack-nova10:00
*** jangutter has joined #openstack-nova10:02
*** ttsiouts has quit IRC10:05
openstackgerritStephen Finucane proposed openstack/nova master: Recalculate 'RequestSpec.numa_topology' on resize  https://review.opendev.org/66252210:05
openstackgerritStephen Finucane proposed openstack/nova master: tests: Cleanup of '_test_resize' helper test  https://review.opendev.org/66424510:05
openstackgerritStephen Finucane proposed openstack/nova master: tests: Add '_setup_compute_services' helper  https://review.opendev.org/66310210:05
*** brinzh has joined #openstack-nova10:06
*** jangutter_ has quit IRC10:06
*** brinzhang has quit IRC10:08
sean-k-mooneyasettle: i found a book you will hate or love last night https://www.amazon.com/Accidence-Will-Happen-Non-Pedantic-English/dp/0297871935/ref=tmm_hrd_swatch_0?_encoding=UTF8&qid=1560294844&sr=8-210:09
asettleHa!10:09
asettleI'm not entirely too sure I want to read that, you know10:09
sean-k-mooneyi went donw the rabbit whole of is "is comprised of" correct to use in ireland vs other english speaking countries10:11
sean-k-mooneyconsidering i the amount of govenment and university site in ireland that use it i have more or less come to the conclution that in ireland at least its an accepted usage but i came across that book in my adventures10:14
*** sridharg has quit IRC10:15
*** maciejjozefczyk has quit IRC10:15
*** takamatsu has quit IRC10:16
cdentasettle: step away from the usage books10:20
asettlesean-k-mooney, damn that is a rabbit hole10:21
asettleI'll admit - I don't care terribly ;) it took me a little while to wrap my head around the discussion10:21
asettleThinking about it, I would usually put "is comprised of" but efried is right, it's not correct10:21
asettlecdent, I'm so very far away10:22
*** rpittau is now known as rpittau|afk10:22
* cdent has learned not to question efried on grammar10:22
asettleYeah good call. I won't be doing that either :p10:24
cdentsave your energy for philosophical debate10:25
asettleWhich... I do... regularly?10:25
*** jbernard_ is now known as jbernard10:26
cdentI mean with efried in particular. It's a bizarre form of stimulating10:26
cdentwith grammar you can't win, but philosophy, something else happens10:27
*** guozijn has joined #openstack-nova10:32
*** markvoelker has quit IRC10:34
*** davidsha has joined #openstack-nova10:38
*** guozijn has quit IRC10:43
sean-k-mooneycdent: actully that useage book basicly explains why many of the rules we use are no longer followed in common usage and advies that you use common sense when deciding if a rule should be followed or ignored10:48
sean-k-mooneycdent: which is why is said asettle will either love it or hate it :)10:48
cdentin truth, neither you, nor I, are in much of a position to be discussing usage :)10:49
*** takamatsu has joined #openstack-nova10:49
sean-k-mooneythe second half of the book i belive tries to explain why  some of the rule exist and actully teaches you why some of the rule exisit10:49
sean-k-mooneycdent: that is very true that said i at least can ligitamtly point to the fact i speak a different dialect of english which has idioms from irish carried over :)10:51
* cdent thinks of an excuse10:51
cdenthmm. born UK, raised US, now in UK? not really good enough10:52
sean-k-mooneyoh i didnt know you grew up in the US what part?10:52
*** jaosorior has joined #openstack-nova10:53
cdentindiana, kentucky, ohio10:53
sean-k-mooneydo you ever miss it?10:54
sean-k-mooneyefried: did your hacking change merge last night?10:55
cdentFor 4 years before I moved to the UK I lived in Seattle. I sometimes miss the pacific northwest, but don't really miss the other parts.10:58
kashyapsean-k-mooney: I think it did10:58
cdentit did, saw the launchpad update10:59
sean-k-mooneycool so i just need to rebase on top of master rather then that specific patch10:59
*** ttsiouts has joined #openstack-nova11:01
*** hjensas|afk is now known as hjensas11:02
*** luksky has joined #openstack-nova11:14
*** jaosorior has quit IRC11:15
*** mdbooth has quit IRC11:18
* aspiers is dealing with the same hacking rebase11:20
*** adrianreza_ has joined #openstack-nova11:26
*** jaosorior has joined #openstack-nova11:28
openstackgerritAdam Spiers proposed openstack/nova master: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported  https://review.opendev.org/63868011:34
openstackgerritAdam Spiers proposed openstack/nova master: Track inventory for new MEM_ENCRYPTION_CONTEXT resource class  https://review.opendev.org/66210511:34
openstackgerritAdam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption  https://review.opendev.org/66442011:34
openstackgerritAdam Spiers proposed openstack/nova master: Use fake flavor instead of empty dict in test  https://review.opendev.org/66255511:34
openstackgerritAdam Spiers proposed openstack/nova master: Pass extra_specs to flavor in vif tests  https://review.opendev.org/66255611:34
openstackgerritAdam Spiers proposed openstack/nova master: Extract SEV-specific bits on host detection  https://review.opendev.org/63633411:34
openstackgerritAdam Spiers proposed openstack/nova master: Add <launchSecurity> element to guest config for AMD SEV  https://review.opendev.org/63631811:34
openstackgerritAdam Spiers proposed openstack/nova master: Allow guest devices to include <driver iommu='on' />  https://review.opendev.org/64456411:34
openstackgerritAdam Spiers proposed openstack/nova master: WIP: Detect that SEV is required and enable iommu for devices  https://review.opendev.org/64456511:34
openstackgerritAdam Spiers proposed openstack/nova master: Use <launchSecurity> element when SEV is required  https://review.opendev.org/66255711:34
openstackgerritAdam Spiers proposed openstack/nova master: Enable memory locking if SEV is requested  https://review.opendev.org/66255811:34
aspiersefried: all SEV stuff now in a single series ^^^ The top 3 can be ignored for now however, since the 3rd from top is still WIP.11:39
*** ratailor has quit IRC11:41
*** hjensas has quit IRC11:57
*** francoisp has quit IRC12:07
*** francoisp has joined #openstack-nova12:09
*** udesale has quit IRC12:10
*** brinzh has quit IRC12:10
*** udesale has joined #openstack-nova12:11
*** bbobrov has quit IRC12:14
*** dave-mccowan has joined #openstack-nova12:17
*** guozijn has joined #openstack-nova12:25
openstackgerritArtom Lifshitz proposed openstack/nova master: Revert resize: wait for events according to hybrid plug  https://review.opendev.org/64488112:25
openstackgerritArtom Lifshitz proposed openstack/nova master: WIP: Include direct-physical in compute manager events check  https://review.opendev.org/66443112:25
openstackgerritArtom Lifshitz proposed openstack/nova master: [DNM] testing bug/1813789 revert resize events  https://review.opendev.org/66444212:25
*** boxiang_ has quit IRC12:27
*** boxiang_ has joined #openstack-nova12:27
alex_xuefried: sean-k-mooney bauzas do you have any idea how can I process when the user specify both the hw:pmem and resources extraspec https://review.opendev.org/#/c/601596/14/specs/train/approved/virtual-persistent-memory.rst@26112:29
sean-k-mooneyim reading that spec at the moment12:29
alex_xuI thought we should have similar problem when we have numa on placement. how to deal with hw:numa_* stuff and resources12:29
sean-k-mooneywell at present the resouces:* extra spec are merged with teh auto calluated set12:30
sean-k-mooneyso we caluate teh vcpu and ram form the flavor and then you can override that using resouces:MEMORY_MB=X12:31
sean-k-mooneybut ideally i think we would prefer people not to ues resouces: directly12:31
alex_xu+1 on not use resources directly12:32
sean-k-mooneyif they use hw:pmem that give us the flexablity adapt to placment modeling changes without needing to modify flavors12:32
alex_xusean-k-mooney: the problem is we have instance.vpmems field, and we extra the vpmem from extra spec, and put them in instance.vpmems. if the user uses resources directly, then we should parse resources, and put them back to the instance.vpmems?12:33
sean-k-mooneyusign resouces:* directly works but its a leaky abstraction12:33
alex_xualso agree with that12:33
*** hjensas has joined #openstack-nova12:34
alex_xuI thought we will have same problem for instance.numa_topology. if the user use the resources directly, how can we parse the guest numa topo from resources extra spec, and put them back to isntance.numa_topology12:34
sean-k-mooneywell today we dont model numa in placmenet12:35
sean-k-mooneyif we did then it would be a proablem we would have to sovle yes12:35
alex_xuit is a problem for pmem now :)12:35
sean-k-mooneythe hw:* extrapecs are the ahtoritive ones for how the guest is virtualised12:35
sean-k-mooneythe resouces:* are authritive for resouce usage12:36
sean-k-mooneyif there is a conflcit wew could rais an exception12:36
sean-k-mooneyi need to finish re reading the spec but are we adding a request prefilter for this12:36
*** rpittau|afk is now known as rpittau12:36
sean-k-mooneyi.e. to convert form hw:pmem to the placement requests?12:36
alex_xudo we need? or just parse the hw:pmem in the ResourceRequest.from_extra_specs ?12:37
sean-k-mooneyif so then i would have it validate them and raise an exception if there is a conflict12:37
aspierssean-k-mooney, alex_xu: I just did something very similar for SEV12:37
aspiershttps://review.opendev.org/#/c/664420/412:37
sean-k-mooneyalex_xu: am we could just parse it there yes12:37
alex_xuaspiers: nice12:37
alex_xusean-k-mooney: yea12:38
sean-k-mooneyaspiers: your using a request prefilter12:38
aspiersyes12:38
alex_xuat least request prefilter is better than mixing everything ResourceRequest.from_extra_specs12:39
sean-k-mooneyright the ohter option is to do it here https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L38712:39
sean-k-mooneyand in resources_from_request_spec12:40
sean-k-mooneybut the prefilter i think are cleaner12:40
sean-k-mooneyboth would work12:40
alex_xuyes, agree12:40
alex_xuwe can add that for pmem12:40
*** jaosorior has quit IRC12:41
sean-k-mooneyalex_xu: as aspiers has done you can do your validation like this https://review.opendev.org/#/c/664420/4/nova/scheduler/request_filter.py@19712:41
sean-k-mooneyto ensure there is no conflict12:42
aspiersright12:42
alex_xusean-k-mooney: then the instance is going to error status?12:42
sean-k-mooneyyes i think so12:42
alex_xuI guess people hate the instance is going to error status....12:42
sean-k-mooneywe will refuse to sechdule12:43
sean-k-mooneywell if we did not validate it would still go into error12:43
sean-k-mooneybut it woudl be a no valid host error12:43
alex_xuwe can validate that in the API layer12:43
sean-k-mooneyas teh livbrt driver would presuably fail to swapn it12:43
alex_xuthe request prefilter is only do the placement translation12:44
sean-k-mooneywhere in the api laryer?12:44
sean-k-mooneyon flavor setting properties on teh flaovr or on instance spawn12:44
alex_xulike somewhere we validate the hw:numa_* extra specs12:45
sean-k-mooneywe dont12:45
sean-k-mooneywell the first validation happens in the numa toplogy filter12:45
sean-k-mooneybut its not really validation we try to use the values to filter a host and that either work or it doesnt12:46
sean-k-mooneyso i think doing it in the prefilter which is even earlier in scheduling is fine12:46
*** mdbooth has joined #openstack-nova12:46
alex_xuwo do, let me find the link12:46
alex_xuhttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L65912:47
sean-k-mooneyoh ok i really never knew that was there12:48
sean-k-mooneyin that case sure you can add the same validate for pmem12:48
alex_xuso we can resolve the conflict of hw:pmem and resource:* somewhere like that12:48
alex_xu\o/ finally find something sean-k-mooney doesn't know12:49
* aspiers claps12:49
alex_xuso I can override resources:* when hw:pmem present.12:49
sean-k-mooneyhehe :) there are plenty of things i dont know like how to use a mac without breaking it or how to spell litrally everything12:49
aspiersXD12:50
alex_xuhah12:50
aspierssean-k-mooney: maybe not, but I bet you can help me with this problem12:50
*** _erlon_ has joined #openstack-nova12:50
alex_xuthe last question is what should I do for the user only specify the resources:*. so I can prase the resources:* and put them into instance.vpmems.12:50
aspiershttps://review.opendev.org/#/c/644565/5/nova/virt/libvirt/driver.py@162512:50
aspiersI need to change _sev_required() so that it checks the resource allocations for the instance (the MEMORY_ENCRYPTION_CONTEXT class)12:51
aspiersbut the callers don't have access to the resource allocations12:51
aspiersAFAICS12:51
sean-k-mooneyalex_xu: i think we shoudl require uses to use hw:pmem personally as we might want to use the resouce class for something else in the future12:51
aspiersthey have access to the request context and the instance, but not the allocations12:52
sean-k-mooneyalex_xu: im thinking of the case where we might want to back guest ram by PMEM12:52
sean-k-mooneye.g. as an alternive to hugepages12:52
sean-k-mooneyor file backed memeory12:52
sean-k-mooneyaspiers: looking12:53
*** zbr|rover is now known as zbr|flow12:53
alex_xugood idea12:53
aspiersI found _instance_to_allocations_dict() in scheduler/client/report.py which maybe could extract the allocations from the instance, but I don't know if that's right12:53
alex_xudo you mean reject pmem resource class in extra spec resource:*?12:53
aspiersalso, nothing uses that method any more, since Iec02942d38 removed the last callers of it12:53
* aspiers looks at efried for that12:54
sean-k-mooneyalex_xu: we could but i was thinking just not populating the instance.vpmems from it12:54
*** guozijn has quit IRC12:55
alex_xuthat will do an allocation in the placement, but in the end, the instance won't attach the pmem12:55
sean-k-mooneyaspiers: do you need to cehck the resouce allocation or jsut the flavor12:55
aspierssean-k-mooney: the allocation12:55
aspiersthat's what efried said yesterday12:55
sean-k-mooneyim not sure why checking the request_sepc or flavor/image would not be enough12:56
aspierssean-k-mooney: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-06-11.log.html#t2019-06-11T16:49:5112:56
aspierssean-k-mooney: but maybe when efried wrote that he didn't know that _sev_required() needs to be called from multiple locations in the driver code which don't have access to allocations13:00
aspiersI guess I could set another instance variable13:00
sean-k-mooneythe instance contains the request_sepc and the request spec contains the request_resouces13:00
*** spatel has joined #openstack-nova13:00
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L9813:00
aspiersbut requested_resources is different from allocations, no?13:01
sean-k-mooneyit is13:01
sean-k-mooneyand it does not currenly hav the info you want see the comment above13:01
*** markvoelker has joined #openstack-nova13:01
aspiersright13:01
sean-k-mooneyim just wondering is that better to use in the future13:01
aspiersin fact efried wants me to help fix that13:01
aspiersI'm guessing that code which wants to know whether to add SEV bits to the libvirt XML config should be checking what got allocated, not just what got requested13:02
sean-k-mooneythey should be the same thing13:02
sean-k-mooneyif placemnet returned an allcoation candatae then eveything that was requested was allcoated13:03
aspiersI guess in the MEM_ENCRYPTION_CONTEXT case where only 1 unit is requested they have to be the same13:03
sean-k-mooneylooking at the instance object i dont see the allcoation stored anywhere13:03
aspiersyeah I couldn't either13:03
aspiersI found https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L243413:05
*** luksky has quit IRC13:05
aspiersthat passes allocations to spawn() via https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L220313:07
sean-k-mooney ya we do pass them to the driver13:08
sean-k-mooneyhttps://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L220713:08
aspiersthat's 4 lines below my link :)13:08
aspierssame thing13:08
aspiersbut then allocs doesn't get passed around to all the smaller methods called by spawn()13:08
sean-k-mooneyright its only used to get teh mdevs13:09
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L323713:09
aspiersso maybe I can set an _sev_required instance variable in spawn()13:09
sean-k-mooneywell you could jsut pass the allcoation to _get_guest_xml13:10
aspiersor somewhere underneath that13:10
aspiersthat's a good idea13:10
aspiersI guess I only need it for constructing XML13:10
aspiersso that would scope it correctly13:11
aspiershopefully efried will come online before I disappear down this rathole :)13:11
*** BjoernT has joined #openstack-nova13:12
sean-k-mooneyits still a little messy13:12
sean-k-mooneyi think really we want to add the allcotion to the instance13:12
sean-k-mooneythat way you dont need to pass a new param all over the place13:13
aspiersyeah13:13
sean-k-mooneyand i think more things will need the allocation in the future anyway13:13
sean-k-mooneywe track things like pci device allcotation in teh instance already so i think that is the best path forward.13:13
aspierssounds reasonable but I can't really comment13:14
*** eharney has joined #openstack-nova13:14
sean-k-mooneyefried: when you are online any objection to adding the allocations form placmenet to the instnace object?13:15
*** lbragstad has joined #openstack-nova13:20
artomsean-k-mooney, sorta like network_info in info_cache?13:21
sean-k-mooneynot quite although kind of13:22
sean-k-mooneyartom: we store the list of pci devices allocated to an instance in the instance13:23
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/objects/instance.py#L20013:23
sean-k-mooneyso that we can use the same ones on reboot13:23
sean-k-mooneyit would be somewhat like storing the vifs in the info_cache13:23
sean-k-mooneybut keeping the allocation in the insantce so we dont have to look them up on swapn or reboot makes sense13:24
sean-k-mooney*start or reboot13:24
*** mgariepy has quit IRC13:27
*** artom has quit IRC13:29
*** mgariepy has joined #openstack-nova13:29
*** pcaruana has quit IRC13:30
*** pcaruana|afk| has joined #openstack-nova13:30
sean-k-mooney...13:30
sean-k-mooneyi think our vgpu code is busted13:30
sean-k-mooneybauzas: did you ever test stopping an instance with vgpus13:31
sean-k-mooneythen starting it again13:31
*** jaosorior has joined #openstack-nova13:32
sean-k-mooneypower_on in the libvirt driver delegate to _hard_reboot which assumes the xml still exists to get the mdevs from13:32
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2897-L290013:32
sean-k-mooneypower_off calls destroy13:33
sean-k-mooneyso if you shutdown an instance with vgpus and then start it again it wont have vgpus...13:33
*** dklyle has quit IRC13:34
*** markvoelker has quit IRC13:34
kashyapSpeaking of assigned devices, somepeople might find this tool ("mdevctl") useful: https://github.com/awilliam/mdevctl13:39
kashyapMore info and background about it here:13:39
kashyaphttps://www.redhat.com/archives/libvir-list/2019-May/msg00722.html13:39
kashyap("mdevctl: A shoestring mediated device management and persistence utility")13:39
kashyapIt's a shell tool.  So, be gentle with your eyes :D13:40
sean-k-mooneyya maybe13:40
sean-k-mooneythey are not that hard to manage i personlaly would praobly do it with systemd rather then udev personally13:41
kashyapI don't know, if the VFIO maintainer suggests that, then I'd go the route they suggest.13:42
sean-k-mooneyperhaps if it existited when i started managing mdev like 2 years ago maybe i think its still failly tivial to do yourself too13:44
sean-k-mooneykashyap: this is the striped down lib we created for managian mdevs for smart nics last year https://github.com/intel-orchestration-software/networking-vhost-vfio/blob/master/networking_vhost_vfio/mdev/mdev.py13:47
kashyapsean-k-mooney: If it were "trivial", why would they write that tool?13:47
sean-k-mooneyit does not do persistence but at the time i also looked into doing it with systemd13:47
sean-k-mooneykashyap: because they felt like it? just because its trivial to do does not mean you dont have to do it alot and still want to automate it13:48
*** liuyulong has joined #openstack-nova13:49
*** rafaelweingartne has joined #openstack-nova13:49
*** mriedem has joined #openstack-nova13:49
openstackgerritMerged openstack/nova master: Make get_provider_by_name public and remove safe_connect  https://review.opendev.org/66406213:49
rafaelweingartneHello guys, is there an "openstack server event list" command like that is able to list the events for deleted VMs?13:50
*** jaosorior has quit IRC13:50
sean-k-mooneyim not sure that is what that is for13:52
*** mlavalle has joined #openstack-nova13:52
rafaelweingartneno?13:52
*** ricolin_ has joined #openstack-nova13:52
sean-k-mooneyi think it list the life cycle events a server has undergone13:52
sean-k-mooneyi dont think you can use it to wait for an event13:52
rafaelweingartneIt looks like it is presenting he vents I need/want such as attaching something, and or creating the vm13:53
rafaelweingartneah13:53
rafaelweingartneno, I do not want to wait13:53
kashyapsean-k-mooney: It's not "they felt like it"; there's a proper rationale there.13:53
kashyap[quote]13:53
kashyapCurrently mediated device management, much like SR-IOV VF management,13:53
kashyapis largely left as an exercise for the user.  This is an attempt to13:53
kashyapprovide something and see where it goes.  I doubt we'll solve13:53
kashyapeveryone's needs on the first pass, but maybe we'll solve enough and13:53
rafaelweingartneI just want to list all events that already happened to a VM13:53
kashyapprovide helpers for the rest.  Without further ado, I'll point to what13:53
kashyapI have so far:13:53
kashyap[/quote]13:53
rafaelweingartnesean-k-mooney: I think your reply was not meant for me13:54
rafaelweingartnesorry ;)13:54
sean-k-mooneykashyap: sure but its proably not the first attempt to do that either13:54
*** whoami-rajat has quit IRC13:55
sean-k-mooneyrafaelweingartne: no it was13:55
*** ricolin has quit IRC13:55
sean-k-mooneyi was stating that cli command is to show the list of event that server has undergon. but im currently confiming13:55
rafaelweingartneah o13:56
rafaelweingartneok13:56
rafaelweingartnebut that is actually what I want/need13:56
rafaelweingartneto list everything that has already happened to a VM13:56
rafaelweingartnethe problem is that it only works for VMs that have not beeing deleted13:56
rafaelweingartneor at least, I was not able to use it for deleted VMs13:56
sean-k-mooneydeleted or soft deleted13:58
rafaelweingartnethe difference is not that clear to me13:58
rafaelweingartnedeleted13:58
*** whoami-rajat has joined #openstack-nova14:01
sean-k-mooneythis is basically showing the events form the instance action log14:01
sean-k-mooney i did not think we removed that when we deleted an instace provided you have not archive teh deleted instances or purged them form the db14:02
sean-k-mooneybut maybe we do not allow you to retrive the info14:02
rafaelweingartnethat is what I thought14:03
rafaelweingartneis this implemented in Nova API?14:03
*** yankcrime has quit IRC14:03
rafaelweingartneor is it somewhere else? where I can take a look and maybe propose a method to retrieve data for deleted VMs as well14:03
sean-k-mooneyi think its hitting this endpoint https://developer.openstack.org/api-ref/compute/?expanded=list-server-usage-audits-detail14:04
*** jaosorior has joined #openstack-nova14:04
sean-k-mooneyactully no that is not correct14:05
sean-k-mooneyits hitting the server action endpoint14:06
sean-k-mooneyhttps://developer.openstack.org/api-ref/compute/?expanded=list-server-usage-audits-detail,list-actions-for-server-detail#list-actions-for-server14:06
rafaelweingartnecool thanks14:07
rafaelweingartneI was looking for "/servers/{server_id}/events"...14:08
rafaelweingartnenow I know why I did not find it14:08
rafaelweingartneWhat does this "Action information of deleted instances can be returned for requests starting with microversion 2.21." mean?14:08
rafaelweingartneNova version?14:08
rafaelweingartneNova-compute*14:09
sean-k-mooneythe nova api support microversion form v2.1 on14:09
sean-k-mooneybut the openstack client does not use them14:09
sean-k-mooneyit default to 2.114:09
sean-k-mooneyso if you want to get it to work you have to pass a a microverion of at lest 2.2114:10
sean-k-mooneyone sec14:10
sean-k-mooneyadd --os-compute-api-version 2.21 to the request14:11
sean-k-mooney*command14:11
*** factor has quit IRC14:12
*** factor has joined #openstack-nova14:15
rafaelweingartnesomething like? "openstack server event list 9b82ae8f-ac7e-47e9-819c-24105631df80 --os-compute-api-version 2.21"14:16
rafaelweingartneI just checked the code, and aren't the instances removed from "instance_mappings" table when they get deleted?14:16
*** takamatsu has quit IRC14:18
*** igordc has joined #openstack-nova14:26
*** ttsiouts has quit IRC14:27
*** ttsiouts has joined #openstack-nova14:28
efriedsean-k-mooney: First blush, adding the allocations from placement to the Instance object sounds like a solid idea.14:29
*** takamatsu has joined #openstack-nova14:31
*** markvoelker has joined #openstack-nova14:32
*** cdent has quit IRC14:32
*** ttsiouts has quit IRC14:32
openstackgerritStephen Finucane proposed openstack/nova master: Fix double word hacking test  https://review.opendev.org/66494014:34
stephenfinefried: f*** me that was a rabbit hole and half ^14:34
efriedstephenfin: no doubt. Looking...14:35
stephenfintl;dr: I can't decide if either the Python patch or pycodestyle is broken, but it's the edgiest of edge cases that we'd only really see in tests, so we can work around it14:35
mriedemrafaelweingartne: no,14:37
rafaelweingartnehmm14:37
mriedemthe instance mappings are cleaned up when you archive14:37
mriedemnova-manage db archive_deleted_rows14:38
mriedemrafaelweingartne: 2.21 is about instance actions / events14:38
*** takamatsu has quit IRC14:38
mriedemrafaelweingartne: https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server-event.html14:39
gibistephenfin: what a detective work!14:39
dansmithmriedem: can you quickly weigh in on this? I thought you might care about the use of a sentinel value in nova-manage. Otherwise I'm good with it: https://review.opendev.org/#/c/662383/514:42
*** dklyle has joined #openstack-nova14:45
mriedemew14:45
*** tetsuro has joined #openstack-nova14:46
* dansmith knew it14:46
dansmithbefore you shame him, note that it was my idea :)14:47
*** ttsiouts has joined #openstack-nova14:47
*** hamdyk has quit IRC14:48
mriedemi'm just trying to think of alternatives,14:48
mriedemi saw melwitt pointed out https://review.opendev.org/#/c/603998/ but i'm not sure what that change is doing,14:49
mriedemwith takashi's change,14:49
mriedemif you specify one but not the other it's an error,14:50
mriedemi was thinking, what if we change the logic such that if you specify one but not the other, we just don't read from the config for the other (don't set/update the other)14:50
*** JamesBenson has joined #openstack-nova14:50
mriedemif you don't specify either, we use config,14:50
mriedemif you specify both, we set/update both,14:50
dansmiththat just seems confusing to me14:50
mriedemif you only provide one, we only use one14:50
mriedemi think that's more in line with how osc set commands work14:51
dansmithI was actually expecting to have a --transport_url=(keep|config|[url]) sort of thing, but..14:51
dansmiththe confusing bit is that we do the magic config thing if we don't specify either.. if we specify one, then we do a totally different set of things14:52
mriedemi'm assumine when this was written, we expected people were either using all of the command options or none to let config handle it14:52
mriedemnot a mix14:52
dansmiththis has tripped up more than one person who was surprised by one or the other behaviors14:52
dansmithwell,14:52
dansmithI think it actually came from create, where that makes more sense14:53
dansmithand we imported the same behavior for update where it does not14:53
*** Luzi has quit IRC14:54
mriedemyeah ok i can see that,14:54
mriedemso in that case i think it makes more sense to only update the field provided via the option if only one option is provided, and ignore the other (don't use config)14:54
dansmithle sigh14:55
mriedemhey, you asked me14:57
mriedemanyway, i commented14:58
mriedemif we need a tie breaker i vote that we ask dean to weigh in14:58
mriedemmean dean okerlund14:58
mriedemfrom WWF fame14:58
*** artom has joined #openstack-nova15:02
*** cdent has joined #openstack-nova15:04
*** cfriesen has joined #openstack-nova15:05
*** markvoelker has quit IRC15:05
*** jaosorior has quit IRC15:06
openstackgerritStephen Finucane proposed openstack/nova master: Fix double word hacking test  https://review.opendev.org/66494015:07
bauzassean-k-mooney: hey15:08
bauzassean-k-mooney: yeah I tested it and it worked15:08
bauzasie. stopping the instance and then restarting it15:09
stephenfinefried: I need to rebase this series now, right? https://review.opendev.org/#/c/651311/15:09
stephenfinto pick up the fix to test_hacking.py15:09
sean-k-mooneybauzas: ok looking at the code im not sure where we figureout the mdevs in that case but i also didnt look15:09
sean-k-mooneyto far15:09
bauzassean-k-mooney: I provided a change for that15:09
bauzassec15:09
sean-k-mooneymy concern was we had to hit the placmenet api to look up the allcoation again15:10
sean-k-mooneywhich i dont think we shoudl have to do.15:10
efriedstephenfin: I wouldn't think you need to rebase; I think zuul automatically rebases you against tip of master before starting tests15:10
bauzassean-k-mooney: https://review.opendev.org/#/c/564257/15:11
bauzasand https://review.opendev.org/#/c/533642/15:11
sean-k-mooneybauzas: that wont fix it15:11
sean-k-mooneythe second on might15:12
stephenfinefried: Yeah, I'm not sure. That said, I think I'm going to have to recheck every one of them again anyway so maybe a rebase would be the surer thing15:12
stephenfinYeah, they're all -215:12
* stephenfin rebases :(15:12
efriedstephenfin: Yeah, that would be an easy way to get them all back in the queue. Feel free to re+W the ones that were already +A.15:12
sean-k-mooneybauzas: quickly looking i dont think either of those will fix the edgecase i am thinking of15:12
bauzassean-k-mooney: mmm N15:13
bauzas?15:13
sean-k-mooneybauzas: if the instance is not found on the host in libvirt you retrun {]15:13
openstackgerritStephen Finucane proposed openstack/nova master: Remove cells v1 parameter from 'ComputeTaskAPI.resize_instance'  https://review.opendev.org/65131115:13
openstackgerritStephen Finucane proposed openstack/nova master: Stop passing 'kwargs' to 'rebuild_instance'  https://review.opendev.org/65131215:13
openstackgerritStephen Finucane proposed openstack/nova master: Stop passing 'delete_type' to 'terminate_instance'  https://review.opendev.org/65131315:13
openstackgerritStephen Finucane proposed openstack/nova master: filters: Stop handling cells v1  https://review.opendev.org/65131415:13
openstackgerritStephen Finucane proposed openstack/nova master: Remove nova.compute.*API() shims  https://review.opendev.org/66052715:13
openstackgerritStephen Finucane proposed openstack/nova master: Add reno for removed cells v1 policies  https://review.opendev.org/66203115:13
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'InstanceUnknownCell' exception  https://review.opendev.org/66241115:13
openstackgerritStephen Finucane proposed openstack/nova master: Ensure controllers all call super  https://review.opendev.org/66095015:13
sean-k-mooneybauzas: we can talk after standup15:13
*** amodi has joined #openstack-nova15:14
*** Sundar has joined #openstack-nova15:16
sean-k-mooneybauzas: basically if we stop the instance then we undefine the domain so if start it when we call _get_all_assigned_mediated_devices15:18
sean-k-mooneybauzas: we retrun {}15:18
bauzasI'm pretty sure I tested it15:18
stephenfinmriedem: Are you okay for me to rebase https://review.opendev.org/#/c/621061/ onto the cells v1 removal series (all but one +W'd now). It conflicts with that series and I'd like to use it as a new base for https://review.opendev.org/#/c/651315/15:18
mriedemsure15:22
mriedemmaybe you want to re-apply your +2 when doing so15:22
*** nicolasbock has quit IRC15:24
*** pcaruana|afk| has quit IRC15:30
Sundarsean-k-mooney: Re. tempest CI with a fake driver/device, I have some questions15:39
Sundarsean-k-mooney: When there is no real device, the VM bringup is going to fail. Not only that, there would be no VM in 'virsh list', so we can't do 'virsh dumpxml ...' to see if the right device(s) got attached.15:41
SundarSo, how would would one do any testing?15:41
sean-k-mooneySundar: there are a few ways. one we can use dummy devices15:42
sean-k-mooneybut the intent is to test teh end to end workflow not assert a spcific device exits15:43
SundarWhat would be the success metric for the test?15:43
mriedemSundar: tempest isn't going to be doing virsh list anyway15:46
mriedemtempest tests should be hypervisor agnostic, like the compute api should be hypervisor agnostic15:46
mriedemSundar: the basic success metric for tempest tests are going to be that the API behaves as expected,15:47
mriedemi.e. if i create a server with a flavor configured for an ARQ device profile, that once the server is ACTIVE there is an attached ARQ in cyborg15:47
mriedemand when the server is deleted, the corresponding ARQ resource is also deleted15:48
*** helenfm has quit IRC15:48
mriedemSundar: whitebox integration testing is something that would likely be done in a tempest plugin / tests that are configured to only run when there is real hardware in a 3rd party CI env15:49
Sundarmriedem: "once the server is ACTIVE" -- with a fake device, it never becomes active. It will go to error state.15:50
mriedemSundar: because of the event not being sent from cyborg, or because libvirt will fail to start the domain?15:51
SundarWe need to ensure the device gets attached to the VM15:51
*** jangutter has quit IRC15:51
sean-k-mooneySundar: not if we add a bus type for dummy devices and handel that in nova15:51
Sundarmridem: latter - libvirt will fail it15:51
mriedemthen i agree with sean-k-mooney that we'd need to stub something out if we know we're using a fake device,15:52
sean-k-mooneySundar: we dont  we jsut need to pass info to nova to let it know its a fake device and libivirt can just not try to atach it15:52
mriedemwhich is gross, but i'd rather have that than no api integration testing15:52
Sundarsean-k-mooney: 'bus type for dumy devices' -- is this a new thing? It is not there today, right?15:52
mriedemwouldn't there be some metadata on the ARQ resource that can tell us (nova) that it's a fake device?15:52
sean-k-mooneysure but its useful for testing15:52
mriedemsimilar to vif type on a port15:53
mriedemor type on a volume15:53
*** ttsiouts has quit IRC15:53
*** ttsiouts has joined #openstack-nova15:53
sean-k-mooneySundar: we have many thing we can do like have the fake driver create mdev or other software device like a loop device and tell nova to use those too15:54
sean-k-mooneyor we can have a sentenel that just tells nova its a fake device for testing15:54
Sundarmriedem, sean-k-mooney: The attach handle in the ARQ, returned by Cyborg to Nova virt driver, will identify the type of the handle, e.g. 'PCI'. I could return a special type, say, 'testPCI', and modify Nova virt driver to ignore that15:55
SundarThat would be used solely for testing15:55
sean-k-mooneySundar: yes that is basically what i was thinking wew would do15:55
mriedemi'd just calle it "fake" or something like that but yeah15:55
SundarAh ok. Got it. Thanks. :)15:56
sean-k-mooneySundar: the real thing we want to test is teh end to end workflow15:56
mriedems/real/main/ for now15:57
sean-k-mooney:) right15:57
mriedemreal low-level whitebox integration testing can be done with 3rd party CI and real hardware,15:57
mriedembut let's not get the cart before the horse15:57
sean-k-mooneyin a third party ci we can then also validate it with real hardware15:57
sean-k-mooneyyep15:57
*** ttsiouts has quit IRC15:58
stephenfinmriedem: Cool. I spotted some other things when rebasing. Comments left and I've a follow-up patch I'll post. Feel free to squash it into yours if you want16:01
openstackgerritStephen Finucane proposed openstack/nova master: Drop pre-cinder 3.44 version compatibility  https://review.opendev.org/62106116:01
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'MultiattachNotSupportedByVirtDriver'  https://review.opendev.org/65131516:01
openstackgerritStephen Finucane proposed openstack/nova master: Follow-up for I6a777b4b7a5729488f939df8c40e49bd40aec3dd  https://review.opendev.org/66496716:01
*** markvoelker has joined #openstack-nova16:02
*** gyee has joined #openstack-nova16:03
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'MultiattachSupportNotYetAvailable' exception  https://review.opendev.org/65131516:03
openstackgerritBalazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth  https://review.opendev.org/65510916:07
openstackgerritBalazs Gibizer proposed openstack/nova master: func test for migrate server with ports having resource request  https://review.opendev.org/65511316:07
*** pcaruana|afk| has joined #openstack-nova16:09
*** mdbooth_ has joined #openstack-nova16:10
*** mdbooth has quit IRC16:12
*** rafaelweingartne has quit IRC16:12
Nick_ADo you guys have any tips for what we should look at to determine why cloud-init is working properly for us on lxd but not kvm?16:14
*** mdbooth_ has quit IRC16:17
sean-k-mooneyif its working on lxd then the nova metadata service is working properly16:18
sean-k-mooneyit might be a diffrence in how netwroking works16:19
sean-k-mooneyyou really need to try and trace the request16:20
sean-k-mooneyso if you can log into one of your kvm instnce try an curl the metadata api via the 169... adress16:21
sean-k-mooneyif you dont have a vm image with a password set for debuging then you can enable config drive to initally be able to log in to the vm and debug the issue16:22
Nick_Athank you16:24
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: flatten rbd images when unshelving an instance  https://review.opendev.org/45788616:34
*** markvoelker has quit IRC16:36
openstackgerritAdam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption  https://review.opendev.org/66442016:37
mriedemstephenfin: this shouldn't be stable-only i don't think but you might want to verify if the bug is legit https://review.opendev.org/#/c/664838/116:42
*** dtantsur is now known as dtantsur|afk16:45
aspiersefried: Slightly out of my depth here. So shall I go ahead and change spawn() to persist allocations as a new field in the Instance object?16:48
*** derekh has quit IRC16:50
*** cdent has quit IRC16:50
efriedaspiers: I wasn't following whatever conversation led up to this16:50
efriedIs something we're doing with SEV requiring us to be able to look at the allocation some time after spawn?16:51
efriedor is this related to some other topic?16:51
aspiersYes16:51
efriedDo tell16:51
aspiershttp://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-06-12.log.html#t2019-06-12T12:50:5516:51
aspiersThere are multiple places scattered through the code for building the guest config XML which need to know whether SEV is required16:52
aspiersbut to perform the check in the way you requested, allocations need to be accessible at those points16:52
efriedsay wha now?16:53
efriedyou're telling me that every time libvirt attaches a volume, it rebuilds the whole XML from scratch?16:53
aspiersno16:53
aspiersit needs to know whether to use iommu16:53
efriedyou're telling me that attaching a volume needs to be SEV aware?16:53
aspiersnot necessarily even attaching a volume16:53
efriedokay, I see.16:54
aspiersjust block devices and stuff at launch-time16:54
aspiersand also to decide whether to include <locked />16:54
aspiersthe latest 3 commits at the top of the series16:54
efriedI think long term, having allocations on the instance object is a great idea. mriedem, dansmith, how do y'all feel about that?16:55
efriedHowever, in this scenario, you could also solve by commonizing (libvirt/utils?) the code that inspects the flavor/image meta.16:55
dansmithefried: why?16:55
aspiersYes, that possibility occurred to me too16:55
*** tetsuro has quit IRC16:55
*** luksky has joined #openstack-nova16:55
*** rpittau is now known as rpittau|afk16:56
efrieddansmith: example here is SEV. We were considering doing the flavor/image parsing and validation just once, in the request filter, to add resources=MEM_ENCRYPTION_CONTEXT. Then after that, e.g. in spawn(), just looking at the allocation for MEM_ENCRYPTION_CONTEXT so we don't have to redo that parsing/validation.16:56
aspiershere's sean-k-mooney's take: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-06-12.log.html#t2019-06-12T13:13:1616:57
efriedIn spawn specifically, we are getting the allocation as a param, so that's fine. But there are (aspiers tells me) other places where we need the same information but don't (currently) have access to the allocations.16:57
dansmithspawn having access to the allocations makes sense, but storing them on/with the instance doesn't really16:57
aspiershere's an example: https://review.opendev.org/#/c/662558/5/nova/virt/libvirt/driver.py16:57
dansmithI imagine bauzas would want access to allocations for gpu stuff as well, and I'm sure we discussed making that a param to spawn in the past16:58
aspierscurrently this is broken because it's insufficient to pass only the flavor to _sev_required()16:58
efriedallocations are already passed to spawn16:58
dansmithack, okay I was sure we had discussed16:58
aspiersright, the problem is that they are not passed much further on16:58
aspierssean-k-mooney's other suggestion was to pass from spawn() to _get_guest_xml() and so on16:58
dansmithyeah, pass them further if you want, but storing them .. no so much16:59
aspiersbut that doesn't solve things like attaching volumes to an SEV instance16:59
efriedyou could cache a map of instance:allocations on the virt driver16:59
dansmithefried: dude16:59
efriedbut if you restart the compute driver you'd have to rebuild that by querying placement16:59
dansmithaspiers: so look them up and pass them in if you need16:59
efriedwe've said we don't like virt drivers talking to placement17:00
dansmithyeah17:00
efriedthough I guess `read` may be acceptable17:00
dansmithand caching placement data is also smelly, IMHO17:00
dansmithefried: no, make compute manager look them up and pass them in17:00
efrieddansmith: You mean augment every ComputeDriver method to accept allocations?17:01
dansmithsurely we don't need them on every call17:01
efriedcreeping death of a thousand cuts17:01
efriedwe already store other (pre-placement) allocation-like things on the Instance, don't we? PCI devices and such?17:02
dansmithbut we own those things17:02
dansmithwe cache the neutron port information and it's a disaster17:02
efriedwhy?17:03
efriedbecause that information can get changed via neutron?17:03
efriedand then we have to figure out how to sync it?17:03
efriedIn this case nova does "own" the information.17:03
efriedthe allocation should not change unless nova changes it17:03
efriedwhereupon we're editing the Instance obj anyway.17:03
aspiersso how would something like DriverVolumeBlockDevice.attach() get hold of allocations?17:03
dansmithokay, whatever, you asked my my opinion.. I hate it. My opinion doesn't matter anyway, only mriedem's, so just do whatever he says17:04
aspiersif not via the Instance?17:04
aspiers(Yes, that is an honest stupid question)17:04
efriedaspiers: If I'm understanding dansmith correctly, he's suggesting adding an allocations param to attach_volume and then passing it down through the call stack to DVBD.attach()17:04
efrieddoing that ^ as needed every time we encounter a ComputeDriver operation who(se guts) require access to the allocation17:05
aspiersefried: so through attach_volume() in the manager?17:05
efriedyup. The compute manager would call placement to get the allocations for the instance before invoking the method.17:05
aspiersit seems pretty much every instance lifecycle method is already passing context and instance through17:05
efriedyes17:06
aspierslooks like adding allocations would bloat the already long parameter lists of many methods17:07
*** davidsha has quit IRC17:07
aspierslong parameter lists seem like a code smell to me in general, but I don't really enough about nova to judge here17:08
aspiersI'll do whatever you gurus think is best :)17:08
efriedlet's see what mriedem thinks17:08
aspiersOK17:09
dansmithwe have virtapi for compute drivers to ask compute manger for help. compute manager already has an in-memory cache of a bunch of this information, so letting the driver ask manager for allocation info for an instance when it needs it, which can be a readthrough cache operation would also be reasonable17:09
efriedah, that could work. What's that virtapi called?17:10
dansmithstoring this on the instance is pointless to me because I think we always need to get it from placement to be sure it's right I think, and the instance record is already a massive thing we shoot across the stressed RPC bus with a ton of extra crap we don't need 90% of the time17:10
efriedComputeDriver.virtapi...17:11
dansmithbut, as I said, it matters only what mriedem thinks, so ... no point in even discussing until he opines17:11
aspiersRPC bloat sounds like a very valid concern17:11
*** mdbooth_ has joined #openstack-nova17:12
sean-k-mooneyRPC bloat being the reason not to put it in the instance?17:16
aspiersthat's how I interpreted what dansmith said17:16
efriedThis virtapi thing is pretty small right now, basically just has wait_for_instance_event17:16
aspiersyeah17:16
aspiersalso, I don't see allocations cached in the manager17:16
sean-k-mooneydansmith: the allcoation should not change over the lifetime of the instance without a server action to modify it17:17
dansmithefried: it used to have a bunch of services the driver used, but has whittled down17:17
sean-k-mooneye.g. it will only cahnge on move operattion/resize/rebulds/or attaches/detaches17:17
dansmithsean-k-mooney: in some future where I can allocate non-compute resources for the instance, the instance's allocation can change not from nova right?17:17
efriedbut if dansmith likes the idea of extending it with allocations_for_instance, which we can cache in the manager, I'm down with that idea.17:18
dansmithaspiers: no, we cache inventory AFAIK, but not allocations at the moment17:18
sean-k-mooneydansmith: im notsure about that17:18
sean-k-mooneyare you thinking baout things like changing the bandwith allcoation via neutron17:18
sean-k-mooneye.g. by changing the qos policy17:18
efriedaspiers: The inventory (basically all the provider tree information for all the hosts managed by this compute) is cached in the SchedulerReportClient today. But yeah, not the allocations.17:19
sean-k-mooneyi guess that could happen in the future17:19
*** spsurya has quit IRC17:19
dansmithsean-k-mooney: I'm thinking of allocating things like a new volume, or even ephemeral things like networked secure enclave keys or something17:19
sean-k-mooneydansmith: well a new volume would be a volume attach right17:20
efriedas long as those ^ things happen in nova, we're good, but yeah, if they happen outside of nova, weirdness.17:20
dansmithsean-k-mooney: it also means our rpc messages and database footprint scales with whatever else we add into the allocation in the future17:20
efriedI think we have other problems to solve ("heal allocations"??) if we start allowing outside entities to modify instance allocations17:20
dansmithsean-k-mooney: not always in the case of manilla or similar higher level services17:20
sean-k-mooneythat is true altheough we have a 64k userdata blob in there already17:21
efriedI'm happy with the virtapi solution personally.17:21
efriedI don't even think we need to bother caching it, at least initially.17:21
sean-k-mooneyfor mania the filesystem is not own by the instnace17:21
efriedSince it's on demand and should be a pretty rare ask.17:21
sean-k-mooneythe instace can have acess too it but its not tied to the lifetime of the instnace17:21
*** mdbooth_ has quit IRC17:22
sean-k-mooneyefried: i do kindof dislike the idea that if placement goes offline you cant reboot an instnace17:22
dansmithsean-k-mooney: okay, you understand I'm talking about high-level services that sit on top of infra that would have per-instance allocations right?17:22
sean-k-mooneydansmith: yes17:22
sean-k-mooneyand i get that it could be extendted that way in the future17:23
sean-k-mooneywithout storing the allcoation somewhere in nova then placment becmoes a singel point of failture for starting or stroping vms if they use sev or vgpus17:24
dansmithI definitely don't like that we'd depend on placement to reboot an instance or do other things, but I'd rather us not depend on the placement *data* in that case,17:25
dansmithand not just solve it by replicating everything everywhere17:25
efriedyeah, when I found out we rebuild the domxml every time we reboot I was like whaaa?17:26
sean-k-mooneywell that makes sense in some ways17:26
efriedit must17:26
efriedin some ways17:26
sean-k-mooneythat is not really the root cause of the dependcy in the vgpu case17:26
dansmithis this all coming up because we've already translated a request into a "will have SEV" and the only way we can think to know that later is persist the whole allocation?17:26
efrieddansmith: more or less17:26
sean-k-mooneyno17:26
efriedheh17:26
efriedanti-jinx17:26
sean-k-mooneywe can look at the request spec17:26
dansmithefried: well, that's a bad reason to do that, IMHO17:27
*** eharney has quit IRC17:27
efrieddansmith: It's not "the only way we can think to know that later"17:27
sean-k-mooneyand use the request for sev17:27
efriedwe could reinvoke the logic we used to decide the first time17:27
dansmithefried: point being, let's store what we need about that decision and not just couple the guts of the virt driver into the placement data17:27
efriedby looking at the flavor & image - which we have access to via the Instance obj, right?17:27
sean-k-mooneyya we can compute it form the info in the request spec which these fucntion already have acess too17:27
dansmithbecause the other thing is, allocations are somewhat tied to a microversion in placement, and while it seems hard to imagine the core structure changing, we've changed a lot of the external data structures of placement since we started17:28
sean-k-mooneyso once the comment is address i personally would have check the requestd_resouces object in the request spec https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L93-L10017:29
*** eharney has joined #openstack-nova17:29
sean-k-mooneybut we also have acess to the image and flavor via the instance yes17:30
dansmithefried: re: [10:27:05]  <efried>dansmith: It's not "the only way we can think to know that later"17:31
dansmithefried: I know not the only way, but "the way", collapsed to "only" for dramatic effect17:31
*** markvoelker has joined #openstack-nova17:33
sean-k-mooneyso the instance is already passed to all the places we need to check if the instace requested sev17:36
sean-k-mooneyso why dont we jsut hav ea single function that takes the instance object and determins if sev is needed and reuse that everywhere we care.17:37
sean-k-mooneythat could live in nova.virt.hardware.yp with the numa stuff?17:38
openstackgerritArtom Lifshitz proposed openstack/nova master: Revert resize: wait for events according to hybrid plug  https://review.opendev.org/64488117:38
openstackgerritArtom Lifshitz proposed openstack/nova master: WIP: Include direct-physical in compute manager events check  https://review.opendev.org/66443117:38
openstackgerritArtom Lifshitz proposed openstack/nova master: [DNM] testing bug/1813789 revert resize events  https://review.opendev.org/66444217:38
sean-k-mooneylike is_realtime_enabled https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1436-L143817:40
openstackgerritEric Fried proposed openstack/nova master: WIP: ComputeVirtAPI.allocations_for_instance  https://review.opendev.org/66498617:40
efriedaspiers: for grins, you can try this out ^17:40
efrieddansmith: this what you had in mind?17:40
dansmithefried: mostly17:41
efriedI explained why no caching in the commit message17:41
sean-k-mooneyefried: but is there any reason to have to check the allotion the athoritive info is stored in the image/flavor not the allcoation17:41
efriedsean-k-mooney: just to not have to duplicate that logic.17:42
efriedbut in this case, no, not really.17:42
sean-k-mooneyan api call is a lot more expensive17:42
dansmithis a single call to that less expensive than calling the placement?17:42
efriedAccessing the flavor/image meta from Instance is cheap17:42
efrieddansmith: assuming we already have the flavor & image available in the Instance object, it's all local, yeah.17:42
efriedwell17:43
efriedsome of it involves pawing at sysfs17:43
sean-k-mooneywe do17:43
dansmithit better not,17:43
dansmithbecause the api nodes' sysfs wouldn't be the same as compute17:43
sean-k-mooneywe dont need to look at sysfs for schduling17:43
efriedright, the compute pawed at sysfs to expose the inventory, so by virtue of having the MEM_ENC_CTX inventory at all, we know we did the sysfs stuff already.17:44
*** ricolin_ has quit IRC17:44
sean-k-mooneywe may or may not for xml generation17:44
dansmithefried: ack, I see17:44
efriedbut how would I know that on the compute without looking at placement? :P17:44
sean-k-mooneyefried: know what?17:44
efriedknow that I can SEV17:45
sean-k-mooneybecause its asked for in teh flavor/image17:45
efriedno17:45
sean-k-mooneyif we got to the compute node we know we were allocated everything we asked for17:45
efriedwell, yes, okay17:45
*** ociuhandu has quit IRC17:45
efriedthat's kind of a lot of assuming.17:45
efriedincluding assuming nothing changed on the host that makes it no longer work17:46
efriedbut that's reasonable.17:46
sean-k-mooneyassuming that if placment could not fulfil a request it returned no allcoation candates?17:46
sean-k-mooneythat kind of fundemental no?17:46
*** Sundar has quit IRC17:46
dansmithdefinitely don't think that being sent an instance with sev required is good enough to assume we have it17:46
dansmithbecause we don't know what the scheduler policy is17:46
dansmithor if that node is old17:46
efriedor got force migrated?17:46
*** tssurya has quit IRC17:46
dansmithor if the request has been sitting in a rabbit queue across config changes17:46
sean-k-mooneywell the virt direver is going to check compatiblity17:47
sean-k-mooneyright17:47
efriedso then yeah, in order to truly fulfill "can and should do SEV" I would need to check the flavor/image *and* sysfs, every time.17:47
efriedwhich is still going to be cheaper than calling placement across the wire17:47
sean-k-mooneywell libvirt capablitys api17:47
sean-k-mooneyrather then sysfs but same effect17:48
efriedyeah, using "sysfs" to encompass "introspecting the host in whatever way is necessary"17:48
efriedwhich should be all "local" one way or another.17:48
efried"local" to the system; not necessarily local to whatever's in process memory already, which would be even better.17:49
sean-k-mooneyso back to https://review.opendev.org/#/c/664420/4/nova/scheduler/request_filter.py17:51
sean-k-mooneyif we just move thos three funtion into nova/virt/hardware.py wiht all the cpu pinning and numa stuff and just call17:52
dansmithartom: I think maybe too much got removed, but see my comments and hopefully prove me wrong17:52
artomdansmith, looking17:53
sean-k-mooneyrequired_encryped_memory support in both the dirver and filter that shoudl be fine right17:53
efriedsean-k-mooney: that and the sysfs pawing part, yes. Not sure if hardware.py is the right place17:53
sean-k-mooneyi think this is similarly to hugepages,realtime,cpupinning and numa17:54
sean-k-mooneyall of which are in the hardware.py module17:54
efrieddoes hardware.py also do the flavor interpretation bits associated with that?17:54
*** owalsh has quit IRC17:54
sean-k-mooneyefried: yes17:54
efriedI kind of object to hardware.py not being nova/virt/libvirt/hardware.py17:55
*** owalsh has joined #openstack-nova17:55
efriedbut that soapbox is gathering dust in my closet at this point.17:55
sean-k-mooneyits used in other driver too17:55
sean-k-mooneyits used in the hyperv driver17:55
sean-k-mooneyand its used in the api17:55
sean-k-mooneyand the scheduler17:55
* efried drops it like a bad habit17:55
aspiersI can never drop bad habits :-(17:55
sean-k-mooneythe trick is to replace them with other sligly less bad habits17:56
aspierstrue17:56
sean-k-mooneyanyway it could go somewhere else17:57
artomAgile self-improvement ;)17:57
efriedaspiers: not sure if you've been following along, but I think the consensus is to centralize the methods that do a) flavor/image parsing/validation, and b) host capability introspection; and call those from all the places (update_provider_tree calls b to expose inventory; request filter calls a to add to the request; virt driver lifecycle ops call a & b to decide whether SEV-y things should be done or not)17:58
aspiersOK17:59
efriedbut if you want to just play around, I made this for you: https://review.opendev.org/66498617:59
efried...for lifecycle ops to use to look for MEM_ENC_CTX in the alloc to bypass at least a).18:00
* aspiers reads and thinks18:00
mriedemumm, i just got back18:02
mriedemnot going to read all of the scrollback18:02
mriedemwithout knowing more, i'd say i don't want to replicate allocation data per instance in nova18:03
mriedemsource of truth is the external service and all that18:03
sean-k-mooneymriedem: the context was how to determin if sev is need. efried summerised where we landed a few lines up18:05
*** markvoelker has quit IRC18:06
mriedemisn't sev a required trait on the flavor?18:07
sean-k-mooneyits a resouce class in the flavor18:07
mriedemif so, that is already information stored on the instance18:07
mriedemok either way18:07
efried"stored on the instance" you mean via the flavor (and/or image in this case)?18:07
sean-k-mooneyyes efried didnt want to duplicate the logic between the filter an the virt driver18:07
mriedemnot the image18:07
mriedemif it's a resource class it's not on the image18:07
mriedembut yes if it's on the flavor it's embedded on the instance18:08
efriedThe flavor doesn't use a resource class directly18:08
mriedeminstance.flavor.extra_spec18:08
mriedemit's an extra spec18:08
mriedemright?18:08
efriedIn this case we decide whether to SEV based on flavor extra spec *or* image meta prop18:08
mriedemresources:SEV=118:08
mriedemwhat image meta prop?18:08
mriedemi thought the image only had traits?18:08
efriedno, no explicit placement-ese in flavor or image18:08
efriedhw:memory_encryption=true <= flavor18:08
efriedhw_memory_encryption=true <= img18:08
mriedemi have been deliberately ignoring / avoiding the sev talk going on in here for the last several months so idk wtf we are now18:08
efried(I may have spelled it wrong, but that's the idea)18:09
efriedrequest filter interprets those into placement-ese18:09
mriedemas a trait? or a resource class?18:09
mriedemor both?18:09
openstackgerritEric Fried proposed openstack/nova master: Raise if flavor and image disagree on hide_hypervisor_id  https://review.opendev.org/66336518:09
efrieda resource class18:09
mriedemwith what amount? 118:09
efriedrequired=MEM_ENCRYPTION_CONTEXT:118:09
mriedem?18:09
sean-k-mooneyyes18:09
efriedwe got here because there's a limited number of SEVs you can do on a host18:10
efriedand18:10
mriedemgimme all the sevs18:10
* aspiers has caught up with the scrollback... sort of18:10
efriedwe want the solution to be generic for memory encryption technologies, so e.g. MKTME can play in this space.18:10
mriedemis mktme that band from the 90s?18:10
mriedemwith the cool album covers?18:10
efriedyes18:10
aspiers:)18:10
aspierswhereas SEV is just terrible Euro-pop18:11
mriedemlet me guess, mktme is intel something18:11
aspiersyes, Intel multi-key total memory encryption18:11
edleafewhich sed18:12
edleafedoh!18:12
sean-k-mooneyhehe this is one of the intel acronym that i dont auto expand when i see it18:12
efriedor Right SEV Fred, who's too sexy for his RAM18:13
aspiersOK so are we still here? -> <efried> aspiers: not sure if you've been following along, but I think the consensus is to centralize the methods that do a) flavor/image parsing/validation, and b) host capability introspection; and call those from all the places (update_provider_tree calls b to expose inventory; request filter calls a to add to the request; virt driver lifecycle ops call a & b to decide18:14
aspierswhether SEV-y things should be done or not)18:14
efriedunless mriedem has a different opinion on the other options discussed.18:15
efriedhe already -1'd allocations-on-Instance18:15
efriedbut has not weighed in on virtapi.allocations_for_instance18:15
efriedbut jumped right to "go look at the flavor"18:15
efriedso that seems like the path18:16
aspiersWhat about https://review.opendev.org/#/c/664420/4/nova/scheduler/request_filter.py@22318:16
sean-k-mooneyi would emulate this https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L25918:16
aspiersalex_xu seems to have a reasonable point there18:16
sean-k-mooneyor maybe this is a little less scary https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L17118:16
efriedaspiers, alex_xu: How is this different from what's happening in require_tenant_aggregate ?18:17
aspierssean-k-mooney: BTW you know that we have gitea running on opendev now :)18:17
sean-k-mooneyaspiers: i do and the last time i used it it nova almost crashed it18:17
efriedaspiers: Commenting on the review18:17
aspierssean-k-mooney: interesting, gitea seems a lot more lightweight on my browser than github18:17
aspiersefried: thanks18:18
sean-k-mooneythat was because they messed up a tempelate which is now fixed but still18:18
*** BjoernT has quit IRC18:18
aspiersefried: right, I copied the raise RequestFilterFailed() from that18:18
sean-k-mooneyanyway im feeling really tired today so im going to go lie down. o/ talk to people tomorow18:19
aspierssean-k-mooney: so what exception should I throw if the SEV extra spec and image property conflict with each other?18:19
sean-k-mooneyam18:19
sean-k-mooneyit depend on where you are thowing it18:20
aspierswell, you are suggesting to put it in hardware.py?18:20
sean-k-mooneyalex asked you to add some validation in the api as well18:20
aspiersIIUC18:20
*** udesale has quit IRC18:20
aspiersit needs to be in a shared library, right?18:20
*** boxiang_ has quit IRC18:20
*** boxiang_ has joined #openstack-nova18:20
sean-k-mooneyya so nova.virt.hardware.py is called everywhere18:20
aspiersso that it can be called from the request_filter, from the driver, and maybe also from the api18:20
sean-k-mooneyits in the virt dirver schduler and api already18:21
aspiersI'm talking about the exception currently at https://review.opendev.org/#/c/664420/4/nova/scheduler/request_filter.py@22318:21
aspiersif I move it to a shared library, the exception needs to be more generic18:21
aspiersInvalidRequest?18:22
sean-k-mooneywe have generally beein add new excpetion as needed for each check18:22
aspiersOK18:22
sean-k-mooneylike this18:22
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1192-L119818:22
aspiersthat sounds fine to me18:23
aspiersI can add one to exceptions.py18:23
aspiersI mean exception.py18:23
aspiersefried: does that work for you?18:23
openstackgerritEric Fried proposed openstack/nova master: update constraints url  https://review.opendev.org/66477118:23
dansmithefried: fwiw, my unmattering vote would be for just checking image+flavor for the sev thing and not doing the virtapi bit until we come up with a good reason18:24
dansmiththis being, not a good enough reason18:24
dansmithin the future, when said reason exists, that's how we do it, IMHO18:24
efrieddansmith: ack, that's where we're going18:24
efriedthanks for the input sir18:25
dansmithcool18:25
aspierswfm18:25
efriedaspiers: Yes, the centralized method in hardware.py should raise some kind of generic conflict exception, which should be caught and converted to RequestFilterFailed (or whatever it's called today) in the request filter.18:25
*** boxiang_ has quit IRC18:25
aspiersefried: sean-k-mooney suggested making a new exception. ACK about the conversion to RFF18:26
*** boxiang_ has joined #openstack-nova18:26
efried(by "generic" I mean not request filter specific; it should still have the lovely and hard-fought message you've already composed)18:26
aspiersoh right, gotcha18:26
sean-k-mooneyaspiers: right just copy this one and change the wording https://github.com/openstack/nova/blob/master/nova/exception.py#L205418:26
efriedaspiers: you could use this: https://review.opendev.org/#/c/663365/2/nova/exception.py18:26
sean-k-mooneyefried: oh ya you were adding a reusable one18:27
sean-k-mooneyefried: that works too18:27
aspiersoh perfect18:27
aspiersWell, I might inherit from that one :)18:27
aspierssince my message is more informative18:27
aspiersclass SEVFlavorImageConflict(FlavorImageConflict)18:28
efriedyou should introduce the exception (class name) in your own patch, cause there's no telling if/when ^ will merge18:28
efriedand whoever comes second can resolve conflict.18:28
sean-k-mooneyaspiers: non of the other conflcit ones inherit for efried new excetion at teh moment18:28
efriedbut yeah, make the exception name generic, and you can override the message in your method.18:28
sean-k-mooneythey inherit for Invalid or Forbidden18:29
aspiersand NotFound18:29
efriedThose have HTTP semantic baggage, swhy I avoided them.18:29
sean-k-mooneyForbidden when its disallows by policy and Invalid when the did not specify it correctly18:29
sean-k-mooneye.g mem_encyption_context=yes instead or true18:30
aspiersefried: why introduce the same new exception in two patches? can't we just land yours sooner?18:30
aspiersis it because you can +2 my patches but not your own? ;-)18:30
efriedYour API invocation of new centralized message should convert generic exception to something that inherits from Invalid18:30
efriedaspiers: I can't +2 my patches, no, and also, there doesn't seem to be an overwhelming consensus that that patch of mine is a good thing to do at all.18:31
aspiersefried: even if it's needed for SEV?18:31
efriedso I don't have high confidence that it will land soon/ever.18:31
efriedit's not18:31
efriedonly the exception is18:31
aspiersI'm confused18:31
efriedso it should be extracted.18:31
aspiersohhhhh18:31
sean-k-mooneyefried: i think i found a bug in our vgpu code today that might use your patch18:31
aspiersI missed that that patch does other stuff18:31
aspiersOK18:31
sean-k-mooneye.g. without looking too close i think we dont handel stop followed by start proerly18:32
efriedyeah, the patch I pointed to has nothing to do with SEV. It has to do with "hide hypervisor ID to make NVIDIA drivers work18:32
efried"18:32
aspiersyeah, got it now18:32
aspiersyikes, feels like I need another 40k spec just to remember all the plans we made in the last hour18:32
efriedYou don't need to update the spec with any of this.18:32
aspiersthank god for IRC logs18:32
aspiersI know, was just being silly :)18:33
aspiersit's a lot of detail for a newbie to remember, but I think I'll be ok18:33
sean-k-mooneyanyway this time im really going to go and rest. o/18:33
aspiersI guess my right to play the newbie card is gradually fading though18:33
aspierscya sean-k-mooney, thanks for your help o/18:33
efried- create two consolidated methods in hardware.py: a) parse/validate flavor/image for SEV yes-or-no; b) introspect host for SEV capability18:33
efried- ^ methods raise exceptions18:33
efried- existing usages of ^ logic cut over to using ^, converting exceptions to contextually-appropriate ones.18:33
aspiersI think b) and callers of b) do not need to change18:34
aspiersit's only a)18:34
*** maciejjozefczyk has joined #openstack-nova18:34
efriedight18:34
aspiersb) is all in the driver18:34
aspiersand available via the supports_amd_sev instance variable18:35
efried"instance" == compute driver instance, not "instance" == "nova server"18:35
aspierssure :)18:35
aspiersand then there's Instance instances too :)18:36
aspiersOK, gonna take a break or probably stop for today18:36
aspiersthanks a lot all18:36
efrieddustinc: Not rechecking the ironicclient part of the sdk series for yesterday's doubled_words snafu - pep8 needs resolving on the lowermost one.18:37
dustincefried: saw that, once I am done with the spec update I am working on I will take care of it - thanks18:39
efrieddustinc: no hurry, just letting you know why it's not going to be included in my "recheck everything" sweep :P18:40
efrieddustinc: also lmk if at some point you want to talk through providers.yaml18:40
dustincefried: providers.yaml: will do..I def. want to at some point18:42
*** igordc has quit IRC18:43
*** BjoernT has joined #openstack-nova18:45
*** BjoernT_ has joined #openstack-nova18:50
*** BjoernT has quit IRC18:53
*** tesseract has quit IRC18:54
*** eharney has quit IRC18:57
*** markvoelker has joined #openstack-nova19:03
openstackgerritEric Fried proposed openstack/nova master: Make RequestContext(instance_lock_checked) fail  https://review.opendev.org/66500319:10
efriedmriedem: resolves a TODO of yours ^19:10
openstackgerritMerged openstack/nova master: Remove unnecessary setUp methods  https://review.opendev.org/66317919:11
mriedemefried: does it or does it not have to do with SEV19:12
efrieddoes not19:13
efriedI was looking into removing a hack for glance using get_endpoint_data through _ContextAuthPlugin (fail) and just happened to notice this.19:14
efriedmriedem: what was that bug you opened for the doubled_words hacking test yesterday? Did you mark it as a dup of https://bugs.launchpad.net/nova/+bug/1804062 already?19:14
openstackLaunchpad bug 1804062 in OpenStack Compute (nova) "test_hacking fails for python 3.6.7 and newer" [High,In progress] - Assigned to Stephen Finucane (stephenfinucane)19:14
*** maciejjozefczyk has quit IRC19:14
mriedemyes19:15
mriedemhttps://bugs.launchpad.net/nova/+bug/183239219:15
openstackLaunchpad bug 1804062 in OpenStack Compute (nova) "duplicate for #1832392 test_hacking fails for python 3.6.7 and newer" [High,In progress] - Assigned to Stephen Finucane (stephenfinucane)19:15
mriedemefried: question in your patch19:15
melwittefried: after the discussion about nested magic 1 in office hours today, how are you feeling about the it vs the nova spec for numa affinity for vgpus?19:16
*** factor has quit IRC19:16
openstackgerritEric Fried proposed openstack/nova master: Make RequestContext(instance_lock_checked) fail  https://review.opendev.org/66500319:17
efriedmriedem:  done19:17
melwittI wasn't sure if I understood whether nested magic 1 will take much more effort than previously believed19:18
efriedmelwitt: Components of it - specifically the ones that allow us to do NUMA modeling/affinity for simple cases like VGPU - are not under conflict. I still think the VGPU numa affinity thing doesn't move us forward in a useful way, and just introduces tech debt we'll have to remove very soon.19:19
efriedbut I don't feel strongly enough to downvote.19:19
openstackgerritArtom Lifshitz proposed openstack/nova master: Revert resize: wait for events according to hybrid plug  https://review.opendev.org/64488119:20
openstackgerritArtom Lifshitz proposed openstack/nova master: WIP: Include direct-physical in compute manager events check  https://review.opendev.org/66443119:20
openstackgerritArtom Lifshitz proposed openstack/nova master: [DNM] testing bug/1813789 revert resize events  https://review.opendev.org/66444219:20
* efried bbiab19:20
melwittefried: ack. and do you know if there are people available to work on nested magic 1 or does it need an owner?19:21
melwittfor the implementation after the spec merges19:21
dansmithartom: ooh, did somebody find a bug while writing their tests? :)19:23
artomdansmith, I don't think so?19:23
artomBut parts of the code were untested, yeah19:23
dansmithartom: okay, just looking at your events=None change in the latest patch19:23
artomOh, err, yeah19:24
artomThat may have been a problem :/19:24
dansmithsweet19:24
dansmithnow I feel less bad19:24
*** xek_ has joined #openstack-nova19:24
*** maciejjozefczyk has joined #openstack-nova19:25
artomdansmith, so not only am I making Nova better, I'm also contributing to your mental health19:27
artomCome to think of it, maybe the latter isn't an advantage >;)19:27
* dansmith queues that up for his next therapy session19:27
*** maciejjozefczyk_ has joined #openstack-nova19:30
*** maciejjozefczyk has quit IRC19:31
*** maciejjozefczyk has joined #openstack-nova19:36
*** maciejjozefczyk_ has quit IRC19:37
*** markvoelker has quit IRC19:37
*** jenglisch has quit IRC19:39
*** eharney has joined #openstack-nova19:41
*** jenglisch has joined #openstack-nova19:43
*** slaweq has joined #openstack-nova19:48
*** ralonsoh has quit IRC19:50
*** hoonetorg has quit IRC19:51
*** maciejjozefczyk_ has joined #openstack-nova19:54
*** whoami-rajat has quit IRC19:55
*** maciejjozefczyk has quit IRC19:57
*** maciejjozefczyk_ has quit IRC19:59
*** hoonetorg has joined #openstack-nova20:03
*** factor has joined #openstack-nova20:08
*** factor has quit IRC20:21
*** cdent has joined #openstack-nova20:32
*** slaweq has quit IRC20:33
*** xek_ has quit IRC20:34
*** markvoelker has joined #openstack-nova20:34
*** cdent has quit IRC20:37
*** slaweq has joined #openstack-nova20:38
mriedemdansmith: for when you're on the can http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007097.html20:39
*** slaweq has quit IRC20:43
openstackgerritArtom Lifshitz proposed openstack/nova master: [WIP] Introduce live_migration_claim()  https://review.opendev.org/63566920:49
openstackgerritArtom Lifshitz proposed openstack/nova master: New objects for NUMA live migration  https://review.opendev.org/63482720:49
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source  https://review.opendev.org/63482820:49
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source  https://review.opendev.org/63522920:49
openstackgerritArtom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration  https://review.opendev.org/63460520:49
openstackgerritArtom Lifshitz proposed openstack/nova master: NUMA live migration support  https://review.opendev.org/63460620:50
openstackgerritArtom Lifshitz proposed openstack/nova master: CONF.enable_numa_live_migration is not needed >= Stein  https://review.opendev.org/64002120:50
efriedmelwitt: cdent has been picking up most of it one way or another. More bodies would be nice, but probably not critical.20:50
efriedmelwitt: and we've not been sticking to "spec must merge first" rules. We've already cut a microversion with part of the feature set.20:51
melwittoh, interesting. ok20:51
efriedyeah, it's the wild wild west over here in placement-land20:52
melwittheh20:55
melwittwell, if there's anything I can do to help, give me a holler20:55
*** artom has quit IRC20:59
efriedmelwitt: oo, now you're in for it :P21:02
melwitt:)21:03
*** markvoelker has quit IRC21:08
*** ivve has quit IRC21:11
*** pcaruana|afk| has quit IRC21:16
openstackgerritMatt Riedemann proposed openstack/nova master: Add Migration.cross_cell_move and get_by_uuid  https://review.opendev.org/61401221:23
openstackgerritMatt Riedemann proposed openstack/nova master: Add InstanceAction/Event create() method  https://review.opendev.org/61403621:23
openstackgerritMatt Riedemann proposed openstack/nova master: Add Instance.hidden field  https://review.opendev.org/63112321:23
openstackgerritMatt Riedemann proposed openstack/nova master: Add TargetDBSetupTask  https://review.opendev.org/62789221:23
openstackgerritMatt Riedemann proposed openstack/nova master: Add CrossCellMigrationTask  https://review.opendev.org/63158121:23
openstackgerritMatt Riedemann proposed openstack/nova master: Execute TargetDBSetupTask  https://review.opendev.org/63385321:23
openstackgerritMatt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_dest compute method  https://review.opendev.org/63329321:23
openstackgerritMatt Riedemann proposed openstack/nova master: Add PrepResizeAtDestTask  https://review.opendev.org/62789021:23
openstackgerritMatt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_source compute method  https://review.opendev.org/63483221:23
openstackgerritMatt Riedemann proposed openstack/nova master: Add nova.compute.utils.delete_image  https://review.opendev.org/63760521:23
openstackgerritMatt Riedemann proposed openstack/nova master: Add PrepResizeAtSourceTask  https://review.opendev.org/62789121:23
*** mriedem has quit IRC21:24
*** luksky has quit IRC21:25
efrieddansmith: Thanks for the review on the providers.yaml spec. I agree with you (mark your calendar).21:38
*** takashin has joined #openstack-nova21:46
*** markvoelker has joined #openstack-nova22:05
*** spatel has quit IRC22:10
*** mlavalle has quit IRC22:14
*** markvoelker has quit IRC22:38
*** elod has quit IRC22:41
*** rcernin has joined #openstack-nova22:41
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13)  https://review.opendev.org/57602022:54
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14)  https://review.opendev.org/57602722:54
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15)  https://review.opendev.org/57603122:54
*** tkajinam has joined #openstack-nova22:56
*** lifeless has quit IRC23:05
openstackgerritMerged openstack/nova stable/rocky: Fix live-migration when glance image deleted  https://review.opendev.org/66215323:10
openstackgerritMerged openstack/nova master: Refresh instance network info on deletion  https://review.opendev.org/66076123:21
openstackgerritsean mooney proposed openstack/os-vif master: set ignore_basepython_conflict = True in tox.ini  https://review.opendev.org/66503423:22
*** markvoelker has joined #openstack-nova23:35
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16)  https://review.opendev.org/57629923:36
openstackgerritsean mooney proposed openstack/nova master: update comment on ignore_basepython_conflict  https://review.opendev.org/66503623:37
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17)  https://review.opendev.org/57634423:37
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18)  https://review.opendev.org/57667323:37
*** JamesBenson has quit IRC23:37
openstackgerritMerged openstack/nova master: Fix double word hacking test  https://review.opendev.org/66494023:42
*** elod has joined #openstack-nova23:42
openstackgerritsean mooney proposed openstack/os-vif master: set ignore_basepython_conflict = True in tox.ini  https://review.opendev.org/66503423:43
openstackgerritsean mooney proposed openstack/nova master: libvirt: delegate ovs plug to os-vif  https://review.opendev.org/60243223:53

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