Thursday, 2018-02-15

*** Guest10778 has quit IRC00:00
mriedemmelwitt: this is what i wanted the retrospective link for http://lists.openstack.org/pipermail/openstack-dev/2018-February/127402.html00:02
*** acormier has quit IRC00:02
melwittmriedem: a-ha, nice. I was just looking for that email to link in the agenda for tomorrow's meeting00:02
*** Guest10778 has joined #openstack-nova00:04
*** acormier has joined #openstack-nova00:05
*** jobewan has quit IRC00:06
mnaserhere goes nothing :>00:06
*** hshiina|afk is now known as hshiina00:08
openstackgerritMohammed Naser proposed openstack/nova master: Drop extra loop which modifies Cinder volume status  https://review.openstack.org/53975800:08
openstackgerritMohammed Naser proposed openstack/nova master: Clean up ports and volumes when deleting ERROR instance  https://review.openstack.org/34061400:08
openstackgerritMohammed Naser proposed openstack/nova master: Add functional tests to ensure BDM removal on delete  https://review.openstack.org/54474700:08
openstackgerritMohammed Naser proposed openstack/nova master: Store block device mappings in cell0  https://review.openstack.org/54474800:08
*** sdague has quit IRC00:09
mnaseri guess at some point we'll have to squash the func. tests and clean up commit to get them to merge00:14
melwittmriedem: just updated the agenda for tomorrow's meeting https://wiki.openstack.org/wiki/Meetings/Nova00:15
mriedemmnaser: what we usually do,00:15
mriedemis land the regression test that asserts the failre,00:16
melwittmnaser: why? the way we do that is the func test is introduced with the after-bug-fix asserts commented out with a note (and I'll let mriedem finish)00:16
mriedemthen the patch that fixes it changes the functional test to show it's passing00:16
mnaserok i see so then my functional test is wrong00:17
mnaserbecause it is a failing one (which will pass in the patch above of it)00:17
*** acormier has quit IRC00:17
*** acormier has joined #openstack-nova00:18
mnaserso i will switch the best to make it assert the failure and then change the fixing patch as explained00:18
melwittmnaser: that's nearly there, just have to comment out the failing assert and add TODO(mnaser) above it to explain it should be uncommented in the same patch as the fix, then add an assert for the wrong (but expected) thing with a TODO to remove it in the fix patch00:19
*** rmcall has joined #openstack-nova00:20
*** rmcall has quit IRC00:20
*** jdurgin has joined #openstack-nova00:23
openstackgerritMohammed Naser proposed openstack/nova master: Store block device mappings in cell0  https://review.openstack.org/54474800:26
openstackgerritMohammed Naser proposed openstack/nova master: Add functional tests to ensure BDM removal on delete  https://review.openstack.org/54474700:26
openstackgerritMohammed Naser proposed openstack/nova master: Clean up ports and volumes when deleting ERROR instance  https://review.openstack.org/34061400:26
mnaserthat should do it00:26
openstackgerritMohammed Naser proposed openstack/nova master: Drop extra loop which modifies Cinder volume status  https://review.openstack.org/53975800:27
openstackgerritMohammed Naser proposed openstack/nova master: Store block device mappings in cell0  https://review.openstack.org/54474800:27
openstackgerritMohammed Naser proposed openstack/nova master: Add functional tests to ensure BDM removal on delete  https://review.openstack.org/54474700:27
openstackgerritMohammed Naser proposed openstack/nova master: Clean up ports and volumes when deleting ERROR instance  https://review.openstack.org/34061400:27
*** chyka has quit IRC00:35
openstackgerritTetsuro Nakamura proposed openstack/nova-specs master: Enable NUMA Features for Libvirt/QEMU Driver  https://review.openstack.org/53307700:36
*** tetsuro has joined #openstack-nova00:37
*** s1061123_ has quit IRC00:39
mriedemmnaser: melwitt: ok i've gone through the first 3, left some nits but nothing major00:39
mriedemi can get the final big patch in the morning00:40
melwittthanks00:42
mnasermriedem: thanks, im addressing them now and rebasing00:43
*** s1061123 has joined #openstack-nova00:43
*** moshele has joined #openstack-nova00:47
*** mriedem has quit IRC00:50
*** acormier has quit IRC00:50
tonybmelwitt: It is indeed confusing.  The "next pahse" shoudl just go strainght to EOL but there is a window in there where it's in Phase III while we do the EOLing ... and then we went and confused ourselves with the Long lived stable branches so I don't know what'll happen00:53
tonybmelwitt: but there's a session at the PTG to discuss it so hopefully shortly after that I can at least make that table look more sane00:54
*** dave-mccowan has joined #openstack-nova00:54
melwitttonyb: thanks for the glimpse at what it means :)00:54
tonybmelwitt: ;P I guess you have to care more about that stuff now:)00:55
melwittnah, total coincidence00:55
tonybmelwitt: anytime I can help you know where I am00:55
melwitt:) thanks00:55
tonybmelwitt: ohh my bad ;P00:55
melwittheh00:56
*** r-daneel has quit IRC00:56
*** acormier has joined #openstack-nova01:08
openstackgerritMohammed Naser proposed openstack/nova master: Store block device mappings in cell0  https://review.openstack.org/54474801:09
openstackgerritMohammed Naser proposed openstack/nova master: Add functional tests to ensure BDM removal on delete  https://review.openstack.org/54474701:09
openstackgerritMohammed Naser proposed openstack/nova master: Clean up ports and volumes when deleting ERROR instance  https://review.openstack.org/34061401:09
mnaseraddressed all comments ^01:10
*** acormier has quit IRC01:12
*** acormier has joined #openstack-nova01:13
*** suresh12 has quit IRC01:14
*** acormier has quit IRC01:20
*** Guest10778 has quit IRC01:26
*** yassine has joined #openstack-nova01:27
*** acormier has joined #openstack-nova01:27
*** yassine is now known as Guest4878201:27
*** jdurgin has quit IRC01:30
*** acormier has quit IRC01:30
*** acormier has joined #openstack-nova01:30
*** moshele has quit IRC01:40
*** lbragstad has quit IRC01:45
openstackgerritMohammed Naser proposed openstack/nova master: Store block device mappings in cell0  https://review.openstack.org/54474801:46
openstackgerritMohammed Naser proposed openstack/nova master: Add functional tests to ensure BDM removal on delete  https://review.openstack.org/54474701:46
openstackgerritMohammed Naser proposed openstack/nova master: Clean up ports and volumes when deleting ERROR instance  https://review.openstack.org/34061401:46
mnaser..broke some functional tests and fixed them..01:46
*** itlinux has joined #openstack-nova01:47
*** jdurgin has joined #openstack-nova01:53
*** chyka has joined #openstack-nova01:57
*** jdurgin has quit IRC01:57
*** suresh12 has joined #openstack-nova01:58
*** yamahata has quit IRC02:01
*** chyka has quit IRC02:01
openstackgerritmelanie witt proposed openstack/nova master: Add periodic task to clean expired console tokens  https://review.openstack.org/32538102:04
openstackgerritmelanie witt proposed openstack/nova master: Use ConsoleAuthToken object to generate authorizations  https://review.openstack.org/32541402:04
openstackgerritmelanie witt proposed openstack/nova master: Convert websocketproxy to use db for token validation  https://review.openstack.org/33399002:04
*** hiro-kobayashi has joined #openstack-nova02:06
*** tbachman has quit IRC02:12
*** slaweq has joined #openstack-nova02:13
*** acormier has quit IRC02:15
*** slaweq has quit IRC02:18
openstackgerritTetsuro Nakamura proposed openstack/nova master: [libvirt] Add _get_vcpu_realtime_scheduler()  https://review.openstack.org/52763002:18
openstackgerritTetsuro Nakamura proposed openstack/nova master: [libvirt] Add _get_numa_memnode()  https://review.openstack.org/52990602:18
openstackgerritTetsuro Nakamura proposed openstack/nova master: [libvirt] Add _get_XXXpin_cpuset()  https://review.openstack.org/52763102:18
openstackgerritTetsuro Nakamura proposed openstack/nova master: Add NumaTopology support for libvirt/qemu driver  https://review.openstack.org/53045102:18
openstackgerritTetsuro Nakamura proposed openstack/nova master: disable cpu pinning with libvirt/qemu driver  https://review.openstack.org/53104902:18
*** acormier has joined #openstack-nova02:35
*** slaweq has joined #openstack-nova02:36
*** slaweq has quit IRC02:39
*** salv-orlando has joined #openstack-nova02:44
*** suresh12 has quit IRC02:44
*** suresh12 has joined #openstack-nova02:46
*** acormier has quit IRC02:47
*** salv-orl_ has quit IRC02:47
*** acormier has joined #openstack-nova02:47
*** bhujay has joined #openstack-nova02:50
*** suresh12 has quit IRC02:51
*** acormier has quit IRC02:51
*** harlowja has quit IRC03:08
*** bhujay has quit IRC03:09
*** chyka has joined #openstack-nova03:12
*** chyka has quit IRC03:17
*** yamahata has joined #openstack-nova03:17
*** suresh12 has joined #openstack-nova03:21
*** amodi has joined #openstack-nova03:22
*** suresh12 has quit IRC03:26
*** amodi has quit IRC03:29
*** hongbin has joined #openstack-nova03:34
*** itlinux has quit IRC03:37
*** yamamoto has joined #openstack-nova03:47
*** yamamoto has quit IRC03:47
*** yamamoto has joined #openstack-nova03:51
openstackgerritHironori Shiina proposed openstack/nova master: ironic: Clean up resources after unprovision fails  https://review.openstack.org/54477203:54
*** bkopilov has quit IRC04:00
*** itlinux has joined #openstack-nova04:01
*** bkopilov has joined #openstack-nova04:03
*** bhujay has joined #openstack-nova04:08
openstackgerritMerged openstack/nova master: Fix nits in allocation candidate limit handling  https://review.openstack.org/53678404:13
*** jogo has quit IRC04:13
*** udesale has joined #openstack-nova04:13
*** gyee has quit IRC04:14
*** itlinux has quit IRC04:17
*** elod has quit IRC04:18
*** dave-mccowan has quit IRC04:25
*** psachin has joined #openstack-nova04:27
*** masber has joined #openstack-nova04:33
*** links has joined #openstack-nova04:34
*** elod has joined #openstack-nova04:35
*** vladikr has quit IRC04:37
*** lpetrut has joined #openstack-nova04:39
*** vladikr has joined #openstack-nova04:40
*** abhishekk has joined #openstack-nova04:41
*** links has quit IRC04:42
*** hongbin has quit IRC04:43
*** links has joined #openstack-nova04:45
*** r-daneel has joined #openstack-nova04:57
*** janki has joined #openstack-nova04:57
*** janki has quit IRC05:03
*** janki has joined #openstack-nova05:03
*** janki has quit IRC05:06
*** janki has joined #openstack-nova05:06
*** lpetrut has quit IRC05:08
*** janki has quit IRC05:08
*** janki has joined #openstack-nova05:09
*** threestrands_ has joined #openstack-nova05:09
*** janki has quit IRC05:09
*** threestrands_ has quit IRC05:09
*** threestrands_ has joined #openstack-nova05:09
*** threestrands has quit IRC05:09
*** jogo has joined #openstack-nova05:10
openstackgerritTetsuro Nakamura proposed openstack/nova master: [libvirt] Add _get_XXXpin_cpuset()  https://review.openstack.org/52763105:10
openstackgerritTetsuro Nakamura proposed openstack/nova master: Add NumaTopology support for libvirt/qemu driver  https://review.openstack.org/53045105:10
openstackgerritTetsuro Nakamura proposed openstack/nova master: disable cpu pinning with libvirt/qemu driver  https://review.openstack.org/53104905:10
*** janki has joined #openstack-nova05:10
*** threestrands_ has quit IRC05:10
*** threestrands_ has joined #openstack-nova05:11
*** threestrands_ has quit IRC05:11
*** threestrands_ has joined #openstack-nova05:11
*** harlowja has joined #openstack-nova05:15
*** threestrands has joined #openstack-nova05:15
*** threestrands has quit IRC05:15
*** threestrands has joined #openstack-nova05:15
*** sree has joined #openstack-nova05:15
openstackgerritTetsuro Nakamura proposed openstack/nova master: [libvirt] Add _get_vcpu_realtime_scheduler()  https://review.openstack.org/52763005:17
openstackgerritTetsuro Nakamura proposed openstack/nova master: [libvirt] Add _get_numa_memnode()  https://review.openstack.org/52990605:17
openstackgerritTetsuro Nakamura proposed openstack/nova master: [libvirt] Add _get_XXXpin_cpuset()  https://review.openstack.org/52763105:17
openstackgerritTetsuro Nakamura proposed openstack/nova master: Add NumaTopology support for libvirt/qemu driver  https://review.openstack.org/53045105:17
openstackgerritTetsuro Nakamura proposed openstack/nova master: disable cpu pinning with libvirt/qemu driver  https://review.openstack.org/53104905:17
*** threestrands_ has quit IRC05:18
*** lpetrut has joined #openstack-nova05:19
*** threestrands has quit IRC05:28
*** lpetrut has quit IRC05:34
*** jaosorior has quit IRC05:37
*** lajoskatona has joined #openstack-nova05:39
*** janki has quit IRC05:40
*** janki has joined #openstack-nova05:40
*** tetsuro has left #openstack-nova05:42
*** sridharg has joined #openstack-nova05:44
*** jaosorior has joined #openstack-nova05:44
*** mdnadeem has joined #openstack-nova05:46
*** udesale has quit IRC05:48
*** udesale has joined #openstack-nova05:48
*** lpetrut has joined #openstack-nova06:06
*** jchhatbar has joined #openstack-nova06:09
*** janki has quit IRC06:09
*** harlowja has quit IRC06:14
*** slaweq has joined #openstack-nova06:15
*** lpetrut has quit IRC06:19
*** slaweq has quit IRC06:19
*** ameeda has joined #openstack-nova06:20
*** Eran_Kuris has joined #openstack-nova06:26
*** rcernin has quit IRC06:44
*** stakeda has joined #openstack-nova06:51
*** mrodden has quit IRC06:54
*** jchhatbar has quit IRC06:56
*** hoonetorg has quit IRC06:56
*** janki has joined #openstack-nova06:56
*** hoonetorg has joined #openstack-nova06:57
*** sree has quit IRC07:01
*** sree has joined #openstack-nova07:01
*** sapcc-bot2 has quit IRC07:01
*** sapcc-bot has joined #openstack-nova07:02
*** ccamacho has quit IRC07:02
*** sree has quit IRC07:06
*** udesale_ has joined #openstack-nova07:07
*** udesale has quit IRC07:09
*** hshiina has quit IRC07:09
*** threestrands has joined #openstack-nova07:09
*** threestrands has quit IRC07:09
*** threestrands has joined #openstack-nova07:09
*** hshiina has joined #openstack-nova07:09
*** janki has quit IRC07:09
*** janki has joined #openstack-nova07:10
*** jamesdenton has quit IRC07:10
*** moshele has joined #openstack-nova07:18
*** sree has joined #openstack-nova07:20
openstackgerritMerged openstack/nova master: Avoid inventory DELETE API (no conflict detection)  https://review.openstack.org/53971207:22
*** udesale__ has joined #openstack-nova07:23
*** psachin has quit IRC07:24
*** udesale_ has quit IRC07:26
*** rcernin has joined #openstack-nova07:28
*** chyka has joined #openstack-nova07:29
*** lpetrut has joined #openstack-nova07:29
*** sshwarts has joined #openstack-nova07:29
*** chyka has quit IRC07:33
*** pcaruana has joined #openstack-nova07:40
*** andreas_s has joined #openstack-nova07:40
*** edmondsw has joined #openstack-nova07:41
*** slaweq has joined #openstack-nova07:45
*** edmondsw has quit IRC07:45
*** tssurya has joined #openstack-nova07:50
*** ragiman has joined #openstack-nova07:55
*** belmoreira has joined #openstack-nova07:55
*** psachin has joined #openstack-nova07:59
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata  https://review.openstack.org/54156108:01
*** AlexeyAbashkin has joined #openstack-nova08:08
*** gibi has joined #openstack-nova08:13
gibigood morning08:13
*** slaweq_ has joined #openstack-nova08:15
*** tesseract has joined #openstack-nova08:17
*** slaweq_ has quit IRC08:20
*** alexchadin has joined #openstack-nova08:22
*** ansiwen has joined #openstack-nova08:23
hrwmorning08:23
*** mdbooth has joined #openstack-nova08:24
*** danpawlik has quit IRC08:24
*** danpawlik has joined #openstack-nova08:25
*** jpena|off is now known as jpena08:26
*** lajoskatona has quit IRC08:30
*** links has quit IRC08:35
ameedamorning :)08:42
ameedagibi: thanks for reviews. what about this https://review.openstack.org/#/c/542378/ ? I am not sure why bug reporter asked to add this file, do you guess that I have to remove it ?08:43
*** mgoddard_ has joined #openstack-nova08:44
ameedaalso regarding this https://review.openstack.org/#/c/543348/, I will ask openstack-requirements channel to get suitable answer08:44
gibiameeda: by reading the bug report I think dhellmann wants to move the doc only requirements to a separate file and _then_ change tox to use that requirement file for doc generation08:47
gibiameeda: I think you missed that second part08:48
ameedagibi: let me check. brb08:48
*** jaianshu has joined #openstack-nova08:50
*** links has joined #openstack-nova08:52
*** lajoskatona has joined #openstack-nova08:53
ameedagibi: thank for the update, I guess the edit of tox.ini will be here https://review.openstack.org/#/c/543348/1/tox.ini , so the old tox.ini was running correctly since the test-requirements have all requirements.08:55
ameedagibi: it make since ?08:55
*** alexchadin has quit IRC08:56
*** alexchadin has joined #openstack-nova08:57
gmann_gibi: your fix looks fine just comment for newton branch - https://review.openstack.org/#/c/538908/309:01
*** sambetts|afk has quit IRC09:03
*** ccamacho has joined #openstack-nova09:03
gibiameeda: I don't get it. This patch https://review.openstack.org/#/c/543348/1/tox.ini still does not refer to the doc/requirements.txt you created in https://review.openstack.org/#/c/542378/09:04
*** ccamacho has quit IRC09:04
gibiameeda: so something is missing09:04
*** ccamacho has joined #openstack-nova09:04
ameedagibi: so I have to edit this https://review.openstack.org/#/c/543348/1/tox.ini to have -r{toxinidir}/doc/requirements.txt ? so my edit must be in this review https://review.openstack.org/#/c/543348/ to avoid merge conflict ?09:06
*** sambetts_ has joined #openstack-nova09:07
*** amoralej|off is now known as amoralej09:09
gibiameeda: I would keep your two change separate. I would change the tox.ini in https://review.openstack.org/#/c/542378/ to use the new doc/requirements.txt09:09
gibiameeda: for the testenv:docs and the testenv:releasenotes target09:09
ameedagibi: what should I write to use it ?09:10
*** hiro-kobayashi has quit IRC09:10
ameedagibi: deps =   -r{toxinidir}/doc/requirements.txt, right ?09:11
gibiameeda: I guess deps = -r{toxinidir}/doc/test-requirements.txt09:11
gibiameeda: yes09:11
ameedaokay, Thanks for help ^_^09:11
*** derekh has joined #openstack-nova09:12
gibigmann_: looking09:13
ameedagibi: is this correct https://pasteboard.co/H7JnfYu.png ?09:13
gibiameeda: at least that is what I would try :)09:14
ameedagibi: so I will upload new patch now ^_^09:15
openstackgerritAmeed Ashour proposed openstack/osc-placement master: Change documentation theme  https://review.openstack.org/54237809:15
*** chyka has joined #openstack-nova09:18
*** dtantsur|afk is now known as dtantsur09:21
*** threestrands_ has joined #openstack-nova09:21
*** threestrands has quit IRC09:21
*** chyka has quit IRC09:23
*** ralonsoh has joined #openstack-nova09:23
*** hshiina is now known as hshiina|afk09:25
openstackgerritAmeed Ashour proposed openstack/osc-placement master: Change documentation theme  https://review.openstack.org/54237809:26
*** edmondsw has joined #openstack-nova09:29
openstackgerritAmeed Ashour proposed openstack/osc-placement master: Change documentation theme  https://review.openstack.org/54237809:32
*** edmondsw has quit IRC09:34
*** alexchadin has quit IRC09:37
*** alexchadin has joined #openstack-nova09:38
bauzasmorning Nova09:40
ameedabauzas: morning :)09:41
gibigmann_: I removed the newton branches from https://review.openstack.org/#/c/538908/09:43
stephenfinbauzas: Oh hai. I'm going to be pushing up a reworked version of https://review.openstack.org/#/c/541290/ shortly and would love your thoughts :)09:44
stephenfinLet me know if you want me to return the favour anywhere09:44
bauzasstephenfin: sure thing09:45
kashyapbauzas: Hey, when you get a sec, a question for you on #openstack-dev (on writing a new scheduler filter)09:45
bauzaskashyap: ack09:45
*** cdent has joined #openstack-nova09:45
bauzaskashyap: why #openstack-dev btw. ? :)09:46
bauzassince I very rarely scroll it09:46
kashyapHeh09:46
* stephenfin didn't even know #openstack-dev existed09:46
kashyapbauzas: It's not me, someone else asked the question09:46
bauzashah ok09:46
bauzasnp09:46
kashyapI noticed the question and prompted you :-)09:46
kashyapI _think_ he's left the channel :-(09:46
kashyapI recognize the name of the developer from Kubernetes community09:47
cdentstephenfin: it's funny how that works isn't it? so much stuff can stay under the radar, no matter how long you're around.09:47
stephenfincdent: For sure. You never stop learning new stuff09:48
*** acormier has joined #openstack-nova09:48
stephenfinThough I suppose if you did, it would probably be time to move on09:48
cdenttrue09:49
*** bhujay has quit IRC09:49
*** bhujay has joined #openstack-nova09:50
*** acormier has quit IRC09:53
openstackgerritBence Romsics proposed openstack/nova master: Clarify 'capacity' in placement api-ref  https://review.openstack.org/54434710:00
*** hshiina|afk has quit IRC10:01
*** yamahata has quit IRC10:05
*** sree has quit IRC10:06
*** sree has joined #openstack-nova10:07
openstackgerritChris Dent proposed openstack/nova master: WIP: Move resource provider objects into placement hierarchy  https://review.openstack.org/54004910:08
openstackgerritChris Dent proposed openstack/nova master: Optional separate database for placement API  https://review.openstack.org/36276610:08
openstackgerritChris Dent proposed openstack/nova master: WIP: Isolate placement database config  https://review.openstack.org/54143510:08
openstackgerritChris Dent proposed openstack/nova master: Isolate config parse_args for placement  https://review.openstack.org/54349510:08
*** sree has quit IRC10:11
bauzasdoes anyone know if our nova documentation includes HTML rendered docstrings of our internal interfaces ?10:13
bauzasstephenfin: ^10:13
bauzasI'd like to point in a document some object structures10:14
stephenfinbauzas: Nope10:14
bauzasokay, then I'll say look at the code10:14
stephenfinThat would need Sphinx's 'apidoc' tool, which we don't use enable10:14
stephenfinThat'd be the best call, yeah10:14
*** slaweq_ has joined #openstack-nova10:16
*** sambetts_ is now known as sambetts10:21
*** slaweq_ has quit IRC10:21
openstackgerritSylvain Bauza proposed openstack/nova master: doc: Clarify how to create your own filter  https://review.openstack.org/54483610:23
bauzasstephenfin: gibi: doc nits fix in https://review.openstack.org/54483610:23
bauzasrelated to kashyap's proxying someone for clarifications about scheduler filters10:24
kashyapbauzas: Thanks; will look at the review in a few10:24
stephenfinbauzas: One newline missing and I'm +210:24
bauzasstephenfin: ack, thanks10:29
*** udesale_ has joined #openstack-nova10:30
*** udesale__ has quit IRC10:33
openstackgerritSylvain Bauza proposed openstack/nova master: doc: Clarify how to create your own filter  https://review.openstack.org/54483610:37
openstackgerritStephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec  https://review.openstack.org/54129010:38
stephenfinbauzas: Boom ^10:38
*** sdague has joined #openstack-nova10:38
bauzasstephenfin: okay, I'll look at your spec once I'm done with jaypipes's one about aggregate ratios10:39
*** stakeda has quit IRC10:41
*** sridharg has quit IRC10:41
openstackgerritAmeed Ashour proposed openstack/osc-placement master: Change documentation theme  https://review.openstack.org/54237810:42
*** priteau has joined #openstack-nova10:59
*** jistr is now known as jistr|mtg11:00
*** yamamoto has quit IRC11:01
openstackgerritStephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec  https://review.openstack.org/54129011:02
*** lucas-afk is now known as lucasagomes11:04
*** chyka has joined #openstack-nova11:04
*** yamamoto has joined #openstack-nova11:06
*** tbachman has joined #openstack-nova11:08
*** chyka has quit IRC11:09
openstackgerritAmeed Ashour proposed openstack/osc-placement master: Change documentation theme  https://review.openstack.org/54237811:12
*** udesale__ has joined #openstack-nova11:14
*** abhishekk has quit IRC11:15
*** udesale_ has quit IRC11:16
openstackgerritAmeed Ashour proposed openstack/osc-placement master: Change documentation theme  https://review.openstack.org/54237811:28
*** udesale__ has quit IRC11:30
openstackgerritMerged openstack/nova master: doc: Clarify how to create your own filter  https://review.openstack.org/54483611:31
*** tssurya has quit IRC11:34
*** acormier has joined #openstack-nova11:36
*** Tom-Tom has joined #openstack-nova11:36
*** abalutoiu_ has quit IRC11:42
*** tssurya has joined #openstack-nova11:43
*** abalutoiu has joined #openstack-nova11:43
*** sree has joined #openstack-nova11:45
*** sree has quit IRC11:50
*** jpena is now known as jpena|lunch11:52
*** tbachman has quit IRC11:53
*** sree has joined #openstack-nova11:55
*** sree has quit IRC11:55
*** sree has joined #openstack-nova11:56
*** sree_ has joined #openstack-nova11:57
*** sree_ is now known as Guest4391111:57
*** sree has quit IRC12:01
*** acormier has quit IRC12:03
*** yamamoto has quit IRC12:09
*** bhujay has quit IRC12:09
*** dave-mccowan has joined #openstack-nova12:10
*** bhujay has joined #openstack-nova12:10
*** janki is now known as janki|aafk12:12
*** janki|aafk is now known as janki|afk12:12
*** slaweq_ has joined #openstack-nova12:17
*** slaweq_ has quit IRC12:22
*** yamamoto has joined #openstack-nova12:22
*** jistr|mtg is now known as jistr12:23
openstackgerritChris Dent proposed openstack/nova-specs master: VMware: add support for live migration  https://review.openstack.org/29920712:33
*** sridharg has joined #openstack-nova12:35
*** chyka has joined #openstack-nova12:37
*** yamamoto has quit IRC12:39
*** chyka has quit IRC12:41
*** mgoddard_ has quit IRC12:42
*** tssurya has quit IRC12:47
*** yamamoto has joined #openstack-nova12:54
*** jaianshu has quit IRC13:02
*** yamamoto has quit IRC13:05
*** edmondsw has joined #openstack-nova13:06
*** tssurya has joined #openstack-nova13:08
*** edmondsw has quit IRC13:10
*** pooja-jadhav is now known as pooja_jadhav13:10
openstackgerritBence Romsics proposed openstack/nova master: Clarify 'capacity' in placement api-ref  https://review.openstack.org/54434713:13
*** Guest43911 has quit IRC13:14
*** sree has joined #openstack-nova13:14
*** sree has quit IRC13:21
*** mgoddard_ has joined #openstack-nova13:21
*** edmondsw has joined #openstack-nova13:24
*** udesale has joined #openstack-nova13:25
openstackgerritThomas Goirand proposed openstack/nova master: Python 3 fix for sphinx doc  https://review.openstack.org/54495613:26
ameedaHello, what do you think if I take this review and complete on it ? https://review.openstack.org/#/c/525253/13:30
*** kaisers has quit IRC13:31
*** acormier has joined #openstack-nova13:32
*** kaisers has joined #openstack-nova13:32
*** pchavva has joined #openstack-nova13:33
*** acormier has quit IRC13:34
*** acormier has joined #openstack-nova13:34
*** jpena|lunch is now known as jpena13:37
*** acormier has quit IRC13:38
*** abhishekk has joined #openstack-nova13:42
*** elmaciej has joined #openstack-nova13:42
hrwameeda: you mean "take it, update, send for review"?13:48
hrwameeda: if you feel that change is needed but abandoned by original author then why not13:48
ameedayes13:48
hrwameeda: my way from 'wth is kolla' to 'kolla core reviewer' started from taking over one patch13:49
ameedaoriginal author doesn't do any activity from awhile "5 weeks"13:49
ameedahrw: I am not sure if that is legal to take this patch, I want approval, what if I comment on the bug to ask current assignee if he still working on the bug. also I am not sure about the rank of this bug.13:54
ameedahrw: since I have patches need for review from awhile.13:55
*** ragiman has quit IRC13:57
*** esberglu has joined #openstack-nova13:58
hrwameeda: do what you think. nova is foss and mia maintainer can be overriden imho with new ver of patch13:59
*** yamamoto has joined #openstack-nova14:00
hrwameeda: sometimes during review it is easier for reviewer to send new version than comment14:00
*** mriedem has joined #openstack-nova14:01
ameedahrw: so you guess me to mark current patch as abandoned then upload new patch14:02
jrollameeda: cfriesen is the author, he is active in this channel, might as well ask him14:02
hrwameeda: no.14:02
ameedacfriesen: are you around ?14:02
*** dtantsur is now known as dtantsur|brb14:02
hrwameeda: git review 525253 -d; edit, git commit --amend, git review14:03
ameedahrw: thanks14:03
mriedemheh, mnaser check out https://review.openstack.org/#/c/525253/ being discussed; look familiar?14:04
ameedamriedem: Hello :)14:05
mnasermriedem: lol, well now that I’ve learned a whole lot, I can tell that shouldn’t work for scenarios involving new flow :p14:06
mnaserI don’t think it would be a fun time to replicate all the code used in the clean up section (but maybe it could be moved out to utils somewhere and reused)14:07
mnaserBut imho transactionally It feels more correct that bdms for failed instances aren’t disappearing14:07
mriedemmnaser: yup, that's part of my -114:07
mnaserIf the detach fails there should still be some sort of reference, right now there’s nothing14:07
mnasermriedem: as much as I’d hate to rebase the series again, should we add a release note for operators that “hey, if you have a lot of failed scheduled instances, your bdm table might get bigger because they’re saved now”14:09
*** jmlowe has quit IRC14:09
*** lucasagomes is now known as lucas-hungry14:09
mriedemmnaser: those will be deleted when the failed instance is deleted14:10
mnasermriedem: oh okay so thats not a big impact, i guess bdms are not soft deleted14:10
mriedemi doubt anyone would need to know that we start putting bdms in cell0 now14:10
mriedembdms are soft deleted14:10
mriedemlike instances and everything else (except tags) in the 'nova' table14:10
mriedemso you'd still have to archive/purge that stuff at some point14:10
mnasergotcha14:10
*** sree has joined #openstack-nova14:11
mnaseranyways, whole series is ready to be reviewed (and i don't think i have a lot of review karma saved up for my lack of nova reviews to use :p)14:11
mriedemi've got +2s on the first 314:12
mnaserit's causing a ton of annoyance for some customers because they cant delete their volumes14:12
mriedemthere is a force detach in cinder14:12
mnaserafaik thats an admin op14:12
mriedemyeah maybe14:13
mriedemyup it's an admin action by default os-force_detach14:13
mriedemhttp://git.openstack.org/cgit/openstack/cinder/tree/cinder/api/contrib/admin_actions.py#n20314:14
mnaseranyways no worries, i know the first 3 are much more simple, the last one is the tough one but i'm ready to pick up any other work that comes on top so ping me if anything :>14:14
*** janki|afk has quit IRC14:16
*** jmlowe has joined #openstack-nova14:18
*** bhujay has quit IRC14:19
*** bhujay has joined #openstack-nova14:19
*** yamahata has joined #openstack-nova14:21
*** rmcall has joined #openstack-nova14:21
*** acormier has joined #openstack-nova14:22
efriedmelwitt: I have to duck out of the nova meeting around quarter after, FYI.  On the hook for school runs again.14:22
*** dave-mccowan has quit IRC14:23
*** jaosorior has quit IRC14:23
*** lbragstad has joined #openstack-nova14:29
*** ccamacho has quit IRC14:29
*** tbachman has joined #openstack-nova14:29
*** alexchadin has quit IRC14:29
*** Eran_Kuris has quit IRC14:31
*** awaugama has joined #openstack-nova14:31
*** acormier has quit IRC14:31
*** doude has quit IRC14:33
*** tbachman has quit IRC14:34
*** esberglu has quit IRC14:34
*** threestrands_ has quit IRC14:39
*** dtruong has quit IRC14:40
*** dtruong has joined #openstack-nova14:41
*** yamamoto has quit IRC14:41
*** tbachman has joined #openstack-nova14:41
*** amodi has joined #openstack-nova14:42
jaypipesbauzas: would you mind pinging sahid to hop on #openstack-nova please? just for a few minutes. have a question for him..14:44
bauzassure, lemme try ;)14:44
*** mlavalle has joined #openstack-nova14:44
jaypipesmerci14:44
*** doude has joined #openstack-nova14:44
*** doude has quit IRC14:44
*** doude has joined #openstack-nova14:44
bauzasmmm, he's not on our internal IRC, lemme verify if he has some PTO14:44
*** ccamacho has joined #openstack-nova14:46
*** yamamoto has joined #openstack-nova14:48
jaypipesbauzas: ok, no worries.14:48
bauzasjaypipes: well, I don't see any PTO on our agenda14:49
jaypipesbauzas: danpb isn't available is he?14:49
*** dtantsur|brb is now known as dtantsur14:49
jaypipesbauzas: specifically, I am looking to find out whether Dan's comment here: https://review.openstack.org/#/c/527631/9/nova/virt/libvirt/driver.py@a4299 (that was removed by tetsuro) is still valid.14:50
bauzasjaypipes: I can ask danpb to go here14:50
jaypipesbauzas: cool, cheers :)14:50
bauzaseven if he's no longer working on nova14:50
*** READ10 has joined #openstack-nova14:51
*** psachin has quit IRC14:51
stephenfinjaypipes: kashyap is the person to ask about that14:52
* kashyap blinks14:52
stephenfinFar as I know, that comment is still valid. We've got support or emulator threads enabled but not IO threads14:52
kashyapAnd clicks on the URL14:53
stephenfinHowever, iirc, kashyap was in talks where the value of IO threads was called into question14:53
*** yamamoto has quit IRC14:53
stephenfinWell, IO threads > 1 anyway14:53
kashyapstephenfin: jaypipes: (I have a discussion for it (IO Threads at Dublin too)14:53
kashyapThat said...14:53
kashyapYeah, the IO Threads value is in contention14:55
kashyapRecently, I saw a presentation at KVM Forum where someone from oVirt claimed the "ideal" number of IO Threads is ...1!14:55
kashyap(In their benchmarks)14:55
kashyapBut I won't believe it.  "Seeing is believing" --> Need `fio` benchmarks for that14:56
kashyapjaypipes: Also see: https://review.openstack.org/#/c/230968/ "iothreads for disk devices"14:57
jaypipeskashyap: so, bottom line, that comment from danpb is still valid, yeah?14:59
bauzasjaypipes: when you have time, I'd also like to discuss abotu https://review.openstack.org/#/c/544683/114:59
kashyapjaypipes: Yes, it is still valid; it's better to retain that14:59
kashyap(I.e. I agree with your comment on Gerrit)14:59
kashyapNova isn't yet using IO Threads.15:00
* kashyap goes to comment there15:00
jaypipesdanke15:00
jaypipeskashyap: dan just responded.15:01
*** rcernin has quit IRC15:01
kashyapjaypipes: I think you're trying to speak Dutch, in that case: "Dank je" / "Heel erg bedant" :P15:02
kashyap(You wrote German)15:02
kashyapIf that was intentional; disreregard me15:02
openstackgerritDan Smith proposed openstack/nova-specs master: Support member_of param for allocation candidates  https://review.openstack.org/54469415:03
jaypipeskashyap: oh, I wasn't trying to write Dutch... I just say danke all the time...15:04
jaypipesdansmith: why thank you dan15:04
kashyapTrue; I've noticed it before15:04
dansmithcha15:04
mriedemmelwitt: mnaser: i've gone through the local delete https://review.openstack.org/#/c/340614/ change in detail, lots of questions and head scratching15:05
jaypipesstephenfin: I -W'd https://review.openstack.org/#/c/527630/ since the blueprint isn't yet approved..15:05
stephenfinOh, good catch. It is just cleanup though, right?15:06
mriedem527630 is in the gate15:06
efriedcdent, jaypipes: Can we talk about the "2001 providers" issue from https://review.openstack.org/#/c/540111/ ?15:06
mriedemyou're going to have to rebase it to pull it out15:06
mriedemor change the commit message15:06
mriedemjaypipes: stephenfin: ^15:06
stephenfinDo we want to?15:06
cdentefried: I can if you like but it will be partial attention, doing tc office hours then api-s15:07
cdentig15:07
*** tidwellr has joined #openstack-nova15:07
openstackgerritDan Smith proposed openstack/nova master: Add request filter functionality to scheduler  https://review.openstack.org/54473015:07
openstackgerritDan Smith proposed openstack/nova master: WIP: Add require_tenant_aggregate request filter  https://review.openstack.org/54500215:07
stephenfinjaypipes: I'll let you call that15:07
jaypipesmriedem: it's just a small refactor. if you want to keep it in, that's OK with me. but the series is associated with a blueprint that is not approved, as you know.15:07
jaypipesefried: sure. hangout or IRC?15:08
mriedemi haven't been tracking it, just saw you mention that15:08
efriedcdent, jaypipes, edleafe: If y'all are okay with limiting based on the MISC_SHARES_VIA_AGGREGATE trait, at least for now, I'll make it so.  If I'm the only one who's uncomfortable about that, and I can't give a good reason/counterexample, then I'm okay to let it ride.15:08
jaypipesmriedem: for some reason I thought -W would prevent it from gating...15:08
dansmithjaypipes: nay15:08
efriedjaypipes, mriedem: A -2 might15:08
jaypipesah15:09
jaypipeswell I don't want to do that...15:09
mriedemno, the best thing with stuff that's not bp approved right now, is don't +2 it15:09
*** lajoskatona has quit IRC15:09
dansmitha -2 will, but it will reset the gate at the last moment15:09
bauzasdansmith: oh, saw https://review.openstack.org/#/c/544585/15:09
mriedem+1 if you wanted to review it and said lgtm but the bp isn't approved yet15:09
*** r-daneel has quit IRC15:09
*** hamzy_ has quit IRC15:10
dansmithbauzas: came out of discussing some concerns with CERN15:10
bauzasokay, I need to review it carefully then15:10
bauzasI wasn't really paying attention to specs yet15:10
jaypipesstephenfin: I -W'd the following patch.15:11
dansmithbauzas: it's pretty simple, and you can see my prototype code which is probably easier to grok15:11
jaypipesstephenfin: and left the one small refactoring in the gate.15:11
bauzasdansmith: yeah, will look15:11
stephenfinjaypipes: Cool. I had concerns about that one anyway (though it's also a refactoring change)15:12
jaypipesefried: let me comment on the spec.15:12
efriedjaypipes: ack, thx.  I'd like to answer the question in the text before it's published.15:12
jaypipesya15:13
efriededleafe: btw, we're talking about https://review.openstack.org/#/c/540111/4/specs/rocky/approved/update-provider-tree.rst@4815:13
*** dave-mccowan has joined #openstack-nova15:13
*** abhishekk has quit IRC15:14
dansmithmriedem: you're going to let me know when I can un -W this right? https://review.openstack.org/#/c/543580/15:16
*** mdnadeem has quit IRC15:17
mriedempreferably after rc215:18
*** lucas-hungry is now known as lucasagomes15:18
jaypipesefried: done15:18
*** bhujay has quit IRC15:19
*** Nil_ has joined #openstack-nova15:22
*** jaosorior has joined #openstack-nova15:27
*** elmaciej has quit IRC15:28
edleafeefried: was getting coffee. Makes sense to limit the tree by that trait.15:29
mriedemmelwitt: i thought about this earlier today for some reason: if anyone, new contributor, stephen, whoever :) wants to start converting mox to mock in nova, they should definitely either way for cellsv1 and nova-net removal first, or be sure to stear clear from converting any tests that touch those code paths15:29
mriedem*wait15:29
efriededleafe: Rgr, thx15:29
*** ralonsoh_ has joined #openstack-nova15:32
*** yamamoto has joined #openstack-nova15:33
bauzasdansmith: question for you, why can't we leave Placement return all the hosts and only select the ones from that or this in a filter ?15:34
bauzasdansmith: you described that in https://review.openstack.org/#/c/544585/6/specs/rocky/approved/placement-req-filter.rst@115 IIRC but it's a bit confusing for me15:35
dansmithbauzas: because cern would have to process 9000 hosts that couldn't possibly work before they get to the first one that would15:35
dansmithbauzas: if you have a 10k node deployment with lots of space, and you boot a small instance, you get back a ridiculous number of hosts that you're not allowed to use and we have to run filters on all of them15:36
bauzasdansmith: it ties to a Placement performance question, right?15:36
*** ralonsoh has quit IRC15:36
dansmithno15:36
dansmithplacement is fast at doing that,15:36
dansmithscheduler is slow at processing the result15:36
bauzasdansmith: because for that kind of purpose, we always say to use the more important filters first15:36
mriedemmelwitt: i've started a technical debt / cleanup section in https://etherpad.openstack.org/p/nova-ptg-rocky L15715:36
dansmithbauzas: at CERN-level scale, that is still very wasteful15:37
bauzasdansmith: since each filter is processed one after the other, depending on the ordering of the list15:37
bauzasdansmith: did they found some bottleneck ?15:37
*** hamzy_ has joined #openstack-nova15:37
dansmithbauzas: did you read the irc conversation?15:37
bauzasbecause the last benches I had from the scheduler, the filtering process itself was way fast15:37
*** yamamoto has quit IRC15:38
bauzasdansmith: from the cells meeting ? unfortunately no15:38
dansmithbauzas: we also only request 1000 hosts from placement, so if your hosts are after the first thousand, we wouldn't get back any that work for us15:38
dansmithbauzas: no, linked in the spec15:38
mriedembauzas: cern ties tenants to cells,15:38
mriedemso top level cells v1 scheduler will pick the cell for the tenant,15:38
mriedembut with cells v2, we have a flat scheduler,15:39
dansmithbauzas: so if you have more than 1000 hosts that could fit your size flavor, but the first one you're allowed to use is after that, you could never schedule, or have to bump that limit higher15:39
mriedemso rather than a request from that tenant being just the computes in the chosen child cell, now it's all hosts from all cells,15:39
mriedemas dan pointed out15:39
dansmithand, any hard requirement we (nova) knows about that it can communicate to placement ahead of time will only improve performance, and ensure we get back a richer set of hosts to choose from15:39
dansmithand "can never be on hosts in aggregate X" is a pretty concrete requirement :)15:40
bauzasdansmith: mriedem: I understand that concern15:40
bauzasI just wonder how big it can become15:40
mriedemi like to also think of this as a way to eventually get rid of these other post-placement filters15:40
dansmithyeah15:40
bauzasthe fact we said placement was efficient is that because it doesn't care of anything specific15:40
dansmiththat is also nice15:40
mriedemwe have already said don't use ram/disk/core filter b/c placement15:40
mriedemthis would also remove the aggregate tenant isolation filter15:40
dansmithbauzas: placement already does aggregates, this is well within its scope15:41
mriedembauzas: i'm not aware of anyone that has done benchmarking before and after placement at scale15:41
mriedemto say that we're way better now15:41
dansmithbauzas: performance aside, you get the point about the request limit right?15:41
*** hamzy_ has quit IRC15:41
bauzasmriedem: no,  the benches were pre-placement, but saw the filtering process very fast15:41
bauzasdansmith: sure15:41
dansmithif we'reonly getting back 1000 hosts, then we could get back none15:41
openstackgerritClaudiu Belu proposed openstack/nova master: compute: Cleans up allocations after failed resize  https://review.openstack.org/54397115:42
bauzaswell, I don't know what to say15:42
*** lpetrut has quit IRC15:42
dansmithbauzas: performance aside, we want to get back a list of hosts that are candidates, and hosts that are in aggregates we're not allowed to be on are not candidates, so they're just busy work and they defeat the point of getting a solid fast set of canidates from placement based on things it knows about15:42
*** dave-mccowan has quit IRC15:43
bauzasdansmith: sure15:43
bauzasanyway, here is my take15:43
bauzasI'm not opposed at that15:43
bauzasI just need to consider all the implications15:44
bauzasbecause filters are like the nova things the most tweaked15:44
bauzasby ops15:44
mriedemdansmith: i'm assuming the pre-placement filters would also be pluggable?15:44
dansmithmriedem: modular, like our scheduler filters, not necessarily pluggable15:45
*** acormier has joined #openstack-nova15:45
bauzasif we're about to introduce a new hook for cheating placement to only return the subset we want, chances are that in the future ops will come with solid use-cases15:45
dansmithbauzas: cheating placement? I can't understand how this is that :)15:45
bauzasand at the end of the day, we'd just introduce more and more complexity to placement15:45
dansmiththis doesn't change placement at all15:45
dansmithnot a single bit15:45
mriedemthese pre-placement filters are restricted to what placement api supports15:45
bauzasdansmith: for your proposal, I agree15:45
mriedemwhich is resource classes, traits and aggregates15:45
dansmiththey operate on request spec15:46
bauzasdansmith: again, I'm not opposed to *your* use case which is tenant filtering15:46
mriedemi also have a use case for this15:46
mriedemif you care15:46
bauzasthat said, we could do that without using aggregateds15:46
bauzasI guess15:46
bauzasanyway15:46
bauzasfinding use-cases is not the thing I'm worried15:47
bauzasI'm more worried by how big it can become15:47
mriedemwe knew we wanted to move filters in sql via placement as much as possible since the beginning right?15:47
dansmithI think I need a more concrete argument than that to understand the concern :)15:47
bauzasdansmith: hence why I'm discussing over IRC15:48
bauzasFUD isn't a valid argument and I respect that15:48
dansmithIMHO, this is the natural evolution of us asking placement for hosts based on resources (which it deals with) and then traits (which it deals with) and now aggregates (which it deals with)15:48
bauzasI just need to understand the context15:48
dansmithbauzas: why don't you want to hear mriedem's use case?15:49
bauzasdansmith: I'm open to his use-case15:49
dansmithbauzas: I also had a BFV use case in the first rev of the spec,15:49
dansmithbut removed it because it was distracting to some people15:50
bauzasthe limitation thing is certainly a valid argument15:50
*** felipemonteiro has joined #openstack-nova15:50
bauzasbecause we need to get all the corresponding hosts from placement15:50
*** hamzy has joined #openstack-nova15:50
bauzasif we say we won't allow pluggability, I think I'd be okay15:50
dansmithpersonally I don't want this to be pluggable, just modular15:50
dansmith(brb)15:51
bauzasthen okay15:51
bauzasif we're all clear that we will never open that to ops15:51
openstackgerritEric Fried proposed openstack/nova-specs master: Update Provider Tree  https://review.openstack.org/54011115:51
mriedembauzas: what i want to use this for is making sure we can pick a host that supports multiattach volumes for bfv, and tagged attach during bfv15:51
efriededleafe, jaypipes, cdent: There's that reword ^15:51
mriedembauzas: because today that's just luck of the host and we don't reschedule on failed volume attaching during bfv15:51
bauzasmriedem: you could achieve that with a filter, right?15:51
*** felipemonteiro_ has joined #openstack-nova15:51
bauzasatm, we have two placing mechanisms15:52
bauzas#1 is placement15:52
bauzas#2 is filters15:52
mriedemdo we have a filter that actually has the driver.capabilities information exposed to it?15:52
bauzasI agree with both of you to try to make #1 prioritary15:52
cdentefried: good, thanks15:52
*** moshele has quit IRC15:52
efriedbauzas: IMO we should do any filtering that's possible/practical to do in placement, in placement.  Cause that'll be more efficient.15:52
bauzasmriedem: we have one caring about the compute capabilities themselves15:52
*** sridharg has quit IRC15:53
mriedembauzas: but i'm not sure if that filter actually gets that data15:53
bauzasefried: yeah, hence my15:53
bauzas(16:52:33) bauzas: I agree with both of you to try to make #1 prioritary15:53
efriedcool15:53
bauzasokay, looks like I'm settling down15:53
mriedemi have a hard time even grokking the code in the compute capabilities filter15:53
bauzas#1 scheduling (placement) shouldn't never be open to operators15:53
bauzas#2 scheduling (filters) would eventually only be custom15:54
bauzasif we could15:54
bauzaslooks like a deal then15:54
mriedemthe ComputeCapabilitiesFilter works on the HostState.stats right?15:54
*** felipemonteiro has quit IRC15:55
mriedemanyway, it would be easy to make one of these pre-placement filters that sees, 'oh you're doing bfv with a multiattach volume, let me add required trait CUSTOM_COMPUTE_SUPPORTS_MULTIATTACH to the request to placement for filtering'15:56
efriedbauzas: Not sure I agree that ops don't affect placement-level scheduling.  They do so via traits etc.15:56
efriedmriedem: ++, assuming the compute got tagged with that trait somehow15:56
jaypipesefried: +215:56
mriedemefried: that's https://review.openstack.org/#/c/538498/15:56
mriedemhttp://lists.openstack.org/pipermail/openstack-dev/2018-January/126653.html15:56
mnasermriedem: left some comments about the change .. to the best of my knowledge15:56
bauzasefried: no, I meant custom code modifying behaviour of placement15:57
*** r-daneel has joined #openstack-nova15:58
bauzasmriedem: IIRC, the ComputeCapabilitiesFilter matches any HostState field15:58
bauzasthat's magic15:58
cdentyes, definitely custom code should not happen to placement15:58
dansmithcdent: that's not what he's saying here htough15:58
bauzasdansmith: so, modularity is good, provided we don't open the entry points15:59
dansmithcdent: nobody is talking about touching placement at all, he's talking about in this code that we use to query placement15:59
bauzasdansmith: a big fat comment in the code would be fine for me15:59
dansmithbauzas: we don't comment code that isn't pluggable so I don't see why this would be any different :)15:59
bauzasyeah, what dansmith said15:59
cdentah, sorry, I misinterpreted "I meant custom code modifying behaviour of placement"15:59
dansmithbauzas: I will have to say, that scheduler filters and these pre-filters would be the _best_ place to introduce custom behavior if I was an operator16:00
bauzasdansmith: you surely imagine the creativity of people using our code :)16:00
cdentpresumably the only way to modify placement is by sending different queries and creating various entities. in which case it's not "custom" is it?16:00
dansmithbecause placement is a solid interface and all this is doing is augmenting how we call it16:00
cdentit's what it's for16:00
dansmithcdent: exactly my point16:00
bauzasthe scheduler base filter is an external interface16:00
cdentyay, agreeing with dan is fun16:01
bauzaswhat would be the base pre-filter isn't an external interface and I'd vote -2 on any change that would open that16:01
dansmithbauzas: why do you think the scheduler filters are an external interface?16:01
bauzasdansmith: because it's pluggable :)16:02
bauzasshit, meeting16:02
dansmithbauzas: we don't load them externally anymore right?16:02
bauzasoh hell, we still do that alot16:02
bauzasunless I missed the bus16:02
bauzasand cutting that flexibility would be a huge thing16:03
dansmithwhere is the loading code for that?16:03
bauzassec16:03
dansmitheither way, the spec says I'm not even adding a list of pre-filters, but making each one a semantic config toggle16:04
dansmithso it should be pretty clear we're not adding a new external interface here :)16:04
bauzasdansmith: https://docs.openstack.org/nova/latest/user/filter-scheduler.html?#writing-your-own-filter16:04
dansmithah, I thought we removed the classloading from available_filters16:05
*** ralonsoh_ has quit IRC16:05
bauzasno, we removed the possibility to hook a custom scheduler *driver*16:05
dansmithyeah I remember that16:06
mriedemno we didn't16:06
*** ralonsoh_ has joined #openstack-nova16:06
mriedemthat was reverted16:06
bauzasokay, I thought we never agreed on removing the custom filter16:06
dansmithwell, anyway, this is not that :)16:06
bauzasmriedem: orly?16:06
mriedemyes you were on the reno for it16:06
bauzasman, did I slept 100 years like the Sleeping Beauty ?16:06
bauzasmriedem: on reverting the removal of the classloading ?16:07
bauzasif so, I apologize for my memory lack16:07
dansmithbauzas: I think he's talking about the driver pluggability16:07
mriedemyou can't classload the driver, but you can add an entry point for the scheduler driver in setup.cfg16:07
bauzasrighrt16:08
mriedemhttps://github.com/openstack/nova/commit/1e5c7b52a403e708dba5a069dd86b628a4cb952c16:08
*** tbachman has quit IRC16:08
bauzasseriously, I'm sometimes afraid of my memory lacks :/16:09
bauzasI totally forgot that story16:09
bauzasapologies for that16:09
*** pcaruana has quit IRC16:09
bauzasit's 6 months ago and I don't recall it16:10
bauzascreepy16:10
dansmithso, um,16:10
dansmithare we okay on this non-pluggable modular pre-filter thing or what?16:11
cdentbauzas: too much chaud-verte (or was it verte-chaud or whatever)?16:11
*** andreas_s has quit IRC16:11
bauzascdent: no, Chartreuse16:11
bauzasdansmith: oui16:11
bauzasdansmith: I'm currently re-reviewing your spec16:11
*** andreas_s has joined #openstack-nova16:11
*** tbachman has joined #openstack-nova16:12
*** damien_r1 has joined #openstack-nova16:17
*** yamamoto has joined #openstack-nova16:18
*** READ10 has quit IRC16:18
*** damien_r has quit IRC16:18
bauzascdent: edleafe: I mostly see your concerns by having a spec approved in 1 day, and pre-PTG16:19
bauzascdent: edleafe: please note that I don't feel it's a problem16:19
*** slaweq_ has joined #openstack-nova16:19
bauzaswe can approve a spec and amend it later based on feedback that can come from the PTG or elsewhere16:19
edleafebauzas: the concern was that a series of related specs came out all at once16:19
bauzasor we can at the end of the day have a spec that is approved but leading to a dead-end, that's not a problem to me16:20
edleafeAt first I thought I missed the discussions about them16:20
dansmithI don't think the concern is over PTG discussion,16:20
dansmithwe can't tie spec approvals to ptg discussion globally.. not everyone can or will go, nor will we have enough time for that16:20
edleafedansmith: agreed.16:20
bauzasedleafe: the relationship between specs is surely a thing to consider, but which shouldn't hold an approval if that's not blocking (heh, tautology)16:20
*** andreas_s has quit IRC16:21
bauzasdansmith: sure, hence my "or elsewhere"16:21
*** slaweq has quit IRC16:21
*** tbachman has quit IRC16:21
edleafebauzas: it was because there were a few unstated assumptions, such as the idea that we would be syncing nova aggs to placement aggs, that were surprising16:21
dansmithedleafe: I dunno why that is surprising, I feel like we've covered that multiple times16:22
*** links has quit IRC16:22
*** slaweq has joined #openstack-nova16:22
dansmithbut that said, I'm totally cool with letting the ink dry a bit on things before they go in so all the timezones have a chance to comment16:22
edleafedansmith: it's possible, but I must have missed those discussions16:22
dansmithI actually thought we already were doing that syncing,16:22
dansmithbecause of the method for doing so in the scheduler client, which is apparently unused as of yet16:22
edleafedansmith: I still repeated the mantra "placement aggs are not nova aggs"16:22
dansmith...which is still true :)16:23
*** yamamoto has quit IRC16:23
*** slaweq_ has quit IRC16:24
edleafenow it's "placement aggs *are* nova aggs, and then some"16:24
edleafe:)16:24
mriedemfwiw i never thought we were syncing nova aggs to placement aggs, or intended to do so, before yesterday16:24
mriedemedleafe: but they aren't16:24
mriedemplacement aggs don't have metadata16:25
mriedemthey don't have to exist for anyone outside of nova16:25
*** tbachman has joined #openstack-nova16:25
edleafemriedem: I don't mean they are exactly the same16:25
mriedemi believe jay said they'd be a superset of nova host aggregates, which i think is correct16:25
edleafemriedem: just that if a compute node is in a nova agg, it will also be a matching placement agg16:25
dansmithright, a superset16:25
*** tbachman has quit IRC16:25
mriedembecause my compute node providers could be in an aggregate that mirror a nova host aggregate, and also in a shared storage provider aggregate with cinder16:25
*** andreas_s has joined #openstack-nova16:26
dansmithaggregates are a thing that placement provides for consumers to group resource providers,16:26
bauzasmriedem: edleafe: if we only keep placement aggregates as a bag of a collection of hosts, I'm fine with sync'ing that to nova16:26
edleafeagain, I don't think that this is a bad approach16:26
edleafeit was just a big surprise16:26
*** slaweq has quit IRC16:26
dansmithnova is a user of placement and thus would use it to augment its grouping when placing instances,16:26
bauzaswhat I'm not okay is if placement aggs begin to have metadata information that carries some superseding logic16:26
dansmithas I would expect neutron to create aggregates to mirror is grouping constructs when it helps to place things, cinder the same16:26
bauzasyeah that16:27
*** chyka has joined #openstack-nova16:27
mriedembauzas: no one said they would, and i'm sure jaypipes' head would explode16:27
mriedemif we said that16:27
bauzasmriedem: just stating loud things16:27
mriedemmaybe i should update https://review.openstack.org/#/c/539033/16:27
*** lpetrut has joined #openstack-nova16:27
*** suresh12 has joined #openstack-nova16:28
bauzasmriedem: please, CC'ing that change16:28
bauzassince my brain is untrustable, I need to star things16:28
*** suresh12 has quit IRC16:28
*** suresh12 has joined #openstack-nova16:28
*** jaosorior has quit IRC16:29
*** hongbin has joined #openstack-nova16:30
mriedemedleafe: ^ replied in that change, see what you think16:31
mriedemthe point of that patch is to provide an example,16:31
* jaypipes reads back after escorting the exterminator through a field of feral pugs.16:31
mriedemsince mgagne correctly pointed out that the api-ref today only talks about what placement aggregates "aren't", not an example of what they "are"16:31
hrwmy next patch will look weird for some. There will be comments added to explain why that way16:32
bauzasjaypipes: don't use Bravecto16:33
bauzason your pugs16:33
openstackgerritMerged openstack/nova master: [libvirt] Add _get_vcpu_realtime_scheduler()  https://review.openstack.org/52763016:33
hrwdoes virt/libvirt/driver.py have access to config entries from nova.conf?16:34
bauzashrw: of course16:34
*** ccamacho has quit IRC16:34
hrwpcie.numberofslots (int8) will be new option16:34
jaypipeshrw: yes. via the global CONF variable.16:35
hrwor rather libvirt.pcie.numberofslots or sth like that16:35
jaypipeshrw: python doesn't have an int8. :) you're Golanging.16:35
hrwso admin can set how many 'slots' VM will have16:36
hrwjaypipes: int5 even ;D and I know that python is typeless16:36
jaypipeshrw: it's int5 today. I'm sure a certain hardware manufacturer will change that at some point in the future...16:37
*** AlexeyAbashkin has quit IRC16:37
*** imacdonn has quit IRC16:37
*** imacdonn has joined #openstack-nova16:37
*** READ10 has joined #openstack-nova16:38
hrwjaypipes: have nothing against it in real hw16:38
hrwjaypipes: there are cpus with >32 pcie lines so it is (in theory) possible16:38
jaypipeshrw: yup.16:38
*** Tom-Tom has quit IRC16:38
hrwjaypipes: I remember time when my arm64 machine boot was ~13 minutes due to pci bus scanning16:39
mriedemmnaser: you magnificent bastard, you clarified my big sticking point in melwitt's patch,16:40
mriedemthe main thing is that when the instance is in cell0, instance.host is None but the vm_state is ERROR, so we don't enter that first block of code because "if not has_been_scheduled" is False16:40
jaypipeshrw: I remember a time when we weren't coding hardware-defined software ;)16:40
mriedemand the context is targeted at cell0 because the api code does that when we pull the instance out of cell016:40
mriedemso we can get bdms using that context too16:40
mnasermriedem: i won't take credit, i had the same train of thought, and melwitt corrected me :p16:41
mriedemthe has_been_scheduled variable name is confusing i think16:41
mriedembut i don't have a better alternative16:41
hrwjaypipes: I am not getting young as well ;D16:42
mriedemhas_been_scheduled_or_should_be_in_cell0_or_idk_whatever16:42
*** udesale has quit IRC16:44
*** andreas_s has quit IRC16:44
*** tbachman has joined #openstack-nova16:46
hrwhttps://paste.fedoraproject.org/paste/A9Gtb~sliIFo2-yvA32ymw - preliminary version16:48
bauzasdansmith: I left some comments but only one is blocking me from +2 on https://review.openstack.org/#/c/544585/616:50
bauzasdansmith: the fact that I wonder if we should persist the changes in the RequestSpec or not16:51
dansmithbauzas: why wouldn't we?16:51
bauzasmaybe it's just an implementation detail, but we've seen in the past some problems with the RequestSpec fields that were badly designed whether they should be persisted or not16:51
mriedemlike instance groups?16:52
bauzasdansmith: for the usecase you described, I agree16:52
dansmithbauzas: we'll re-run the pre filters on reschedule, so persisted data could be kept, re-evaluated, updated, etc16:52
bauzasdansmith: but since we'll define a modular mechanism, we could end up having cases where it's necessary and some not16:52
bauzasdansmith: that answer suits me16:52
*** slaweq has joined #openstack-nova16:52
dansmithyeah, each one could do a different thing with the persisted data16:53
mriedemyeah we'd definitely need this for any move operations16:53
bauzasdansmith: we could persist that, but we shouldn't use that value on a later reschedule but rather recalculate it16:53
bauzasthat being a per-filter policy16:53
dansmithbauzas: depends16:53
dansmithyeah16:53
dansmithI will reply16:53
bauzascool16:53
bauzasone last point16:53
bauzasbut it's a nit16:53
bauzasI'm poor at wording16:53
bauzasbut I'm afraid the word "filter" carries a lot of context16:54
bauzasso I'd prefer to use a synonym for that mechanism16:54
bauzasI know it's sneaky16:54
bauzasso feel free to NACK me16:54
dansmithbauzas: it's not exposed as a filter to the user or admin at all16:54
dansmithbauzas: so we can change it either now or later if it becomes a problem16:55
bauzasyeah it's just wording16:55
dansmithbut, IMHO, it's not a big enough deal to rename the things I have already :)16:55
bauzaslike we have nova aggs and placement aggs16:55
bauzasdansmith: not requiring a respin of your spec16:55
bauzasdansmith: but maybe we should consider that in your series :)16:55
dansmithbauzas: well feel free to take exception to it in the code if you still feel that way yeah16:56
bauzasscheduler filters and request filters seem very identical to me in terms16:56
bauzasagain, it's maybe me overreacting on some blueprints I could see in the future16:56
*** tidwellr has quit IRC16:56
dansmithwhat word do you like better?16:57
openstackgerritMarcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe slots in aarch64 instance  https://review.openstack.org/54503416:57
*** slaweq has quit IRC16:57
*** tidwellr has joined #openstack-nova16:57
hrwcna someone take a look at that patch? mriedem stephenfin bauzas?16:57
bauzasdansmith: from a French folk, the Thesaurus tells me "strain"16:57
dansmithlol16:57
bauzasbut anyway, I feel ashamed of nitpicking on that16:57
dansmiththat would make no sense to an english speaker16:58
bauzasthe history of nova told me that there are 3 NP problems16:58
bauzasdistibuted locks16:58
bauzasNFV16:58
bauzasor BFV even16:58
bauzasand naming things16:58
bauzasnaming a new thing requires 3 cycles at least16:59
bauzasin order to get consensus16:59
bauzasso, anyway, let's just pretend I never asked for that16:59
dansmithbauzas: as the only one who has (thus far) taken exception with the name, it's funny for you to be complaining about that :)16:59
bauzasI know, hence my apologies17:00
bauzaslet's pretend that discussion never existed17:00
bauzas(17:57:55) bauzas: but anyway, I feel ashamed of nitpicking on that17:00
*** sree has quit IRC17:00
*** sree has joined #openstack-nova17:01
mriedemhrw: busy atm, can you mark that WIP if it's the initial version w/o tests?17:02
hrwmriedem: ok17:02
hrwW-117:02
*** yamamoto has joined #openstack-nova17:03
openstackgerritMerged openstack/nova master: Don't JSON encode instance_info.traits for ironic  https://review.openstack.org/54357417:04
openstackgerritMerged openstack/nova master: Python 3 fix for sphinx doc  https://review.openstack.org/54495617:04
mriedemameeda: i think you're missing a unit test in https://review.openstack.org/#/c/528385/17:05
*** Matias_ has joined #openstack-nova17:06
*** sree has quit IRC17:06
mriedemotherwise i think that's mostly ok, outside of the commit message cleanup17:06
openstackgerritMark Goddard proposed openstack/nova stable/queens: Don't JSON encode instance_info.traits for ironic  https://review.openstack.org/54503717:06
*** Matias_ is now known as Matias17:07
*** yamamoto has quit IRC17:08
*** Tom-Tom has joined #openstack-nova17:09
*** Tom-Tom has quit IRC17:14
*** sshwarts has quit IRC17:14
*** abhishekk has joined #openstack-nova17:15
*** lpetrut has quit IRC17:18
*** sambetts is now known as sambetts|afk17:19
*** harlowja has joined #openstack-nova17:19
*** pcaruana has joined #openstack-nova17:20
*** yamahata has quit IRC17:20
mriedemstephenfin: i don't know what people want in here https://review.openstack.org/#/c/544015/17:22
*** suresh12 has quit IRC17:22
bauzasmriedem: dansmith: edleafe: cdent: I'm about to +W https://review.openstack.org/#/c/544585/17:22
bauzasif anyone has concerns, that's the moment17:22
bauzasoops, jaypipes too ^17:22
*** suresh12 has joined #openstack-nova17:23
dansmithmy only concern would be the dependent specs, if people want those landed first17:23
dansmithbut I don't mind either way really17:24
stephenfinmriedem: I think you identified what he was looking for, which was different to what I thought. Given that the caching scheduler is deprecated (I didn't know that), we don't need to worry about IMO17:24
*** Tom-Tom has joined #openstack-nova17:25
mriedembauzas: it is certainly possible to know if we're doing a first schedule or a reschedule,17:25
mriedemRequestSpec.retry has that information17:25
bauzasmriedem: for a reschedule yes17:26
bauzasmriedem: for a move operation, nope17:26
edleafebauzas: that's cool. At least there has been some discussion since my comment17:26
mriedembauzas: that's because https://review.openstack.org/#/c/505771/17:26
*** damien_r1 has quit IRC17:26
*** stephenfin has left #openstack-nova17:26
mriedemwell, the issue in ^ confuses the fact that you're doing a reschedule or a move17:26
*** stephenfin has joined #openstack-nova17:26
bauzasshit17:26
*** suresh12 has quit IRC17:27
*** belmoreira has quit IRC17:27
bauzashow many times will I regret to not have thought more on persisted fields for the RequestSpec object ?17:27
openstackgerritClaudiu Belu proposed openstack/nova master: compute: Cleans up allocations after failed resize  https://review.openstack.org/54397117:27
jaypipesbauzas: hold please.17:27
cdentbauzas: feel free to +w the spec if there's been enough feedback17:27
jaypipesstill reviewing17:28
mriedemi thought that would be an easy fix but then second guessed myself, and need to write a functional test to be sure17:28
cdentbauzas: except for jay :)17:28
bauzasjaypipes: ack17:28
efriedCould rebase it on top of the other spec17:29
*** cdent has quit IRC17:30
dansmithor someone could slam it in: https://review.openstack.org/#/c/544694/17:31
dansmithit's really simple, has a lot of +1s from stakeholders and only needs a +W17:31
mriedemlooking17:31
mriedemi will ram this down your throat like obamacare to the republicans17:32
* dansmith nods17:32
mriedemlemme call nancy quick17:32
dansmithlolol17:32
*** yamamoto has joined #openstack-nova17:32
openstackgerritJay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API  https://review.openstack.org/54505717:33
*** yamamoto has quit IRC17:33
dansmithapparently by "lots" I meant "two" but.. you know17:34
*** lpetrut has joined #openstack-nova17:34
mriedemconsider it rammed17:34
mriedemthanks obama17:35
mriedemthe two that matter17:35
jaypipesdansmith: cern doesn't use the cachingscheduler does it?17:38
mriedemtssurya: ^17:39
dansmithjaypipes: presumably not because they're working through placement issues right now17:39
jaypipesak17:39
openstackgerritMerged openstack/nova-specs master: Support member_of param for allocation candidates  https://review.openstack.org/54469417:40
*** moshele has joined #openstack-nova17:41
*** yamamoto has joined #openstack-nova17:41
tssuryamriedem, jaypipes, dansmith : no we don't17:42
mriedemexcellente17:42
*** moshele has quit IRC17:44
*** yamamoto has quit IRC17:46
*** amodi has quit IRC17:47
gibidansmith: I also left some comments / questions on https://review.openstack.org/#/c/544585 just now17:47
*** itlinux has joined #openstack-nova17:47
openstackgerritSurya Seetharaman proposed openstack/nova master: Extending delete_cell --force to delete instance_mappings  https://review.openstack.org/54007317:51
*** tesseract has quit IRC17:52
bauzasgibi: dansmith: I got the name. Let's call it "scheduler transformers" and name the first one "autobot"17:52
dansmithgibi: replying17:53
mriedemgibi: i cleaned up the commit message on this and added a simple unit test for detach failing, see if you still like it ^17:53
mriedemoops17:53
openstackgerritMatt Riedemann proposed openstack/nova master: Detach volumes when VM creation fails  https://review.openstack.org/52838517:53
mriedemgibi: ^17:53
bauzasplease folks, don't tell me about Shia LaBeouf or anything stupid like the movies17:53
gibimriedem: looking17:53
bauzasthey killed my childhood17:53
*** suresh12 has joined #openstack-nova17:54
*** yamahata has joined #openstack-nova17:58
*** suresh12 has quit IRC17:58
*** amodi has joined #openstack-nova17:58
mriedemgibi: and left a comment17:58
*** tssurya has quit IRC17:59
*** derekh has quit IRC17:59
mriedemdeleting the volume before we reschedule is kind of dumb17:59
mriedemlet's say i boot from volume with a pre-existing volume,17:59
gibimriedem: oops, +Wd it17:59
mriedemspawn on the first host fails after i've attached the instance to the volume,17:59
mriedemwe then detach and delete the volume, and reschedule,17:59
mriedemthen we get to the 2nd host, and attach will fail b/c the volume is gone17:59
mriedemwell i was +2,18:00
mriedemand might still be,18:00
mriedembecause this is a latent thing that's always been in here, but i just don't think it's ever worked because of the bug he's fixing18:00
gibimriedem: I see. I guess this is a new bug report then18:00
*** AlexeyAbashkin has joined #openstack-nova18:01
gibimriedem: we fixed something that allowed another latent bug to manifest itself18:02
mriedemat least delete_on_termination defaults to False...18:03
mriedemthis is also kind of why i didn't like the spec proposed for doing delete_on_termination with ports18:03
mriedemsince nova is not good at orchestrating this18:03
*** mgoddard_ has quit IRC18:04
gibiI also think that nova should only delete these if nova was the one that created them in the first place. But it would be even better if nova would never create these things18:04
mriedemyeah that's the exact thing i was thinking18:04
*** dtantsur is now known as dtantsur|afk18:04
mriedemand we handle that with ports by storing a flag if nova created the port or not18:04
mriedemin the nw info cache18:05
mriedembecause if nova did create this volume and attach it, then we fail and reschedule but don't delete it, we'll create another volume on the next host we try18:05
mriedemand never cleanup the old one18:05
mriedemand given enough retries, you could also hit quota limits on creating volumes18:06
*** AlexeyAbashkin has quit IRC18:06
mriedemoh, well we do know if nova created it actually,18:06
mriedemif source_type=volume, it's pre-created18:06
mriedemok i left some notes in the review so we can remember this conversation 2 years from now18:08
mriedemwhen it's still a bug :)18:08
imacdonnwas something fixed recently-ish w.r.t. ports on reschedule .... seems I've seen issues with an exception, something like PortInUse, when an instance creation fails and gets rescheduled on another compute node, but that probably was with Ocata18:09
openstackgerritMerged openstack/nova-specs master: Add placement-req-filter spec  https://review.openstack.org/54458518:09
mriedemimacdonn: that's pretty vague18:10
openstackgerritLee Yarwood proposed openstack/nova master: DNM: Test LM with encrypted volumes  https://review.openstack.org/53635018:10
mriedemhttps://github.com/openstack/nova/commit/08d24b733ee9f4da44bfbb8d6d3914924a41ccdc went into newton18:10
mriedem*mitaka18:10
gibimriedem: thanks for that note18:10
mriedemimacdonn: i have this https://review.openstack.org/#/c/520248/18:11
mriedembut might not be what you're asking about18:11
imacdonnmriedem: yeah, I know ... I'd have to try to come up with a way to reproduce it ... but it's likely that the port was not created by nova, in my case .. because I use heat a lot, and usually create the port separately there18:11
openstackgerritLee Yarwood proposed openstack/nova stable/pike: DNM: Test LM with encrypted volumes  https://review.openstack.org/54507418:11
*** yamamoto has joined #openstack-nova18:11
mriedemimacdonn: in that case nova shouldn't try to delete the port18:12
mriedemjust unbind it18:12
gibidansmith: thanks for the reply on the request filter spec. I have a better view now, so I'm +118:12
mriedemif nova didn't unbind it and a reschedule tried to bind that host to another host, that would fail18:12
dansmithgibi: np, thanks for those comments18:13
* gibi calls it a day18:13
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Detach volumes when VM creation fails  https://review.openstack.org/54414418:13
imacdonnmriedem: yeah. I'm fairly sure I've seen this with Ocata .. but it's one of those things that only happens when something else goes wrong (to cause the initial creation failure), so it never got hot enough for me to really dig into ... you just reminded me of if when you mentioned ports above18:14
*** jpena is now known as jpena|off18:14
*** kukacz has quit IRC18:15
mriedemat the risk of angering the gods, i think we actually do a relatively decent job of managing ports and cleaning up after ourselves18:15
mriedemwith volumes, not so much18:15
imacdonnheh. I'll try to find time to attempt to reproduce it ... but my "round tuit" supply is low18:16
mriedemi understand18:16
*** yamamoto has quit IRC18:16
*** ralonsoh_ has quit IRC18:17
imacdonnI guess you really can by ANYTHING on Amazon! https://www.amazon.com/Round-TUIT-Tokens-Multi-Pack-Encouragement/dp/B00J8KVHLY18:18
mriedemheh, find me a hang in there poster with a kitten that doesn't suck18:18
mriedemand doesn't say "baby" on it18:18
imacdonnadded to my todo list .. I'm try when it .... well, you know...18:19
mriedemhttps://play.google.com/store/books/details?id=KEMFmlv1uKcC&source=productsearch&utm_source=HA_Desktop_US&utm_medium=SEM&utm_campaign=PLA&pcampaignid=MKTAD0930BO1&gclid=Cj0KCQiA_JTUBRD4ARIsAL7_VeXOQT1TCYHJZb7ifQDAGqbTm2uSwLsNB0_bR7o0pTSXHwROSrbpsSUaAtxPEALw_wcB&gclsrc=aw.ds&dclid=CLC_ypvEqNkCFYzdwAod8RYOVg18:19
mriedemoh there is one on amazon now, well goes to show demand is up since last i checked18:19
*** kukacz_ has joined #openstack-nova18:20
*** slaweq has joined #openstack-nova18:20
mriedemjaypipes: even have one for you https://ih0.redbubble.net/image.475009417.6220/flat,800x800,070,f.u5.jpg18:20
*** amoralej is now known as amoralej|off18:21
*** gibi has quit IRC18:22
*** slaweq has quit IRC18:25
openstackgerritDan Smith proposed openstack/nova master: WIP: Add require_tenant_aggregate request filter  https://review.openstack.org/54500218:28
openstackgerritDan Smith proposed openstack/nova master: WIP: Add a require_tenant_trait request filter  https://review.openstack.org/54507918:28
dansmithefried: ^ example of using traits to do the tenant isolation as an alternative18:28
efrieddansmith: Nice, looking.18:29
dansmithefried: and a question in there you can probably answer and save me a few minutes of reading18:29
*** suresh12 has joined #openstack-nova18:29
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Detach volumes when VM creation fails  https://review.openstack.org/54414318:30
melwittefried: ack, np18:33
*** yamamoto has joined #openstack-nova18:35
*** yamamoto has quit IRC18:35
melwittmriedem: yep, good point to avoid nova-net and cells v1 for mox -> mock18:36
efrieddansmith: Responded18:38
*** lpetrut has quit IRC18:38
*** lpetrut has joined #openstack-nova18:39
*** mgoddard_ has joined #openstack-nova18:39
dansmithefried: tanks18:40
openstackgerritMatt Riedemann proposed openstack/nova stable/ocata: Clean up volumes on boot failure  https://review.openstack.org/54508618:42
openstackgerritMatt Riedemann proposed openstack/nova stable/ocata: Detach volumes when VM creation fails  https://review.openstack.org/54508718:42
openstackgerritDan Smith proposed openstack/nova master: WIP: Add require_tenant_trait request filter  https://review.openstack.org/54507918:42
TheJuliadansmith: so we managed to get nova not to crash in ironic's grenade jobs.... we had to inject -B on to the python command line to prevent the .pyc files from being placed on disk18:42
dansmithTheJulia: I heard.. that sounds a lot like a python bug to me18:43
dansmithTheJulia: it's one thing if we get some broken call and an exception or something, but a segv seems way out of the realm of reasonable to me18:43
*** jamesdenton has joined #openstack-nova18:43
TheJuliadansmith: I believe it is officially a feature....18:43
dansmithTheJulia: ...18:43
TheJuliacertian app toolsets allow dynamic recompliation/reloading of python code in the app during runtime, the trick afaik is to remove the .pyc file which was likely occuring during upgrade18:44
TheJuliaregardless, we're hunting something breaking with placement18:44
*** abhishekk has quit IRC18:44
dansmithTheJulia: right, but that can't cause a segv and not be called a bug, IMHO18:45
efrieddansmith: The request_spec.project_id is always a UUID, yes?18:45
dansmithTheJulia: dynamic recompile is cool, even if it causes some python call imcompatibility or something, but not a segv18:45
dansmithefried: I think it depends on your keystone backend, no?18:45
dansmithTheJulia: what placement thing are you chasing now?18:45
dansmithefried: I bet lbragstad knows18:46
dansmithefried: https://github.com/midokura/python-midonetclient/issues/1918:47
efrieddansmith: no idea, swhy I'm asking.  Cause it's gonna make a difference how much you have to sanitize it, etc.18:47
efriedBut18:47
efriedI think we may be barking up the wrong tree anyway.  Don't we actually want the trait to be CUSTOM_HOST_AGGREGATE_{agg_id} ?18:47
lbragstadefried it depends on the resource backend being used18:47
TheJuliadansmith: http://logs.openstack.org/50/544750/8/check/ironic-grenade-dsvm-multinode-multitenant/5713fb8/logs/screen-placement-api.txt.gz#_Feb_15_18_00_31_109054 after everything gets up and running and nova-compute is able to post data back out, we're getting a conflict, but I'm afraid we don't understand the mechanisms in that publishing/use of data18:47
dansmithefried: I don't :)18:47
TheJuliadansmith: to then go backwards and figure out what is truly causing that failure18:48
dansmithTheJulia: hmm, that's interesting18:48
dansmithjaypipes: ^18:48
lbragstadefried if keystone is told to pull projects from something other than the default sql backend, then we can't guarantee them to be uuids18:49
dansmithTheJulia: I'm not sure that's really a blocking thing.. is there a matching failure in the n-cpu log?18:49
TheJuliahttp://logs.openstack.org/50/544750/8/check/ironic-grenade-dsvm-multinode-multitenant/5713fb8/logs/screen-n-cpu.txt.gz#_Feb_15_18_00_31_11274418:49
efriedlbragstad: Thanks.18:49
lbragstadefried yep18:50
dansmithTheJulia: okay that almost maybe kinda looks like someone changed ids or there's some confusion going on18:50
dansmithTheJulia: multiple nova-computes? multiple ironic nodes?18:50
dansmithactually, efried ^18:52
TheJuliadansmith: 2x n-cpu running pike, 2x ironic-conductor (1 master, 1 queens) 1x ironic api running queens.18:52
jrolland multiple ironic nodes18:52
TheJuliayup18:52
TheJulia7 of them18:52
dansmithefried: this is during a upgrade, any chance the report client being providertreeish after the upgrade is breaking something?18:52
*** claudiub has joined #openstack-nova18:52
dansmithbecause it's ensuring that the provider exists, and then freaking out because it does18:52
jrollreminder it could be a real incompatibility between pike nova and queens ironic, given this test has been off for weeks18:52
jrolldansmith: still pike nova18:52
* efried looks18:52
dansmithjroll: ah, right18:53
TheJuliajroll: it should presently be queens -> master, I'll double check (since the devstack-gate patch was involved)18:53
jrolloh, right18:53
dansmithokay so queens nova code yeah?18:53
jrollwhich shouldn't be much different than queens/queens which has been working18:54
jrolldansmith: yes, sorry18:54
jrollqueens nova on both sides18:54
dansmithack18:54
TheJuliajroll: we should propably cherry-pick the patch to stable/queens and let it run to see what the case is there...18:54
jaypipesmriedem: heh18:54
jrollTheJulia: wouldn't hurt18:54
TheJuliajroll: going to click button18:55
jrollthank you18:55
*** rmcall has quit IRC18:55
dansmithwell, queens code still has the provider tree stuff so still worth efried looking at I think18:55
dansmithalthough weird that it would be different/broken across such a small upgrade boundary18:56
jrollyeah, that's my thought18:56
TheJuliadansmith: in the mean time, we can check the pike -> queens job results and see if it is broken the same way18:56
efriedYup, I'm looking.  We shouldn't be able to get here except by really bad timing.18:56
*** oomichi has joined #openstack-nova18:56
efriedTheJulia: And you said it happened more than once?18:56
dansmithmore than once in the logs even18:56
dansmithon each sync18:56
jrollcould also be a problem with our multinode, whether it's queens+queens or queens+master18:56
TheJuliaefried: we have _not_ tried to recheck in case it was some process fluke18:57
efriedNo, this simply shouldn't happen, still looking...18:57
*** lucasagomes is now known as lucas-afk19:00
*** harlowja has quit IRC19:00
efriedOkay, this is a *name* conflict, not a *uuid* conflict.  This means we somehow got two RPs with different UUIDs but the same name.19:00
efriedand the name is a UUID, which is nice and confusing.19:00
cfriesenmriedem: with respect to https://review.openstack.org/#/c/544748/ and my proposed change https://review.openstack.org/#/c/525253/.  In our case it passes scheduling but then fails for whatever reason on the compute node.  As such, the proposed fix is not sufficient because we would not end up calling _bury_in_cell0().19:00
efriedI thought johnthetubaguy was banging his head against this last Fall.19:00
jrollefried: the name would be the ironic uuid, right?19:00
efriedjroll: I'm not an expert there, but yeah, something like that.19:01
dansmithefried: I wonder if we detected the ironic node go away and come back and we're trying to recreate it but never deleted it?19:01
dansmithjroll: yes19:01
jrollI seem to remember this being john's head banging https://review.openstack.org/#/c/508555/19:01
jrollbut there shouldn't be a rebalance happening19:02
efriedjroll: Beat me to it, yeah, that's the patch I was thinking of.19:02
efriedbut there was more to it than that, I thought.19:03
jrollnot sure19:03
*** gyee has joined #openstack-nova19:03
openstackgerritJay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API  https://review.openstack.org/54505719:04
jrollthe title on the bug certainly looks like this problem: https://bugs.launchpad.net/nova/+bug/171424819:04
openstackLaunchpad bug 1714248 in OpenStack Compute (nova) pike "Compute node HA for ironic doesn't work due to the name duplication of Resource Provider " [High,In progress] - Assigned to Matt Riedemann (mriedem)19:04
efriedThere was another patch where we mucked with one of the rt update methods to look for things with different names.19:04
dansmithjroll: if ironic was down and the two nova computes notice it is back at different times maybe they could be disagreeing briefly on who owns what?19:04
jrolldansmith: yeah, trying to track down if it's long enough to trigger a rebalance19:05
jrollservicegroup api tells us19:05
melwittmriedem: FYI, digging into the difference between the cleanup volumes vs ports bugs today19:06
melwittbased on your comments in the patch19:06
*** burt has joined #openstack-nova19:06
openstackgerritLee Yarwood proposed openstack/nova stable/queens: DNM: Test LM with encrypted volumes  https://review.openstack.org/54509319:08
jrolldansmith: ah yep, the subnode n-cpu considers itself down at this point, I believe http://logs.openstack.org/50/544750/8/check/ironic-grenade-dsvm-multinode-multitenant/5713fb8/logs/subnode-2/screen-n-cpu.txt.gz#_Feb_15_17_59_05_73806919:09
jrollironic is unreachable for like 5 minutes19:10
jrollor rather a full resource tracker run and then some19:10
openstackgerritJackie Truong proposed openstack/python-novaclient master: Microversion 2.61 - Add trusted_image_certificates  https://review.openstack.org/50039619:11
mriedemcfriesen: then what you have here https://review.openstack.org/#/c/525253/1/nova/conductor/manager.py doesn't help you19:12
mriedemcfriesen: so i'm confused19:12
mriedemcfriesen: is https://review.openstack.org/#/c/528385/ what you are looking for?19:12
dansmithjroll: yeah, but with johnthetubaguy's reuse-compute-node patch I would think this wouldn't be a problem right?19:12
jrollaaaand we have some problems deleting RPs: http://logs.openstack.org/50/544750/8/check/ironic-grenade-dsvm-multinode-multitenant/5713fb8/logs/screen-n-cpu.txt.gz#_Feb_15_17_58_22_41887519:12
jroll(wtf)19:13
jrolldansmith: I would think so too, just confirming there is likely a rebalance, so they could be disagreeing19:13
dansmithyeah19:13
dansmithjroll: ah, that 503 during deleting is weird19:13
jrolldansmith: indeed19:14
dansmithjroll: do you guys have to restart apache?19:14
TheJuliadansmith: we do19:14
dansmithokay19:14
dansmithalso19:14
TheJuliawe update the configuration to load a vhost19:14
TheJuliawe also shutdown services at 17:55 for the upgrade, nova would have remained running19:15
dansmithif placement is crashing the same way as conductor, maybe placement is dead under apache, hence the 503?19:15
jrollgood lord keystone db migrations are spammy19:15
dansmithuntil you restart?19:15
TheJuliaso 17:58 is when everything is down19:15
dansmiththus nova never got to delete the RPs19:15
TheJuliaI think the restart is during the ironic upgrade, checking to see when it actually occured19:15
dansmithright, but if placement started crashing during the upgrade of packages,19:16
dansmithwhich is when nova would have noticed ironic went away and tried to delete RPs or something,19:16
jrollOH19:16
jrollkeystone is upgrading there19:16
jrolland so placement can't validate the token19:16
dansmithand then you restart apache..19:16
dansmithohh19:16
jrollhttp://logs.openstack.org/50/544750/8/check/ironic-grenade-dsvm-multinode-multitenant/5713fb8/logs/screen-placement-api.txt.gz#_Feb_15_17_58_22_46322819:16
*** felipemonteiro_ has quit IRC19:16
mriedemmelwitt: i'm likely also going to start writing a functional test for the case that we delete a build request for a bfv instance during local delete, because we aren't cleaning up volumes there either19:17
*** felipemonteiro_ has joined #openstack-nova19:17
dansmithand you get a bug, and you get a bug, and you get a bug...19:17
* jroll makes a note to file a bug to not 503 placement here19:17
dansmithjroll: good catch19:17
melwittmriedem: ack19:17
TheJuliahttp://logs.openstack.org/50/544750/8/check/ironic-grenade-dsvm-multinode-multitenant/5713fb8/logs/grenade.sh.txt.gz#_2018-02-15_18_00_28_322 is when we restart apache19:17
dansmithjroll: surely you're not intending to have keystone be upgradingin this task right?19:17
dansmiths/task/job/19:17
jrolldansmith: I think we just haven't cared either way in the past19:18
jrollkeystone's one of those hand-wavy things to me, it's always there, don't care what version19:18
dansmithjroll: do you care now? :P19:18
jrollheh19:18
openstackgerritMatt Riedemann proposed openstack/nova master: Add admin guide doc on volume multiattach support  https://review.openstack.org/54409019:21
TheJuliajroll: we could just skip restarting apache and fire up the local ironic-api, however then we're not forcing traffic through an older API endpoint which changes the scenario, although we would still have the rpc version pin19:21
mriedembauzas: since you helped review the multiattach series, can you check out ^ so we can backport that for queens RC2?19:21
jrollTheJulia: eh, I'd rather not19:22
jrollalso these times aren't lining up :/19:22
TheJuliaactually, other services will still likely need to restart things19:22
TheJuliaso we shouldn't try to avoid restarting apache19:22
jrolloh it does line up, okay19:22
jrollTheJulia: maybe we um, try to make apache not need 66 seconds to restart19:23
TheJuliaheh, 28 apache restarts in the grenade log19:23
jrolljesus19:23
dansmithwow19:23
dansmiththat's impressive19:23
mriedemthe edge people said openstack needed to be slimmed down19:23
TheJuliayeah....19:24
cfriesenmriedem: I think you're right, I got messed up with which patch was fixing what. :)   the fixes at https://review.openstack.org/#/c/528385 and https://review.openstack.org/#/c/340614/ look like they might do the trick.19:24
mriedemcfriesen: cool19:24
mriedemit is confusing19:24
mriedemcfriesen: the point of creating the bdms in cell0 also was so that the local delete in the api can remove them19:24
mriedemand thus avoid us having nova-compute, nova-api AND nova-conductor doing volume cleanup19:25
TheJuliajroll: what makes you think 66 seconds?19:25
jrollTheJulia: this line to the next one: http://logs.openstack.org/50/544750/8/check/ironic-grenade-dsvm-multinode-multitenant/5713fb8/logs/screen-keystone.txt.gz#_Feb_15_17_57_44_53887819:26
jrollit isn't 66 seconds to restart19:26
jrollnor is it an apache thing19:26
jrollbut we shut down keystone for the entire keystone upgrade19:26
TheJuliaahh, yeah19:26
jrollwhich is silly19:27
*** r-daneel has quit IRC19:27
TheJuliaWell.... are we sure it is not silly?19:27
jrollI would think keystone should be able to do rolling upgrades very easily19:28
jrollbut they don't have the magic tag, so who knows19:28
* jroll needs to stand up and move for a bit19:29
* jroll is thinking placement should be able to handle this, but needs to load in all the context to be sure19:29
dansmithwell, it's not really placement, it's nova-compute right?19:30
dansmithwe're probably not handling the 503 very gracefully in compute whilst trying to do things19:30
*** mriedem has left #openstack-nova19:32
*** mriedem has joined #openstack-nova19:32
*** slaweq has joined #openstack-nova19:33
mriedemis the 503 this? https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L9319:33
dansmithI woudn't think so, we're getting a response19:34
oomichihi, can someone take a look at https://review.openstack.org/#/c/532822 ?  that is easy and completely the same patch is posted. so want to avoid the same thing19:34
dansmithwe just raise and kill the RT19:34
*** harlowja has joined #openstack-nova19:35
*** yamamoto has joined #openstack-nova19:35
oomichithanks, mriedem19:37
*** harlowja_ has joined #openstack-nova19:37
*** harlowja has quit IRC19:39
mriedemmelwitt: i went ahead and created this for tracking the community wide goal and linked it to the other 4 bp's we've had in the past for the same thing https://blueprints.launchpad.net/nova/+spec/mox-removal19:40
*** lpetrut has quit IRC19:40
openstackgerritJay Pipes proposed openstack/nova-specs master: Account for host agg allocation ratio in placement  https://review.openstack.org/54468319:40
mriedemand marked the other as done https://review.openstack.org/54510019:41
melwittmriedem: great, thank you19:41
jaypipesbauzas, cdent, edleafe, dansmith, mriedem, efried: ^^ round two on the aggregate allocation ratio one.19:41
openstackgerritJay Pipes proposed openstack/nova-specs master: Account for host agg allocation ratio in placement  https://review.openstack.org/54468319:43
mriedemmelwitt: i also assume we'll want 2 blueprints for removing nova-network and cellsv119:44
mriedemas those likely won't be a single change19:44
openstackgerritJay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API  https://review.openstack.org/54505719:44
melwittmriedem: yeah, I don't think they would be a single change19:44
mriedemi'm not sure on the order there though, probably nova-network first since you can't start nova-network w/o cells v1 enabled19:44
mriedemand some people run cellsv1 with neutron19:45
*** mgoddard_ has quit IRC19:45
*** yamamoto has quit IRC19:45
openstackgerritJay Pipes proposed openstack/nova-specs master: Account for host agg allocation ratio in placement  https://review.openstack.org/54468319:46
efriedjaypipes: Ya done yet?19:50
*** munishmehan has joined #openstack-nova19:53
jaypipesefried: yeah, sorry :)19:58
*** pchavva has quit IRC20:01
*** pcaruana has quit IRC20:03
*** suresh12 has quit IRC20:04
*** suresh12 has joined #openstack-nova20:05
*** suresh12 has quit IRC20:09
openstackgerritMatt Riedemann proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits  https://review.openstack.org/53849820:10
*** sree has joined #openstack-nova20:11
openstackgerritMatt Riedemann proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits  https://review.openstack.org/53849820:14
*** tssurya has joined #openstack-nova20:14
*** AlexeyAbashkin has joined #openstack-nova20:15
*** sree has quit IRC20:15
*** kukacz_ has quit IRC20:17
*** AlexeyAbashkin has quit IRC20:19
openstackgerritJay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API  https://review.openstack.org/54505720:19
mnasermriedem: do i have to make any changes at this point for the clean up patch .. i know there's a lot of discussion but anything actionable for me right now?20:24
mriedemmnaser: nope20:25
* jaypipes wondering if mnaser ever sleeps...20:25
*** tidwellr has quit IRC20:25
*** tidwellr has joined #openstack-nova20:25
mnaserjaypipes: ahah.  words that once i settle down with someone + kids, time disappers20:26
mnaserenjoying it while it lasts, ha20:26
*** READ10 has quit IRC20:29
mriedemyou can still have a family, and ignore them20:29
jaypipesmnaser: :)20:29
mnaserhaha20:29
* mnaser has honestly enjoyed every bit of working in openstack for the past few years20:29
jaypipesmnaser: that's awesome to hear!20:29
jrollthat is awesome, but I'm skeptical, *every* bit?20:30
jroll:P20:30
mnaserjaypipes: :D20:30
mnaserjroll: it helps having super awesome understanding customers that know all about open source projects20:30
*** hongbin has quit IRC20:31
mnaserany issues we usually work with them to iron out and work with openstack teams to roll fixes out and everyone's happy20:31
jrollsweet :)20:31
*** r-daneel has joined #openstack-nova20:31
jaypipesmnaser: perhaps you can come visit with my internal customers ... ;)20:31
mnasermaybe they should just use us and make your life easier </salesman>20:32
mnaserhaha20:32
jaypipesmnaser: ++ :)20:32
*** hongbin has joined #openstack-nova20:32
jrolljaypipes: wow, trying to drag mnaser down so quickly after mentioning the fun20:32
mnaseri'm just a bit bummed that i don't think we'll be able to get to queens right away20:33
jaypipeslol20:33
mnasermainly because we have consumers using the images v1 api20:33
openstackgerritMatthew Edmonds proposed openstack/nova-specs master: PowerVM Virt Integration (Rocky)  https://review.openstack.org/54511120:34
mnaserjaypipes: will you be at the ptg?20:36
jaypipesmnaser: yessir20:36
mnaserjaypipes: lets chat money sinks aka cars one day (maybe if nova is having a dinner? :p)20:37
dansmithooh ooh, me me20:38
mnaser:D20:39
openstackgerritMatthew Edmonds proposed openstack/nova-specs master: PowerVM Virt Integration (Rocky)  https://review.openstack.org/54511120:40
jaypipesdansmith, mnaser: I am always up for that :)20:41
mnaserdoes anyone want to organize a lunch or a dinner for the nova team? :>20:42
*** andreas_s has joined #openstack-nova20:43
mriedemmnaser: i think you just did20:43
mriedemthursday night20:43
mriedemcburgess was the food czar but i don't know if he'll be in dublin20:44
mriedemactually, we should make stephenfin organize a dinner since he's local20:44
*** mgoddard_ has joined #openstack-nova20:46
*** andreas_s has quit IRC20:47
melwittnova meeting in 10 minutes20:50
openstackgerritMatthew Edmonds proposed openstack/nova-specs master: PowerVM Virt Integration (Rocky)  https://review.openstack.org/54511120:51
efriedmriedem: Small delta reproposal from Q to R ^20:52
*** takashin has joined #openstack-nova20:56
mriedemyour call will be processed in the order in which it was received20:59
dansmithhandled20:59
dansmithyou don't process calls20:59
dansmithduh.20:59
mriedemi made a phone call today20:59
mriedemwith my phone20:59
mnasermriedem: a local organizing it might be way better than me :>20:59
mriedemi like to consider myself enterprise business solutions21:00
mriedemmnaser: i've got a recreate functional test for the bfv + delete build request issue, will push up shortly21:01
*** ttsiouts_ has joined #openstack-nova21:04
*** mgoddard_ has quit IRC21:05
openstackgerritMatt Riedemann proposed openstack/nova master: Add functional recreate test of deleting a BFV server pre-scheduling  https://review.openstack.org/54512321:05
mriedemmnaser: ^21:05
cburgessmriedem Tragically I will not be in dublin. I think I can make it to Vancouver, but probably won't be in Berlin. Might be able to swing Fall PTG is its North America.21:11
dansmithcburgess: boo :(21:13
cburgessdansmith Yeah, since the product is no in sustaining mode I don't have budget to travel. I do have budget for "training" so I can swing 1 or 2 openstack events a year that way but I can do all 4 now.21:14
cburgesss/no/now21:14
dansmithyeah :/21:14
cburgessdansmith But like I said, I'm working on being in Vancouver.21:16
dansmithwell, I'll take it21:16
openstackgerritMerged openstack/nova master: libvirt: remove TODO on validation of scsi model  https://review.openstack.org/52505521:17
*** burt has quit IRC21:18
*** sree has joined #openstack-nova21:20
openstackgerritJackie Truong proposed openstack/python-novaclient master: Microversion 2.61 - Add trusted_image_certificates  https://review.openstack.org/50039621:23
cburgesshave fun in dublin for me. Always wanted to go to Ireland.21:23
edmondswmelwitt you asked about 3rd party CI failures... the powervm CI (and presumably others) was failing for the tinyrpc issue that is hopefully fixed by https://review.openstack.org/#/c/545033/21:24
*** burt has joined #openstack-nova21:24
*** sree has quit IRC21:24
edmondswefried FYI ^21:25
*** tidwellr_ has joined #openstack-nova21:26
*** tidwellr has quit IRC21:26
melwittedmondsw: ah, thanks for that info21:27
edmondswnp21:27
*** ttsiouts_ has quit IRC21:27
*** suresh12 has joined #openstack-nova21:29
edmondswmelwitt looks like that hasn't merged yet for master, but has +W: https://review.openstack.org/#/c/545025/21:30
*** pcaruana has joined #openstack-nova21:31
melwittedmondsw: ack, thanks21:31
openstackgerritTakashi NATSUME proposed openstack/nova master: List/show all server migration types (1/2)  https://review.openstack.org/43060821:31
openstackgerritTakashi NATSUME proposed openstack/nova master: List/show all server migration types (2/2)  https://review.openstack.org/45948321:32
openstackgerritMerged openstack/nova master: Detach volumes when VM creation fails  https://review.openstack.org/52838521:33
openstackgerritTakashi NATSUME proposed openstack/python-novaclient master: Microversion 2.61 - List/Show all server migration types  https://review.openstack.org/43083921:33
openstackgerritTakashi NATSUME proposed openstack/nova master: Adds view builders for keypairs controller  https://review.openstack.org/34728921:34
openstackgerritMatt Riedemann proposed openstack/nova master: Add functional recreate test of deleting a BFV server pre-scheduling  https://review.openstack.org/54512321:37
openstackgerritMatt Riedemann proposed openstack/nova master: Detach volumes when deleting a BFV server pre-scheduling  https://review.openstack.org/54513221:37
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers.inc  https://review.openstack.org/52820121:37
mriedemmelwitt: mnaser: ^ thar she blar21:37
mriedemthat was actually pretty easy21:37
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Example verification for servers.inc  https://review.openstack.org/52952021:37
openstackgerritTakashi NATSUME proposed openstack/nova master: Fix 500 error while passing 4-byte unicode data  https://review.openstack.org/40751421:38
melwittBFV + easy ... that might be a first21:38
*** tidwellr_ has quit IRC21:38
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Fix parameter order in rebuild  https://review.openstack.org/52971821:38
openstackgerritTakashi NATSUME proposed openstack/nova master: Transform live_migration_post_dest notification  https://review.openstack.org/46978421:39
*** tbachman has quit IRC21:39
mriedemeasy like bfv morning21:42
melwittlol21:42
*** Lingwu has quit IRC21:43
*** openstack has joined #openstack-nova21:45
*** ChanServ sets mode: +o openstack21:45
*** cdent has joined #openstack-nova21:45
*** hamzy has quit IRC21:46
*** tidwellr has joined #openstack-nova21:47
*** pcaruana has quit IRC21:48
*** felipemonteiro_ has quit IRC21:48
*** rcernin has joined #openstack-nova21:50
mriedemmelwitt: replied in https://review.openstack.org/#/c/340614/ - i think it's mostly a matter of cleaning up the commit message and comments for clarity21:51
mriedemthe rest i'm OK with after mnaser sorted me out earlier today21:51
melwittmriedem: that's what I gathered too, thanks. just have to take another pass to try and make it not confusing. which has been surprisingly hard21:52
*** oomichi has quit IRC21:52
mriedemdansmith: how would you like to do something exciting like go through the stable/queens backports and figure out what we want to get into RC2?21:55
mriedemdansmith: or do you want me to take a pass, +2 what i think is safe, and then prod you21:55
dansmithdefinitely the latter :P21:56
mriedemheh i figured21:56
*** awaugama has quit IRC21:56
imacdonnmriedem: FYI, I have been able to reproduce the issue where a rescheduled instance fails with a PortInUse exception (https://pastebin.com/6HAL944i)... on Ocata .. I guess I'll try on Pike next (in spare time)21:59
*** tssurya has quit IRC21:59
*** tssurya has joined #openstack-nova22:00
*** tssurya has quit IRC22:00
*** tssurya has joined #openstack-nova22:00
*** tssurya has quit IRC22:01
mriedemdansmith: while i do that, mayhap you'd be so kind as to review these simple docs changes https://review.openstack.org/#/c/544090/ (and the one below it) so i can backport those to queens as well22:02
dansmithmriedem: mayhap done22:05
mriedemgreat22:05
mriedemdo you feel sufficiently up to date on volume multiattach now?22:06
*** suresh12 has quit IRC22:06
dansmithoh totes22:08
*** felipemonteiro__ has quit IRC22:09
*** felipemonteiro__ has joined #openstack-nova22:10
*** belmoreira has joined #openstack-nova22:11
mriedemdansmith: how do you feel about this one for queens? https://review.openstack.org/#/c/543489/22:13
mriedemRC2 i mean22:13
dansmithidk, I'd like to see those backported, but they don't _have_ to be in rc222:13
mriedemif it's low impact/low risk i think it's ok22:14
belmoreiradansmith thanks for https://review.openstack.org/#/c/544585 I added few comments to clarify how we use the cell-scheduler in cellsV122:14
dansmithbelmoreira: I think you're probably going to have to be willing to tweak some of your current mappings to make things work,22:16
dansmithbut yes, we can have more filters with more behaviors,22:16
dansmithand/or tweak the stuff I have proposed22:17
dansmithbelmoreira: https://review.openstack.org/#/c/545002/22:17
dansmithbelmoreira: I would like to understand more about why aggregates are more complicated at your scale, as they're pretty much intended to simplify stuff at higher scale22:17
openstackgerritMerged openstack/nova master: Cleanup the manage-volumes admin doc  https://review.openstack.org/54406622:18
dansmithmaybe we can hear from you/surya in dublin about it22:18
openstackgerritMerged openstack/nova master: Add admin guide doc on volume multiattach support  https://review.openstack.org/54409022:18
mriedemdansmith: ok +2s on the stuff that i thought was fine; https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens - mine that aren't -W are up for review also, since i can't +2 those; i also didn't do takashi's for the placement global req id since they are rather large, but could maybe convinced otherwise22:18
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Cleanup the manage-volumes admin doc  https://review.openstack.org/54514122:20
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Add admin guide doc on volume multiattach support  https://review.openstack.org/54514222:20
mriedemand these ^22:20
dansmithokay let me hit your +2s first22:21
dansmithah yeah all those +2s other than the UC ones are things I had reviewed on master22:22
mnasermelwitt: mriedem so i guess just updating the commit message remains but i'll leave that for melwitt i think she'll do a better job than i will :p22:24
belmoreiradansmith sure, I'm willing to tweak the current mappings to work with the new scheduler schema. I just wanted to describe how we currently do it for reference22:27
dansmithbelmoreira: okay, definitely appreciate that :)22:27
mriedembelmoreira: hard-coding projects in config is a bit odd22:27
mriedemhttps://gitlab.cern.ch/belmiro/cellsv1-filters/blob/master/target_cell_project.py#L2922:27
*** priteau has quit IRC22:29
*** priteau has joined #openstack-nova22:29
belmoreiramriedem I agree, that was the initial approach. Now the cell mapping is a property of the project. Just didn't remove that old code just in case...22:29
*** jaypipes has quit IRC22:30
*** jaypipes has joined #openstack-nova22:31
mriedemoh yeah i see now22:31
mriedemcells_mapping = client_key.get_cells_mapping(instance_project_id)22:31
mriedemif config, use those, else get the mappings from keystone22:31
belmoreiramriedem it was kept for the transition phase, when not all the projects had the cell mapping as a property22:31
belmoreiraI have >3000 projects :)22:32
mriedembelmoreira: i assume the complexity with host aggregates at that scale is that a lot of hosts are in a lot of different aggregates22:34
*** priteau has quit IRC22:34
mriedemhow much of the aggregate management is automated?22:34
belmoreiradansmith mriedem also because is very difficult to automate add/remove nodes22:35
dansmithwhy22:35
dansmith?22:35
dansmith(is it difficult)22:35
belmoreirausing a configuration management tool is not that safe/easy for this operations22:35
*** felipemonteiro_ has joined #openstack-nova22:35
dansmithsure, but this is done via the api22:36
belmoreirathat is one of the main reasons. The conf tool will need to have credentials for these operations22:36
mriedemremoving nodes is a problem i can see, there is no api for that really - we have delete service, but that doesn't cleanup the compute_nodes table entry22:37
dansmithbelmoreira: oh okay, I guess my point was .. maybe using conf management for this is not a good idea ;)22:37
dansmithmriedem: removing nodes what? you can remove a node from an aggregate via the api22:38
mriedemi assumed he was talking about dropping hosts22:38
mriedemnot add/remove aggregate members22:38
dansmithhmm22:39
belmoreiramriedem was talking about aggregate management using a conf management tool22:39
mriedemwhich spurred the discussion the other day about delete_cell needing a --ignore-placement flag or whatever22:39
mriedemok, ignore me then, i'm talking about something else22:39
mriedem'decomissioning' nodes22:39
*** felipemonteiro__ has quit IRC22:40
belmoreirathat is a one time operation. I'm not that worry if is not full automated22:41
*** slaweq has joined #openstack-nova22:42
dansmithbelmoreira: are you going to be in dublin or just tssurya?22:42
belmoreiradansmith just tssurya22:42
dansmithokay22:42
belmoreiraI will be Vancouver22:42
dansmithokay22:43
*** munishmehan has quit IRC22:43
*** threestrands has joined #openstack-nova22:43
*** slaweq has quit IRC22:44
belmoreiramy previous point was that if for a specific use case we need to create aggregates/add nodes it will be very difficult to manage this at scale22:44
melwittmriedem: replied on https://review.openstack.org/#/c/340614 about instance.host = None + vm_state = ERROR22:45
belmoreiraespecially because aggregates and cells need to be in sync. Missing a node in this mapping could mean that it will not be used even if it's in the cell22:46
openstackgerritArvind Nadendla proposed openstack/nova-specs master: Support traits in Glance  https://review.openstack.org/54150722:47
mriedemedmondsw: efried: done https://review.openstack.org/#/c/545111/22:48
efriedmriedem: Thanks!22:49
mriedemmelwitt: we expect that in a *very specific scenario*22:53
mriedemthe commit message makes it sound like the instance is ever only in error state because of a failed build, which is not the case22:53
melwittokay, so the words should be "we can expect" instead of "we expect"22:56
mriedemlet me get cochran on the horn22:56
melwitt"on the horn" means phone? that's new to me22:57
mriedemyes22:58
mriedemdid you get the cochran reference at least?22:59
melwittlike johnny cochran?22:59
mriedemyes22:59
melwittyeah22:59
mriedemhow about just saying, "If the instance is in ERROR because of a failed build"23:00
mriedemmy council informs me that would be satisfactory23:00
melwittthank you, council people23:01
*** mrhillsman has joined #openstack-nova23:06
imacdonnmriedem: I reproduced the PortInUse thing on Pike, and also confirmed it only happens when using a pre-existing port - created https://bugs.launchpad.net/nova/+bug/174983823:08
openstackLaunchpad bug 1749838 in OpenStack Compute (nova) "Rescheduled instace with pre-existing port fails with PortInUse exception" [Undecided,New]23:08
*** itlinux has quit IRC23:09
mriedemok23:10
mriedemimacdonn: this is latest stable/pike?23:12
imacdonnIt's RDO - nova 16.0.323:12
mriedemok so port.device_id is set23:12
mriedemis what it's failing on23:13
mriedemwhen we unbind the port before rescheduling, we should wipe that out23:13
mriedemport_req_body = {'port': {'device_id': '', 'device_owner': ''}}23:13
mriedemhttps://github.com/openstack/nova/blob/stable/pike/nova/network/neutronv2/api.py#L51123:14
mriedemdo you see "Unable to clear device ID" in the logs?23:14
mriedemon the first host?23:14
imacdonnwill look .. I did attach debug lots from both nodes to the bug just now23:14
imacdonnlogs*23:14
imacdonnI don't see that message (grep for "clear" only finds a couple of config options)23:15
mriedemi feel like i had a patch that added debug logging in this code for when we tore down, but i probably abandoned it23:16
mriedemimacdonn: oh i bet this is the fix you need https://review.openstack.org/#/c/520248/23:17
*** belmoreira has quit IRC23:17
mriedemin the case of nova creating a port,23:18
mriedemit doesn't fail because nova orphans the port created from the first host, and creates a new port when going through the 2nd host23:18
mriedemso you end up with 2 ports for the instance that nova created even though you're only using 123:18
mriedemin the case that you bring a port, nova doesn't unbind it before rescheduling, and that's why we fail to use it on the 2nd host23:18
imacdonnseems plausible ... looks like a one-line change, so I can try to drop it in23:18
mriedemimacdonn: you could try applying that patch and see if it resolves it23:18
*** acormier has quit IRC23:18
*** acormier has joined #openstack-nova23:19
*** acormier has quit IRC23:23
*** r-daneel has quit IRC23:24
*** amodi has quit IRC23:24
*** felipemonteiro_ has quit IRC23:24
*** felipemonteiro_ has joined #openstack-nova23:24
imacdonnmriedem: yup, that fixed it - thanks!23:35
*** hshiina has joined #openstack-nova23:36
*** hshiina2 has joined #openstack-nova23:38
*** hshiina has quit IRC23:40
*** sdague has quit IRC23:41
*** cdent has quit IRC23:45
openstackgerritTakashi NATSUME proposed openstack/nova master: List/show all server migration types (1/2)  https://review.openstack.org/43060823:46
openstackgerritTakashi NATSUME proposed openstack/nova master: List/show all server migration types (2/2)  https://review.openstack.org/45948323:46
*** stakeda has joined #openstack-nova23:52
cfriesendoes anyone know offhand what the rules are for using instance.info_cache.network_info vs calling self.network_api.get_instance_nw_info(context, instance) ?23:54
*** hshiina2 is now known as hshiina23:55
*** hongbin has quit IRC23:56

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