Wednesday, 2019-02-27

*** sdake has quit IRC00:00
*** liuyulong has quit IRC00:02
*** sdake has joined #openstack-nova00:02
*** tosky has quit IRC00:02
*** sdake has quit IRC00:05
*** markvoelker has joined #openstack-nova00:06
*** sdake has joined #openstack-nova00:06
*** alex_xu has joined #openstack-nova00:08
*** igordc has quit IRC00:09
*** sdake has quit IRC00:10
melwittsigh... BuildRequest doesn't have a user_id field. only a project_id field. so, neeeeevermind00:12
openstackgerritBrin Zhang proposed openstack/nova master: Remove the string check of the flavor attribute 'swap'  https://review.openstack.org/63901200:12
*** mriedem has quit IRC00:15
*** mriedem has joined #openstack-nova00:17
sean-k-mooneymelwitt: if you wanted to optimise the data migration slightly you coudl do it in 2 phases00:17
*** brinzhang has joined #openstack-nova00:17
*** edmondsw has quit IRC00:17
sean-k-mooneymelwitt: first add the user ids form all instace that have a user id in there request spec00:18
sean-k-mooneythen call done to the cell and grab it out of the instance table for the remainder00:18
melwittyeah. that might be a good idea00:19
sean-k-mooneyyou may not be able to rely on it being present in the request spec but you can conditionally use it to minimise the down calls00:19
melwittfor this, it was about whether we can make the InstanceMapping.user_id field non-nullable. and I think because of the aforementioned things, we can't00:19
melwittno user_id on BuildRequest, and user_id not guaranteed to be set on RequestSpec00:19
mriedemyonglihe: i replied in https://review.openstack.org/#/c/621474/ and i'm ok with the server_groups as a list since that seems to be the consensus00:19
sean-k-mooneymelwitt: if this change lands in stien you could make it non nullable in train00:20
sean-k-mooneythe only donwside to that would be for FFU you would have to run the online migration. although i assume this could be done as an offline migration too00:21
melwittsean-k-mooney: yeah. I don't understand whether it needs to be a major object version bump or not, but I can ask about that next cycle. because it would be good to make it non-nullable whenever we can00:21
melwittyes, offline (nova-manage) migration is the one that does the cell database reads00:22
melwittwe're going to have a blocker migration in T also, to ensure all migrated, and then be able to remove transitionary online/active migration code00:23
sean-k-mooneyok if its an offline data migration that is executed centrally on the controller that is not too much of a headache for ffu00:23
melwittright00:23
sean-k-mooneythanks for +1'ing the os-vif releae patch by the way.00:24
sean-k-mooneyhopefully it will get merged soon but ill follow up tomorrow if not00:25
*** agopi has joined #openstack-nova00:25
sean-k-mooneynight o/00:25
melwittnp, gnight00:29
*** mlavalle has quit IRC00:29
*** sdake has joined #openstack-nova00:32
*** erlon has joined #openstack-nova00:34
*** markvoelker has quit IRC00:40
*** wolverineav has quit IRC00:42
*** macza has quit IRC00:43
*** _hemna has joined #openstack-nova00:44
openstackgerritMatt Riedemann proposed openstack/python-novaclient master: Fix changes-before values in an instance action test  https://review.openstack.org/63884900:44
openstackgerritAdam Spiers proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits  https://review.openstack.org/53849800:46
*** mriedem has quit IRC00:47
*** awalende has joined #openstack-nova00:47
*** tetsuro has joined #openstack-nova00:51
*** awalende has quit IRC00:52
*** Sundar has joined #openstack-nova00:52
*** tetsuro has quit IRC00:53
*** tetsuro has joined #openstack-nova00:56
*** sdake has quit IRC00:59
*** lbragstad has quit IRC00:59
*** takashin has joined #openstack-nova01:01
openstackgerritArtom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration  https://review.openstack.org/63460501:01
openstackgerritArtom Lifshitz proposed openstack/nova master: Make the use of the CastAsCall fixture configurable  https://review.openstack.org/63942801:01
openstackgerritArtom Lifshitz proposed openstack/nova master: [WIP needs more tests] Full NUMA live migration support  https://review.openstack.org/63460601:01
*** Swami has quit IRC01:08
jaypipesmelwitt: hmm, how user_id isn't guaranteed on request spec or build request is very odd to me...01:08
jaypipesone would think both of those would by their very nature have a user associated with them. :)01:08
melwittjaypipes: build request doesn't even have a user_id field (wah wah). but request spec waits until conductor to set project_id and user_id01:09
melwittand yeah, I agree. I think it's because user_id wasn't "required" when they were first added as tables01:10
melwittthere's definitely a user associated with them. just not recorded so well01:10
*** _fragatina has quit IRC01:14
*** itlinux has joined #openstack-nova01:16
openstackgerritGhanshyam Mann proposed openstack/nova stable/queens: DNM: For testing multinode and tempest-slow job  https://review.openstack.org/62399201:21
*** igordc has joined #openstack-nova01:26
*** slaweq has joined #openstack-nova01:26
*** slaweq has quit IRC01:31
*** sdake has joined #openstack-nova01:35
*** _fragatina has joined #openstack-nova01:35
*** itlinux has quit IRC01:36
*** markvoelker has joined #openstack-nova01:37
*** takamatsu_ has quit IRC01:39
*** edmondsw has joined #openstack-nova01:42
*** erlon has quit IRC01:45
*** takamatsu_ has joined #openstack-nova01:45
openstackgerritMerged openstack/nova master: Mention SR-IOV cold migration limitation in admin docs  https://review.openstack.org/60390901:47
yonglihemriedem, got that, working on it now, thanks.01:51
*** lbragstad has joined #openstack-nova01:58
*** whoami-rajat has joined #openstack-nova02:01
openstackgerritmelanie witt proposed openstack/nova master: Add online data migration for populating user_id  https://review.openstack.org/63335102:03
openstackgerritmelanie witt proposed openstack/nova master: Add get_counts() to InstanceMappingList  https://review.openstack.org/63807202:03
openstackgerritmelanie witt proposed openstack/nova master: WIP Count instances from mappings and cores/ram from placement  https://review.openstack.org/63807302:03
openstackgerritmelanie witt proposed openstack/nova master: Use instance mappings to count server group members  https://review.openstack.org/63832402:03
*** tetsuro has quit IRC02:05
*** sdake has quit IRC02:09
*** markvoelker has quit IRC02:10
*** sdake has joined #openstack-nova02:10
*** sdake has quit IRC02:13
*** gyee has quit IRC02:15
*** sdake has joined #openstack-nova02:15
*** sdake has quit IRC02:16
*** tetsuro has joined #openstack-nova02:18
*** _hemna has quit IRC02:18
*** tetsuro has quit IRC02:24
*** _hemna has joined #openstack-nova02:30
*** Dinesh_Bhor has joined #openstack-nova02:30
*** rcernin has quit IRC02:32
*** _hemna has quit IRC02:34
*** tetsuro has joined #openstack-nova02:35
*** hongbin has joined #openstack-nova02:38
*** igordc has quit IRC02:40
*** igordc has joined #openstack-nova02:40
*** tetsuro has quit IRC02:40
*** sdake has joined #openstack-nova02:41
*** hongbin has quit IRC02:43
*** sdake has quit IRC02:45
*** _fragatina has quit IRC02:45
*** sdake has joined #openstack-nova02:47
*** tetsuro has joined #openstack-nova02:47
*** takamatsu_ has quit IRC02:53
*** sdake has quit IRC02:55
*** sdake has joined #openstack-nova02:56
*** sdake has quit IRC03:01
*** psachin has joined #openstack-nova03:01
*** sdake_ has joined #openstack-nova03:01
*** tetsuro has quit IRC03:02
*** markvoelker has joined #openstack-nova03:04
*** tetsuro has joined #openstack-nova03:08
*** _hemna has joined #openstack-nova03:09
*** sdake_ has quit IRC03:10
*** sdake has joined #openstack-nova03:12
*** sdake has quit IRC03:15
*** tetsuro has quit IRC03:15
*** sdake has joined #openstack-nova03:16
*** wolverineav has joined #openstack-nova03:18
*** sdake has quit IRC03:23
*** sdake_ has joined #openstack-nova03:23
*** sdake_ has quit IRC03:25
*** sdake has joined #openstack-nova03:26
*** tetsuro has joined #openstack-nova03:30
*** sdake has quit IRC03:30
*** sdake has joined #openstack-nova03:31
*** itlinux has joined #openstack-nova03:31
*** sdake has quit IRC03:35
*** sdake has joined #openstack-nova03:36
*** _hemna has quit IRC03:40
*** sdake_ has joined #openstack-nova03:44
*** sdake has quit IRC03:44
*** diga has joined #openstack-nova03:47
*** sdake_ has quit IRC03:51
*** sdake has joined #openstack-nova03:52
openstackgerritZhenyu Zheng proposed openstack/nova master: Add compute service support for attach/detach root volume  https://review.openstack.org/61475003:53
*** wolverineav has quit IRC03:55
*** sdake has quit IRC03:55
*** sdake has joined #openstack-nova03:56
*** sdake has quit IRC03:57
*** sdake has joined #openstack-nova03:58
*** Sundar has quit IRC03:58
*** sdake has quit IRC04:00
*** tetsuro has quit IRC04:02
*** tetsuro has joined #openstack-nova04:03
*** tetsuro has quit IRC04:04
*** sdake has joined #openstack-nova04:06
*** masber has joined #openstack-nova04:08
*** sdake has quit IRC04:11
*** sdake_ has joined #openstack-nova04:12
*** spsurya has joined #openstack-nova04:15
*** sdake_ has quit IRC04:17
openstackgerritMerged openstack/python-novaclient master: Fix changes-before values in an instance action test  https://review.openstack.org/63884904:21
*** janki has joined #openstack-nova04:33
*** _fragatina has joined #openstack-nova04:52
*** wolverineav has joined #openstack-nova05:01
*** itlinux has quit IRC05:01
*** wolverineav has quit IRC05:02
*** dave-mccowan has quit IRC05:05
*** macza has joined #openstack-nova05:13
openstackgerritMerged openstack/nova master: Avoid BadRequest error log on volume attachment  https://review.openstack.org/58145305:13
*** macza has quit IRC05:17
*** _hemna has joined #openstack-nova05:37
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove duplicate cleanup in functional tests  https://review.openstack.org/63699605:37
*** sridharg has joined #openstack-nova05:38
*** tetsuro has joined #openstack-nova05:38
*** ileixe has joined #openstack-nova05:42
*** udesale has joined #openstack-nova05:42
*** ileixe has quit IRC05:42
*** ileixe has joined #openstack-nova05:43
*** masber has quit IRC06:04
*** tetsuro has quit IRC06:05
*** dcdawg has joined #openstack-nova06:07
*** tetsuro has joined #openstack-nova06:08
*** ivve has joined #openstack-nova06:08
*** ratailor has joined #openstack-nova06:10
*** _hemna has quit IRC06:11
openstackgerritYongli He proposed openstack/nova master: Adds the server group info into show server detail API.  https://review.openstack.org/62147406:11
openstackgerritYongli He proposed openstack/nova master: Adds the server group info into show server detail API.  https://review.openstack.org/62147406:16
*** wolverineav has joined #openstack-nova06:21
*** tetsuro has quit IRC06:31
*** sridharg has quit IRC06:32
*** dcdawg has quit IRC06:36
*** wolverineav has quit IRC06:38
*** wolverineav has joined #openstack-nova06:39
*** dcdawg has joined #openstack-nova06:39
*** _hemna has joined #openstack-nova06:42
openstackgerritBoxiang Zhu proposed openstack/nova master: Convert to raw format into rbd volume  https://review.openstack.org/63808006:45
*** _hemna has quit IRC06:47
*** Luzi has joined #openstack-nova06:47
*** markvoelker has quit IRC06:51
*** ttsiouts has joined #openstack-nova06:53
*** wolverineav has quit IRC06:54
*** slaweq has joined #openstack-nova06:57
*** Dinesh_Bhor has quit IRC06:58
openstackgerritMichael Still proposed openstack/nova master: We no longer need rootwrap.  https://review.openstack.org/55443806:59
openstackgerritMichael Still proposed openstack/nova master: Move final bridge commands to privsep.  https://review.openstack.org/63958006:59
openstackgerritMichael Still proposed openstack/nova master: Cleanup the _execute shim in nova/network.  https://review.openstack.org/63958106:59
openstackgerritZhenyu Zheng proposed openstack/nova master: Detach/Attach root volume API changes  https://review.openstack.org/62398106:59
*** Dinesh_Bhor has joined #openstack-nova07:01
*** tetsuro has joined #openstack-nova07:07
*** phasespace has quit IRC07:08
*** Dinesh_Bhor has quit IRC07:12
*** ivve has quit IRC07:17
openstackgerritYongli He proposed openstack/nova master: Adds the server group info into show server detail API.  https://review.openstack.org/62147407:19
*** takamatsu_ has joined #openstack-nova07:21
*** belmoreira has joined #openstack-nova07:25
*** dpawlik has joined #openstack-nova07:25
*** dcdawg has quit IRC07:28
*** ccamacho has joined #openstack-nova07:29
openstackgerritYongli He proposed openstack/nova master: Add server sub-resource topology API  https://review.openstack.org/62147607:30
*** ttsiouts has quit IRC07:33
*** ttsiouts has joined #openstack-nova07:34
*** ivve has joined #openstack-nova07:34
*** ttsiouts has quit IRC07:38
*** wolverineav has joined #openstack-nova07:44
*** dcdawg has joined #openstack-nova07:48
*** liuyulong has joined #openstack-nova07:50
*** sridharg has joined #openstack-nova07:52
*** markvoelker has joined #openstack-nova07:52
*** tetsuro has quit IRC07:55
*** ccamacho has quit IRC07:56
*** takashin has left #openstack-nova08:01
*** lbragstad has quit IRC08:01
*** moshele has joined #openstack-nova08:05
*** ccamacho has joined #openstack-nova08:07
*** Dinesh_Bhor has joined #openstack-nova08:10
*** tssurya has joined #openstack-nova08:12
*** pcaruana has joined #openstack-nova08:13
*** Dinesh_Bhor has quit IRC08:14
*** phasespace has joined #openstack-nova08:16
*** imacdonn has quit IRC08:18
*** imacdonn_ has joined #openstack-nova08:18
*** wolverineav has quit IRC08:18
*** tesseract has joined #openstack-nova08:20
*** ttsiouts has joined #openstack-nova08:25
*** markvoelker has quit IRC08:25
openstackgerritSagar Waghmare proposed openstack/nova master: db sync prints stack-trace on invalid version  https://review.openstack.org/63959108:25
*** pcaruana has quit IRC08:28
*** dcdawg has quit IRC08:29
*** ttsiouts has quit IRC08:30
*** takamatsu_ has quit IRC08:31
*** tkajinam has quit IRC08:33
openstackgerritBoxiang Zhu proposed openstack/nova master: Convert to raw format into rbd volume  https://review.openstack.org/63808008:35
*** helenafm has joined #openstack-nova08:38
*** tosky has joined #openstack-nova08:41
*** pcaruana has joined #openstack-nova08:42
*** _hemna has joined #openstack-nova08:45
openstackgerritgaryk proposed openstack/nova master: Better handle live migration abort  https://review.openstack.org/63544008:46
*** wolverineav has joined #openstack-nova08:51
*** pcaruana has quit IRC08:51
*** ttsiouts has joined #openstack-nova08:55
*** diga has quit IRC08:56
*** liuyulong_ has joined #openstack-nova08:56
*** pcaruana has joined #openstack-nova08:58
*** liuyulong has quit IRC08:59
*** pcaruana|afk| has joined #openstack-nova09:01
openstackgerritBoxiang Zhu proposed openstack/nova master: Convert to raw format into rbd volume  https://review.openstack.org/63808009:02
*** dcdawg has joined #openstack-nova09:02
*** pcaruana has quit IRC09:03
*** snevi has joined #openstack-nova09:08
*** ttsiouts has quit IRC09:08
*** ttsiouts has joined #openstack-nova09:09
*** ivve has quit IRC09:11
*** ttsiouts_ has joined #openstack-nova09:11
*** ttsiouts has quit IRC09:12
*** takamatsu has joined #openstack-nova09:15
*** _hemna has quit IRC09:16
*** snevi has quit IRC09:19
openstackgerritLee Yarwood proposed openstack/nova master: WIP status: Ensure templated connection URLs are rendered before use  https://review.openstack.org/63960709:20
*** ralonsoh has joined #openstack-nova09:22
*** markvoelker has joined #openstack-nova09:23
*** wolverineav has quit IRC09:23
openstackgerritBalazs Gibizer proposed openstack/nova master: Fup for the bandwidth series  https://review.openstack.org/63915909:24
openstackgerritBalazs Gibizer proposed openstack/nova master: Handle placement error during re-schedule  https://review.openstack.org/63960809:24
*** igordc has quit IRC09:25
*** cdent has joined #openstack-nova09:25
*** ivve has joined #openstack-nova09:26
*** janki has quit IRC09:30
*** janki has joined #openstack-nova09:30
openstackgerritZhenyu Zheng proposed openstack/nova master: Detach/Attach root volume API changes  https://review.openstack.org/62398109:32
*** sapd1 has quit IRC09:33
*** Luzi has quit IRC09:36
aspierscan anyone help me understand why this failed? http://logs.openstack.org/77/638677/2/gate/grenade-py3/e4fb83b/09:40
*** derekh has joined #openstack-nova09:41
*** takamatsu has quit IRC09:44
*** mvkr has quit IRC09:46
*** macza has joined #openstack-nova09:46
*** macza has quit IRC09:50
*** Luzi has joined #openstack-nova09:51
*** efoley has joined #openstack-nova09:56
*** markvoelker has quit IRC09:57
*** owalsh_ has joined #openstack-nova09:57
*** owalsh has quit IRC09:58
*** mvkr has joined #openstack-nova10:01
*** sdake has joined #openstack-nova10:03
*** sdake has quit IRC10:05
*** priteau has joined #openstack-nova10:06
*** sdake has joined #openstack-nova10:08
*** owalsh has joined #openstack-nova10:09
*** owalsh_ has quit IRC10:10
*** sdake has quit IRC10:10
*** sdake has joined #openstack-nova10:12
*** sdake has quit IRC10:13
*** moshele has quit IRC10:13
*** sdake has joined #openstack-nova10:16
*** sdake has quit IRC10:17
*** dpawlik has quit IRC10:20
*** wolverineav has joined #openstack-nova10:20
*** sdake has joined #openstack-nova10:22
*** panda|ruck|off is now known as panda10:23
*** panda is now known as panda|ruck10:23
*** sdake has quit IRC10:25
*** sdake has joined #openstack-nova10:25
*** sdake has quit IRC10:30
*** sdake has joined #openstack-nova10:31
*** dpawlik has joined #openstack-nova10:35
*** sdake has quit IRC10:35
*** sdake has joined #openstack-nova10:35
*** priteau has quit IRC10:40
*** tssurya has quit IRC10:40
*** sdake has quit IRC10:41
*** sdake_ has joined #openstack-nova10:41
*** tssurya has joined #openstack-nova10:42
*** priteau has joined #openstack-nova10:45
*** sdake_ has quit IRC10:45
*** sdake has joined #openstack-nova10:46
*** brinzhang has quit IRC10:46
*** dcdawg has quit IRC10:47
*** sdake has quit IRC10:50
*** sdake has joined #openstack-nova10:51
*** markvoelker has joined #openstack-nova10:53
*** udesale has quit IRC10:53
*** wolverineav has quit IRC10:54
*** sdake has quit IRC10:55
*** sdake has joined #openstack-nova10:57
*** Dinesh_Bhor has joined #openstack-nova10:57
*** sdake has quit IRC11:00
*** Dinesh_Bhor has quit IRC11:00
*** sdake has joined #openstack-nova11:01
*** dpawlik has quit IRC11:04
*** Shilpa has joined #openstack-nova11:05
*** ShilpaSD has quit IRC11:06
*** dcdawg has joined #openstack-nova11:09
*** ttsiouts_ has quit IRC11:09
*** ttsiouts has joined #openstack-nova11:10
*** sapd1 has joined #openstack-nova11:11
*** erlon has joined #openstack-nova11:12
*** dcdawg has quit IRC11:13
*** _hemna has joined #openstack-nova11:14
*** ratailor has quit IRC11:20
*** ileixe has quit IRC11:20
*** ttsiouts has quit IRC11:23
*** takamatsu has joined #openstack-nova11:24
openstackgerritZhenyu Zheng proposed openstack/nova master: Detach/Attach root volume API changes  https://review.openstack.org/62398111:25
*** Shilpa has quit IRC11:25
*** markvoelker has quit IRC11:26
*** dcdawg has joined #openstack-nova11:27
*** dcdawg has quit IRC11:31
*** dcdawg has joined #openstack-nova11:34
*** dpawlik has joined #openstack-nova11:35
*** dcdawg has quit IRC11:38
*** dpawlik has quit IRC11:39
*** dpawlik has joined #openstack-nova11:41
*** macza has joined #openstack-nova11:44
*** _hemna has quit IRC11:47
bauzasgibi: hola11:47
bauzasgibi: do you know where we set VCPU inventories for https://review.openstack.org/#/c/631559/ ?11:48
* bauzas tries to find it but I haven't seen it yet11:48
*** macza has quit IRC11:48
bauzasFWIW, we have a VCPU inventory that only accepts two VCPUs :)11:49
bauzas(Pdb) compute_inventory11:49
bauzas{u'VCPU': {u'allocation_ratio': 16.0, u'total': 2, u'reserved': 0, u'step_size': 1, u'min_unit': 1, u'max_unit': 2}, u'MEMORY_MB': {u'allocation_ratio': 1.5, u'total': 4096, u'reserved': 512, u'step_size': 1, u'min_unit': 1, u'max_unit': 4096}, u'DISK_GB': {u'allocation_ratio': 1.0, u'total': 128, u'reserved': 0, u'step_size': 1, u'min_unit': 1, u'max_unit': 128}}11:49
*** ttsiouts has joined #openstack-nova11:49
bauzasoh my bad11:50
*** wolverineav has joined #openstack-nova11:51
sean-k-mooneybauzas: technically the vcpu inventory will accept 32 cpu allocation but each allcoation can only contin 211:52
bauzasyup, so that's not the problem I have then11:52
bauzassuper weird11:52
sean-k-mooneywhat is the problem you are having?11:52
bauzasplacement returns me no alloc candidates but inventories are okay11:53
*** efoley has quit IRC11:53
sean-k-mooneyis it a timeing issue?11:53
sean-k-mooneyand have we talked about this like 3 times in the past and we keep forgetting11:53
bauzassean-k-mooney: nope, I don't think it's a race11:54
bauzassean-k-mooney: http://paste.openstack.org/show/746416/11:54
sean-k-mooneybauzas: ok i was wondering if it was the downstream issue you had been looking at on and off for the last few months11:55
*** moshele has joined #openstack-nova11:55
bauzasnope, working on the reshape series11:55
bauzashttp://paste.openstack.org/show/746418/11:56
*** moshele has quit IRC11:57
sean-k-mooneyim not sure what im looking at.11:57
*** tetsuro has joined #openstack-nova11:57
bauzassean-k-mooney: I modified the functest and now i have a NoValidHost http://paste.openstack.org/show/746419/11:58
bauzasthat's probably a PEBKAC11:59
bauzasoh wait, it's the memory...11:59
bauzaswe ask for 2048GB of RAM in the flavor11:59
*** tetsuro has quit IRC11:59
*** moshele has joined #openstack-nova12:00
bauzaswe have 4096 * 1.5 - 51212:00
*** ivve has quit IRC12:00
sean-k-mooneyGB i think you mean MB12:00
sean-k-mooney* i hope you mean MB12:00
bauzaswhoops indeed12:00
bauzasanyway, that's why I get a placement thingy12:00
*** Luzi has quit IRC12:00
bauzasI need to create more room or ask for less12:01
bauzasbut then the question remains, where do we set inventories from the functional tests ?12:01
sean-k-mooneyubutnu/fedroa and centos will work with 256mb and cirros will work with 64mb12:01
*** Luzi has joined #openstack-nova12:02
sean-k-mooneyits using the libvirt fake driver12:02
sean-k-mooneyso its in the driver code12:02
bauzasbingo, found it12:03
bauzasHostInfo()12:04
sean-k-mooneyya that sound about right12:04
bauzasyay, it works when changing kB_mem attribute \o/12:05
*** awalende has joined #openstack-nova12:16
*** s10 has joined #openstack-nova12:16
*** markvoelker has joined #openstack-nova12:22
*** wolverineav has quit IRC12:24
*** udesale has joined #openstack-nova12:26
aspierscan anyone give me some hints on how to debug failing grenade jobs?12:27
openstackgerritSylvain Bauza proposed openstack/nova master: Use the correct mdev allocated from the pGPU  https://review.openstack.org/63659112:31
openstackgerritSylvain Bauza proposed openstack/nova master: libvirt: implement reshaper for vgpu  https://review.openstack.org/59920812:31
openstackgerritSylvain Bauza proposed openstack/nova master: Add functional test for libvirt vgpu reshape  https://review.openstack.org/63155912:31
openstackgerritSylvain Bauza proposed openstack/nova master: FUP: docs nit  https://review.openstack.org/63964712:31
bauzasefried: ^12:32
gibibauzas: this is where the 2 VCPU is coming from fakelibvirt.HostInfo12:34
aspiersah, logs/grenade.sh.txt.gz is the logfile I was looking for12:35
gibibauzas: ohh I see your figured it out12:35
*** dcdawg has joined #openstack-nova12:37
*** gbarros has joined #openstack-nova12:41
*** moshele has quit IRC12:46
openstackgerritBalazs Gibizer proposed openstack/nova master: Remove port allocation during detach  https://review.openstack.org/62242112:47
openstackgerritBalazs Gibizer proposed openstack/nova master: Add remove_resources_from_instance_allocation to report client  https://review.openstack.org/63965312:48
*** rpsene has joined #openstack-nova12:48
jaypipesaspiers: have a friend jump on them.12:50
aspiers:)12:50
*** markvoelker has quit IRC12:56
*** ivve has joined #openstack-nova12:57
*** mdbooth_ has quit IRC12:57
sean-k-mooneyhow do people feel about backporting https://review.openstack.org/#/q/topic:bug/1751923+(status:open+OR+status:merged)12:58
*** agopi has quit IRC12:59
sean-k-mooneymriedemn asked me to hold off for a while a when it merged but i have a downstream customer asking for this so im wondering if i should backport upstream or not?12:59
sean-k-mooneyi wont get around to starting the backport untill next week but input would be welcome.13:01
*** dave-mccowan has joined #openstack-nova13:02
*** mdbooth has joined #openstack-nova13:02
tssuryastephenfin: I had a small doubt here: https://review.openstack.org/#/c/634600/9 regarding the doc samples; could you confirm ?13:03
*** pcaruana|afk| has quit IRC13:09
openstackgerritBalazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest  https://review.openstack.org/62531013:09
sean-k-mooneytssurya: assuming you are correct that means we are missing a gate job to build the api samples13:13
tssuryasean-k-mooney: yea that's what I think so too13:13
openstackgerritBalazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist  https://review.openstack.org/62531113:14
openstackgerritBalazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF  https://review.openstack.org/62354313:14
openstackgerritBalazs Gibizer proposed openstack/nova master: Support server create with ports having resource request  https://review.openstack.org/63636013:14
openstackgerritBalazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance to make place for port healing  https://review.openstack.org/63795313:14
openstackgerritBalazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance (2)  https://review.openstack.org/63795413:14
openstackgerritBalazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations  https://review.openstack.org/63795513:14
openstackgerritBalazs Gibizer proposed openstack/nova master: cache neutron ports in heal allocation  https://review.openstack.org/63820713:14
sean-k-mooneyi have never actully built the api-sampels personally so i dont know the answer to your question but ya my takeaway from that question is we shoudl fix them if need and add a gate job in the same patch to prevent future regressions13:15
*** mchlumsky has joined #openstack-nova13:15
tssuryasean-k-mooney: yea thanks13:16
*** sdake has quit IRC13:16
*** priteau has quit IRC13:19
*** wolverineav has joined #openstack-nova13:21
artomtssurya, I think the stuff under doc/ is generated automatically, don't remember how though, it's been forever since I played with that..13:21
artomHrmm, although Matt had to add them manually in his path here https://review.openstack.org/#/c/631948/13:22
artomOK, I have no idea, ignore me13:22
*** derekh has quit IRC13:22
openstackgerritBalazs Gibizer proposed openstack/nova master: Add remove_resources_from_instance_allocation to report client  https://review.openstack.org/63965313:25
openstackgerritBalazs Gibizer proposed openstack/nova master: Remove port allocation during detach  https://review.openstack.org/62242113:25
openstackgerritBalazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest  https://review.openstack.org/62531013:25
openstackgerritBalazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist  https://review.openstack.org/62531113:25
openstackgerritBalazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF  https://review.openstack.org/62354313:25
openstackgerritBalazs Gibizer proposed openstack/nova master: Support server create with ports having resource request  https://review.openstack.org/63636013:25
openstackgerritBalazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance to make place for port healing  https://review.openstack.org/63795313:25
openstackgerritBalazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance (2)  https://review.openstack.org/63795413:25
openstackgerritBalazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations  https://review.openstack.org/63795513:25
openstackgerritBalazs Gibizer proposed openstack/nova master: cache neutron ports in heal allocation  https://review.openstack.org/63820713:25
*** jmlowe has quit IRC13:29
*** agopi has joined #openstack-nova13:35
*** tbachman has quit IRC13:38
*** agopi has quit IRC13:40
tssuryaartom: oh he added them manually ?13:40
tssuryaI was actually trying to review this: https://review.openstack.org/#/c/621474/26 and some things seemed off when added manually like the test samples and doc samples didn't match13:41
tssuryaanyways thanks artom I am confused too at this point13:41
*** _hemna has joined #openstack-nova13:43
*** mriedem has joined #openstack-nova13:44
mriedemtssurya: from your question in https://review.openstack.org/#/c/634600/ it sounds like a bug if you want to report one and push a fix13:46
*** phasespace has quit IRC13:52
*** markvoelker has joined #openstack-nova13:53
*** rambo_li has joined #openstack-nova13:53
*** janki has quit IRC13:53
tssuryamriedem: ack will do13:54
mriedemalso, nice review on https://review.openstack.org/#/c/621474/13:54
*** wolverineav has quit IRC13:55
tssurya:)13:55
*** igordc has joined #openstack-nova13:56
*** rambo_li has quit IRC13:56
*** derekh has joined #openstack-nova13:57
gibimriedem: fixed your comments in https://review.openstack.org/#/c/622421 and split out the report client change to a separate patch13:58
gibimriedem: the fup is also up to date https://review.openstack.org/#/c/63915914:00
mriedemok14:00
*** mlavalle has joined #openstack-nova14:00
*** liuyulong has joined #openstack-nova14:00
gibiI have to spend the rest of the afternoon in downstream land so let's communicate via the code reviews :/14:01
mriedemfare thee well14:01
*** rambo_li has joined #openstack-nova14:01
gibimriedem: thanks I will try :)14:01
*** eharney has joined #openstack-nova14:04
*** awaugama has joined #openstack-nova14:06
*** agopi has joined #openstack-nova14:08
*** rambo_li has quit IRC14:10
*** sdake has joined #openstack-nova14:12
*** sdake has quit IRC14:12
*** jmlowe has joined #openstack-nova14:13
sean-k-mooneymriedem: o/14:13
mriedem~o~14:14
sean-k-mooneymriedem: i asked this before you joined today but do you still want me to hold off on backporting https://review.openstack.org/#/q/topic:bug/1751923+(status:open+OR+status:merged) upstream? i will need to start backporting them downstream next week but i would prefer to do it upstream14:14
mriedemsean-k-mooney: if you're going to do the backport work anyway, can you start it upstream and then cherry pick the upstream backports for your downstream work? knowing that the upstream backports might sit awhile to bake14:15
mriedemi'm not comfortable landing that on stable before it's been released on master and someone like cern or vexxhost has run them yet14:16
sean-k-mooneyyep i can do that. i was jsut not sure if you wanted me to avoid backporting them upstream in general14:16
*** priteau has joined #openstack-nova14:16
sean-k-mooneyis it the data migrtation script that you are most concerned about or the force refesh patch in general14:17
*** Luzi has quit IRC14:17
mriedemthe data migration script14:17
*** _hemna has quit IRC14:18
sean-k-mooneyya technically that is optional and only required for old instnaces that do not alreay have a vlue poplulated in the virtual interfaces table14:18
mriedemi probably won't be comfortable with that on backports upstream until cern has run it14:18
sean-k-mooneyi rased that as a conern downstream too14:18
mriedemsince it hits all of the cells14:18
aspierskashyap: you around? I have an idea of how to move forward with getDomainCapabilities()14:19
*** eharney_ has joined #openstack-nova14:19
kashyapaspiers: Yes14:19
kashyapaspiers: Shoot14:19
sean-k-mooneyya from a down stream perspecitve we are going ot have to test this carfully for FFU also14:20
aspiersI think it would be good enough for now if we call it once per arch, using the default machine type for that arch specified by hw_machine_type14:20
*** lbragstad has joined #openstack-nova14:20
kashyapaspiers: Yeah.  How many arches is SEV supported, BTW?14:21
sean-k-mooneymriedem: what im hoping to do is get the patches inplace next week so we can do some addtional testing before wew fully decided if we will apply the patch. thanks for clarifing :)14:21
aspierslater we could consider calling it for other machine types14:21
aspierskashyap: only x86_64 I think14:21
kashyapaspiers: Thought as much.  Yeah, for now, let's go the x86_64 route, document it in the conf file / wherver appropriate14:22
aspierskashyap: so the memoized _domaincaps would be a nested dict of dicts like I mentioned the other day14:22
*** eharney has quit IRC14:22
sean-k-mooneyaspiers:  you can set the machive type in the image_metadata too14:22
kashyapsean-k-mooney: Yes, that's what I'm getting at14:22
aspierssean-k-mooney: sure, but right now there is nothing in domain capabilities which would need to influence that14:23
kashyap        $ openstack image set \14:23
kashyap            --property hw_machine_type=x86_64=q35 Fedora-29-Template14:23
kashyapaspiers: Aside, ^ have you tested the above with Git master?14:23
aspierskashyap: have I tested setting image props?14:23
kashyapYes14:23
aspiersno14:23
kashyap(Asking because, I got a bug report, albiet for an older release, that the above isn't working.  I'm still suspicious of the bug report.)14:23
aspiersah OK14:24
kashyapI asked the reporter to get me the logs, and libvirt debug log (with filters), etc.  So I can see what's going on.14:24
aspierskashyap: so I'm suggesting something like (effectively) self._domaincaps['x86_64']['q35'] = <XML tree object>14:24
kashyap"Seeing is believing."  Because too many times I got burnt by taking the word of the bug reporter14:24
aspiershaha yeah :)14:25
kashyap... only to see in the logs that they misconfigured or did a blatant no-op14:25
*** markvoelker has quit IRC14:25
openstackgerritLajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.70  https://review.openstack.org/63723414:26
kashyapaspiers: BTW, just saw the comment in the review (and the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1683471)14:26
openstackbugzilla.redhat.com bug 1683471 in libvirt "getDomainCapabilities claims SEV is supported for pc-i440fx-1.4 machine type" [Unspecified,New] - Assigned to libvirt-maint14:26
sean-k-mooneykashyap: i got libvirtError: XML error: No PCI buses available14:26
kashyap(I see you filed it yourself, though)14:26
sean-k-mooneywhen i tried that a few seconds ago14:26
openstackgerritLajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.71  https://review.openstack.org/63723414:26
kashyapsean-k-mooney: Ah, on Git master?14:27
kashyapsean-k-mooney: So something is broken :-(14:27
aspierskashyap: yes :)14:27
kashyapsean-k-mooney: Can you add the log filters I noted in the second bullet here:14:27
kashyaphttps://kashyapc.fedorapeople.org/virt/openstack/request-nova-libvirt-qemu-debug-logs.txt14:27
kashyapsean-k-mooney: And then re-post the complete libvirt debug log somewhere, if you can...14:27
*** psachin has quit IRC14:27
sean-k-mooneyon f77791954d8a39652ea30ccf51968886471de612 form master14:27
aspierskashyap: does that dict of dicts make sense to you? it allows for calling getDomCaps on more machine types in the future14:27
aspiersand at least one per arch for now14:28
kashyapaspiers: Yeah, it does make sense to me.  (As we future-proofed it.)14:29
aspierskashyap: OK great, I'll update the patch to do that and test it on a real SEV machine14:29
*** Sundar has joined #openstack-nova14:29
sean-k-mooneykashyap: the only difference form the default filter on ubunut is the also have 1:cpu14:29
kashyapsean-k-mooney: Did you get your default filter from DevStack?  (I made sure to add '1:cpu' there too)14:30
sean-k-mooneyyes14:30
kashyapaspiers: Thanks!  I've got the SEV series in my browser open.14:31
kashyap("Open in the browser" doesn't mean much, though :D)14:31
sean-k-mooneyat least i assume so since this was just a ubunut cloud image so anything not stadard was devstack14:31
kashyapsean-k-mooney: If you got it from DevStack, you should have '1:cpu'.14:32
kashyapBecause I added:14:32
kashyap   lib/nova_plugins/functions-libvirt:            local log_filters="1:libvirt.c 1:qemu 1:conf 1:security 3:object 3:event 3:json 3:file 1:util 1:cpu"14:32
kashyap(In DevStack)14:32
aspierskashyap: LOL :) maybe you need this https://chrome.google.com/webstore/detail/xtab/amddgdnlkmohapieeekfknakgdnpbleb14:32
sean-k-mooneykashyap: yep i have but the string in https://kashyapc.fedorapeople.org/virt/openstack/request-nova-libvirt-qemu-debug-logs.txt does not have 1:cpu14:32
gibijaypipes, efried: the fup for the bandwidth series is up-to-date and mriedem already +2 it14:32
gibihttps://review.openstack.org/#/c/639159/14:33
jaypipesack, on it.14:33
gibijaypipes: thanks a lot14:33
kashyapsean-k-mooney: Heh, then I should update my doc :-)14:33
kashyapsean-k-mooney: Okay, we're good.14:33
kashyapaspiers: Haha, seems dangerous.  As it destroys the illusion of productivity!14:34
aspiersX-D14:34
aspierson a tangent, I wonder if I broke a world record by having 89 Chrome extensions installed14:35
sean-k-mooneykashyap: looking at the libvirtd log there isnt really any useful infor there. just the same message. this is more then likely a nova issue not a libvirt one14:37
jaypipesgibi: all done.14:39
kashyapsean-k-mooney: Yeah, could be the way Nova is generating guest XML too14:39
sean-k-mooneykashyap: this is the section fo the log around the issu http://paste.openstack.org/show/746435/14:39
kashyapsean-k-mooney: Anything fun in the n-cpu.log?14:39
gibijaypipes: thanks. The rest of the series also up-to-date if you have time https://review.openstack.org/#/c/63965314:39
sean-k-mooneywell there was a traceback but ill check the xml that was generated on second while i grab it14:39
kashyapsean-k-mooney: Thanks!14:40
kashyapsean-k-mooney: Care to post the full libvirtd.log just somewhere?  I'd like to see some messages above that too14:41
sean-k-mooneyhttp://paste.openstack.org/show/746436/14:42
sean-k-mooneyam sure i can but its got a lot of crap in it since just checked it in one of my long running dev vms14:42
sean-k-mooneykashyap: looking at the xml we are not generating a pcie bus or adding a pci bridge device14:43
kashyapsean-k-mooney: Ah, right; I normally just clean it up `> foo.log` and start over14:43
sean-k-mooneyi can truncate it can spin up another vm it will only take a second but this looks like a nova issue14:44
mriedemgibi: i know you told me to leave you alone, but i'm a soft -1 on the bottom 2 changes in the series now, should be easy things to address and then i can +2 those today14:44
sean-k-mooneyfor q35 we expect nova to generate a pcie toplogy in the xml14:45
*** ttsiouts has quit IRC14:45
kashyapsean-k-mooney: Hang on ...14:45
kashyapsean-k-mooney: This is not even valid guest XML:14:46
kashyap     <type machine="x86_64=q35">hvm</type>14:46
sean-k-mooneyhehe ya i just noticed that too14:46
kashyapsean-k-mooney: Also, it's a bug in libvirt itself!14:47
kashyapsean-k-mooney: It should reject that as an invalid XML14:47
sean-k-mooneyit did14:47
kashyapI'll file an upstream bug report, and take it w/ the libvirt folks14:47
openstackgerritYongli He proposed openstack/nova master: Adds the server group info into show server detail API.  https://review.openstack.org/62147414:47
sean-k-mooneythe error startswith "Error defining a guest with XML: ..."14:48
sean-k-mooney maybe that came form nova14:48
kashyapI guess so; libvirt uses the terms "domains"14:48
kashyapsean-k-mooney: Regardless, libvirt's parser should reject invalid XML14:48
sean-k-mooneyah right14:48
kashyapIt is a valid bug in libvirt itself; I just double-confirmed w/ a libvirt upstream dev.14:48
sean-k-mooneyyep let me quickly  set the image prop to q3514:48
*** _hemna has joined #openstack-nova14:49
*** sdake has joined #openstack-nova14:49
kashyapsean-k-mooney: So, this is valid guest XML: <type arch='x86_64' machine='pc-i440fx-rhel7.2.0'>hvm</type>14:50
sean-k-mooneykashyap: openstack image set --property hw_machine_type=q35 cirros-0.3.6-x86_64-disk works14:50
kashyapsean-k-mooney: Excellent.  So the problem is the bug reporter directly copied my bad syntax!14:51
kashyapTalk about copy/paste on the internet.14:51
sean-k-mooneyhttp://paste.openstack.org/show/746437/14:51
sean-k-mooneykashyap: well the syntax you used was correct for the nova.conf14:51
*** wolverineav has joined #openstack-nova14:52
sean-k-mooneybut an image presuably only has on architeure so i guess droping the arch= part makes sense14:52
*** tbachman has joined #openstack-nova14:52
kashyapYeah14:52
kashyapsean-k-mooney: Thanks for the debugging; two birds, one stone.  ;-)14:53
yongliheSurya's comments addressed. thanks. https://review.openstack.org/#/c/621474/2714:53
sean-k-mooneyyou could argue there is also a nova bug here in that nova did not validate the image metadata property before passing it to libvirt14:53
kashyapsean-k-mooney: That, too.14:54
yonglihe jaypipes:  topology patch rebase to microversion 2.72 https://review.openstack.org/#/c/621476/14:54
*** moshele has joined #openstack-nova14:54
*** sdake has quit IRC14:55
*** mrch_ has quit IRC14:56
*** hongbin has joined #openstack-nova14:56
*** pcaruana has joined #openstack-nova14:57
mriedemgibi: -1 on https://review.openstack.org/#/c/625310/ as well14:59
*** itlinux has joined #openstack-nova14:59
kashyapsean-k-mooney: Can you tell the libvirt/QEMU version you tested with, please?15:00
mriedemstephenfin: you should probably take a look at this before me https://review.openstack.org/#/c/625311/15:01
* stephenfin looks15:01
*** sdake has joined #openstack-nova15:02
sean-k-mooneyubuntu@os-vif-1:/opt/stack/nova$ qemu-system-x86_64 --version15:03
sean-k-mooneyQEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9)15:03
sean-k-mooneyCopyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers15:03
cfriesenmriedem: not sure what you mean by this comment: https://review.openstack.org/#/c/620706/25/nova/compute/api.py@61215:03
sean-k-mooneyubuntu@os-vif-1:/opt/stack/nova$ libvirtd --version15:03
sean-k-mooneylibvirtd (libvirt) 4.0.015:03
*** dpawlik has quit IRC15:03
*** s10 has quit IRC15:04
mriedemcfriesen: reference to https://review.openstack.org/#/c/620706/25/nova/compute/api.py@356915:04
*** s10 has joined #openstack-nova15:05
*** ttsiouts has joined #openstack-nova15:06
mriedemcfriesen: left another comment15:06
mriedemi'd care less about that if it wasn't copy/paste15:06
mriedemDRY that up15:06
mriedemplease15:06
*** ShilpaSD has joined #openstack-nova15:08
*** igordc has quit IRC15:11
*** s10 has quit IRC15:13
*** s10 has joined #openstack-nova15:14
openstackgerritRodolfo Alonso Hernandez proposed openstack/os-vif master: Add "master" parameter to ip.set() API function  https://review.openstack.org/63970215:14
sean-k-mooneyjaypipes: stephenfin by the way i missed ^ in the brctl removal so we need to respin os-vif...15:15
jaypipesyonglihe: yes, I have that in my queue. I have major concerns about the response format in that patch. It is mixing the concept of a guest's virtual CPU topology with that of the NUMA information, and the two things don't really have anything to do with each other -- and unfortunately the way that InstanceNUMATopology and InstanceNUMACell objects were designed, that bad coupling is now going to leak out through the public REST API, which is a15:15
jaypipesproblem I raised during the spec review I believe.15:15
*** eharney_ is now known as eharney15:16
*** moshele has quit IRC15:18
*** hongbin has quit IRC15:18
*** moshele has joined #openstack-nova15:20
*** hongbin has joined #openstack-nova15:20
*** liuyulong has quit IRC15:21
*** liuyulong has joined #openstack-nova15:22
*** _hemna has quit IRC15:22
*** markvoelker has joined #openstack-nova15:22
cfriesenmriedem: regarding https://review.openstack.org/#/c/620706/25/nova/compute/api.py@3569 if I do that then wouldn't I need to change the existing code in _validate_flavor_image() where it's doing stuff like image.get('properties', {})?15:24
*** wolverineav has quit IRC15:24
stephenfinmriedem, gibi: Reviewed https://review.openstack.org/#/c/625311/ Two main issues plus a lot of doc nits (which can be ignored for now)15:29
mriedemcfriesen: yeah i guess you're right15:31
*** itlinux_ has joined #openstack-nova15:31
cfriesenmaking the other changes now15:31
openstackgerritSurya Seetharaman proposed openstack/nova master: Fix the api sample docs for microversion 2.68  https://review.openstack.org/63970715:32
dcdawgI'm trying to run a test "tox -e py27" but get an error File "nova/__init__.py", line 33, in <module>15:32
dcdawg    import oslo_service  # noqa15:33
dcdawgImportError: No module named oslo_service15:33
dcdawgEven though I installed the "test-requirements.txt" stuff15:33
stephenfindcdawg: 'tox -e py27 --recreate'15:33
*** sdake has quit IRC15:33
stephenfindcdawg: If that doesn't work, it usually means you've introduced a syntax error in your code. 'git stash' your changes and try again to confirm (without '--recreate' this time)15:34
*** itlinux has quit IRC15:34
*** ccamacho has quit IRC15:35
*** priteau has quit IRC15:35
*** ccamacho has joined #openstack-nova15:35
*** sdake has joined #openstack-nova15:35
mriedemgdi this root volume detach/attach just gets more complicated15:36
mriedemartom: so i realize there is a bug in the device tag stuff15:36
artommriedem, your new API stuff?15:37
mriedemno. you know how you can try to create a server with device tags and we'll fail late and abort the build in the compute service if the compute driver doesn't support device tags?15:37
*** moshele has quit IRC15:37
artommriedem, yeah15:37
mriedemif you shelve that server and then unshelve it, you could wind up on a host that doesn't support tags either and it won't fail15:37
artommriedem, that's fun15:38
mriedemwhich was the argument i think you made when adding tags to the attach volume api - you didn't allow it for shelved offloaded servers because we wouldn't know if the compute we land on supports them,15:38
mriedembut that's already broken15:38
artommriedem, it's been a while for me with that code, where exactly do we fail? And is that code path not used when we unshelve? Because that's basically a new instance build, no?15:39
mriedemhttps://github.com/openstack/nova/blob/6efa3861a5a829ba5883ff191e2552b063028bb0/nova/compute/manager.py#L211415:39
mriedem^ is only called during server create15:39
mriedemnot unshelve15:39
artommriedem, yeah, I remember saying "can't do tagged attached with shelved because we have no idea if the eventual compute will support it"15:39
mriedemunshelve is a new spawn of the guest15:39
mriedemsure but we don't know if the eventual compute for server create will support it either15:39
mriedemanyway, see my reply to Kevin_Zheng's email in the ML15:40
jangutterstephenfin: re: https://review.openstack.org/#/c/625311/  I spoke in PM to gibi about this, I think the next review in the series shows why it's needed: the tag is propagated to the scheduler.15:40
artommriedem, dammit, yeah, _unshelve_instance() straight up driver.spawn()s15:40
mriedemfor that matter,15:41
mriedemwe could be migrating an instance with device tags to another host that doesn't support it15:41
*** ccamacho has quit IRC15:41
mriedemthe breakdown is that we just have no filtering for device tags in the scheduler15:41
*** awalende has quit IRC15:41
artommriedem, true. We couldn't, back then15:41
artomNow in New Placement Future, we could add it15:41
mriedemwe could, we just didn't15:41
*** ccamacho has joined #openstack-nova15:41
*** awalende has joined #openstack-nova15:42
mriedemi think at the time we just said "aggregates?"15:42
mriedemand conveniently forgot about it15:42
artommriedem, no, we just didn't consider it, I think15:42
artomWell, except for the boot case15:42
mriedemi remember asking about a scheduler filter15:42
*** helenafm has quit IRC15:42
artomWell, we already have ComputeCapabilitiesFilter...15:42
mriedembecause the server create aborts15:42
mriedemwhich is pretty severe15:42
artomShould get shoved in there, somewhere, no?15:43
mriedemthat would have been the option15:43
mriedemanyway the better answer now is likely based on https://review.openstack.org/#/c/538498/15:43
mriedemwith a placement request filter15:44
artommriedem, I see - New Placement Future indeed ;)15:44
mriedemhaving said all this, anyone running mixed hypervisors in the same region is probably asking for trouble15:45
mriedemand anyone running only a hypervisor driver that doesn't support tags should be disabling it in the api via policy15:45
mriedemlike if you're just a vio shop15:45
artom... I don't think we have an API policy for it, do we?15:45
mriedemi thought we did but i guess not15:46
mriedemsuper15:46
*** awalende has quit IRC15:46
*** itlinux_ has quit IRC15:46
*** sapd1 has quit IRC15:46
artomI'll add a patch(es) on top of aspiers's to fix this.15:47
mriedemanything in the api that isn't supported by all backend compute drivers should probably be controlled via policy...15:47
artomWould this be considered a bug? Ie, is it fair game after FF?15:47
aspierskashyap: did you see https://bugzilla.redhat.com/show_bug.cgi?id=1683471#c715:47
openstackbugzilla.redhat.com bug 1683471 in libvirt "getDomainCapabilities claims SEV is supported for pc-i440fx-1.4 machine type" [Unspecified,New] - Assigned to libvirt-maint15:47
mriedemartom: i'm not even sure what we're trying to fix at this point honestly - scheduling?15:47
jrolljaypipes: have a quick question on one of your comments on 635006 while I'm writing tests, if you have a minute15:47
mriedemartom: adding a placement request filter based on compute capabilities traits is likely a blueprint15:48
artommriedem, yeah - don't schedule an instance with tags on a host that can't tag15:48
mriedemi.e. https://blueprints.launchpad.net/nova/+spec/expose-host-capabilities15:48
*** ccamacho has quit IRC15:48
kashyapaspiers: Yes, I saw.15:48
*** ccamacho has joined #openstack-nova15:48
mriedemidk, definitely something i wouldn't rush in the 2 weeks of FF15:48
kashyapaspiers: I was incidentally talking to the same libvirt dev on machine types (he too was looking for docs)15:48
mriedemat this point the design impacts of root volume attach are also making this very risky15:49
artommriedem, hah, indeed - and anyways I'm already rushing NUMA LM15:49
kashyapaspiers: I'll write some common documentation on machine types that serves us (and any other tools that use libvirt/QEMU).  Basing off of this: https://kashyapc.fedorapeople.org/v2-gracefully-handle-qemu-machine-types.rst.txt15:49
* mriedem feels like getting in the fetal position15:49
*** moshele has joined #openstack-nova15:49
artommriedem, have you tried alcoholism?15:50
aspiershaha15:50
artommriedem, I'll be at PTG, we can hash this out - is root volume attach/detach going to be in Stein?15:50
*** rpsene has quit IRC15:51
artom(We need a rule in the Nova rule at PTG: the moment some spends more than 30 seconds talking about how to model someting in placement, they get pied in the face)15:51
artom(... We'll also need a massive pie budget)15:51
*** ccamacho has quit IRC15:51
artom*Nova room15:51
*** ccamacho has joined #openstack-nova15:51
*** ccamacho has quit IRC15:51
*** ccamacho has joined #openstack-nova15:52
*** ccamacho has quit IRC15:54
*** ccamacho has joined #openstack-nova15:54
*** markvoelker has quit IRC15:56
openstackgerritJim Rollenhagen proposed openstack/nova master: ironic: partition compute services by conductor group  https://review.openstack.org/63500615:58
mriedemartom: the root volume attach/detach stuff is trying to get into stein15:58
mriedemwhich is how i came across this issue while reviewing the change15:58
mriedemanyway i'll start by reporting a bug15:58
*** ivve has quit IRC16:01
melwitto/16:05
mriedemartom: https://bugs.launchpad.net/nova/+bug/181792716:05
openstackLaunchpad bug 1817927 in OpenStack Compute (nova) "device tagging support is not checked during move operations" [Undecided,New]16:05
artommriedem, ack16:05
artommriedem, I put a drive-by comment in the ML about root detach, btw16:06
*** takamatsu has quit IRC16:09
*** udesale has quit IRC16:10
artom"volume workflow since in these cases, we want to keep the BDM record but reset some fields." Can that part change? Is a BDM without a volume ID really still a BDM?16:10
artom(from https://review.openstack.org/#/c/614750/)16:10
mriedemnot all bdms are volumes16:10
artomAnyways, I know I'm jumping in here super late and talking out of my butt16:11
mriedemeven if you don't boot from volume, there is an image bdm for the local disk16:11
mriedemBDM.is_volume is what tells you if it represents a volume16:11
artomBut there's still "something" there, right? image ID, volume ID?16:11
mriedemyes there would be in those other non-volume cases16:12
mriedemnot for a detached root volume16:12
artomOK, so my question still makes sense - if a BDM has nothing to "back" it, is it still a BDM?16:13
mriedemit's a placeholder16:13
mriedemthere are probably other ways to model this, and i seem to remember some of that discussion during the spec review, but none of it is great16:13
artomIt's almost as though it'd need to be split in half: the instance side, and the "backing" side16:14
artomAnyways, yeah, way too late to talk about design at this stage16:14
mriedemthere has to be *something* that nova can use to indicate that the root volume is detached16:15
artom(And the tags would move to the "backing" side - because they're a nova concept, but they apply to the volume, not the attachment, strictly speaking)16:15
mriedemin case the user tries to attach a new root volume or do something like shelve offload, detach root, unshelve (without re-attaching a root volume)16:16
*** s10 has quit IRC16:16
artommriedem, yeah, there needs to be a placeholder, as you said16:16
artomOK, brainstorming here, how about this: split image_id, volume_id, snapshot_id and tag (and whatever else is needed) into a new "BlockDeviceBacking" object or whatever16:17
artomAnd null *that* on a detached root volume16:17
artomBut persist that BlockDeviceBacking16:18
artomAnd if the same root volume is re-attached, re-join those two objects?16:18
openstackgerritsean mooney proposed openstack/os-vif master: add addtion check and gate jobs for os-vif  https://review.openstack.org/63973216:21
mriedemno thanks16:21
mriedemi need to move on from this before i become too depressed to get much done today16:21
*** tssurya has quit IRC16:21
*** wolverineav has joined #openstack-nova16:22
*** _hemna has joined #openstack-nova16:24
openstackgerritsean mooney proposed openstack/os-vif master: add addtion check and gate jobs for os-vif  https://review.openstack.org/63973216:26
aspierskashyap: I think I'll make a preliminary patch which extends LibvirtConfigCapsGuest to capture the <emulator> value16:27
dcdawgBeginner question: Can I simply commit spell corrections in the comments of the code or do I have to make a bug report for that?16:27
*** abhishekk has joined #openstack-nova16:28
kashyapaspiers: Alright, I'll keep an eye on that series.  (I'm just about to head out for my Dutch class; next 3 1/2 hours)16:28
openstackgerritsean mooney proposed openstack/os-vif master: add addtion check and gate jobs for os-vif  https://review.openstack.org/63973216:28
openstackgerritJim Rollenhagen proposed openstack/nova master: ironic: check fresh data when sync_power_state doesn't line up  https://review.openstack.org/63669916:28
*** _hemna has quit IRC16:29
*** tbachman has quit IRC16:29
mriedemdcdawg: definitely don't need a bug16:31
mriedemdepending on the comment you're fixing, if the comment is otherwise not something that can be understood or make sense and needs to be re-written for clarity, sure that's fine16:32
mriedemit's just a simple typo but you still understand what the comment is saying, then patches to fix those are mostly just noise, unless you fix a bunch of stuff in a single change16:32
*** hongbin has quit IRC16:33
efriedHi nova. Do the current args passed into a filter (which appear to be a HostState and a RequestSpec) somewhere contain information from GET /a_c? Namely16:34
efrieda) the allocation candidate (allocation_requests[N]) under consideration; and16:34
efriedb) (the relevant subset of) the provider_summaries?16:34
mriedempretty sure no16:35
*** abhishekk has quit IRC16:35
*** macza has joined #openstack-nova16:35
efriedHostState.host is a Selection object?16:36
mriedemno,16:36
mriedemit's a ComputeNode.host16:36
*** _fragatina has quit IRC16:36
mriedemHostState is a wrapper of a ComputeNode16:36
gibimriedem, stephenfin: thanks for the reviews16:36
efriedokay; seems like a and b should be something we should start passing into filters, nah?16:37
mriedemwe haven't had a need yet16:37
efriedas soon as nested starts being real in allocation candidates...16:37
*** dcdawg has quit IRC16:37
mriedemwhen you have a filter that needs that information then we'll talk about it16:37
efriedand until we have every possible filtering and weighing feature natively in placement...16:37
mriedemwhich we won't16:38
efriedright16:38
efriedokay, that's fair. But it seems like it would be pretty easy to do.16:39
mriedemnothing is ever easy anymore16:39
cdentwas it ever?16:39
mriedemsure16:39
mriedemback in grizzly you could do whatever :)16:40
mriedemit didn't need to actually work16:40
* cdent wasn't born then16:40
mriedemhttps://media2.giphy.com/media/11fpbdcbnBd5tu/source.gif16:40
*** tetsuro has joined #openstack-nova16:40
cdentefried: you have a concrete use case yet, or preparing for the future?16:41
*** hongbin has joined #openstack-nova16:41
efriedcdent: more the latter.16:42
cdentthe situation seems to be "lots of things in nova are going to want that info, eventually"16:42
efriedI agree with that.16:42
efriedBut I also sympathize with the notion of: let's not do this just because we think it's a good idea; let's wait until someone actually needs it.16:43
cdentIt's the eventually that seems to be causing strain16:43
efriedYAGNI?16:43
cdentthere's a growing movement to make sure we have contributors who will own that stuff16:43
cdentI guess yagni's a factor, sure, but more: let's not add extra work without adding extra people. If people don't show up, they must not want it.16:44
cdentmaking that void more visible is a thing I care about quite a bit16:44
mriedemartom: ^ sound familiar?16:44
artommriedem, heh, I was gonna say16:45
jaypipesjroll: sorry, yes, please go ahead16:45
cdentmriedem: ?16:45
mriedemcdent: artom and i were just talking about that, in a closet16:45
artomYeah, we've come out of the closet just now16:45
cdentcongrats16:46
* mriedem covers the hickies16:46
*** gouthamr_ has joined #openstack-nova16:46
*** IvensZambrano has joined #openstack-nova16:46
cdentso how to visibilate things/16:47
cdent(not including hickies)16:47
edleafeThis should be added somewhere in the OpenStack charter: "let's not16:47
edleafe          add extra work without adding extra people. If people don't show up,16:47
edleafe          they must not want it."16:47
artomedleafe, people *do* show up. Once.16:48
*** gouthamr has quit IRC16:48
artomAnd as mriedem was saying, in 2 years of deployers upgrade to the new thing, those people are gone.16:48
artom*when16:48
mriedemi'm not in my 20s anymore, i'm looking for a long-term commitment with contributors16:48
artomo/` If you want it better put a ring on it o/`16:50
*** gouthamr has joined #openstack-nova16:50
*** gouthamr_ has quit IRC16:50
*** tetsuro has quit IRC16:51
*** sdake has quit IRC16:52
*** markvoelker has joined #openstack-nova16:53
*** sdake has joined #openstack-nova16:54
*** wolverineav has quit IRC16:55
openstackgerritLee Yarwood proposed openstack/nova master: WIP status: Ensure templated connection URLs are rendered before use  https://review.openstack.org/63960716:56
*** pcaruana has quit IRC16:57
*** _fragatina has joined #openstack-nova16:58
*** gyee has joined #openstack-nova16:59
*** _fragatina_ has joined #openstack-nova16:59
*** rtjure has quit IRC17:00
*** mriedem is now known as mriedem_away17:01
*** sdake has quit IRC17:02
*** _alastor_ has quit IRC17:02
*** _fragatina has quit IRC17:02
efriedmriedem_away, jaypipes, bauzas, gibi: I think https://review.openstack.org/#/c/538498/ is ready to go now, if you want to give it another look-see.17:03
efried(convert compute caps to traits)17:04
*** mvkr has quit IRC17:04
*** macza_ has joined #openstack-nova17:07
*** _fragatina_ has quit IRC17:07
*** tbachman has joined #openstack-nova17:08
openstackgerritBalazs Gibizer proposed openstack/nova master: Add remove_resources_from_instance_allocation to report client  https://review.openstack.org/63965317:08
openstackgerritBalazs Gibizer proposed openstack/nova master: Remove port allocation during detach  https://review.openstack.org/62242117:08
openstackgerritBalazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest  https://review.openstack.org/62531017:08
openstackgerritBalazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist  https://review.openstack.org/62531117:08
openstackgerritBalazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF  https://review.openstack.org/62354317:08
openstackgerritBalazs Gibizer proposed openstack/nova master: Support server create with ports having resource request  https://review.openstack.org/63636017:08
openstackgerritBalazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance to make place for port healing  https://review.openstack.org/63795317:08
openstackgerritBalazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance (2)  https://review.openstack.org/63795417:08
openstackgerritBalazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations  https://review.openstack.org/63795517:08
openstackgerritBalazs Gibizer proposed openstack/nova master: cache neutron ports in heal allocation  https://review.openstack.org/63820717:08
gibimriedem_away: I fixed up https://review.openstack.org/#/c/639653 but I run out of time on https://review.openstack.org/#/c/622421 so I have to do that tomorrow17:09
*** macza has quit IRC17:10
*** gbarros has quit IRC17:11
openstackgerritMerged openstack/nova master: Fup for the bandwidth series  https://review.openstack.org/63915917:13
jaypipesefried: still says cannot merge on that patch...17:15
jrolljaypipes: oops, I meant I left a question in gerrit, sorry17:15
efriedoh?17:15
efriedoh.17:15
efriedaspiers: ^ looks like needs rebase. Which ugh probably means need to wait until predecessor finishes merging.17:16
*** wolverineav has joined #openstack-nova17:16
*** dpawlik has joined #openstack-nova17:17
melwittdoes anyone know what's the correct way to unit test code that calls placement? I found the PlacementFixture nova/tests/functional/fixtures.py but was thinking that's not appropriate for unit tests17:18
*** tesseract has quit IRC17:22
efriedmelwitt: "unit" and "calls placement" don't really gel. If it's a true unit test, the placement calls ought to be mocked.17:22
melwittefried: right.. I wondered if there was a specific way to mock them (like a fixture I don't know about) or if it's just ad-hoc17:23
efriedmelwitt: Do you have a specific example?17:23
melwittI didn't find any example yet. still looking17:23
efriedokay.17:23
*** dpawlik has quit IRC17:24
melwittI'm working on quota check code that calls placement, so once I added the placement call, lots of unit tests fail17:24
melwittand if someone happened to know the recommended way to mock placement, that would help me17:24
*** tesseract has joined #openstack-nova17:24
efriedmelwitt: See nova.tests.unit.scheduler.client.test_report17:24
efriedmelwitt: Those tests mock SchedulerReportClient.<http primitive like get/put/post/delete>17:25
melwittthank you17:25
*** markvoelker has quit IRC17:25
efriedmelwitt: Whereas nova.tests.functional.test_report_client uses the placement fixture to create an interceptor context manager with which to wrap "real" calls to placement.17:26
*** moshele has quit IRC17:26
efriedthe latter, for functional tests, gets you real placement behavior. The former just lets you pretend you got a certain Response object.17:27
melwittefried: got it. thanks for the help17:27
efriednp, enjoy.17:27
*** ttsiouts has quit IRC17:31
*** mrch_ has joined #openstack-nova17:31
efriedmelwitt: correction: test_report_client uses PlacementDirect. The difference in usage between that and PlacementFixture is the context manager-ness.17:31
*** ttsiouts has joined #openstack-nova17:31
efriedbut it sounds like you want the unit level stuff in any case.17:31
melwittright. but that's good info to know anyway. I'll need to use that too for the functional tests I think17:33
openstackgerritsean mooney proposed openstack/os-vif master: add addtion check and gate jobs for os-vif  https://review.openstack.org/63973217:34
*** jmlowe has quit IRC17:34
efriedmelwitt: In case I don't otherwise notice, lmk when you've got code up, would like to review.17:34
*** dims has quit IRC17:35
melwittefried: the patch that adds placement calls is here https://review.openstack.org/638073 implementation done, test coverage is what I'm working on now17:35
*** ttsiouts has quit IRC17:36
efriedack17:36
*** tesseract has quit IRC17:36
*** ivve has joined #openstack-nova17:36
*** tesseract has joined #openstack-nova17:38
*** gbarros has joined #openstack-nova17:38
*** takamatsu has joined #openstack-nova17:41
efriedmelwitt: left a comment. So yeah, if you take that advice, you'll probably want a functional test in test_report_client; and you may decide a unit test isn't necessary.17:45
*** wolverineav has quit IRC17:46
melwittefried: sweet, thanks17:46
efriedyw17:46
*** efried is now known as efried_afk17:47
*** dims has joined #openstack-nova17:48
*** Sundar is now known as DarthNau17:50
*** tbachman has quit IRC17:57
*** _fragatina has joined #openstack-nova17:58
*** gbarros has quit IRC17:58
*** takamatsu has quit IRC18:01
*** tesseract has quit IRC18:02
*** IvensZambrano has quit IRC18:02
*** moshele has joined #openstack-nova18:05
*** IvensZambrano has joined #openstack-nova18:08
*** panda|ruck is now known as panda|ruck|off18:09
*** moshele has quit IRC18:12
*** tbachman has joined #openstack-nova18:12
*** gbarros has joined #openstack-nova18:16
*** sridharg has quit IRC18:22
*** markvoelker has joined #openstack-nova18:22
*** gbarros has quit IRC18:22
*** _hemna has joined #openstack-nova18:25
*** sdake has joined #openstack-nova18:26
*** wolverineav has joined #openstack-nova18:26
*** erlon has quit IRC18:30
*** _fragatina has quit IRC18:31
*** efried_afk is now known as efried18:32
*** sdake has quit IRC18:33
openstackgerritMerged openstack/nova master: Change LibvirtDriver.capabilities to an instance variable  https://review.openstack.org/63867718:33
openstackgerritGhanshyam Mann proposed openstack/python-novaclient master: DNM: Testing legacy jobs on bionic  https://review.openstack.org/63976818:34
*** _fragatina has joined #openstack-nova18:35
efriedaspiers: predecessor merged ^  -- The rebase is trivial, I would be happy to do that and address artom's nits at the same time, unless you're already working on it18:37
aspiersefried: already working on it18:38
efriedokay18:38
aspiersefried: I've already fixed his nits18:38
*** sdake has joined #openstack-nova18:38
aspiershowever I think I may have noticed a missing test case18:38
*** dcdawg has joined #openstack-nova18:38
openstackgerritGhanshyam Mann proposed openstack/os-vif master: DNM: Testing legacy jobs on bionic  https://review.openstack.org/63976918:38
aspiersefried: if someone uses the placement API to put a capability trait on a compute host, and then at the next periodic the driver declares that cap is unsupported, it needs to be removed, right?18:39
efriedyes18:39
efriedthat's, like, the primary use case here18:39
efriedThat's not already covered by the tests?18:39
aspiersI think I only tested removal of traits which were put there by the driver18:39
aspiersI'm just checking now18:40
efriedokay. It would be one of the test cases with a compute manager reset() in it, if that helps you narrow it down.18:40
*** ralonsoh has quit IRC18:40
aspiersYeah, it's not there18:42
openstackgerritMerged openstack/nova master: remove deprecated os_brick import from ScaleIO driver  https://review.openstack.org/63859218:42
*** dcdawg has quit IRC18:43
efriedaspiers: be easy to fold it into test_report_cpu_traits18:43
*** ivve has quit IRC18:43
aspiersefried: I think it needs to go in test_servers.TraitsTrackingTests18:44
aspiersthat's where all the others are18:44
efriedeither way.18:44
*** sdake has quit IRC18:44
aspiersunfortunately I've gotta go but I'll push the rebase as soon as I've covered this test case18:44
efriedokay.18:45
*** jmlowe has joined #openstack-nova18:47
*** jmlowe has quit IRC18:47
*** sdake has joined #openstack-nova18:47
*** jmlowe has joined #openstack-nova18:48
*** mriedem_away is now known as mriedem18:50
*** sdake has quit IRC18:51
*** IvensZambrano has quit IRC18:51
*** takamatsu has joined #openstack-nova18:52
mriedemefried: jaypipes: +2 on https://review.openstack.org/#/c/639653/ - bottom of the bw series now, adds report client functionality for removing part of allocations from the whole18:54
*** markvoelker has quit IRC18:56
*** sdake has joined #openstack-nova18:56
*** _hemna has quit IRC18:58
*** wolverineav has quit IRC18:59
openstackgerritsean mooney proposed openstack/os-vif master: Add "master" parameter to ip.set() API function  https://review.openstack.org/63970219:06
openstackgerritsean mooney proposed openstack/os-vif master: add addtional check and gate jobs for os-vif  https://review.openstack.org/63973219:06
sean-k-mooneyjaypipes: melwitt ^ should fix the os-vif bug and add new gate jobs that will catch them in the future.19:10
openstackgerritChris Friesen proposed openstack/nova master: Flavor extra spec and image properties validation  https://review.openstack.org/62070619:10
sean-k-mooneywe will need to a do a 1.15.1 release to pick up that change. ill do that after teh ci reports back but i have tested it locally with iptables19:10
efriedmriedem: I can't remember why we decided to use retrying instead of the home-grown @retries in https://review.openstack.org/#/c/556669/, can you?19:11
efriedbecause I'm inclined to push for same in gibi's19:11
mriedemhttps://review.openstack.org/#/c/556669/17/nova/utils.py@130119:12
mriedemi guess that's not what you're looking for19:12
sean-k-mooneyim going to grab dinner and kick off a devstack build of a linux bridge env and validated locally too.19:13
mriedemefried: do you mean, why does SchedulerReportClient use our own retries decorator rather than use retrying the library?19:14
mriedemor the RetryDecorator from oslo?19:14
jaypipesmriedem: ack19:14
mriedemb/c that was added in https://review.openstack.org/#/c/516708/19:14
cfriesenmdbooth: any chance you could take a look at https://review.openstack.org/#/c/616692/ ?19:15
efriedmriedem: Well, report client uses home-grown @retries for a few things and @retrying.retry for others. The latter appear to be my handiwork, as linked above; but I also remember having a conversation with you about the relative merits of using retrying lib vs oslo vs this home-grown thing (which is gross btw).19:15
mriedemi asked https://review.openstack.org/#/c/516708/1/nova/scheduler/client/report.py@9719:15
efriedjaypipes: Don't send that one to the gate too quick. I have a gripe about the retries.19:15
mriedembut no reply19:15
*** wolverineav has joined #openstack-nova19:16
*** wolverineav has quit IRC19:16
*** wolverineav has joined #openstack-nova19:16
efriedmriedem: Mm, yeah. IMO we should get rid of that.19:16
efriedand at least for now stop adding more usages of it.19:16
mriedemlet me phone a friend: dansmith19:17
mriedemi'm assuming he just added his own for simplicity19:17
mriedemand i'm assuming gibi is re-using it because the new code borrows heavily from the claim_resources stuff19:17
dansmithwhat now?19:18
mriedemwhy did you write your own https://review.openstack.org/#/c/516708/1/nova/scheduler/client/report.py@9719:18
mriedembecause now gibi is copying it and efried doesn't like it19:18
dansmithoh gah, I dunno.. because I'm not good at remembering all the crap in libraries19:19
artomefried, aspiers, actually, on that capabilities patch, why are we not also adding the driver-owned CUSTOM_ stuff to os_traits?19:19
artomSeems like it would clear stuff up, at the expense of an extra patch that I image won't be difficult to hack up and merge19:20
jaypipessean-k-mooney: +2 from me on both.19:20
artom*I imagine19:20
jaypipesefried: k19:20
jaypipesmriedem: https://review.openstack.org/#/c/538498/ is showing it needs a rebase anyway.19:21
efriedartom: Anything that's a capability-based trait should indeed go into os-traits. Is that what you're saying?19:21
artomefried, yeah19:21
efriedrandom driver-owned CUSTOM_ stuff notsomuch.19:21
mriedemjaypipes: i didn't ask you about that19:21
artomefried, exactl19:22
artomy19:22
artomIt's a weird message we're sending to admins19:22
efriedjaypipes: that was me. aspiers is working on the rebase (and adding a test case).19:22
artom"The driver owns this stuff, but also this other differently-named stuff that shares a namespace with the stuff you can set"19:22
efriedartom: Well, the namespace is COMPUTE_, not CUSTOM_19:23
jaypipesmriedem: sorry, meant efried :)19:23
efriedCUSTOM_ just means it's not in os-traits (yet)19:23
efriedartom: Where are you seeing a driver capability-based trait that's not in os-traits?19:24
efriedOr are you just concerned about the fact that we're testing that scenario?19:24
artomefried, IMAGECACHE?19:24
*** wolverineav has quit IRC19:24
*** DarthNau has quit IRC19:25
efriedmm. mriedem said "optionally" at https://review.openstack.org/#/c/538498/19/nova/virt/driver.py@143 -- whyzat?19:25
*** jdillaman has joined #openstack-nova19:26
efriedTrying to think of a scenario (heterogeneous levels of nova-compute / os-traits in a cloud, upgrade, something) where we would *need* to support a custom version of a driver capability trait.19:26
mriedemlet me remember something from over a year ago...19:26
efriediow could we just make L1033-5 an exception?19:27
mriedemnot all capabilities would have traits,19:27
mriedemlike has_imagecache19:27
efriedokay, but why does has_imagecache not have a trait?19:27
mriedembut your question is if it's in CAPABILITY_TRAITS_MAP should it also be a standard trait19:27
efriedright19:28
efriedalways19:28
mriedemwe don't schedule based on has_imagecache19:28
efriedthen why are we bothering to add it as a trait?19:28
efriedand, who says we wouldn't schedule based on has_imagecache?19:28
mriedemi am19:28
mriedemi am saying that right now19:29
efriedMaybe I have a flavor that favors nodes with imagecache19:29
*** wolverineav has joined #openstack-nova19:29
mriedemthe day we schedule based on has_imagecache is the day i go work at walgreens19:29
efriedthen wy are we bothering to add it as a trait?19:29
efriedon the compute provider19:29
mriedemyou're talking about L1034 right?19:30
*** betherly has joined #openstack-nova19:30
efriedyes19:30
mriedemgdi, did i write that code?19:30
artomThat should be, like, our motto.19:31
efriedyes, it is present in PS7 (though with normalize_name done manually, tsk)19:31
*** igordc has joined #openstack-nova19:31
efriedas well as the corresponding comment on L102319:32
mriedemlooking at https://review.openstack.org/#/c/538498/7/nova/virt/driver.py19:32
mriedemi was probably doing it because supports_trusted_certs wasn't in os-traits at the time19:32
mriedemand didn't think about how that would generate CUSTOM_HAS_IMAGECACHE19:32
mriedemand i think https://review.openstack.org/#/c/538498/7/nova/virt/driver.py@14519:32
mriedemrelates to something i asked jaypipes when he started adding these to os-traits19:32
mriedemso let me dig that up and i can redirect you to jaypipes19:33
efriedbuck about to be passed19:33
mriedemhttps://review.openstack.org/#/c/546713/19:33
jaypipesdamn19:33
efriedI'm not really concerned about whodunit; what's the right thing here? Should we make it a rule that compute driver capability traits must be standard, and anything that's not will be ignored?19:33
mriedem"I don't seehas_imagecachesupports_recreatesupports_migrate_to_same_host"19:33
mriedem"None of those things are capabilities that a flavor or image would require."19:34
efriedthat conversation sounds familiar19:34
efriedI was apparently convinced enough to +2 the thing.19:34
mriedem"Eric Fried  Mar 29, 2018  Patch Set 1: Code-Review+1Okay, I'm convinced we don't need the missing capabilities as traits.  Thanks for your patience, all."19:34
*** betherly has quit IRC19:34
efriedartom signed off on it too.19:35
efriedso, fine, we decided we didn't need them to be standard, and the reason was because we didn't think they would need to be scheduled to. So the question remains: do we need to put them onto the compute node as traits? (Given ^ they would be CUSTOM_ fo sho)19:35
mriedemi think i would agree that if a compute driver capability is going to be reported as a trait, it should probably be a standard trait19:35
artomefried, yeah, but that's like saying a kid ate some candy ;)19:35
artomAnd in my defense, 'twas me who started this whole kerfuffle we're in now19:36
*** ttsiouts has joined #openstack-nova19:36
efriedyup, so it's only fair that the blame ended up back atcha.19:36
artomBut... was it a *useful* kerfuffle?19:36
mriedemespecially because if we added a new driver capability, like supports_trusted_certs, and before it's standard we report CUSTOM_SUPPORTS_TRUSTED_CERTS and then we have a standard trait and it becomes COMPUTE_TRUSTED_CERTS, that's going to be a weird situation for anyone building flavors requiring the former19:36
artomOr did we just re-hash a past discussion to arrive at the same conclusion?19:37
efriedartom: No, this is a slightly new discussion and a decision that needs to be made.19:37
efriedbut we did have to rehash the old discussion as a prerequisite :)19:37
artom\o/ I'm useful!19:37
mriedemi kind of also wish we weren't discussing the design of this ~1 week from feature freeze19:37
artomSorta19:37
efriedmriedem: Yes, there should be no reason we need to introduce a standard trait but wait to use it in nova.19:37
mriedembecause i'm going to say "sure whatever you want idk anymore"19:37
mriedemand in a year we'll be saying "wtf did we do this?"19:38
efriedjaypipes: Do you agree with mriedem? To paraphrase: If we're going to tag the compute RP with a driver capability trait, it should be a standard trait; and conversely we should not tag the compute RP with a driver capability trait that is not standard; and therefore we should never tag the compute RP with a CUSTOM_* capability trait.19:39
*** lbragstad has quit IRC19:39
jaypipesreading...19:39
efried(note use of 'capability' throughout - obviously the compute RP can get CUSTOM_* traits from elsewhere - admin, update_provider_tree, etc.)19:40
*** lbragstad has joined #openstack-nova19:41
jaypipesefried, mriedem: I feel the same as I did back then. If the thing is a capability of the compute node that an end user could feasibly want to influence scheduling, it should be a standardized os-trait. if it's just an internal implementation of the virt driver that isn't something an end-user would ever care about but is important for the virt driver infrastructure, just make it a simple attribute of the virt driver class.19:42
efriedokay, I'll mark up the review for aspiers19:43
mriedemjaypipes: yeah i agree19:43
mriedemas for why the patch was written how it was when i did a year ago, i can only guess (and already did)19:43
jaypipesin the case of trusted certs, if this is something an end user will say "get me on a host that supports trusted certs", then it should be in os-traits as COMPUTE_TRUSTED_CERTS or whatever.19:43
mriedemi believe it is19:44
jaypipesand it sounds like end users do want that (via a flavor of course) so yeah.19:44
mriedemhttps://github.com/openstack/os-traits/commit/3e0a6ea4f5045e0bdfe5a2e8097a184ba2c93c5a#diff-98123dc3728cad793e21fa497cf0572319:44
mriedemit's not really the end user19:44
mriedemit's not something on a flavor or image19:44
mriedemit's that the user says 'i want you to honor my request' and we send you to some compute that has no f'ing clue what that thing is19:44
mriedemi.e. placement request filters19:45
mriedemsame for multiattach volumes and device tags19:45
jaypipesthat's scheduling though. :)19:45
jaypipesbut yes.19:45
mriedemmy point was just trusted certs are not a flavor/image thing19:46
mriedemyou can't build aggregates around them19:46
jaypipesack19:47
mriedemefried: aspiers: ok documented https://review.openstack.org/#/c/538498/19/nova/virt/driver.py@103419:48
efriedmriedem: nice, race condition, correctly assumed "furiously"19:49
*** spsurya has quit IRC19:52
melwittmriedem, dansmith: thanks for the comments on the InstanceMapping.user_id patch. I just replied to mriedem. dansmith, build request doesn't have a user_id field, and request spec has had the user_id field only since rocky. do you think that's ok to rely on? I had been thinking we have to account for request specs older than rocky, but maybe that doesn't make sense because we're trying to account for old instance mappings that are in19:52
melwitt the middle of being scheduled (and something older than rocky should be still in the middle of being scheduled)19:52
melwitt*shouldn't19:52
*** markvoelker has joined #openstack-nova19:53
dansmithmelwitt: right, it seems only worse to rely on something that has only existed since stein, but I thought it was on reqspec from well before that19:53
dansmitheither way,19:53
melwittit was added to reqspec in rocky19:53
dansmith*all* IMs are missing it now, only some reqspecs are19:53
dansmithokay19:53
melwitthttps://github.com/openstack/nova/commit/6e49019fae80586c4bbb8a7281600cf6140c176a19:53
dansmithjust seems like a joined query would be plenty fast, and then we're not just duplicating this again and again19:54
dansmithonce per instance per db should be enough :D19:54
dansmiththat's two years ago.. is that rocky?19:54
melwittyeah, I thought that would be older but I notice the included in version shows 18.0.019:54
dansmithshould be queens right?19:55
dansmither, actually19:55
dansmithmaybe before that?19:55
melwittmust have taken a long time to merge. queens is 17.0.019:55
dansmithqueens was early '1819:55
melwittit merged may 201819:55
melwitthttps://review.openstack.org/56534019:55
dansmithohh, I see, the 2017 date is the first git date I guess19:56
melwittyeah19:56
dansmithwell, anyway, same argument I think19:56
melwittI'm totally cool with not caring about request specs older than rocky if I got that reassurance19:56
dansmithregardless, you could drop the first two patches and just change how you query for it whenever you do that19:57
dansmithwe could fix up old reqspecs on server GET for that matter19:58
dansmithchange our IM query to be IM joined with reqspec.user_id, and if null, set it to the instance.user_id we get from the cell before returning to the user19:58
dansmiththat would be pretty low overhead I think,19:58
*** _pewp_ has quit IRC19:58
dansmithor just tell people if you want this to be accurate, make sure your migrations are done, just like would have to be the case if we added a new column to IM19:59
*** _pewp_ has joined #openstack-nova19:59
*** ccamacho has quit IRC20:00
melwittmigration for what, request spec? the addition of user_id didn't come with a migration20:00
*** wolverineav has quit IRC20:00
*** wolverineav has joined #openstack-nova20:01
melwittdansmith ^20:02
dansmithmelwitt: but you'd need one for your column, right? and I'm not sure why we don't have one for the reqspec one20:02
melwittoh, you mean me add one20:03
melwittyeah, ok20:03
melwittman, all that work I did to do all the various user_id populations20:03
* melwitt sheds a single tear20:03
dansmithI'm saying just add one migration, for the field we have, which would be enough for all cases, instead of adding it to another place that has to also get patched up20:03
melwittI think I'm following now. thanks20:04
melwittback to the salt mines20:04
*** wwriverrat has joined #openstack-nova20:06
*** wwriverrat has left #openstack-nova20:06
dansmithmelwitt: why do we not already have a migration for user_id on reqspec?20:06
dansmithdid that just get missed maybe?20:06
*** wolverineav has quit IRC20:06
melwittdansmith: I dunno. probably wasn't considered important for already existing records20:06
dansmithany idea why?20:06
melwittno, that's my guess20:07
melwittmriedem: do you happen to know why we didn't do nova-manage data migration for RequestSpec.user_id? https://review.openstack.org/56534020:08
dansmithseems really weird to me20:08
melwittaye20:08
dansmithI think because it's for "out of tree filters" and thus wasn't really done completely20:09
dansmithjust another reason not to further proliferate "I need this duplicate info over here so I'll add it again" kinda stuff20:09
melwittyeah. I was thinking in the box20:10
mriedemmelwitt: was never added - as dansmith said, it was added for an out of tree filter (mgagne) that relied on the user_id and therefore a full-fledged data migration wasn't added for existing request specs because we hack them prior to scheduling during moves20:11
mriedembut any persistence of that request_spec.user_id update is purely accidental20:11
* mriedem reads scrollback20:12
dansmithyeah, that's unfortunate20:12
melwittrequest spec, what's persisted? what isn't? it's a surprise!20:12
mriedemhttps://github.com/openstack/nova/commit/6e49019fae80586c4bbb8a7281600cf6140c176a is queens btw20:12
dansmithmelwitt: right, let's migrate to make it consistent and remove this point of ambiguity for the future :)20:13
mriedemoh shit i guess that was rocky20:13
mriedemi thought it was older20:13
melwittYEAH told ya20:13
melwittit was started way before rocky though20:14
melwittmaybe not way before, but in queens20:14
*** gbarros has joined #openstack-nova20:14
*** Sundar has joined #openstack-nova20:15
mriedemwe don't have a db migration for requestspec.user_id b/c it's a json blob20:17
mriedemoh having said that...20:17
melwittwait what? json blob20:17
mriedemyou can't join on a blob20:17
dansmithwait it's not a column?20:17
mriedemnope20:18
mriedemha20:18
mriedemman, all that work I did to do all the various user_id populations20:18
mriedemoops20:18
mriedemspec = Column(MediumText(), nullable=False)20:18
mriedemeverything in request spec is json blob20:18
mriedemso you can't filter on a join20:18
mriedemwahwah20:18
dansmithisn't project_id a column on reqspec?20:18
mriedemhell no20:18
mriedemhttps://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api_models.py#L16420:19
dansmithugh, okay, nevermind then20:20
mriedemsalt mines averted20:20
dansmithso, if we keep that,20:20
dansmithI'm not sure why we're patching it up in all these places, vs. just on create and doing a migration like normal20:20
melwittI was thinking to be opportunistic but maybe I went overboard20:20
dansmithit's just a lot harder to reason about correctness20:21
melwittwe do need one for a soft-deleted instance restore at least. but maybe none of the others20:21
melwittoh wait, no20:21
mriedemi don't think we need the conductor ones20:21
mriedemin https://review.openstack.org/#/c/638574/320:21
melwittsince I added soft-deleted instances to the migration20:21
mriedemwe want the one on GET /servers/{server_id}20:21
dansmithif we do it opportunitstically, just do it on load, not in 100 places, IMHO20:22
dansmithmriedem: right20:22
mriedemi can't speak for the soft deleted restore thing20:22
melwittok, thanks. I pre-emptive optimizationed myself :(20:22
openstackgerritEric Fried proposed openstack/nova master: Better handle live migration abort  https://review.openstack.org/63544020:23
mriedemif someone is building servers between the time the scheduler/conductor is new and the api is old, and they miss that race, the data migration can handle it20:23
melwittno, I think we don't need the soft deleted restore anymore because I included soft deleted in the nova-manage migration. since they could be restored theoretically any time in the future20:23
*** cdent has quit IRC20:24
*** gbarros has quit IRC20:24
mriedemso handle create and GET and that's good enough20:24
mriedemdata migration takes care of the rest20:24
melwittok, I'll clean that up. thanks20:24
*** markvoelker has quit IRC20:26
*** hemna has quit IRC20:28
*** hemna has joined #openstack-nova20:29
*** jmlowe has quit IRC20:29
melwittthat was an emotional roller coaster20:30
openstackgerritMerged openstack/nova master: Fix the api sample docs for microversion 2.68  https://review.openstack.org/63970720:31
*** wolverineav has joined #openstack-nova20:35
*** eharney has quit IRC20:36
*** tosky has quit IRC20:36
*** dcdawg has joined #openstack-nova20:38
*** dave-mccowan has quit IRC20:38
*** wolverineav has quit IRC20:40
*** wolverineav has joined #openstack-nova20:41
*** wolverineav has quit IRC20:41
*** wolverineav has joined #openstack-nova20:41
*** dcdawg has quit IRC20:42
*** betherly has joined #openstack-nova20:43
*** dave-mccowan has joined #openstack-nova20:44
openstackgerritEric Fried proposed openstack/nova master: WIP: Privatize SchedulerReportClient HTTP wrappers  https://review.openstack.org/63981820:45
efriedmelwitt: FYI as discussed earlier ^20:45
*** wolverineav has quit IRC20:45
*** betherly has quit IRC20:48
*** mikal has joined #openstack-nova20:49
melwittefried: ack21:00
*** redcavalier has joined #openstack-nova21:03
*** ivve has joined #openstack-nova21:03
*** redcavalier has left #openstack-nova21:03
mriedemmelwitt: ok i've gone a few more patches up in your series21:03
mriedemto the point of the wip and stopped there21:03
melwittmriedem: been reading through the comments. thanks. indeed I was trying to account for a scenario like, "what if they run nova-manage in the middle of the upgrade but not at the end, how to catch the stragglers". but I realize I might be suffering from not knowing something like, nova-manage is always run once at the end of the upgrade too21:05
mriedemyou run it until there are no more to process21:05
mriedemand then when we drop the compat code,21:05
mriedemwe put in a blocker migration21:06
mriedemthere is no defined time that operators have to run online_data_migrations, they can run it whenever21:06
*** mmethot has quit IRC21:06
melwittwell, if it's run in the middle of the upgrade and run at the exact wrong time, it would come back as "all done" because of the not-yet-scheduled old instance mappings, if there are any21:06
mriedemit should be idempotent, save for the ones that create a marker21:06
melwittyeah, that's what I had thought, no defined time or way to run online_data_migrations21:07
mriedembut then your counting quota code is going to catch that and do the legacy counting method right?21:07
openstackgerritMichael Still proposed openstack/nova master: Cleanup no longer required filters and add a release note.  https://review.openstack.org/63982621:07
mriedemand presumably log something if they haven't opted out of counting from placement b/c of edge or something?21:08
melwittyes21:08
mriedemso i don't think we need to be super paranoid about it21:08
mriedemand we'll add a blocker schema migration before dropping the compat code21:08
melwittok, I see. that's helpful21:08
mriedemi.e. you can't upgrade to U if you haven't done your homework21:08
melwittright21:08
mriedemof course i'd like dansmith to check my work her21:08
mriedem*her21:08
mriedemdi21:08
*** jaosorior has quit IRC21:08
mriedemhere21:08
mriedemalso,21:09
dansmithI refuse to touch your her21:09
mriedemthe GET /servers/{server_id} should catch any that miss that very tight winow21:09
mriedem*window21:09
mriedemb/c the client is going to be polling the API for the server to be ACTIVE21:09
mriedemyeah?21:09
melwittyeah, I guess, another thought is if I re-worked the online_data_migrations to go the other direction, from instance mappings => cells (which was the original proposal)21:10
dansmithI definitely think the less-complicated and more usual migration and update-on-read approach is good21:10
melwittbut looking at the queued_for_delete migration made me think maybe it would be too inefficient to go the other direction21:10
melwittthe reason it can come back as "all done" is about I made it iterate cells and migrate that way21:11
mriedemhmm21:11
melwitt*when there are instance in-flight being scheduled21:11
mriedemso if i'm cern and i've got 72 cells and running this in batches,21:11
mriedemit's going to query instance mappings from the same cells every time until it find something new to process right?21:11
mriedeme.g. we've migrated everything for cells 1-5021:12
dansmithare you talking about how to migrate the mappings in a migration?21:12
mriedemto start processing cells after 50, we have to check 1-50 all over again21:12
mriedemhttps://review.openstack.org/#/c/633351/14/nova/objects/instance_mapping.py@24321:12
dansmithyou process the records by which mappings have a null user_id21:13
dansmithyou collate those by cell, and do them in batches against the cell21:13
dansmithyou don't re-process anything because you've set the value to non-null once it's done21:13
melwittyeah, I did it similar to queued_for_delete, it gets instance mappings that have instances in cells21:13
mriedemi don't tihnk that's what this is doing21:13
dansmithI'm describing what it *should* do21:14
*** ivve has quit IRC21:14
melwittbut it will miss instance mappings that don't yet have an instance in a cell (I think)21:14
dansmiththe current implementation will you mean21:14
melwittyeah21:14
dansmithsure, but iterating by cell makes no sense anyway, IMHO21:15
mriedemwell it's based on populate_queued_for_delete which dansmith wrote so i hope it's correct :)21:15
melwittok :( I will redo it21:15
mriedemwell i guess have dansmith look at https://review.openstack.org/#/c/633351/14/nova/objects/instance_mapping.py and make sure we're on the same page21:16
*** jmlowe has joined #openstack-nova21:17
dansmithI probably did the qfd one by cell because you had to get a list of instances not deleted per cell21:17
dansmithor rather, if you don't find an instance deleted per cell, then you mark all of those mappings as not deleted21:18
dansmithbut you don't need to do that in this case.. you want to batch/collate by cell, but you can do that with a single query I think in the other case21:18
dansmithneither the user_id or qfd ones probably need to care about things in-flight that don't have that set,21:20
dansmithsince you have to run this after you've upgraded your controller code, so things in flight there would already be setting the new value21:21
dansmithmeaing, things that don't have a cell yet21:21
*** markvoelker has joined #openstack-nova21:23
melwittright21:25
*** betherly has joined #openstack-nova21:25
melwittoh, hm ok. I misread at first21:26
melwitthave to run this after upgraded controller code, so things in flight there would already be setting user_id21:26
*** wolverineav has joined #openstack-nova21:27
*** awaugama has quit IRC21:27
dansmithright you have to have upgraded the code that can handle the new format for a thing before you start running migrations to move them into the new format of course21:28
openstackgerritMatt Riedemann proposed openstack/nova master: Optimize populate_queued_for_delete online data migration  https://review.openstack.org/63984021:28
melwittwhat about old controller, in-flight, upgrade controller, run online_data_migrations, doesn't that fall through the cracks?21:28
mriedemwhile we're talking about this ^21:28
mriedemmelwitt: if we hit that, the GET /servers/{server_id} would migrate the mapping21:29
melwittok21:29
*** wolverineav has quit IRC21:30
*** wolverineav has joined #openstack-nova21:30
*** betherly has quit IRC21:30
melwittok, will take another stab at this21:30
mriedemthis, or something21:31
mriedemsomething is getting stabbed21:31
openstackgerritsean mooney proposed openstack/os-vif master: add additional check and gate jobs for os-vif  https://review.openstack.org/63973221:31
dansmithmelwitt: for the qfd you mean? I guess maybe, but it would still be cleared once you delete that21:31
dansmithmelwitt: for user_id if you process by mapping and not by cell, then it doesn't matter21:31
melwittno, for user_id21:32
melwittwhen you said "user_id doesn't need to care about things in-flight that don't have it set"21:32
*** Sundar has quit IRC21:33
dansmithmelwitt: I'm confused if or what you're asking21:34
melwittdansmith: but I think I get it now that if we process by mapping, it will catch them21:34
dansmithright21:34
dansmithI said21:35
melwittI was just thinking if we go by cell then we would miss something in a super specific timed case21:35
dansmith"probably don't need to care" meaning that leaking things in flight probably isn't as big of a deal.. but not saying we should ignore them or not try to get them21:35
dansmithsure21:35
melwittoh, I see. got it21:35
openstackgerritMatt Riedemann proposed openstack/python-novaclient master: Add support for microversion 2.70 - expose device tags  https://review.openstack.org/63677921:37
sean-k-mooneyjaypipes: o/ i fixed yup the typos in https://review.openstack.org/#/c/639732/6 care to +2 +w again?21:38
*** mmethot has joined #openstack-nova21:42
*** wolverineav has quit IRC21:45
*** wolverineav has joined #openstack-nova21:45
mriedemmordred: i think you'll enjoy this https://bugs.launchpad.net/nova/+bug/181796321:45
openstackLaunchpad bug 1817963 in OpenStack Compute (nova) "API reference tells users to not create servers with availability_zone "nova" but the server create samples use "nova" for the AZ :(" [Medium,Triaged] - Assigned to Matt Riedemann (mriedem)21:45
*** eharney has joined #openstack-nova21:47
melwittextra points for the sad face21:48
mriedem"don't do this"21:48
mriedem"here is an example of how to create a server, with exactly what not to do"21:48
mriedem"you're welcome"21:48
melwittgo us21:49
* artom is amused by his own migate typo21:51
artomLike something out of Zoolander21:51
artomBruce Migate21:52
melwittmigrations that run good and do other stuff good too21:53
*** markvoelker has quit IRC21:56
artomWhat is this, a server for ants?21:57
*** mchlumsky has quit IRC21:59
jaypipessean-k-mooney: done22:00
efriedHowdy folks. How, in the ServersTestBase harness, does one go from a server dict to an Instance object?22:06
cfriesenis anyone aware of weirdness with accessing image_meta in the resize code path in devstack?22:06
artomcfriesen, weirdness? It's a method disguised as a property, but other than that...22:07
artomSo, you can't actually set it, IIRC22:07
*** betherly has joined #openstack-nova22:08
cfriesenartom: I'm not seeing entries that I think should be in there.22:08
cfriesenartom: they're in the instance_system_metadata table in the DB22:08
*** derekh has quit IRC22:09
artomcfriesen, lazy-loading?22:09
artomGuessing, mostly22:09
openstackgerritEric Fried proposed openstack/nova master: Test proper allocation of devices during reshape  https://review.openstack.org/63985422:09
*** betherly has quit IRC22:12
efriedmriedem, jaypipes: I think vgpu reshape is ready to go https://review.openstack.org/#/c/636591/22:13
melwittefried: AFAIK, I don't think doing that is a thing. why do you want to do it?22:14
efriedmelwitt: just because there's a libvirt method I want to call that expects Instance. See https://review.openstack.org/63985422:14
melwittoh, I see. I haven't seen a test like that before22:15
melwittmriedem is probably your best bet for an idea22:16
*** agopi has quit IRC22:16
mriedemcfriesen: that's because image meta is stored in instance_system_metadata22:17
mriedemcfriesen: hence https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L12622:17
mordredmriedem: wow, yea. that's awesome22:19
mriedemefried: commented22:19
cfriesenmriedem: _get_guest_config() is called with "image_meta" as an arg, but image_meta.properties.get('traits_required') returns nothing22:19
mriedemon your test that is22:19
mordredmriedem: have we ever fixed documentation suggesting people not use "RegionOne" as the region names for their clouds?22:20
melwittheh, well that was easy22:20
mriedemmordred: not familiar22:20
efriedthanks mriedem22:20
cfriesenmriedem: I see "image_trait:COMPUTE_SECURITY_TPM_1_2" in table instance_system_metadata though22:20
mordredmriedem: and here I thought you knew everything22:20
*** agopi has joined #openstack-nova22:20
mriedemmordred: i'm selfish and only care about compute api docs22:21
mriedemheh lots o todos here https://developer.openstack.org/api-guide/compute/users.html22:21
mriedemcfriesen: _get_guest_config() called with image_meta from where? the API?22:22
artomDo you think egotistical lobsters are shellfish?22:22
mriedemif only the guy that added all the required image traits stuff was still around...22:23
cfriesenmriedem: this is in the context of LibvirtDriver.finish_migration().   I'm wondering if we're not properly passing in image_meta at all.22:23
mriedemcfriesen: "image_trait" isn't the right prefix silly pants22:24
mriedemhttps://docs.openstack.org/glance/latest/admin/useful-image-properties.html22:24
mriedemtrait:HW_CPU_X86_AVX2=required22:24
mriedemif only the code were freely available... :)22:25
openstackgerritArtom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration  https://review.openstack.org/63460522:25
openstackgerritArtom Lifshitz proposed openstack/nova master: Make the use of the CastAsCall fixture configurable  https://review.openstack.org/63942822:25
openstackgerritArtom Lifshitz proposed openstack/nova master: Full NUMA live migration support  https://review.openstack.org/63460622:25
mordredartom: wow22:25
cfriesenmriedem: the image itself has "trait:...."22:25
mriedemoh b/c we slap on the image_ prefix before storing in system_metadata22:25
mriedemnow it comes back to me22:25
cfriesenmriedem: but it in instance_system_metadata it prepends "image_" to it22:25
mriedemis the value "required"22:25
mriedem?22:25
cfriesenmriedem: yes22:25
cfriesenI'm working my way up the stack trying to figure out where it got lost22:26
mriedemwell instance.image_meta -> ImageMeta.from_instance -> instance.system_metadata for all image_ keys22:26
mriedemand it strips the image_ prefix22:26
artommordred?22:26
cfriesenthere's an "image_meta" argument that's passed down the call chain22:26
sean-k-mooneythere is also image meta in the instance and the request spec22:27
sean-k-mooneywe have several copies of it depended on where you are22:27
cfriesenhmm...ComputeManager._finish_resize_helper() does this:   image_meta = objects.ImageMeta.from_dict(image)22:29
mordredartom: "Do you think egotistical lobsters are shellfish?" :)22:30
*** agopi has quit IRC22:31
*** sdake has quit IRC22:36
*** dcdawg has joined #openstack-nova22:38
*** dcdawg has quit IRC22:43
cfriesenmriedem: it looks like the culprit is that call in _finish_resize_helper().   image.properties has "traits_required", but image_meta.properties doesn't.22:46
mriedemcfriesen: i think i know why22:48
mriedemhttps://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L29622:48
mriedemresize gets the RequestSpec.image rather than Instance.image_meta22:49
mriedemwhich might not have the fancy translation of ImageMeta.properties.traits_required22:49
cfriesenokay, but in _finish_resize_helper() the "image" argument seems to have a valid image.properties22:50
cfriesenthe call to  objects.ImageMeta.from_dict(image) seems to be corrupting the image properties22:50
cfriesendropping the "traits_required"22:51
cfriesenlooks like "traits_required" has some special-casing in objects/image_meta.py22:52
cfriesenwonder if something is messed up22:52
*** sdake has joined #openstack-nova22:53
*** mmethot has quit IRC22:57
openstackgerritMerged openstack/os-vif master: Add "master" parameter to ip.set() API function  https://review.openstack.org/63970222:58
*** tkajinam has joined #openstack-nova23:00
melwittzzzeek: I recently learned func.sum will return a Decimal object (https://review.openstack.org/639216) but I can't find where in the documentation I can learn what type will be returned from various func. can you point me to a doc I missed?23:04
*** rcernin has joined #openstack-nova23:06
*** sapd1 has joined #openstack-nova23:06
cfriesenmriedem: I think I see what's wrong.  In _finish_resize_helper() the "image" argument looks like this, with "traits_required" already broken out: http://paste.openstack.org/show/746468/23:08
cfriesenmriedem: but in ImageMetaProps.from_dict() it ignores "traits_required" and tries to build it up from the original "trait:xxxxxx" image property, which isn't there.23:09
openstackgerritEric Fried proposed openstack/nova master: Test proper allocation of devices during reshape  https://review.openstack.org/63985423:09
sean-k-mooneycfriesen: the image metadata key never contains a ":"23:11
cfriesensean-k-mooney: yes it does, for traits23:11
mriedembecause it was already transformed and stored in system_metadata23:11
sean-k-mooneycfriesen: nova uses namesapce:key=value23:12
sean-k-mooneycfriesen: are you sure23:12
mriedemImageMetaProps.from_dict() is expecting the trait:COMPUTE_SECURITY_TPM_1_2=required format23:12
sean-k-mooneyi dont think its ment to be supproted23:12
mriedemwhich in the api it parses to ImageMetaProps.traits_required right?23:12
sean-k-mooneyoh ok ignore me then23:12
mriedemand then that is stored in system_metadata23:12
cfriesensean-k-mooney: https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/glance-image-traits.html23:12
cfriesenmriedem: yep23:12
mriedemand then ImageMetaProps.from_dict from system_metadata image properties only has the "traits_required" entry23:12
mriedembut not the original trait:COMPUTE_SECURITY_TPM_1_2=required23:12
mriedemcfriesen: should be pretty easy to write a test to show the loss during conversion23:13
*** moshele has joined #openstack-nova23:13
sean-k-mooney cfriesen that was proably an oversigt in the spec...23:13
mriedemhasn't been an issue yet because no one has used image traits beyond scheduling yet23:13
cfriesenmriedem: seems likely23:14
openstackgerritEric Fried proposed openstack/nova master: Test proper allocation of devices during reshape  https://review.openstack.org/63985423:14
*** dave-mccowan has quit IRC23:14
sean-k-mooneycfriesen: looking at https://github.com/openstack/nova/blob/f7252b586b4b9f5a098fedfa27715b8f7e662af6/nova/notifications/objects/image.py#L18423:15
sean-k-mooneyit looks like its expecting traits_required23:15
*** mlavalle has quit IRC23:15
sean-k-mooneyboth the schema and field follow the normal convetion and use _23:16
sean-k-mooneyhttps://github.com/openstack/nova/blob/f7252b586b4b9f5a098fedfa27715b8f7e662af6/nova/notifications/objects/image.py#L25323:16
mriedemthose are the notification objects...23:17
cfriesensean-k-mooney: https://github.com/openstack/nova/blob/f7252b586b4b9f5a098fedfa27715b8f7e662af6/nova/objects/image_meta.py#L566 seems to explicitly ignore "traits_required"23:17
*** dave-mccowan has joined #openstack-nova23:20
sean-k-mooney hum ok that is stil rather confusing but ok23:21
openstackgerritArtom Lifshitz proposed openstack/nova master: Introduce live_migration_claim()  https://review.openstack.org/63566923:21
openstackgerritArtom Lifshitz proposed openstack/nova master: New objects for NUMA live migration  https://review.openstack.org/63482723:21
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source  https://review.openstack.org/63482823:21
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source  https://review.openstack.org/63522923:21
openstackgerritArtom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration  https://review.openstack.org/63460523:21
openstackgerritArtom Lifshitz proposed openstack/nova master: NUMA live migration support  https://review.openstack.org/63460623:21
mriedemcfriesen: i think that's in the case when the ImageMetaProps is built from the base image meta in the API23:22
mriedemnot the already-transferred form from system_metadata23:22
mriedemi think it's meant to avoid setting ImageMetaProps.traits_required if the external image literally has a "traits_required" field23:22
cfriesenI'm checking whether I can use instance.image_meta for nwo23:23
mriedemremoving that line probably fixes your problem23:23
cfriesenlooks like down in the guts of resize I can use instance.image_meta.properties.get('traits_required') and it works as expected23:25
mriedemew23:25
cfriesenI think sorting out ImageMetaProps can be a separate issue23:25
mriedemsmells down there in the guts23:25
*** itlinux has joined #openstack-nova23:26
cfriesen"instance" is already one of the args23:26
sean-k-mooneycfriesen: i would hope it would be for a resize23:26
*** betherly has joined #openstack-nova23:32
*** ttsiouts has quit IRC23:32
sean-k-mooneycfriesen: one question in https://review.openstack.org/#/c/633256/423:35
sean-k-mooneyill try to get to https://review.openstack.org/#/c/631363/9 tommorrow23:35
*** harlowja has joined #openstack-nova23:36
cfriesensean-k-mooney: cool.  I've almost got single-node resize working.  would appreciate a test of multinode resize/migrate if you've got time.23:36
*** betherly has quit IRC23:37
*** sdake has quit IRC23:38
sean-k-mooneydo i need to install anyting non standard beyond having new enough qemu/libvirt23:38
cfriesensean-k-mooney: "swtpm" and "swtpm-tools" packages on fedora23:38
sean-k-mooneyok cool ill proably use my centos test vms but i can spin up a fedora one if it does not have the package23:39
cfriesensean-k-mooney: you're thinking about allowing the flavor to explicitly forbid enabling vTPM?  not sure why anyone would want to do that since it's purely a virtual thing.23:40
sean-k-mooneyif i have issue with nested virt i also have pysical servers i can test with too23:40
sean-k-mooneycfriesen: it is but an operator may want to forbid it for live migration reasons23:40
cfriesensean-k-mooney: but we're going to make it support live migration, no?23:41
sean-k-mooneyyes but they may have old hyperviors23:41
*** sdake has joined #openstack-nova23:41
sean-k-mooneyi guess they would have upgraded to stien anyway so its proably not important23:41
cfriesensean-k-mooney: then the dest won't advertise the trait23:42
*** sdake has quit IRC23:42
sean-k-mooneyya ok it shoudl be good23:42
sean-k-mooneythere some traits that operator may  want ot forbid in the falvor expclitly but this likel is not one of them23:42
*** moshele has quit IRC23:43
*** awalende has joined #openstack-nova23:43
*** awalende has quit IRC23:47

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