Monday, 2018-03-26

*** hshiina has joined #openstack-nova00:06
*** Tom-Tom has joined #openstack-nova00:19
*** trozet has quit IRC00:20
*** liverpooler has joined #openstack-nova00:22
*** gus has left #openstack-nova00:23
*** Tom-Tom has quit IRC00:23
*** yangyapeng has quit IRC00:26
*** gouthamr has joined #openstack-nova00:27
*** jaypipes has quit IRC00:34
*** liuzz has joined #openstack-nova00:35
*** odyssey4me has quit IRC00:35
*** odyssey4me has joined #openstack-nova00:35
*** pchavva has joined #openstack-nova00:36
*** masber has joined #openstack-nova00:37
*** yassine has quit IRC00:37
*** zhurong has joined #openstack-nova00:37
*** yamahata has joined #openstack-nova00:38
*** elmaciej has quit IRC00:39
*** Dinesh_Bhor has joined #openstack-nova00:45
*** hoangcx has joined #openstack-nova00:51
*** yassine has joined #openstack-nova00:51
*** jichen has joined #openstack-nova00:52
*** zhurong has quit IRC01:01
*** sree has joined #openstack-nova01:03
*** phuongnh has joined #openstack-nova01:04
*** sree has quit IRC01:08
*** yangyapeng has joined #openstack-nova01:10
*** yingjun has joined #openstack-nova01:10
*** zhaochao has joined #openstack-nova01:11
*** hongbin has joined #openstack-nova01:12
openstackgerritMatt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available  https://review.openstack.org/52354801:12
openstackgerritMatt Riedemann proposed openstack/nova master: Add code to bind a port against a dest host during live migration  https://review.openstack.org/52360401:12
openstackgerritMatt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration  https://review.openstack.org/51542301:12
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration  https://review.openstack.org/55137001:12
openstackgerritMatt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method  https://review.openstack.org/55217001:12
openstackgerritMatt Riedemann proposed openstack/nova master: Add "activate_port_binding" neutron API method  https://review.openstack.org/55594701:12
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: compute: use port binding extended API during live migration  https://review.openstack.org/55137101:12
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Port binding based on events during live migration  https://review.openstack.org/43487001:12
openstackgerritMatt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate  https://review.openstack.org/52253701:12
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Turn on new port binding extended live migrate flow  https://review.openstack.org/55217301:12
openstackgerritMatt Riedemann proposed openstack/nova master: Avoid unnecessary port update during live migration  https://review.openstack.org/55633201:12
openstackgerritMatt Riedemann proposed openstack/nova master: Delete port bindings in setup_networks_on_host if teardown=True  https://review.openstack.org/55633301:12
openstackgerritMatt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron  https://review.openstack.org/55633401:12
*** mriedem has quit IRC01:13
*** Tom-Tom has joined #openstack-nova01:13
*** yangyapeng has quit IRC01:14
*** artom has joined #openstack-nova01:17
*** Tom-Tom has quit IRC01:17
*** yingjun has quit IRC01:17
*** yangyapeng has joined #openstack-nova01:19
*** salv-orl_ has joined #openstack-nova01:30
*** tiendc has joined #openstack-nova01:30
*** fanzhang has quit IRC01:31
*** fanzhang has joined #openstack-nova01:32
*** salv-orlando has quit IRC01:33
*** Dinesh_Bhor has quit IRC01:35
*** Dinesh_Bhor has joined #openstack-nova01:36
*** sree has joined #openstack-nova01:37
*** sree has quit IRC01:41
*** Tom-Tom has joined #openstack-nova01:47
*** tbachman has joined #openstack-nova01:47
openstackgerritNaichuan Sun proposed openstack/nova master: xenapi(N-R-P): Add API to support vgpu resource provider create  https://review.openstack.org/52031301:50
*** sree has joined #openstack-nova01:54
*** _pewp_ has quit IRC01:56
*** sree has quit IRC01:58
*** _pewp_ has joined #openstack-nova01:59
*** tbachman has quit IRC02:02
*** david-lyle has joined #openstack-nova02:08
*** takashin has joined #openstack-nova02:10
*** germs has quit IRC02:11
*** germs has joined #openstack-nova02:11
*** germs has quit IRC02:11
*** germs has joined #openstack-nova02:11
*** _pewp_ has quit IRC02:17
*** archit has joined #openstack-nova02:17
*** masber has quit IRC02:21
openstackgerritNaichuan Sun proposed openstack/nova master: xenapi(N-R-P): Add API to support vgpu resource provider create  https://review.openstack.org/52031302:22
*** vivsoni__ has quit IRC02:32
*** annp has joined #openstack-nova02:34
*** Dinesh_Bhor has quit IRC02:36
*** moshele has joined #openstack-nova02:36
openstackgerritmelissaml proposed openstack/nova master: Use http code constant instead of int  https://review.openstack.org/55634002:38
*** moshele has quit IRC02:42
*** Dinesh_Bhor has joined #openstack-nova02:42
*** kmalloc has quit IRC02:46
*** pchavva has quit IRC02:47
*** vivsoni has joined #openstack-nova02:49
*** Dinesh_Bhor has quit IRC02:54
*** Dinesh_Bhor has joined #openstack-nova02:59
*** lei-zh has joined #openstack-nova03:00
*** david-lyle has quit IRC03:01
*** lei-zh has quit IRC03:01
*** lei-zh has joined #openstack-nova03:02
*** Dinesh_Bhor has quit IRC03:07
*** masber has joined #openstack-nova03:17
*** suresh12 has joined #openstack-nova03:24
*** Tom-Tom has quit IRC03:25
*** Tom-Tom has joined #openstack-nova03:26
*** suresh12 has quit IRC03:26
*** yamamoto has joined #openstack-nova03:27
*** takashin has quit IRC03:27
*** zhaochao has quit IRC03:28
*** jroll has quit IRC03:28
*** gouthamr has quit IRC03:29
*** zhaochao has joined #openstack-nova03:30
*** Tom-Tom has quit IRC03:30
*** jroll has joined #openstack-nova03:31
*** yamamoto has quit IRC03:31
*** dave-mccowan has quit IRC03:34
*** _pewp_ has joined #openstack-nova03:35
*** zhurong has joined #openstack-nova03:37
*** hongbin has quit IRC03:45
*** pooja_jadhav has joined #openstack-nova03:45
*** suresh12 has joined #openstack-nova03:46
*** sree has joined #openstack-nova03:47
*** yassine has quit IRC03:48
*** rcernin has quit IRC03:55
*** rcernin has joined #openstack-nova03:55
*** abhishekk has joined #openstack-nova04:00
*** abhishekk is now known as akekane|wfh04:00
*** akekane|wfh is now known as abhishekk04:00
*** ratailor has joined #openstack-nova04:01
*** bhagyashris has joined #openstack-nova04:01
*** yassine has joined #openstack-nova04:02
*** archit has quit IRC04:04
*** Dinesh_Bhor has joined #openstack-nova04:05
*** _pewp_ has quit IRC04:07
*** _pewp_ has joined #openstack-nova04:08
*** bhujay has joined #openstack-nova04:09
*** vivsoni has quit IRC04:27
*** psachin has joined #openstack-nova04:28
*** yamamoto has joined #openstack-nova04:28
*** vivsoni has joined #openstack-nova04:30
*** rha has quit IRC04:34
*** Tom-Tom has joined #openstack-nova04:35
*** udesale has joined #openstack-nova04:35
*** zhurong has quit IRC04:42
*** masber has quit IRC04:47
*** gyankum has joined #openstack-nova04:49
*** masber has joined #openstack-nova04:49
*** Dinesh__Bhor has joined #openstack-nova05:02
*** Dinesh_Bhor has quit IRC05:02
*** sdeath has joined #openstack-nova05:02
*** jichen has quit IRC05:02
*** sdeath has quit IRC05:02
*** jichen has joined #openstack-nova05:02
*** sdeath has joined #openstack-nova05:02
*** vivsoni has quit IRC05:08
*** moshele has joined #openstack-nova05:14
*** vivsoni has joined #openstack-nova05:14
*** moshele has quit IRC05:16
*** lpetrut has joined #openstack-nova05:19
*** takashin has joined #openstack-nova05:25
*** lpetrut has quit IRC05:32
*** lpetrut has joined #openstack-nova05:32
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: Initial change set of z/VM driver  https://review.openstack.org/52338705:33
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver  https://review.openstack.org/52765805:33
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: add snapshot function  https://review.openstack.org/53424005:33
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: add power actions  https://review.openstack.org/54334005:33
openstackgerritjichenjc proposed openstack/nova master: z/VM Driver: add get console output  https://review.openstack.org/54334405:33
*** Dinesh__Bhor has quit IRC05:37
*** suresh12 has quit IRC05:43
*** suresh12 has joined #openstack-nova05:45
*** suresh12 has quit IRC05:49
*** Dinesh__Bhor has joined #openstack-nova05:53
*** Dinesh__Bhor has quit IRC05:56
*** Dinesh__Bhor has joined #openstack-nova05:56
*** jaosorior has joined #openstack-nova05:59
openstackgerritTakashi NATSUME proposed openstack/nova master: List/show all server migration types (1/2)  https://review.openstack.org/43060805:59
*** lajoskatona has joined #openstack-nova06:04
*** Eran_Kuris has joined #openstack-nova06:08
*** moshele has joined #openstack-nova06:09
*** jaosorior has quit IRC06:14
*** kmalloc has joined #openstack-nova06:17
*** links has joined #openstack-nova06:19
*** AlexeyAbashkin has joined #openstack-nova06:19
*** jaosorior has joined #openstack-nova06:21
*** maciejjozefczyk has joined #openstack-nova06:22
openstackgerritTakashi NATSUME proposed openstack/nova master: List/show all server migration types (2/2)  https://review.openstack.org/45948306:23
openstackgerritTakashi NATSUME proposed openstack/nova stable/queens: [placement] Add sending global request ID in get  https://review.openstack.org/54311606:24
openstackgerritNaichuan Sun proposed openstack/nova master: (WIP)xenapi(N-R-P): Add API to support compute node resource provider update and create  https://review.openstack.org/52104106:24
*** AlexeyAbashkin has quit IRC06:24
openstackgerritTakashi NATSUME proposed openstack/python-novaclient master: Microversion 2.61 - List/Show all server migration types  https://review.openstack.org/43083906:25
openstackgerritTakashi NATSUME proposed openstack/nova master: Fix 500 error while passing 4-byte unicode data  https://review.openstack.org/40751406:26
*** claudiub has quit IRC06:26
*** claudiub has joined #openstack-nova06:27
openstackgerritTakashi NATSUME proposed openstack/nova master: Adds view builders for keypairs controller  https://review.openstack.org/34728906:27
*** Eran_Kuris has quit IRC06:29
openstackgerritGhanshyam Mann proposed openstack/nova master: Fix api-ref: nova image-meta is deprecated from 2.39  https://review.openstack.org/55481306:31
*** toabctl has joined #openstack-nova06:32
*** sar has joined #openstack-nova06:32
*** moshele has quit IRC06:35
*** Eran_Kuris has joined #openstack-nova06:39
*** masber has quit IRC06:41
*** jaosorior has quit IRC06:41
openstackgerritNaichuan Sun proposed openstack/nova master: xenapi(N-R-P): Add API to support vgpu resource provider create  https://review.openstack.org/52031306:41
*** moshele has joined #openstack-nova06:42
*** andreas_s has joined #openstack-nova06:50
*** jaosorior has joined #openstack-nova06:50
*** lpetrut has quit IRC06:58
*** afaranha has joined #openstack-nova06:59
*** fragatina has quit IRC07:03
*** fragatina has joined #openstack-nova07:03
openstackgerritMerged openstack/python-novaclient master: add lower-constraints job  https://review.openstack.org/55616907:04
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata  https://review.openstack.org/54877207:06
*** pcaruana has joined #openstack-nova07:08
*** rcernin has quit IRC07:10
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Parameter verification for servers.inc (1/3)  https://review.openstack.org/52820107:13
*** damien_r has joined #openstack-nova07:15
*** elod has quit IRC07:16
*** sahid has joined #openstack-nova07:17
*** elod has joined #openstack-nova07:18
*** damien_r has quit IRC07:19
*** damien_r has joined #openstack-nova07:19
*** tesseract has joined #openstack-nova07:23
*** moshele has quit IRC07:25
*** moshele has joined #openstack-nova07:26
*** ralonsoh has joined #openstack-nova07:26
*** maciejjozefczyk has quit IRC07:35
*** maciejjozefczyk has joined #openstack-nova07:35
*** markmcclain has quit IRC07:40
*** fanzhang has quit IRC07:42
*** fanzhang has joined #openstack-nova07:42
openstackgerritTakashi NATSUME proposed openstack/nova master: Transform aggregate.update_metadata notification  https://review.openstack.org/46062507:46
openstackgerritTakashi NATSUME proposed openstack/python-novaclient master: Microversion 2.61 - List/Show all server migration types  https://review.openstack.org/43083907:48
*** AlexeyAbashkin has joined #openstack-nova07:50
*** abhishekk has quit IRC07:51
*** mdnadeem has joined #openstack-nova07:52
*** dineshbhor__ has joined #openstack-nova07:52
*** Dinesh__Bhor has quit IRC07:53
*** fragatina has quit IRC07:53
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Spec for Granular API policy  https://review.openstack.org/54785007:54
gmann_johnthetubaguy: can you please check granular API policy spec - https://review.openstack.org/#/c/547850/507:55
openstackgerritNaichuan Sun proposed openstack/nova master: xenapi(N-R-P):Get vgpu info from `allocations`  https://review.openstack.org/52171707:55
*** lucas-afk is now known as lucasagomes07:58
*** moshele has quit IRC08:08
*** masber has joined #openstack-nova08:09
*** moshele has joined #openstack-nova08:12
bauwsergood morning Nova08:12
*** bauwser is now known as bauzas08:12
*** gjayavelu has joined #openstack-nova08:13
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements  https://review.openstack.org/55641808:15
*** dineshbhor__ has quit IRC08:16
*** Dinesh_Bhor has joined #openstack-nova08:16
*** claudiub|2 has joined #openstack-nova08:16
*** danpawlik has joined #openstack-nova08:17
*** sususuryashines has joined #openstack-nova08:18
*** sususuryashines is now known as tssurya08:18
*** claudiub has quit IRC08:19
*** ktibi has joined #openstack-nova08:20
openstackgerritOpenStack Proposal Bot proposed openstack/os-vif master: Updated from global requirements  https://review.openstack.org/53391808:20
openstackgerritSurya Seetharaman proposed openstack/nova master: Allow scheduling only to enabled cells (Filter Scheduler)  https://review.openstack.org/55052708:20
*** derekh has joined #openstack-nova08:23
*** mdbooth has joined #openstack-nova08:28
*** abhishekk has joined #openstack-nova08:28
*** abhishekk has quit IRC08:29
bauzasjianghuaw_: around ?08:29
*** abhishekk has joined #openstack-nova08:29
*** gjayavelu has quit IRC08:29
*** takashin has left #openstack-nova08:30
*** lpetrut has joined #openstack-nova08:35
*** alexchadin has joined #openstack-nova08:40
*** abhishekk has quit IRC08:42
*** ragiman has joined #openstack-nova08:46
*** bjolo has joined #openstack-nova08:49
openstackgerritYikun Jiang (Kero) proposed openstack/nova-specs master: Complex (Anti)-Affinity Policies  https://review.openstack.org/54692508:53
*** masber has quit IRC08:54
*** masber has joined #openstack-nova08:57
*** hshiina has quit IRC08:57
*** abhishekk has joined #openstack-nova08:58
*** abhishekk has quit IRC08:59
*** abhishekk has joined #openstack-nova08:59
*** masber has quit IRC09:02
*** ccamacho has joined #openstack-nova09:02
*** ccamacho is now known as ccamacho|PTO09:03
openstackgerritTetsuro Nakamura proposed openstack/nova master: [WIP] Consider nested RPs in get_all_with_shared  https://review.openstack.org/55645009:03
*** masber has joined #openstack-nova09:03
*** finucannot is now known as stephenfin09:03
openstackgerritTetsuro Nakamura proposed openstack/nova master: [WIP] Consider nested RPs in get_all_with_shared  https://review.openstack.org/55645009:08
*** Kvisle has quit IRC09:10
*** voelzmo has joined #openstack-nova09:10
*** udesale_ has joined #openstack-nova09:10
*** udesale has quit IRC09:10
*** Kvisle has joined #openstack-nova09:11
kashyapis the CloudBase "nova-dsvm-full-tempest" a voting job?09:12
kashyaps/is/Is/ (OCD: Capitalize the first letter of a sentence.)09:12
*** abhishekk_ has joined #openstack-nova09:13
kashyapHmm, `reno lint` doesn't catch indentation problems, I thought it does09:13
*** udesale_ has quit IRC09:15
*** abhishekk has quit IRC09:15
openstackgerritwangqi proposed openstack/nova master: fix a typo  https://review.openstack.org/55645509:15
*** udesale has joined #openstack-nova09:16
*** voelzmo has quit IRC09:16
kashyapstephenfin: Hey there, when you get a moment, can you tell what is wrong with this rel note?09:20
kashyaphttps://review.openstack.org/#/c/534384/12/releasenotes/notes/libvirt-cpu-model-extra-flags-a23085f58bd22d27.yaml09:20
kashyapHere's the relasenotes build error: http://logs.openstack.org/84/534384/12/check/build-openstack-releasenotes/c53ebd5/job-output.txt.gz09:20
* kashyap ran `reno lint` a couple of times. And it didn't show me any actionable errors09:21
bauzasgosh, I'm getting an headache just by trying to reconcile all the comments in between https://review.openstack.org/#/c/555081/3..4/specs/rocky/approved/cpu-resources.rst and https://review.openstack.org/#/c/552924/3/specs/rocky/approved/numa-topology-with-rps.rst09:28
* bauzas needs a serious shot of coffee09:28
bauzasthat looks like a hard start for a Monday09:28
* bauzas needs to warm up09:28
openstackgerritSurya Seetharaman proposed openstack/nova master: Update the cells FAQs and scheduler maintenance docs.  https://review.openstack.org/55645909:29
*** markmcclain has joined #openstack-nova09:32
*** srini_ has joined #openstack-nova09:34
stephenfinkashyap: Done09:35
stephenfincomments in the review09:35
* kashyap clicks; thank you09:36
*** Dinesh_Bhor has quit IRC09:36
kashyapstephenfin: For DefinitionLists, is the below indentation valid?09:37
kashyapFoo:09:37
kashyap    BarWhizz09:37
kashyap(4 spaces)09:37
* kashyap gives it a whirl09:37
stephenfinYup. I think any level of indentation is fine. Just don't leave a newline between the two09:37
stephenfinOr it becomes a paragraph followed by a block comment09:37
*** aloga_ has joined #openstack-nova09:38
*** masber has quit IRC09:38
kashyapYeah, I'll give a pastebin before I waste precious Gate resources, if you can take a quick gander09:38
kashyapHmm, `reno lint .` should catch that.  (TODO: File a ticket on StoryBoard for that)09:38
*** zhurong has joined #openstack-nova09:39
*** giblet is now known as gibi09:39
gibigood day nova09:40
*** Tom-Tom has quit IRC09:43
*** Tom-Tom has joined #openstack-nova09:44
*** Tom-Tom has quit IRC09:48
kashyapHow to re-trigger CloudBase CI?  Is it 'check hyper-v'?09:56
*** sambetts|afk is now known as sambetts09:57
*** lei-zh has quit IRC09:59
*** gyankum has quit IRC10:01
openstackgerritChris Dent proposed openstack/nova master: [placement] Filter resource providers by forbidden traits in db  https://review.openstack.org/55647210:03
*** alexchadin has quit IRC10:03
lpetrutkashyap: yep, "check hyper-v" should work10:04
kashyaplpetrut: Thank you10:04
*** vivsoni has quit IRC10:04
*** yassine has quit IRC10:06
*** phuongnh has quit IRC10:06
*** sdague has joined #openstack-nova10:06
*** sree has quit IRC10:07
*** vivsoni has joined #openstack-nova10:07
kashyaplpetrut: Do you know if this is a legit faliure?  http://cloudbase-ci.com//nova/534384/12/console.log.gz10:11
lpetrutkashyap: checking10:14
*** jichen has quit IRC10:16
lpetrutlooks like nova-compute does not start on the Hyper-V node, it's an unrelated issue but thanks for checking. we'll look into it10:18
lpetrutalso, I took a look at the patch and it was only changing libvirt driver code, which won't be used on Windows10:18
kashyapExactly :-)10:21
kashyapThanks for looking, lpetrut10:21
*** lpetrut has quit IRC10:22
kashyapstephenfin: When you get another minute, mind taking a look: https://kashyapc.fedorapeople.org/libvirt-cpu-model-extra-flags-a23085f58bd22d27.yaml.txt10:23
*** lpetrut has joined #openstack-nova10:23
kashyap(Before I upload the change.)10:23
stephenfinkashyap: Looks correct, aye10:23
kashyapstephenfin: Even the indentation of two 'dashed' bullet points under item 3.?10:24
stephenfinYup, that's what I'd expect to see10:24
kashyapMost excellent; thank you!10:24
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags  https://review.openstack.org/53438410:26
*** tiendc has quit IRC10:34
*** abhishekk_ has quit IRC10:36
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags  https://review.openstack.org/53438410:40
*** alexchadin has joined #openstack-nova10:50
*** lei-zh has joined #openstack-nova10:56
*** alexchad_ has joined #openstack-nova10:56
*** alexchadin has quit IRC10:56
*** elmaciej has joined #openstack-nova10:58
openstackgerritsahid proposed openstack/nova-specs master: update: isolate guests emulthreads on CONF.cpu_shared_set  https://review.openstack.org/51118810:58
sahidstephenfin, cfriesen I updated the emultor threads spec, if you have a moment to take a look ^10:59
sahidmuch simple11:00
alex_xu_sean-k-mooney: efried, found one use-case for the granular reqs in images https://review.openstack.org/#/c/554305/2/specs/rocky/approved/glance-image-traits.rst@8611:00
*** bhagyashris has quit IRC11:01
*** jaosorior has quit IRC11:01
*** lei-zh has quit IRC11:05
*** lei-zh has joined #openstack-nova11:06
*** AlexeyAbashkin has quit IRC11:14
*** bhujay has quit IRC11:15
*** lei-zh has quit IRC11:16
*** bhujay has joined #openstack-nova11:16
*** yassine has joined #openstack-nova11:24
*** liverpooler has quit IRC11:25
*** bhagyashris has joined #openstack-nova11:25
*** yamamoto has quit IRC11:27
*** zhurong has quit IRC11:27
*** AlexeyAbashkin has joined #openstack-nova11:29
*** slagle has joined #openstack-nova11:30
*** andreas_s_ has joined #openstack-nova11:33
*** elmaciej has quit IRC11:33
*** andreas_s has quit IRC11:35
*** yamamoto has joined #openstack-nova11:36
*** dtantsur|afk is now known as dtantsur11:37
*** cdent has joined #openstack-nova11:40
*** jaosorior has joined #openstack-nova11:40
*** yamamoto has quit IRC11:45
*** rmart04 has joined #openstack-nova11:47
*** sree has joined #openstack-nova11:47
sean-k-mooneyalex_xu_: im sure there are several11:49
*** sree has quit IRC11:51
sean-k-mooneyalex_xu_: im not sure that is a usecase at least not in the normal sense11:51
sean-k-mooneyalex_xu_: we had dicussed haveing specific metadata keys for the FPGA usecase not useing the generic resouces and traits workflow11:52
*** lucasagomes is now known as lucas-hungry11:52
*** sree has joined #openstack-nova11:53
gibiefried: I left some clarification about the numbered request group usage in https://review.openstack.org/#/c/502306/20/specs/rocky/approved/bandwidth-resource-provider.rst@49012:01
gibiefried: I want to make sure we are on the same page before I clarify the situation in the spec directly12:02
*** dave-mccowan has joined #openstack-nova12:03
*** yamamoto has joined #openstack-nova12:05
*** elmaciej has joined #openstack-nova12:06
*** alexchad_ has quit IRC12:07
*** andreas_s_ has quit IRC12:08
*** andreas_s has joined #openstack-nova12:09
*** andreas_s has quit IRC12:09
*** andreas_s has joined #openstack-nova12:09
*** eharney has quit IRC12:10
openstackgerritSurya Seetharaman proposed openstack/nova master: Add --enable and --disable options to  nova-manage update_cell  https://review.openstack.org/55541612:11
openstackgerritTetsuro Nakamura proposed openstack/nova master: remove not necessary short cut  https://review.openstack.org/55312212:12
openstackgerritTetsuro Nakamura proposed openstack/nova master: Fix allocation_candidates not to ignore shared RPs  https://review.openstack.org/53339612:12
openstackgerritTetsuro Nakamura proposed openstack/nova master: [WIP] Consider nested RPs in get_all_with_shared  https://review.openstack.org/55645012:12
*** andreas_s_ has joined #openstack-nova12:12
*** edmondsw has joined #openstack-nova12:13
*** andreas_s has quit IRC12:15
*** fragatina has joined #openstack-nova12:16
*** elmaciej has quit IRC12:18
*** lajoskatona has quit IRC12:19
*** lucas-hungry is now known as lucasagomes12:25
*** ratailor has quit IRC12:26
*** ratailor has joined #openstack-nova12:26
*** belmoreira has joined #openstack-nova12:28
*** ratailor has quit IRC12:30
*** elmaciej has joined #openstack-nova12:30
*** yamamoto has quit IRC12:30
efriedalex_xu_, gibi: looking...12:31
efried...and good UGT morning!12:31
*** vladikr has joined #openstack-nova12:31
gibiefried: good morning to you too12:32
*** andreas_s has joined #openstack-nova12:34
efriedalex_xu_: You around?  I need help understanding the use case.12:34
efriededleafe: Is the sched meeting in 25 or 1:25?12:34
cdentefried: latter12:34
cdentunless my calendar is borked12:35
efrieddamn, I thought I had my reminders set up to take SFDST into account.12:35
cdentyeah, latter12:35
efried...last two weeks were12:35
efriedweird12:35
cdentyeah, really bad planning by the illumanit, rotschilds and other members of world government12:36
efriedoh, I think it's because I've got it set to GMT - because my calendar doesn't do UTC - and GMT switches two weeks after US.  So it looked like it was working... but only for a couple of weeks.12:36
efriedeff12:36
cdentuse iceland as your timezone12:37
cdentI _think_ that may work12:37
*** andreas_s_ has quit IRC12:37
bauzasefried: scheduler meeting is planned in 1h 20 mins-ish12:38
*** liverpooler has joined #openstack-nova12:38
bauzasbecause CET and GMT moved to DST yesterday, not UTC12:38
bauzasand yeah, Iceland TZ == UTC12:39
efriedthanks y'all.  cdent - Rekjavik worked -- nice.12:39
bauzasbecause they don't do dayshift12:39
efriedAwesome.12:39
bauzasefried: using gcal ?12:39
efriedNotes :(12:39
openstackgerritMerged openstack/osc-placement master: Migrate legacy-osc-placement-dsvm-functional job in-tree  https://review.openstack.org/54781212:39
openstackgerritMerged openstack/osc-placement master: Add osc-placement-dsvm-functional-py3 job  https://review.openstack.org/54781512:39
bauzasbecause TB/Lightning has a UTC TZ12:39
bauzashah12:39
bauzasFWIW, for the next 6 months, I will only be possible to be in the scheduler meeting for the first 20 mins :(12:40
bauzasefried: cdent: edleafe: ^12:40
efriedack12:41
openstackgerritRoman Dobosz proposed openstack/nova master: allow compute nodes to be associated with host agg  https://review.openstack.org/52675312:41
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add host to API and Conductor  https://review.openstack.org/55651312:42
openstackgerritTetsuro Nakamura proposed openstack/nova master: [WIP] shared and nested allocation candidates  https://review.openstack.org/55651412:43
*** suresh12 has joined #openstack-nova12:43
cdentgerrit seems to be dragging a bit?12:47
*** odyssey4me has quit IRC12:47
*** odyssey4me has joined #openstack-nova12:47
kashyapIt's always dragging a bit12:47
kashyapFFS, releasenotes still fails for reasons I can't see: http://logs.openstack.org/84/534384/14/check/build-openstack-releasenotes/4507437/job-output.txt.gz#_2018-03-26_10_58_14_06327712:47
kashyapCan anyone tell?  (The original change: https://review.openstack.org/#/c/534384/)12:48
*** suresh12 has quit IRC12:48
kashyap(In unreleased.rst; it seems to be moaning about a "Literal block expected", thus treating a warning as an error.)12:48
*** dtantsur is now known as dtantsur|brb12:49
efriedgibi: Responded.  Let me know if you want to talk through the alternatives.12:49
*** hoonetorg has quit IRC12:49
* kashyap goes to fix the "unreleased.rst"12:50
*** pchavva has joined #openstack-nova12:50
*** fragatina has quit IRC12:51
*** sahid has quit IRC12:51
*** psachin has quit IRC12:53
kashyapbauzas: You seem to have added the unreleased.rst file.  I don't see anyone using it.  Can it be deleted?12:53
kashyap(That is the Nova commit: 4c2dfa5)12:53
bauzasplease, no.12:53
bauzasit's used for good reasons12:53
bauzashttps://docs.openstack.org/releasenotes/nova/unreleased.html12:53
stephenfinkashyap: The reno extension isn't reporting your issues correctly12:54
kashyapbauzas: Do you spot what is the failure here: http://logs.openstack.org/84/534384/14/check/build-openstack-releasenotes/4507437/job-output.txt.gz#_2018-03-26_10_58_14_06327712:54
stephenfin*reno sphinx extension12:54
kashyapstephenfin: Hmm, how can I put myself out of my misery, then?12:54
bauzasI guess some relnote had a problem12:54
bauzashence the sphinx build error12:54
bauzasbut the rst page itself is empty12:54
bauzasthat's only reno which generates that file using the sphinx ext12:55
stephenfinkashyap: This is what I did for oslo.config. The reno extension works the same way so the fix should be similar https://review.openstack.org/#/c/554632/12:55
* kashyap clicks12:55
gibiefried: thanks, looking...12:55
stephenfinkashyap: tl;dr: you need to keep an offset counter as you emit rST lines, and it's worth writing what you generate to temporary file so you can view it12:56
kashyapYeah, was reading this change: https://review.openstack.org/#/c/554632/1/oslo_config/sphinxext.py12:57
stephenfinkashyap: I'm pretty sure there's a better way to do it (maybe dumping the offending lines to the terminal) but I haven't figure it out12:57
kashyapThanks for the summary.12:57
gibiefried: thanks for the namespacing alternative. Will it mean that Neutron can say in the port that 'resources-neutron-1': {'BW': 10000} ?12:57
efriedgibi: Yeah, something like that.12:58
*** sahid has joined #openstack-nova12:58
kashyapstephenfin: Right now I don't have time to fix 'reno', I wonder what I can do to figure out what needs to be fixed in this:https://review.openstack.org/#/c/534384/14/releasenotes/notes/libvirt-cpu-model-extra-flags-a23085f58bd22d27.yaml12:58
efriedgibi: Since we haven't connected the final dots on granular even for intra-nova cases, we probably still have the flexibility to flip to using resources-nova-N there.12:58
edleafeefried: Looks like you got your answer. I'm just dragging myself to start working at 8am.12:59
gibiefried: so to keep ports separate it should look more like resources-neutron-<port-uuid>12:59
efriedor resources-flavor-N / resources-image-N12:59
gibior resources-port-<port-uuid>12:59
stephenfinkashyap: It's ugly, but I'd strip it down and start adding parts until it stops working :/13:00
kashyapstephenfin: Hmm, is there a way locally verify that?  Because, 'reno lint .` isn't catching what I need13:01
kashyap(Lest I'll be stuck with this yak)13:01
stephenfin'tox -e releasenotes' should do the trick13:01
kashyapstephenfin: But did I do anything "fancy" there?  I'll see what I can "trip down"13:01
kashyapstephenfin: I did run that13:01
kashyapThe _only_ thing that gave me was:13:01
stephenfinand it worked?13:01
kashyapstephenfin: This is what I see: http://paste.openstack.org/show/714071/13:02
kashyapstephenfin: The same warning I see in the Gate.13:03
kashyapBut it doesn't show any problems with my own file13:03
stephenfinIt probably is your file that's causing the issue though13:04
stephenfinIt's saying the error is in 'unreleased.rst', but that's just because that file contains the 'release-notes' directive13:04
kashyapstephenfin: I see my content in the releasenotes/build/doctrees/unreleased.doctree13:04
kashyapBut nothing in the 'html' dir13:05
kashyapRight13:05
stephenfinyeah, there won't be anything in the html directory because the build failed13:05
kashyapRight; I'll check w/ the #openstack-release folks13:06
*** hoonetorg has joined #openstack-nova13:06
*** eharney has joined #openstack-nova13:09
*** dikonoor has joined #openstack-nova13:10
openstackgerritMerged openstack/nova master: Modify nova-manage cell_v2 list_cells to display "disabled" column  https://review.openstack.org/55541513:11
*** dikonoor has quit IRC13:15
*** dikonoor has joined #openstack-nova13:16
stephenfinsahid: Done https://review.openstack.org/#/c/511188/13:16
sahidstephenfin: thanks, i will address your comments13:17
*** ttsiouts_ has joined #openstack-nova13:18
*** lyan has joined #openstack-nova13:19
*** awaugama has joined #openstack-nova13:19
*** lyan is now known as Guest7542113:19
*** yamamoto has joined #openstack-nova13:20
*** yamamoto has quit IRC13:20
*** yamamoto has joined #openstack-nova13:20
*** gouthamr has joined #openstack-nova13:23
openstackgerritMerged openstack/nova master: Add disabled option to create_cell command  https://review.openstack.org/55541713:26
*** jroll has quit IRC13:27
*** jroll has joined #openstack-nova13:27
*** yangyapeng has quit IRC13:31
*** belmorei_ has joined #openstack-nova13:31
*** aloga_ has quit IRC13:31
*** belmoreira has quit IRC13:33
*** jaypipes has joined #openstack-nova13:35
*** aloga_ has joined #openstack-nova13:35
*** aloga_ has quit IRC13:37
jaypipesmorning supernovas13:39
gibijaypipes: good morning13:39
Spazmoticmorning jay13:39
*** READ10 has joined #openstack-nova13:39
*** mriedem has joined #openstack-nova13:40
gibijaypipes: I added reasoning about the need of the vnic_type in https://review.openstack.org/#/c/502306/20/specs/rocky/approved/bandwidth-resource-provider.rst@396 please let me know what you think13:41
bauzasjaypipes: morning13:41
bauzasstill working on updating my spec13:41
jaypipesgibi: cool, will do right now.13:41
gibijaypipes: thanks13:42
*** elmaciej has quit IRC13:43
stephenfinkashyap: What was the fix?13:43
*** damien_r has quit IRC13:44
kashyapstephenfin: I'm embarassed to tell13:44
kashyapstephenfin: But I will tell13:44
kashyapstephenfin: A mis-quoting a CPU model like this: "'Foo"13:44
*** masuberu has joined #openstack-nova13:45
kashyapstephenfin: (s/mis-quoting a/mis-quoting of a/)  And another spurious "::"13:45
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags  https://review.openstack.org/53438413:46
stephenfinkashyap: aha. Good to hear you got it sorted :)13:47
openstackgerritStephen Finucane proposed openstack/nova master: Add CPUWeigher  https://review.openstack.org/37952513:48
*** lpetrut_ has joined #openstack-nova13:48
*** abalutoiu_ has joined #openstack-nova13:48
openstackgerritStephen Finucane proposed openstack/nova master: Standardize '_get_XXX_constraint' functions  https://review.openstack.org/38507113:49
*** jmlowe has quit IRC13:49
kashyapsean-k-mooney: Do you spot anything else here: https://review.openstack.org/#/c/534384/13:50
openstackgerritsahid proposed openstack/nova-specs master: update: isolate guests emulthreads on CONF.cpu_shared_set  https://review.openstack.org/51118813:50
kashyapsean-k-mooney: I think it's ready for "prime time".  I restricted the options for now to only PCID.13:50
*** mvk has quit IRC13:51
kashyapsean-k-mooney: (To keep it backportable; and in a future patch, remove that restriction, thus making way for other useful stuff.)13:51
*** lpetrut has quit IRC13:52
*** abalutoiu has quit IRC13:52
*** udesale has quit IRC13:53
*** yangyapeng has joined #openstack-nova13:54
*** hongbin has joined #openstack-nova13:55
*** udesale has joined #openstack-nova13:55
*** damien_r has joined #openstack-nova13:57
*** jaosorior has quit IRC13:58
*** jistr is now known as jistr|mtg14:02
jaypipesgibi: done14:03
*** yamamoto has quit IRC14:03
edleafeScheduler subteam meeting running now in #openstack-meeting-alt14:03
*** beekneemech is now known as bnemec14:03
*** burt has joined #openstack-nova14:04
*** Zames has joined #openstack-nova14:04
gibijaypipes: thanks, I will check after the scheduler meeting14:04
*** mlavalle has joined #openstack-nova14:05
*** brault has joined #openstack-nova14:07
*** Zames has quit IRC14:07
*** Tom-Tom has joined #openstack-nova14:08
*** moshele has quit IRC14:09
*** Zames has joined #openstack-nova14:10
*** r-daneel has joined #openstack-nova14:10
*** Zames has quit IRC14:12
*** masuberu has quit IRC14:12
*** masuberu has joined #openstack-nova14:12
*** archit has joined #openstack-nova14:15
*** dtantsur|brb is now known as dtantsur14:15
openstackgerritKonstantinos Samaras-Tsakiris proposed openstack/nova master: Add `hide_hypervisor_id` flavor extra_spec  https://review.openstack.org/55586114:17
*** sree_ has joined #openstack-nova14:17
*** sree_ is now known as Guest578714:18
*** felipemonteiro has joined #openstack-nova14:18
*** Guest75421 has quit IRC14:18
*** felipemonteiro_ has joined #openstack-nova14:20
*** sree has quit IRC14:20
*** jmlowe has joined #openstack-nova14:22
openstackgerritStephen Finucane proposed openstack/nova master: tox: Speed things up and document them  https://review.openstack.org/53438214:23
openstackgerritStephen Finucane proposed openstack/nova master: trivial: Remove 'tools/releasenotes_tox.sh'  https://review.openstack.org/53438314:23
openstackgerritStephen Finucane proposed openstack/nova master: tox: Fix indentation  https://review.openstack.org/55654314:23
openstackgerritStephen Finucane proposed openstack/nova master: tox: Remove unnecessary configuration  https://review.openstack.org/55654414:23
*** felipemonteiro has quit IRC14:23
*** mvk has joined #openstack-nova14:24
*** lyan has joined #openstack-nova14:26
*** lyan is now known as Guest2222414:27
*** jistr|mtg is now known as jistr14:27
*** links has quit IRC14:32
openstackgerritStephen Finucane proposed openstack/nova master: conf: Use new-style choice values  https://review.openstack.org/53092414:34
*** markvoelker_ has joined #openstack-nova14:34
*** bhujay has quit IRC14:34
*** markvoelker has quit IRC14:35
openstackgerritStephen Finucane proposed openstack/nova master: tox: Add mypy target  https://review.openstack.org/53822114:35
openstackgerritStephen Finucane proposed openstack/nova master: tox: Store list of converted files  https://review.openstack.org/53822214:35
openstackgerritStephen Finucane proposed openstack/nova master: mypy: Add type annotations to 'nova.pci'  https://review.openstack.org/53822414:35
openstackgerritStephen Finucane proposed openstack/nova master: zuul: Add 'mypy' job  https://review.openstack.org/53916814:35
mriedemtssurya: this was merged out of order imo https://review.openstack.org/#/c/555417/14:36
mriedemsince the scheduler patch to filter disabled cells isn't merged yet14:36
*** markvoelker has joined #openstack-nova14:37
*** jobewan has joined #openstack-nova14:37
*** ttsiouts_ has quit IRC14:38
*** markvoelker_ has quit IRC14:39
mriedemi guess if we get https://review.openstack.org/#/c/550527/ in soon then it's not a big deal14:39
dansmithI think these got re-ordered at some point,14:39
dansmithbecause the doc patch is before the update_cell patch it talks about14:40
dansmithso maybe just an accident14:40
openstackgerritStephen Finucane proposed openstack/nova master: doc: Remove duplicate 'vnc' config opt descriptions  https://review.openstack.org/53472414:41
stephenfinmriedem: Fancy hitting that? ^14:41
stephenfinthere's a couple of those in the old admin guide (as you've seen)14:41
mriedemstephenfin: yeah after the scheduler meeting14:41
stephenfin(y)14:41
mriedemdansmith: ok that series should probably be rebased then, and the docs patch should come at the end14:42
mriedemi'll look at the scheduler patch after the scheduling meeting14:42
dansmithmriedem: I -1d the docs patch so it should be okay until after,14:42
dansmithmriedem: it's actually not a linear set anymore14:42
mriedemyeah i see that now, which is why the create_cell change merged probably14:42
mriedemanywho14:43
*** prometheanfire has left #openstack-nova14:43
dansmithyeah, not a huge deal to me, but whatever you want14:43
mriedemjohnthetubaguy: can i get you to come back on this nova-status ironic flavor migratoin patch? https://review.openstack.org/#/c/527541/14:43
kashyapDan / Matt, when you get a moment, does this look better?  https://review.openstack.org/#/c/534384/15/nova/virt/libvirt/driver.py14:43
kashyap(Tests pass, and also release note builds.)14:43
mriedemi don't think we can drop the ironic flavor migration stuff in the driver until nova-status has a check for it14:43
mriedemkashyap: what happened to putting a 'choices' or hard-coding the only option to pcie for the backport?14:43
mriedemnot a different option, but restricting the single choice for the backport and then opening it up on master14:44
kashyapmriedem: Yep, that's what I did.  But, the check is in driver.py14:44
mriedemoh14:44
kashyapmriedem: That's exactly what I did :-)14:44
mriedemwhy not 'choices' kwarg on the config option itself?14:44
kashyapBecause, there's no 'choices' for ListOpt() for Oslo class14:44
efriedsee dev ML :)14:44
kashyapOnly for StrOpt(014:44
efriedkashyap: Propose it!14:44
mriedemok, i guess that doesn't surprise me14:45
dansmithman the queues are deep14:45
kashyapefried: Heh :-)  Haven't checked the list responses yet, still ploughing through other stuff14:45
efriedI don't know if anyone responded thusly.  That was off the cuff.14:45
kashyapdansmith: Hey, since you're a stickler for words, I'd love if you see any grammatical mistakes in the release note (I spent 3 hours writing it)14:46
kashyapdansmith: 'Grr'it is slow for me; but here's a quick-loading file: https://review.openstack.org/#/c/534384/15/nova/virt/libvirt/driver.py14:46
kashyapErr, "wrong" URL :P -- https://kashyapc.fedorapeople.org/libvirt-cpu-model-extra-flags-a23085f58bd22d27.yaml.txt14:46
tssuryamriedem: oops14:46
tssuryamriedem: I guess they did get merged out of order14:47
dansmithkashyap: in a bit14:48
tssuryadansmith, mriedem: dansmith has a comment on the debug stuff in the main filter patch,14:48
tssuryaI will fix it and we can merge that soon14:48
*** yamahata has quit IRC14:49
kashyapdansmith: No rush at all.  In an hour-ish, I'll be disappearing to my Dutch class, so I'll respond to questions on the review (if you have them)14:49
*** tbachman has joined #openstack-nova14:49
openstackgerritEric Fried proposed openstack/nova master: Unit test framework: common FakeResponse  https://review.openstack.org/55655114:53
*** felipemonteiro_ has quit IRC14:53
*** felipemonteiro__ has joined #openstack-nova14:53
efriedmriedem: You are interested in this ^14:53
* efried declares with confidence14:53
*** esberglu has joined #openstack-nova14:54
mriedemi am interested in that yes14:54
*** gcb has joined #openstack-nova14:54
*** mdnadeem has quit IRC14:54
efriedmriedem: (While I was reviewing https://review.openstack.org/#/c/556334/1/nova/tests/unit/network/test_neutronv2.py)14:55
mriedemyeah i figured14:55
mriedemi was going to get there eventually14:55
efriedmriedem: But note that I implemented it differently than the one in test_identity.14:55
openstackgerritTyler Blakeslee proposed openstack/nova master: Add __repr__ for NovaException  https://review.openstack.org/55581214:56
mriedemfix the typo and i'm +214:58
*** cdent has quit IRC14:59
openstackgerritEric Fried proposed openstack/nova master: Unit test framework: common FakeResponse  https://review.openstack.org/55655115:00
efriedmriedem: Done.  Though I kinda like 'evalue'.15:00
gibijaypipes: do you have a minute for discussing the vnic_type issue or you prefer to have my reply in the review?15:00
*** germs has quit IRC15:00
tssuryadansmith, mriedem: do you guys have some time now for a question ?15:03
*** sree has joined #openstack-nova15:03
dansmithtssurya: shoot15:03
*** yamamoto has joined #openstack-nova15:03
mriedemefried: i lied15:04
tssuryadansmith: regarding adding the "queued_for_delete" column15:04
tssuryato handle a down cell,15:04
tssuryadoes it need a spec ?15:04
efriedmriedem: you lying liar15:04
rybridgesmriedem: The example of an AttributeError being raised in the Python terminal that you showed on Friday is not meaningful at all. Of course it will throw an exception at the Python CLI. What you did does not represent how Neutron executes the code. Neutron wraps that call with the eventlet spawn_n() method which blanket catches all exceptions and prints them to stderr rather than using the standard15:04
rybridgesPython logging framework.15:04
rybridgesThis means that exceptions thrown within eventlet loops will not be logged to files that are setup in a deployer's standard logging conf. Long story short, exceptions ARE actually being masked / swallowed which is why we had this problem. See my patch which improves the error handling: https://review.openstack.org/#/c/556120/15:04
efriedmriedem: Ah, nice finds15:04
tssuryathe use cases are nova list, nova service-list and blocking VM creations if a user has VMs in the down cell15:05
tssuryahowever each of this has a bug opened15:05
dansmithtssurya: yeah I think it probably should be a spec because there will be lots of behavioral changes to describe ...15:05
tssuryaso was wondering if it needs a spec, since the only common part would be adding the new column to the instance_mapping table15:05
tssuryadansmith: ah okay,15:05
tssuryaalso are we going to consider melwitt's proposal of adding user_id as well ?15:06
tssuryasince she said that is the only info missing for calculating per project per user quptas15:06
tssuryaquotas*15:06
*** Guest5787 has quit IRC15:06
belmorei_are user quotas something that nova will continue to support?15:07
dansmithtssurya: is that related to the down-cell behavior thing? I thought that solved one of the quota issues, but not enough to calculate enough of the quota to enable booting when a cell is down15:07
dansmithtssurya: regardless, if you think it's related and/or should be done at the same time, that's a thing to document the justification for in the spec I think15:07
dansmithbelmorei_: I think we have some we have to support because of history right?15:08
dansmithbelmorei_: I don't have those details in my head, so maybe we should discuss when melwitt is awake15:08
tssuryadansmith: yea sure, the reason I was asking about the user_id is if its going to be incorporated then it changes the solution I would be proposing in this spec for VM booting15:09
mriedemkeypairs15:09
mriedemkeypair quota is based on user_id, not project_id15:09
*** chyka has joined #openstack-nova15:10
dansmithtssurya: yeah, so maybe it needs to be two specs, I dunno, I don't have it all in my head right now, so just use your judgment about whether or not to include it or mention it as a related effort I guess15:10
mriedemhttps://github.com/openstack/nova/blob/master/nova/quota.py#L124815:10
belmorei_mriedem right, missed that15:10
tssuryadansmith: so without the user_id, it would be something like - user can spawn new VMs if he/she doesn't have any in the cell which is down, with the user_id it would be done from placement and VM booting can be allowed even if the user has VMs in the down cell15:10
tssuryadansmith: yea will do that15:10
tssuryaand consult melwitt15:11
tssuryawhen she is awake15:11
gibijaypipes: I'm falling back replying to you in the spec as I have to go offline soonish15:11
dansmithtssurya: oh you mean user_id in placement for calculating quotas?15:11
mriedemwe can't use placement for quota calculations15:11
mriedemnot yet anyway15:11
dansmithyeah, I thought you meant user_id on something else.. instance mapping or something15:11
tssuryadansmith: trying to find the mailing list email in which melwitt was talking about this15:11
tssuryayes its about adding user_id to instance_mapping table15:12
*** danpawlik has quit IRC15:12
dansmithhmm, okay, well, idk15:12
tssuryabut using placement db for quotas calculation15:12
dansmithprobably two specs though15:12
tssuryaso that we no longer depend on individual cell_db's15:12
dansmithyeah, that placement quotas thing is a larger can of worms,15:12
dansmithdon't depend on that for your queued_for_delete thing15:12
*** moshele has joined #openstack-nova15:13
tssuryadansmith: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128334.html15:14
tssuryadansmith: yes okay then will do a spec without thinking about ^^15:14
*** yamamoto has quit IRC15:15
dansmithtssurya: we can sneak that column in so we just have one db migration to add both, but the actual work is a separate spec I think15:16
tssuryadansmith: yea I agree,15:16
*** kmalloc has quit IRC15:16
*** pcaruana has quit IRC15:18
*** derekh has quit IRC15:19
gibijaypipes: replied in https://review.openstack.org/#/c/502306 but I have to go offline in 5. I will check your reply tomorrow morning15:21
mriedemstephenfin: https://review.openstack.org/#/c/534724 drops a lot of info15:21
stephenfinmriedem: Fair points. I'll address those15:22
stephenfinThanks for the review (y)15:22
gibiKevin_Zheng: I left some suggestion in https://review.openstack.org/#/c/55328815:23
*** mdnadeem has joined #openstack-nova15:24
mriedemtssurya: figured out why you can't run nova-api without having [database]/connection setup http://logs.openstack.org/46/555346/2/check/tempest-full/69cf0dc/controller/logs/screen-n-api.txt.gz#_Mar_24_00_53_19_45295515:25
mriedemtssurya: File "/opt/stack/nova/nova/api/openstack/wsgi_app.py", line 49, in _setup_service is not multi-cell aware15:25
mriedembelmorei_: ^15:25
*** imacdonn has joined #openstack-nova15:26
mriedemthat code should likely just lookup the cell0 mapping and use it's context15:26
tssuryamriedem: ah okay15:27
kashyapdansmith: Responded; I'm not quite sure if a soft log warning would suffice...15:27
belmorei_mriedem thanks15:28
openstackgerritEric Fried proposed openstack/nova master: Unit test framework: common FakeResponse  https://review.openstack.org/55655115:28
efriedmriedem: Done.  More red!  Yay!15:29
kashyapdansmith: Also, about verbosity in the `reno`, I was aware of it; but I was not merely describing _what_ are those 3 modes.15:29
tssuryamriedem: thanks for spotting it15:29
*** david-lyle has joined #openstack-nova15:29
kashyapdansmith: Rather, what would Operators want to do in context of the three modes Nova allows.15:29
kashyap(As I've lost count on other Virt lists & IRC where people have asked about it.)15:29
kashyapThat said ... happy to snip it, and add it to a separate blog post or something.  I'm all for brevity with clarity.15:30
dansmithkashyap: ask someone else, but IMHO, it's about 500% too wordy15:31
kashyapdansmith: Folks on #openstack-release said it reads very well, FWIW.  smcginnis and dhellmann reviewed it15:31
dansmithkashyap: cool, but I think it's too much15:31
kashyapdansmith: I can cut it down.  But I'd rather want to definitely retain the info about what an Operator would do with each of the 3 modes15:32
kashyapIt _certainly_ makes sense.  As it's a completely valid question that will come up.15:32
kashyap(As not everyone dwells on it.)15:32
dansmithkashyap: that's fine, but I'll still be -1 on it15:32
kashyapI'd rather first get someone else's view too in Nova.15:33
*** sahid has quit IRC15:34
*** _ix has joined #openstack-nova15:34
dansmithkashyap: didn't I say ask someone else? :)15:34
*** cdent has joined #openstack-nova15:34
kashyapSure :-)15:34
* kashyap AFK; bbiab15:35
dansmithefried: are you looking for me to add aggregates to ResourceRequest, or just to slap it into the result of resources_from_request_spec? because it seems like that function does some weirdness where it requests some resource group and then jams extra resources into the result15:35
dansmithefried: this specifically: https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L33415:36
dansmithI guess it's returning some internal object and then jamming the resource request in there15:36
efrieddansmith: That bit is for special handling of the "default resource classes".  Wouldn't think aggregates would play in there.15:37
dansmithefried: yeah, I'm trying to figure out where aggregates go and reading that is confusing to me15:37
efrieddansmith: Anyway, yeah, I was looking for ResourceRequest to get an agg field (similar to the traits field) which would be populated based on the request spec.15:37
dansmithefried: you want an setter method on ResourceRequest that takes aggregates?15:37
efried...using the code you already done wrote.15:37
dansmithor can I just set res_req.aggregates = []15:37
dansmith?15:37
dansmithlike, resources_from_request_spec() seems like it should be a classmethod on ResourceRequest, but it's not so I'm trying to figure out how much of "friends" they are15:38
efrieddansmith: um, looks like I already have member_of on RequestGroup .15:38
dansmithokay and I don't really get the RequestGroup thing15:39
dansmithand that comes out of placement,15:39
*** bhujay has joined #openstack-nova15:39
*** andreas_s has quit IRC15:39
dansmithso in that case, I _would_ actually do aggregates like the extra resources are getting jammed in there?15:40
dansmithres_req.get_request_group(None).member_of = aggregates ?15:40
*** andreas_s has joined #openstack-nova15:40
*** ragiman has quit IRC15:40
*** jobewan has quit IRC15:40
efriedyeah15:40
dansmithmkay15:40
dansmithI don't really get what this is doing, but.. as you wish15:40
efrieddansmith: It's the framework for granular.15:40
dansmithah, and that's what ident is then.. okay15:41
efrieddansmith: Puts in one place the parsing of the extra specs into the RequestGroups which will feed into the placement call.15:41
dansmithefried: so, RequestGroup doesn't have much schema, so do you want me to:15:42
dansmithgrp.member_of = ['foo,bar', 'baz']15:42
dansmithor15:42
dansmithgrp.member_of = [('foo','bar'), ('baz',)]15:42
dansmith?15:42
efrieddansmith: Guess it depends on how that spec shakes out :P15:42
*** david-lyle has quit IRC15:42
jaypipesgibi: hey, sorry, went to get something to eat. I'll respond on the spec.15:43
openstackgerritMatthew Booth proposed openstack/nova-specs master: Add serial numbers for local disks  https://review.openstack.org/55656515:43
dansmithefried: I don't think it really does, this is just the internal way we communicate the request to report client right?15:43
*** afaranha has quit IRC15:43
dansmithefried: I'm not really sure why this lives in placement.lib I mean15:43
dansmithbecause later that will be out of tree and we won't use it to communicate with our own reportclient I think15:43
efrieddansmith: yeah.  I think the sooner we get to the list-of-tuples representation, the better.  So option 215:43
dansmithmkay15:43
efrieddansmith: It's just because RequestGroup is used by both nova side and placement side.15:44
efriedon the placement side, we parse the incoming querystring into the exact same representation.15:44
*** jobewan has joined #openstack-nova15:44
dansmithyeah, this seems like code sharing we should be removing so that we don't have any ties15:44
efriedIt's like... having a serializable object without having a serializable object.15:44
efrieddansmith: Well, cdent is aware, and was involved in the review process (I think).  I imagine there will come a time when there will be a placement_lib module that both of them will import.15:45
dansmithI don't see why we'd use that to communicate between internal components of nova, unless it provides a lot of pre-calculation of things or something, which it does not do now,15:45
*** david-lyle has joined #openstack-nova15:46
dansmithbut just be advised how hard it will be to land changes to that across both projects and update requirements and such before you can use a new thing if we go that route15:46
cdentI think I expressed reservations at the time, but mostly shrugged in a "we'll figure it out" and "if it helps now, cool" kind of way.15:46
dansmiththis provides zero help in its current form, IMHO :)15:46
*** bhujay has quit IRC15:47
efrieddansmith: Well, only because we haven't closed the final switches on granular yet.15:47
cdentIt helps on the placement side to decode the query string, but on the nova side, dunno. I'm not paying huge amounts on the nova side as it is just too hard to keep track of _all_ things15:47
cdentyeah, I think it is groundwork for stuff that was expected sooner than turned out15:47
efrieddansmith, cdent: On the nova side it lets us parse extra_specs; on the placement side it lets us parse the querystring.  On both sides they parse into the same representation.15:48
efriedwhich is (or will be) useful).15:48
efried))15:48
efried(((15:48
dansmithcdent: it's just a class with a few variables righ tnow15:48
dansmithanyway, I'm just pre-complaining, nothing that is going to block me right now15:48
*** andreas_s has quit IRC15:48
*** fragatina has joined #openstack-nova15:49
cdentdansmith: yeah, I know. I'm mostly speaking generally: I've de-prioritized my attention to the nova side of things for sake of being able to get anything done15:49
*** damien_r has quit IRC15:50
*** yamahata has joined #openstack-nova15:53
*** andreas_s has joined #openstack-nova15:54
openstackgerritmelissaml proposed openstack/nova master: fix a typo in service.py  https://review.openstack.org/55657515:55
openstackgerritMerged openstack/nova master: Updated from global requirements  https://review.openstack.org/55641815:56
*** rnoriega has quit IRC15:56
*** jaosorior has joined #openstack-nova15:56
openstackgerritEric Berglund proposed openstack/nova master: PowerVM: Add proc_units_factor conf option  https://review.openstack.org/55468815:57
*** rnoriega has joined #openstack-nova15:57
*** pchavva has quit IRC15:57
*** weshay has quit IRC15:57
openstackgerritEric Berglund proposed openstack/nova master: PowerVM: Add proc_units_factor conf option  https://review.openstack.org/55468815:57
*** kashyap has quit IRC15:58
*** belmorei_ has quit IRC15:59
*** kashyap has joined #openstack-nova16:02
*** weshay has joined #openstack-nova16:02
*** liverpooler has quit IRC16:02
*** pchavva has joined #openstack-nova16:02
*** gcb has quit IRC16:03
*** bhujay has joined #openstack-nova16:04
mriedemlike killing mosquitoes https://review.openstack.org/#/c/556575/16:06
mriedemhttps://review.openstack.org/#/c/545528/16:06
mriedemhttps://review.openstack.org/#/c/555404/16:07
mriedemgeez16:07
mriedemyay!16:07
mriedemefried: "Note that some people are opposed to typo-in-comment-or-docstring  patches.  It's a religious thing, I think.  So don't be surprised if  this gets the kibosh." heh16:07
mriedemi'm not opposed to fixing documentation if it makes the documentation more clear, i am opposed to stat padding py pushing several 1-line spell check fixes across openstack at random16:08
mriedem*by pushing16:08
*** felipemonteiro__ has quit IRC16:09
*** yangyapeng has quit IRC16:10
efriedmriedem: I thought we didn't put enough stock in stats to make that the sole reason for rejecting things like this.  IMO patches like this could be fast-approved more quickly than they can be squashed.  And let the author have the stats - what difference does it really make?16:10
efriedAnyway, that's my 2c16:10
mriedemit's not the sole reason16:10
stephenfinI'd be more lenient. If it doesn't cause merge conflicts, it's good and could be conceivably fast approved. If someone's basing their employee reviews on Stackalytics, they're the fools16:10
mriedemit's also noise16:10
*** yangyapeng has joined #openstack-nova16:11
efriedMeh, how much noise is it really?  Are you worried about an explosion of trivial patches if you start approving these?16:11
mriedemimo it encourages bad behavior16:12
cdentFWIW I agree with efried16:13
cdentthe only thing that should matter in the end is the quality of the code16:13
stephenfincdent: With the caveat that it's trivial and doesn't cause merge conflicts. Functional changes still have to take priority16:14
efriedI agree there's a balance to be struck against reviewer time.  In this case, it's eta/eta16:14
*** yamahata has quit IRC16:14
*** david-lyle has quit IRC16:14
efried(or whatever greek letter means "something really small")16:14
bauzasgosh, I'm about to ragequit because of all the NUMA quirks we need to support16:15
stephenfinbauzas: You're welcome :)16:15
bauzasfaking cpu sockets for licensing reasons => booooh16:15
bauzasthe question I wonder is, should https://docs.openstack.org/nova/latest/admin/cpu-topologies.html#customizing-instance-cpu-topologies be Placement-specific ?16:16
bauzasmy guts say no16:16
bauzasstephenfin: jaypipes: thoughts on that ?16:16
stephenfinWhat do you mean, "placement-specific"?16:17
bauzasResource classes and other things16:17
*** udesale has quit IRC16:17
bauzasIMHO, we should just provide the NUMA topology, find a node and period.16:17
jaypipesbauzas: on a call... gimme a bit.16:17
stephenfinbauzas: It doesn't affect what you need to claim so IMO no16:17
*** udesale has joined #openstack-nova16:17
bauzasyup, cool16:17
stephenfinbut jaypipes might have other ideas, once he's free16:17
*** andreas_s has quit IRC16:18
openstackgerritMerged openstack/nova master: Fix api-ref: nova image-meta is deprecated from 2.39  https://review.openstack.org/55481316:18
*** masuberu has quit IRC16:18
bauzasefried: question, can I ask for both a resource query on a root node *and* a child RP ?16:22
*** andreas_s has joined #openstack-nova16:22
* bauzas trying to wrap his head around a loooong transition period for having all the NUMA features checked by Placement queries16:23
efriedbauzas: The only place you can ask for resources that span RPs is in the un-numbered request group.16:23
bauzasideally, I'd love to see something like MEMORY_MB on both the root RP *and* the NUMA node16:23
bauzasefried: can you please explain further ?16:24
efriedbauzas: Are those separate blocks of memory?16:24
bauzasI dunno yet16:24
bauzas(tbh)16:24
*** ktibi has quit IRC16:24
bauzasI'm just hardly trying to not lock all the world16:24
efriedIMO we should not try to do the thing where we have e.g. 2048MB of memory in each NUMA node and then represent 4096MB on the compute node which isn't really there.16:25
bauzaslike I'd like to provide a mechanism to select a NUMA node but huge pages could still be checked by the virt driver16:25
*** salv-orl_ has quit IRC16:25
bauzasefried: I got your point, my problem is more about trying hard to not draw a house of cards16:26
*** salv-orlando has joined #openstack-nova16:26
efriedbauzas: is there a fixed ratio between memory MB and number of huge pages?16:26
*** moshele has quit IRC16:26
bauzasefried: the solution is simple in my mind16:26
bauzasthat's all about traits and step_size16:26
bauzasbut16:26
*** sambetts is now known as sambetts|afk16:26
bauzasif we go decide to provide a tree of NUMA nodes16:26
bauzasbut we don't support yet hugepages, then we have a problem because flavors asking for hugepages would get NoValidHosts16:27
*** gyee has joined #openstack-nova16:27
bauzaswe somehow still need to accept compute nodes to report their memory the old way16:28
efriedwhat's a hugepage?16:28
efried(use little words)16:28
bauzashttps://docs.openstack.org/nova/latest/admin/huge-pages.html16:28
bauzasit's a defined memory page size16:28
bauzasbut that's just an example16:28
bauzasfor the moment, placement only checks the total memory of the host, right?16:28
bauzasthen the scheduler filter does magic things to find a destination16:29
*** suresh12 has joined #openstack-nova16:29
efriedWell, yeah, so this is kind of in line with what we need to do wrt bandwidth.16:29
efriedWe represent the number of huge pages as inventory alongside the MEMORY_MB inventory.16:29
efriedbut16:29
efriedif the consumer is going to include hugepages as part of their request, they *always* need to do so.16:30
bauzasso, my concern is that if I'm beginning to shard the memory between NUMA nodes, then it requires the flavors to be updated to explicitly ask for a NUMA node, whereas huge pages are totally NUMA unrelated16:30
*** salv-orlando has quit IRC16:30
efriedbecause what we can't (or shouldn't) do is try to convert a request for MEMORY_MB:4096 into MEMORY_MB:4096,HUGEPAGES:4 (or whatever)16:30
bauzasefried: I'm not trying to design now how to make placement queries for hugepages16:31
efriedbauzas: But does a huge page come from the same place as a MEMORY_MB or is it a separate thing?16:31
*** masuberu has joined #openstack-nova16:31
bauzasefried: what I'm trying is to make sure we keep a compatible behaviour for the existing feature16:31
bauzasothers, later, will try to solve that design and use placement resources for that16:32
bauzaslike the PCPU spec16:32
efriedbauzas: okay, maybe we back up and I just answer your original question :)16:33
bauzasbut again, what I want is to make sure that if operators enable reporting of NUMA nodes using NRPs, then it can still be possible to use hugepages flavors for finding a destination16:33
*** bhujay has quit IRC16:34
efriedYou can specify multiple resources of different classes in a request group.  A numbered request group will get *all* of those resources from the *one* resource provider.  The un-numbered request group will get the resources from any provider in a tree or associated sharing providers.  However, even in the latter case, all resources of a specific resource *class* will still come from a single provider.16:34
*** suresh12 has quit IRC16:35
*** udesale has quit IRC16:35
*** andreas_s has quit IRC16:36
*** germs has joined #openstack-nova16:36
*** germs has quit IRC16:36
*** germs has joined #openstack-nova16:36
*** lucasagomes is now known as lucas-afk16:37
*** sree has quit IRC16:38
*** srini_ has quit IRC16:38
bauzasefried: I see, thanks16:39
bauzasso that could work16:40
bauzasif I'm providing a NUMA topology through nested RPs, placement will give me a resource provider that supports that memory16:40
*** germs has quit IRC16:41
*** trozet has joined #openstack-nova16:42
bauzasefried: from a scheduler perspective, when it finds a nested resource provider as a destination when calling Placement API, I guess it uses the root RP for passing it down to the filters ?16:42
*** srini_ has joined #openstack-nova16:43
efriedbauzas: We haven't fully closed the switch on that yet, but yes, even if zero resource comes from the root RP, it'll still be the thing used as the "destination host".  Not sure if that's a full answer to your question.  Because filtering might need more info than that.16:43
efriedI'm guessing the entire allocation_request will need to be considered for some filters.16:43
*** pcaruana has joined #openstack-nova16:44
bauzasefried: that's the problem I see with NUMA filter16:44
bauzasefried: because say placement finds a NUMA node, then it will return the child to the scheduler on a classic call16:44
bauzaseg. a regular flavor16:45
bauzasso we need to pass down the root RP16:45
bauzasbut then, the NUMA filter could try to find another NUMA node instead of using the one allocated16:45
efriedbauzas: Correlating the allocation_request with the provider_summary ought to allow you to figure out which NUMA node the resources were allocated from.16:46
efriedBut yeah, without further invention, only the virt driver will know which RP UUID corresponds to which NUMA node.16:46
*** dklyle has joined #openstack-nova16:47
bauzasthat's not really the problme16:47
efried...which is kind of appropriate, because "identifying a NUMA node" is a virt-specific thing.16:47
efriedI.e. libvirt is gonna do it a different way than hyperv or whatever.16:47
bauzasthe problem is, say you ask for 2GB of memory within a NUMA node, then placement gives you host A with 2 NUMA nodes but only one NUMA node for host B16:48
bauzasbecause the other NUMA node of host B is full16:48
bauzasthen, we need to pass to the scheduler filters the root RP16:48
bauzasin theory, when it goes on NUMA filter for host B, it could consider the second NUMA node for host B as legit16:49
bauzasthere be dragons16:49
*** dklyle has quit IRC16:49
*** david-lyle has joined #openstack-nova16:49
efriedhow could it?16:50
efriedThere's no candidate with allocations in that second NUMA node on host B.16:50
sean-k-mooneybauzas: there might be dragons but the host state object for host b should also know that the second numa node is fully used and ignore it16:50
sean-k-mooneybauzas: what is an issue if both numa nodes are valid and the filter chooses the other one form placement16:51
sean-k-mooneye.g. placement decremetes the inventor that corresponds to node 0 but the numa topology filter decrements node 116:51
bauzasokay, then I'm maybe overthinking16:51
*** yangyapeng has quit IRC16:52
sean-k-mooneybauzas: there is an edge case here but its for  host A with 2 NUMA  not host B with 116:52
*** kmalloc has joined #openstack-nova16:52
sean-k-mooneyfor host b the resouce tracker will have updted the numatoplogy blob to also show the second numa nodes as full but in the case of host A both are valid from its point of view16:53
*** lpetrut_ has quit IRC16:54
bauzasI guess my fears are coming from the fact we litterally try to draw something out of nowhere, and without good testing for making sure we don't trample folks16:55
*** sree has joined #openstack-nova16:55
openstackgerritEric Berglund proposed openstack/nova master: PowerVM Driver: DiskAdapter parent class  https://review.openstack.org/54905316:55
bauzasif I was able to just test what I write, I wouldn't be trying to consider all the edge cases16:55
*** gjayavelu has joined #openstack-nova16:55
*** david-lyle has quit IRC16:55
*** andreas_s has joined #openstack-nova16:55
openstackgerritEric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Localdisk  https://review.openstack.org/54930016:55
*** tssurya has quit IRC16:56
bauzasand I just feel I'm just trying to sink all the ocean's water16:56
*** suresh12 has joined #openstack-nova16:57
sean-k-mooneybauzas: i think you have raised a valid issue here. the virt driver will likely need to tag the resouce providres with a trait or aggregat to allow it to map its internal view(in the resouce tracker/numa toploygy bob) to the view it gets back in the allocation canditates16:57
bauzassean-k-mooney: how do you see that ?16:58
*** sree has quit IRC16:59
*** JunoMan is now known as penick16:59
sean-k-mooneyhow would you do it? when the virt driver create the RP for the numanode in the provider tree update it would include a CUSTOM_HOST_NUMA_ID_X trait where X is its internal identify for the numa node e.g. 0 or 116:59
*** rmart04 has quit IRC16:59
sean-k-mooneythen in the allocation canditates resoponce the numa topology filter can use that trait to map the the correct cell in the numa topology blob17:00
*** mdnadeem has quit IRC17:00
sean-k-mooneyyou could also use an agregate but that would be harder to map to the topoploy blob unless we add teh aggregate uuid to the blob17:00
bauzassean-k-mooney: ouch.17:01
sean-k-mooneythat trait/aggreage would be uses soly by the virtdriver/filter and never passed in any request to placement17:01
*** suresh12 has quit IRC17:01
bauzassean-k-mooney: the problem is that the virt.hardware module is a pleasure to modify17:02
bauzasI'd really want to avoid any subsequent modification17:02
sean-k-mooneybauzas: yes well if we use a trait then we dont need to modify it17:03
sean-k-mooneywe just need to modify the update provider tree stuff to also include the cell id17:03
sean-k-mooneyas a trait on the numa node17:03
bauzasnot sure I'm getting you17:04
sean-k-mooneyi have not looked but im assumeing the numa patches where going to use the info from the numa topology blob to create teh RPs for the NUMA node and the sub resouces of that node17:04
bauzasbecause the virt.hardware module gets a topology from both the hoststate and the instance proposed topolgy17:04
bauzashere, we would need to hack the module to look at the resource providers, right ?17:05
bauzasinstead of the host state17:05
bauzasanyway, I'm running out of fuel for my brain17:06
sean-k-mooneybauzas: i think we would need to pass in the allocation candiates to the filter yes and then pass that down into the fit_instance_to_host fucntion or whatever it is called so that it could make a descission based on the allcoation candiate17:06
bauzasright, that's what I meant17:07
*** masuberu has quit IRC17:07
sean-k-mooneyya that fuction is a pain to modify or debug but its going to need to be scoped to the allocation candiate to work correct when numa is in placement17:07
*** ralonsoh has quit IRC17:08
*** archit has quit IRC17:08
*** andreas_s has quit IRC17:09
*** liverpooler has joined #openstack-nova17:09
jaypipesbauzas, stephenfin, sean-k-mooney, efried: sorry, done with call now.17:09
*** yassine has quit IRC17:09
* jaypipes reads back17:09
bauzasjaypipes: I'm just rat-holing17:10
bauzasmy concern is, how to make sure we can still have all the NUMA features be workable in a world with nested RPs albeit all things solved in the future++ with placement resources17:11
sean-k-mooneyjaypipes: the issue is basically how to correlate placement RPs with the compute node resouce tracker so that when the the numa topology filter or pining code runs we only look at the resouce selected by placement in the allocation candidate and not all numa nodes for example.17:12
*** mdbooth has quit IRC17:12
*** moshele has joined #openstack-nova17:12
*** andreas_s has joined #openstack-nova17:14
*** AlexeyAbashkin has quit IRC17:15
*** dtantsur is now known as dtantsur|afk17:15
*** david-lyle has joined #openstack-nova17:18
jaypipesefried: iota?17:20
*** moshele has quit IRC17:23
*** david-lyle has quit IRC17:25
*** lpetrut_ has joined #openstack-nova17:25
*** szaher has joined #openstack-nova17:25
*** salv-orlando has joined #openstack-nova17:26
*** srini_ has quit IRC17:27
*** salv-orlando has quit IRC17:31
*** tssurya has joined #openstack-nova17:31
jaypipessean-k-mooney: I don't think it's really a big issue. Basically, let the NUMA topology filter just run as-is. It will "pick" a NUMA node to pin the instance to (and then promptly forget about its pick). The scheduler will claim resources against one of the NUMA nodes on the host (via the normal allocation request claim_resources() process). The build request gets to the compute host. During the instance_claim() process, the numa_fit_instance_to_17:33
jaypipeshost() is run again. If that picks a different NUMA node than what is in the allocation_request that is sent along with the build request, then we raise an exception and just retry the scheduling.17:33
dansmithefried: so, questions about L371 here: https://review.openstack.org/#/c/547990/10/nova/scheduler/client/report.py17:35
dansmithefried: what 406 are you talking about?17:35
dansmiththe only one I know of is if the version isn't supported that we need for member_of17:35
dansmithefried: and, I'm only running the intersection and setting of the member_of if aggregates is non-empty, which is what you're saying I'll need to do17:36
sean-k-mooneyjaypipes: thats one option be se should really not have to retry here17:36
sean-k-mooneyjaypipes: we should be able to just look at the cell that was selected by placement17:36
sean-k-mooneyalso when numa_fit_instance_to_host runs how to you tell if it picked a different node to the one in the allocation_request if you cant correlate between them17:38
efrieddansmith: The functionality you want is to be able to do the set logic on aggregates.  We plan to allow placement to do that via some new syntax (your pending spec delta).  Once that happens, there'll be a microversion for that.  And at that time, if you try to use that new microversion, you'll also have to handle the case where placement is downlevel, just like we do everywhere else where we might be straddling versions.17:39
edleafeefried: is there a spec/bp/bug for adding the consumer generation?17:40
efrieddansmith: And what I'm saying is that the 406 branch will have to do the placement query without taking member_of into account (or using the intersection thing as a prefilter) and then do the set logic on the candidates that come back for that too-broad query.17:40
dansmithefried: why? the last couple times we've bumped that version we have't supported an older placement17:40
efriedWhoah.  Yes, we do, every time.17:41
dansmithefried: we've been saying placement goes first in the upgrade stack17:41
efriededleafe: Not as of the last time I checked, which I think was yesterday.17:41
dansmithefried: where? that code has changed several times while I was working on this and we don't have any fallback code there17:41
*** suresh12 has joined #openstack-nova17:41
efrieddansmith: I think we say that as a best practice or something, but we've got somewhere else that defines the minimum placement microversion for a given release and it's always lower than the maximum for same release.  mriedem help me out here.17:42
jaypipesdansmith: example? the code has changed in a backwards *incompatible* way and we don't have fallback code?17:42
efrieddansmith: Just look for 406 in report.py17:42
efriedcdent culled the stale ones at the end of Queens, so there aren't many left, but still some.17:42
dansmithjaypipes: the last couple of times this exact method has changed17:42
sean-k-mooneyefried: the grenagde job in the gate is proably upgradeing placement first so even if it could work its proably not tested today17:43
*** r-daneel has quit IRC17:43
dansmithI can go actually dig up reviews if you care17:43
edleafeefried: yeah, I didn't see anything either. So would you call this a bug fix or a new feature?17:43
dansmithefried: why are we using different initial versions for any of those calls then?17:43
efriededleafe: needs a bp fo sho17:43
edleafeefried: ok. Is there any discussion I can refer to? I'm not clear on the reasons for doing this17:44
efrieddansmith: Because the newer way is usually more efficient or similar; and it gives us an easier delta when we do bump the min17:44
cdentedleafe: needs a spec, is a new feature and an api change17:44
dansmithefried: jaypipes this one is the one I have in my head right now: https://review.openstack.org/#/c/536085/9/nova/scheduler/client/report.py17:45
cdentedleafe: if you want to chat about a bit later this evening I can do a bit of a brain dump on you if you want17:45
cdentbut in the midst of something at the moment17:45
edleafecdent: you mean you haven't dumped it in an email yet? :)17:45
dansmithefried: the problem is that if placement doesn't go first, scheduler depends on it for az calculation, then we have to fail any request that cares about az if placement doesn't support 1.21 _anyway_17:46
cdentno, because I was trying not to own this one. I did have a to do list item which said "write email about consumer uuid" but deleted it when you "got ownershipw of this" :)17:46
*** andreas_s has quit IRC17:47
edleafecdent: ah, I was just volunteering my cycles to code it. If I gotta write a spec, I should at least understand the motivation behind it.17:47
edleafe(that usually helps) :)17:47
efriededleafe: I got you, gimme sec17:47
cdentedleafe: details! but yeah, I can dump some brain shortly if efried doesn't beat me to it17:47
jaypipesdansmith: you will note I did not review that.17:47
dansmithjaypipes: so cdent was culling all the microversions when, at the end of each release?17:49
efrieddansmith, jaypipes: Agree that one should have had the 406-fallback conditions.  I shoulda reviewed it too, but didn't.  IIRC that got jammed in really late in Q because we weren't going to make granular happen in time.17:49
dansmithjaypipes: so you want a bunch of microversion handling code for within-release changes?17:49
cdentjaypipes, dansmith: we've been inconsistent about our expectation with nova-side microversion fallback. I've not been able to discern a pattern, mostly because _some_ of the time we say "we expect placement to upgrade first" at which point why bother falling back?17:49
cdentI didn't cull them all, just anything less than 1.14 (I think it was 1.14, would need to check to be sure)17:49
dansmithcdent: yeah I see some places where we do fallback, and some where we don't17:49
dansmithcdent: it was 1.1417:49
jaypipesdansmith: I'm just noting I did not review that patch (didn't know about it at all). I believe I was in Dallas that week.17:50
*** r-daneel has joined #openstack-nova17:50
jaypipesdansmith: I do support the reportclient supporting fallback code (406 handling) for at least a release, yes.17:50
dansmithso what do you people propose? scheduler fails if you request an az and placement is old? fall back but make sure the old filter is enabled otherwise fail?17:50
jaypipesdansmith: yes, that sounds reasonable to me.17:51
dansmithjaypipes: we're not testing nova against an older placement, so it basically doesn't work17:51
dansmithjaypipes: seriously? that was a joke :)17:51
*** wolverineav has joined #openstack-nova17:51
dansmithwell, the second part was a joke17:51
dansmithmaybe you mean the first part?17:51
dansmithbut that doesn't seem very friendly to me17:51
jaypipesdansmith: well, the "make sure the old filter is enabled" was a joke, right?17:51
*** wolverineav has quit IRC17:52
dansmithyes17:52
sean-k-mooneyjaypipes: as other service start using placement it will likely make sense to have placement upgrade early in the sequence. is there a reason you do not want to commit to placement before nova in general?17:52
*** wolverin_ has joined #openstack-nova17:52
jaypipesdansmith: the "fail if placement doesn't support the az filter" wasn't.17:52
dansmithjaypipes: I think if we're adding code for all those branches we need a grenade test where we leave placement behind on queens and run master against it17:52
efrieddansmith: I think what I'm saying is that nova can support the AZ filter even without support for GET /a_c?member_of=17:53
dansmithlike we did for nova-compute17:53
dansmithotherwise it's broken17:53
*** felipemonteiro has joined #openstack-nova17:53
efrieddansmith: And if we need to support N-1 release of placement in nova, we've gotta write that code "the hard way".17:53
dansmithefried: it can if you leave the post-processing filter enabled17:53
mriedemefried: nova-status has a min placement API version check17:53
jaypipessean-k-mooney: if the change in the placement API is backwards compatible (which a *new* query param is), I don't see a reason to fixate an upgrade to always do placement first.17:53
dansmithefried: yeah, I'm asserting we do not17:53
efriedmriedem: So the discussion here is: why isn't that minimum version always the same as the max-in-release?17:53
*** archit has joined #openstack-nova17:54
mriedembecause the nova side code might not be using the max yet17:54
*** felipemonteiro_ has joined #openstack-nova17:54
dansmithmriedem: in most cases it's not17:54
efriedmriedem: Under what circumstances?  Haven't we always said you have to upgrade placement first?17:54
mriedemgenerally it likely is because we added the new placement api versions for things nova needs17:54
sean-k-mooneyjaypipes: that is true but it appears we are not quite to that point yet. as dan said we likely need a gate job that leaves placement on N-1 to validate it works if that is the guareentee we want to give17:54
dansmithmriedem: that's why I'm saying we might as well use the same default microversion in the whole file if we're going to require this, which i think defeats a lot of the point of microversioning this at all17:55
mriedemsee first bullet in #2 here https://docs.openstack.org/nova/latest/user/upgrade.html#rolling-upgrade-process17:55
mriedemi haven't been paying attention to this conversation so don't have context17:55
*** owalsh_ is now known as owalsh17:56
dansmithso by the same argument,17:56
dansmithif a flavor has any required trait in it,17:56
sean-k-mooneymriedem: that likely should be expanded to "before and openstack service that uses placement" rather then nova but ya.17:56
dansmithwe must fail if placement doesn't support 1.17 for that rev I linked above17:57
mriedemsean-k-mooney: these are nova upgrade docs...17:57
dansmithsean-k-mooney: those are nova upgrade notes17:57
dansmithheh17:57
efrieddansmith: Or write a post-filter.  Yeah.17:57
sean-k-mooneyhehe ok fair point :)17:57
dansmithefried: we can't do that, AFAIK17:57
mriedemdansmith: i thought we did fail if a flavor has required traits in it but 1.17 isn't available?17:57
dansmithefried: filters don't have access to the actual a-c I don't think17:57
dansmithmriedem: we do, but they are arguing that it should fall back to 1.1417:58
efrieddansmith: I'm not talking about a Filter.  Talking about code in the report client that manually does the trait filtering.17:58
dansmithand I'm saying I don't know what we do in that case, because 1.14 isn't enough17:58
mriedemi disagree,17:58
mriedemif the flavor has required traits, the admin is saying, 'i require traits for this flavor so make it happen or fail'17:58
*** felipemonteiro has quit IRC17:58
dansmithmriedem: agreed, and same for my aggregate requirement17:58
dansmiththere's no point in falling back17:58
efrieddansmith: Except that putting a trait in a flavor is a new thing the admin would do.17:59
mriedemhttps://docs.openstack.org/nova/latest/user/flavors.html has something about required traits but doesn't say we fail explicitly if 1.17 isn't available17:59
dansmithefried: so?17:59
efrieddansmith: But AZ filtering is something we're trying to make compatible with existing setups... no?17:59
dansmithefried: but we can't test for membership from the client side18:00
dansmithefried: at least not providing the same semantics the user is expecting18:00
dansmithwe can approximate it by looking in nova's notion of the aggregate, but it's not the same18:00
efrieddansmith: Sure, why not?  That method has received the list of aggregate UUIDs. We can glean RP UUIDs by looking at placement.  We just do the filtering on the client side rather than at the placement server.18:01
efriedI mean, it's likely to be horribly inefficient.18:01
dansmithmriedem: that text implies NoValidHost if we can't find RPs with the traits requested, which is even less obvious about why it's failing18:01
efriedmriedem: TBC, I think we agree it was a miss that this issue wasn't considered one way or another in that traits review.  We're kind of post-morteming what we *should* have done there.18:01
dansmithwell, fwiw, I had been assuming what our docs say, which is placement goes first18:02
efrieds/glean RP UUIDs/glean aggregate UUIDs for those RPs/18:02
*** salv-orlando has joined #openstack-nova18:02
cdentIs there a reason we can't assume placement goes first?18:02
cdentI mean can we decide today that's how it is going to be?18:03
dansmithor acknowledge that we already did? :)18:03
mriedemefried: eh? if placement 1.17 isn't available for required traits in a flavor, i think we should fail18:03
cdentdansmith: well, sure, yeah18:03
efriedmriedem: That seems like a reasonable decision to me.  I wasn't necessarily advocating for anything else, just pointing out that there are other options.18:04
*** mvk has quit IRC18:04
efriedableit sucky ones.18:04
dansmithefried: BS you were too :)18:04
efrieddansmith: Well I certainly was advocating for that in the case of your patch.18:04
dansmith<efried>Whoah.  Yes, we do, every time.18:04
dansmith^18:04
dansmithheh, okay18:04
efrieddansmith: Yeah, that was before I realized we had screwed the pug on the traits one.18:05
mriedemfor the traits one, the pug needed to get laid imo18:05
mriedemnot every case is a fallback situation18:05
dansmithright18:05
efriedI (now) agree with that.18:05
efriedBut dansmith I'm still needing to be told that it won't represent a regression if we go the failure path in the agg filtering case.18:06
efriedLike, does an existing flavor in an existing cloud quit working because we made this path fail (if they don't have recent placement)?18:07
dansmithaz is per user request18:07
dansmithnothing to do with flavor18:07
dansmithin this case18:07
efriedsame thing as far as I'm concerned.  Clouds have scripts.  Or orchestrators, or whatever.  That expect it to work a certain way.18:07
efriedIf we put a real stake in the ground about upgrading placement first, it's moot.  We can rip out the existing 406 code, never have to implement it again going forward.18:08
dansmithokay I'm not sure what you're looking for here18:08
dansmithefried: as mriedem said, I'm not opposed to all failback code18:08
dansmithby any means, but this one has no legit alternate path imho18:09
efriedI would love to see us say placement must always be upgraded first.  I just wasn't aware that was even a possibility.18:09
dansmithfor example,18:09
dansmiththe compute code paths may be able to tolerate older or newer placement because they're mostly just massaging data into the right format,18:09
dansmithand we changed POST (or GET) once already and meh they can handle it18:09
dansmithbut this is more than just format and it's something the scheduler is hard depending on18:09
dansmithso, I can use 1.17 if no aggregates are required, and only request 1.21 if they are, if you think that's better, but I don't think falling back to 1.17 is a thing for this18:10
dansmithso we'll tolerate older placement if we don't need it,18:10
*** tesseract has quit IRC18:10
dansmithalthough that just means the operator says "half these requests work, wtf?"18:10
dansmithand, I think if we're going to do any of that, we need a real grenade test where the service is left unupgraded18:11
dansmithotherwise we have nfi if it works or not18:11
jaypipes-1 just because efried just said "screwed the pug"18:11
efriedI was wondering when you would catch up with that.18:11
* jaypipes having ten conversations at once18:11
efrieddansmith: My concern is this: will there be some script "out there" that says "do this AZ thing" that works on Queens, and then when they upgrade to Rocky, that same script will no longer work IF they're downlevel placement.18:12
dansmithefried: yeah and I don't see that as a problem18:13
efriedAnd if the answer is yes, are we accepting that and our response would be "go upgrade placement"18:13
dansmithefried: if the rule is placement goes first18:13
dansmithefried: any idea how much will break if you upgrade nova-compute and nothing else?18:13
efrieddansmith: Then w00t and let's update the docs (mandatory) and let's rip out all the fallback code (optional) and let's forget anyone ever mentioned a grenade test.18:13
efrieddansmith: And in this case, use 1.21 and be done.18:14
efrieddansmith: Although actually it'll be 1.2x whenever the list-of-tuples business is approved and written.18:14
sean-k-mooneyefried:  well if you boot a vm via horizon i think it forces you to specify an availablity zone so if nova has a hard dependcy on 1.21 for AZs to work that would break horizon booted vms if you did not upgrade placement18:14
dansmithefried: see, I don't think that's the way to go.. using 1.21 means every time I need to bump the level for g-a-c, I have to go fix all the other code in that file which is perfectly fine with 1.118:14
dansmithefried: that's the whole point of microversions, as I see it.. that you don't need to do that18:15
efrieddansmith: I'm talking about using 1.2x for just this method, not for the whole file.18:15
dansmithefried: you opt into new features (and maintenance) on a per-call basis as you need it18:15
*** jmlowe has quit IRC18:15
dansmithefried: ack, okay18:15
*** jmlowe_ has joined #openstack-nova18:15
efrieddansmith: But I *am* saying the fallback code elsewhere in the file (two places, I think) becomes dead and can be removed.18:15
jaypipesright, exactly.18:15
dansmithjaypipes: who are you agreeing with?18:16
jaypipesdansmith: you.18:16
jaypipes"you opt in ..."18:16
dansmithjaypipes: okay I'm totes confused about where you sit on this then ;)18:16
efriedI was agreeing with that too.  So everybody agrees.18:16
*** yamahata has joined #openstack-nova18:16
jaypipesdansmith: I guess my butt hurts from the fence.18:16
* dansmith walks away, wide-eyed18:17
jaypipesdansmith: on the one hand I don't want to *always* force users to upgrade placement first when it's not necessary to. on the other hand, I see the futility of operators upgrading nova-scheduler first, placement second and having a time when some requests involving AZs suddenly start failing.18:18
*** lpetrut_ has quit IRC18:18
jaypipesdansmith: I was referring to sitting on the fence, there...18:18
jaypipesin case that wasn't obvious ;)18:19
dansmithjaypipes: yeah, and I also don't think operators are at all complaining about having a clear order of services for upgrades18:19
sean-k-mooneyjaypipes: well we would only be frocing them to upgrade placement first if they need a placement feature in nova18:19
*** wolverin_ has quit IRC18:19
jaypipesdansmith: ok, then I'm cool with all of this, then. :)18:19
jaypipescarry on.18:19
dansmithaight18:19
jaypipessorry for being dense.18:19
sean-k-mooneydansmith: well from an install tool poing of view ya most installers would perfer to always have a clear order of operations even if it wasnt strictly required.18:20
efriedjaypipes: Ugh, why is maxlength for a RP name 200?  (As opposed to 255, like for trait and RC?)18:20
dansmithsean-k-mooney: in the early days of making nova upgrade smoothly, that was the #1 request.. "just tell me which order and I'll do it."18:20
jaypipesefried: UGH. Why would you need an rp name longer than 200 characters. UGH!18:21
efriedjaypipes: Sorry, the ugh was because inconsistent with trait/RC.18:21
sean-k-mooneydansmith: i think that is still the case although "keep it running without any downtime magically while i upgrade" may have over taken it18:21
jaypipesefried: no idea18:21
efriedcdent: any idea?18:22
sean-k-mooneyefried: its saves you half a KB per RP? do you have a reason to have a name over 20018:23
cdentwell, rp name came first, so I reckon it was arbitrary decision at the time and then when custom traits and resource classes came along people expressed concern about wanting to make them super long and 255 some some random compromise. AKA: I don't think there were _reasons_ as such18:23
efriedsean-k-mooney: No.  I'm writing code to sanitize RP/RC/trait names and the inconsistency is gonna make me write >1 method instead of just 1.18:24
sean-k-mooneyefried: or jsut assume make 200 for all names18:24
sean-k-mooneythere is no harm in makeing it a 255 lenght however you would need a sql schema update which likely is not worth it for this allow18:25
* cdent suspects efried is optimizing again, rather than letting the api tell him when things are wrong18:25
cdent?18:25
melwitttssurya: hey, thanks for bringing up the user_id column in instance_mappings table thing. I agree it should be a separate spec to handle the "quota when cell-down" issue. I have an old spec for it that I can resurrect. my spec will depend on yours because I also need the queued_for_delete column18:25
tssuryamelwitt: okay, :) I guess we can co-ordinate on this then, I will let you know as soon as I put up a spec for it then.18:27
melwitttssurya: cool, thank you :)18:27
efriedcdent: Not quite.  I was reviewing 520313 which has code that will wind up sending down an RP name that will fail - https://review.openstack.org/#/c/520313/23/nova/tests/unit/virt/xenapi/test_driver.py@443.  Letting the API fail in this case will be worse than suboptimal, because by the time that happens, we're outside of where virt can do anything about it.18:27
efriedcdent: This isn't the first time I've seen a need for a method to "slugify" a placement identifier, so I thought I would write it.18:27
tssuryamelwitt: the only concern I have is that at the PTG, we discussed that we would not use placement and do a solution of allowing the users to create VMs if they don't have any in the down cell18:28
cdentefried: I was teasing18:28
cdentgentle ribbing and all that18:28
melwitttssurya: you mean disallowing?18:28
tssuryamelwitt: however if we are going to use placement, then this changes things i guess18:28
efriedcdent: It's a valid concern that you should check me on constantly, even though (or perhaps especially because) you and I fundamentally disagree on whether such pre-optimizations are desirable.18:28
efriedcdent: But in this case, it's more than that.18:29
tssuryamelwitt: no, I mean allowing VM creation as long as there are no living VMs in the down cell18:29
tssuryamelwitt: since in that case the quota calculation will be correct18:29
melwitttssurya: yeah, that was when we had thought being able to count instances while cells are down would require adding a "type" to placement allocations. that is something that will take a lot of work to figure out18:29
cdentFair enough. I never really said they are not desierable, I suggested that they should wait for the road to show they are needed.18:29
sean-k-mooneyefried: maybe just take the lenght as an optional param that you defalt to 255 and the caller can set 200 or what ever if they no its less for that field18:29
tssuryamelwitt: ah okay, so then  I will do a spec for queued_for_delete and we can take it from there then18:30
melwitttssurya: yeah. we had said that because at the time we were thinking to remove the dependency on reading cell databases, we would have to add a "type" to placement allocations and that was not going to be straightforward and needed a lot more time and design18:31
*** mvk has joined #openstack-nova18:32
tssuryamelwitt: hmm yea now I remember, thanks!18:32
*** vipul has quit IRC18:32
melwitttssurya: but when I was thinking about it later, if we have queued_for_delete (from your spec) that was the main missing piece preventing us from being able to count instances in the instance_mappings table. the other piece is user_id18:32
melwittthe "queued_for_delete" column was controversial in the past, but now that it's not, it opens that door again18:33
tssuryamelwitt: yea I agree, I guess I will go ahead with the queued_for_delete and will leave out the user_id for a separate spec and we (you) can battle out adding the "type" with the placement guys later18:33
melwittuser_id I think is not controversial because we already have project_id, I'm actually not sure why we didn't add user_id too18:33
tssuryamelwitt: the reason I was asking for the user_id is because I could do these two in the same spec if you want like dansmith said its one migration18:34
melwitttssurya: sounds good18:34
melwitttssurya: yeah, I agree with him that it can be one migration, just two specs where each problem being solved for down cells is described in detail separately18:35
melwittjust so it's easier to organize18:35
tssuryamelwitt: cool, I was waiting to get your opinion too, so I will do it in two specs, one for nova-list/service-list when a cell is down, second for quotas when a cell goes down, however I won't touch any from placement18:36
tssuryacalculations since you already have a spec18:36
*** germs has joined #openstack-nova18:37
melwitttssurya: okay, won't that mean we would have three specs then? I was thinking I would just roll the "add user_id column" stuff into the spec I have https://review.openstack.org/#/c/50904218:37
melwittand then also add reference to your spec where it depends on your queued_for_delete column18:38
tssuryamelwitt: oh yes that's fine with me18:38
tssuryamelwitt: so I will do one single spec with queued_for_delete,18:38
tssuryamelwitt: sounds good ?18:39
melwitttssurya: yep sounds good18:39
tssuryamelwitt: thank you18:39
*** yamahata has quit IRC18:39
openstackgerritEric Berglund proposed openstack/nova master: PowerVM Driver: Localdisk  https://review.openstack.org/54930018:40
*** germs has quit IRC18:42
*** jobewan has quit IRC18:42
*** AlexeyAbashkin has joined #openstack-nova18:42
*** jobewan has joined #openstack-nova18:44
*** fragatina has quit IRC18:45
*** fragatina has joined #openstack-nova18:45
*** pcaruana has quit IRC18:46
openstackgerritDan Smith proposed openstack/nova master: Add request filter functionality to scheduler  https://review.openstack.org/54473018:52
openstackgerritDan Smith proposed openstack/nova master: Add aggregates list to Destination object  https://review.openstack.org/54472918:52
openstackgerritDan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions  https://review.openstack.org/54799018:52
openstackgerritDan Smith proposed openstack/nova master: Add an index on aggregate_metadata.value  https://review.openstack.org/55585118:52
openstackgerritDan Smith proposed openstack/nova master: Add AggregateList.get_by_metadata() query method  https://review.openstack.org/54472818:52
openstackgerritDan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter  https://review.openstack.org/54500218:52
openstackgerritDan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement  https://review.openstack.org/54628218:52
*** AlexeyAbashkin has quit IRC18:54
*** voelzmo has joined #openstack-nova18:54
*** fragatina has quit IRC18:57
*** voelzmo has quit IRC19:00
*** yangyapeng has joined #openstack-nova19:02
*** yangyapeng has quit IRC19:07
*** moshele has joined #openstack-nova19:10
*** trozet has quit IRC19:11
*** AlexeyAbashkin has joined #openstack-nova19:14
*** voelzmo has joined #openstack-nova19:15
*** moshele has quit IRC19:15
imacdonnmriedem or toabctl : either of you around ?19:16
*** AlexeyAbashkin has quit IRC19:18
imacdonnmriedem toabctl In case you show up while I'm at lunch:) Regarding https://github.com/openstack/nova/commit/3a3b0f09db318faf1a1ea711a73bb365cab8b233 - I think we have the same issue with the "image" service, if glance.api_servers is not configured (which is recommended)19:19
*** ccamacho|PTO has quit IRC19:21
imacdonnefried: your name is on this too :) https://github.com/openstack/nova/blob/master/nova/image/glance.py#L114-L11619:21
mriedemimacdonn: 'image' is already in that list https://github.com/openstack/nova/commit/3a3b0f09db318faf1a1ea711a73bb365cab8b233#diff-c83f1fae2a677ed29036e293dd0e63caR12119:23
efriedyeah, what he said.19:23
mriedemdevstack doesn't set glance.api_servers either19:23
imacdonnoh yeah, I'm blind19:23
imacdonnI wonder why I'm getting this, then...19:23
imacdonn2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113]   File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 126, in get_api_servers19:24
imacdonn2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113]     endpoint = utils.get_endpoint(ksa_adap)19:24
imacdonn2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113]   File "/usr/lib/python2.7/site-packages/nova/utils.py", line 1373, in get_endpoint19:24
imacdonn2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113]     "interfaces: %s" % interfaces)19:24
imacdonn2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] EndpointNotFound: Could not find requested endpoint for any of the following interfaces: ['internal', 'public']19:24
mriedemi probably know why19:24
mriedemhttps://review.openstack.org/#/c/554703/19:24
imacdonn4 days ago, eh? that seems plausible19:25
imacdonnwill have to see if I'm doing something "the old way" ... removed the api_servers option to try to be current :)19:26
*** READ10 has quit IRC19:27
imacdonnI guess maybe it's the code, not me ... not using versioned notifications19:27
*** salv-orlando has quit IRC19:31
mriedemthis isn't about versioned notifications19:31
mriedemit's about notifications sent during periodic tasks where we don't have a token19:31
*** salv-orlando has joined #openstack-nova19:31
imacdonnYou comment says "there isn't much the operator can do about it outside of (1) switching entirely to versioned notifications, which not many people are using yet if at all, or ...."19:32
openstackgerritEric Fried proposed openstack/nova master: Slugification utilities for placement names  https://review.openstack.org/55662819:32
efriedcdent: For nosey parkers ^19:32
*** fragatina has joined #openstack-nova19:32
*** salv-orlando has quit IRC19:37
*** harlowja has joined #openstack-nova19:37
*** voelzmo_ has joined #openstack-nova19:38
openstackgerritmelanie witt proposed openstack/nova master: Migrate tempest-dsvm-multinode-live-migration job in-tree  https://review.openstack.org/55594519:39
*** fragatina has quit IRC19:41
*** voelzmo has quit IRC19:42
openstackgerritEric Fried proposed openstack/nova master: doc: Upgrade placement first  https://review.openstack.org/55663119:42
efriedmriedem, jaypipes, dansmith, sean-k-mooney cdent edleafe ^19:42
*** yamamoto has joined #openstack-nova19:45
*** voelzmo_ has quit IRC19:46
*** salv-orlando has joined #openstack-nova19:46
*** yamamoto has quit IRC19:50
*** danpawlik has joined #openstack-nova19:50
*** voelzmo has joined #openstack-nova19:51
*** voelzmo has quit IRC19:51
*** voelzmo has joined #openstack-nova19:51
*** voelzmo_ has joined #openstack-nova19:52
*** cdent is now known as nosey_parker19:54
* nosey_parker shakes fist at efried 19:54
*** nosey_parker is now known as cdent19:54
*** voelzmo has quit IRC19:55
*** moshele has joined #openstack-nova19:56
*** EmilienM has quit IRC19:57
openstackgerritEric Fried proposed openstack/nova master: Get rid of 406 paths in report client  https://review.openstack.org/55663319:57
efriedmriedem, jaypipes, dansmith, sean-k-mooney cdent edleafe and ^19:57
efrieddev ML note coming soon19:57
*** EmilienM has joined #openstack-nova19:57
cdentefried is a stack not a queue19:57
efriedcdent: Too true, much to my dismay.19:58
cdenttakes all kinds19:58
*** awaugama has quit IRC19:59
*** yassine has joined #openstack-nova20:01
*** voelzmo_ has quit IRC20:02
*** voelzmo has joined #openstack-nova20:02
openstackgerritMatt Riedemann proposed openstack/nova master: Add "bind_ports_to_host" neutron API method  https://review.openstack.org/52360420:02
openstackgerritMatt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration  https://review.openstack.org/51542320:02
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration  https://review.openstack.org/55137020:02
openstackgerritMatt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method  https://review.openstack.org/55217020:02
openstackgerritMatt Riedemann proposed openstack/nova master: Add "activate_port_binding" neutron API method  https://review.openstack.org/55594720:02
openstackgerritMatt Riedemann proposed openstack/nova master: Delete port bindings in setup_networks_on_host if teardown=True  https://review.openstack.org/55633320:02
openstackgerritMatt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron  https://review.openstack.org/55633420:02
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: compute: use port binding extended API during live migration  https://review.openstack.org/55137120:02
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Port binding based on events during live migration  https://review.openstack.org/43487020:02
openstackgerritMatt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate  https://review.openstack.org/52253720:02
openstackgerritMatt Riedemann proposed openstack/osc-placement stable/queens: Migrate legacy-osc-placement-dsvm-functional job in-tree  https://review.openstack.org/55663520:05
*** liverpooler has quit IRC20:08
*** suresh12 has quit IRC20:09
*** suresh12 has joined #openstack-nova20:09
mriedemesberglu: why is tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON.test_create_list_show_delete_interfaces_by_network_port[id-73fe8f02-590d-4bf1-b184-e9ca81065051,network] skipped in https://review.openstack.org/#/c/546813/ ?20:09
*** jobewan has quit IRC20:11
*** suresh12 has quit IRC20:14
*** trozet has joined #openstack-nova20:15
openstackgerritMerged openstack/nova master: Standardize '_get_XXX_constraint' functions  https://review.openstack.org/38507120:15
*** felipemonteiro__ has joined #openstack-nova20:16
*** felipemonteiro_ has quit IRC20:16
*** suresh12 has joined #openstack-nova20:19
*** r-daneel has quit IRC20:21
*** edmondsw has quit IRC20:21
*** r-daneel has joined #openstack-nova20:22
cfriesenSuppose I have a stopped instance.  I then restart nova-compute.  It appears that _init_instance() will call self.driver.plug_vifs() unconditionally.  Is this expected/necessary?  Won't we call plug_vifs from the power_on() code anyways?20:23
*** fragatina has joined #openstack-nova20:25
*** eharney has quit IRC20:28
*** suresh12 has quit IRC20:28
*** yassine has quit IRC20:29
*** suresh12 has joined #openstack-nova20:29
*** fragatin_ has joined #openstack-nova20:29
*** fragatina has quit IRC20:33
*** moshele has quit IRC20:33
*** suresh12 has quit IRC20:33
*** gouthamr has quit IRC20:33
openstackgerritMerged openstack/nova master: tox: Fix indentation  https://review.openstack.org/55654320:36
*** suresh12 has joined #openstack-nova20:36
*** germs has joined #openstack-nova20:38
*** germs has quit IRC20:38
*** germs has joined #openstack-nova20:38
esberglumriedem: We're working on a solution to that. Right now to attach interfaces we need to wait for the RMC connection to become active for the instance20:38
esbergluWhich takes a really long time (like 10 minutes)20:38
esbergluWe're trying to get something going in our CI that will pre-spawn the instances so that they are ready by the time tempest gets to that test20:39
*** vipul has joined #openstack-nova20:39
mriedemesberglu: ok then you just have some small things to update in that patch and i'll be +2 on it20:41
*** germs has quit IRC20:42
esberglumriedem: ack. Thanks for the review20:43
efriedmriedem: D'oh, I totally shoulda thought to send that mail to the ops list.  Thanks for forwarding.20:47
*** edmondsw has joined #openstack-nova20:47
*** vipul has quit IRC20:48
*** vipul has joined #openstack-nova20:51
*** yamahata has joined #openstack-nova20:52
*** ttsiouts_ has joined #openstack-nova20:54
*** vivsoni has quit IRC20:56
*** vivsoni has joined #openstack-nova20:56
*** vipul has quit IRC20:58
imacdonnmriedem efried Another stupid question.... for things like neutron, placement, etc., is it reasonable to assume that if I don't need to override them, the keystone stuff from [keystone_authtoken] (auth_url, auth_type, etc.) should apply? It seems somewhat inconsistent .. e.g. it seems to work for cinder, but not for neutron20:59
efriedimacdonn: Some services operate under admin context, some user context, some both depending on the code path.21:00
*** jaypipes has quit IRC21:01
efriedimacdonn: ...uuhhhh, and that's apparently all I've got to say on that.21:01
*** voelzmo has quit IRC21:01
*** voelzmo has joined #openstack-nova21:02
efriedimacdonn:  I was composing more stuff to say and realized I really don't know how it works.21:02
efriedI would have to go do some digging.21:02
imacdonnefried: heh, OK ... thinking through this ... does it mean that cinder is working because it's reusing the user's auth token ?21:02
*** voelzmo has quit IRC21:02
efriedI think sdague probably has this in his head without sleuthing.21:02
*** voelzmo has joined #openstack-nova21:02
*** vipul has joined #openstack-nova21:03
*** pchavva has quit IRC21:03
*** voelzmo has quit IRC21:03
sdagueimacdonn: it is working because it uses the user's token21:03
*** voelzmo has joined #openstack-nova21:04
*** voelzmo has quit IRC21:04
imacdonnsdague: right ... that makes sense .. thanks21:04
*** voelzmo has joined #openstack-nova21:04
sdaguethe prefered model is the user auths to the first service or keystone, and then that token gets used for the users through the whole flow21:04
sdaguewhich ensures that if there is a bug in the code, the user permissions restrict how much damage they can do21:04
*** voelzmo has quit IRC21:05
*** edmondsw has quit IRC21:05
*** voelzmo has joined #openstack-nova21:05
*** voelzmo has quit IRC21:05
imacdonnsdague: Understood. It makes sense now.21:05
*** edmondsw has joined #openstack-nova21:08
openstackgerritEric Fried proposed openstack/nova master: doc: Upgrade placement first  https://review.openstack.org/55663121:10
cfriesendoes anyone know why we call driver.plug_vifs() in _init_instance() for a stopped instance?21:22
cfriesenlooks like that code has been there forever21:22
cfriesenI'm wondering if it's a lowest-common-denominator virt driver thing21:23
kashyapcfriesen: melwitt: dansmith: Since I'm awake, thinking a bit more on https://review.openstack.org/#/c/534384/15/nova/virt/libvirt/driver.py: While I agree that failing at Nova start up is better it seems better to hard-fail _at_ instance start up, much like we do for 'mode' and 'model'?21:23
kashyapIf you see we're actually hard-failing for 'custom' and 'mode' just in the driver.py file21:23
cfriesenkashyap: arguably we should hard-fail those at nova-compute startup too.21:24
kashyapIMHO, it just is consistent (for better or worse) to raise exception.Invalid()fail for the closely related 'extra_flags' too.21:24
kashyapcfriesen: Yes, exactly!21:24
kashyapcfriesen: But that's a surgery for different day21:24
kashyapI'm curious if anyone can poke holes in the above logic21:24
dansmithcfriesen: mode is protected by choices21:24
*** vladikr has quit IRC21:24
dansmither, kashyap21:24
* kashyap waits to get dansmith'ed21:24
dansmithkashyap: and model is defined in the libvirt cpu models xml, which can be custom-written21:24
*** vladikr has joined #openstack-nova21:24
kashyapdansmith: Custom-writing models is a horrible thing to do21:25
dansmithkashyap: that has nothing to do with it21:25
kashyap(It'll just cause untold pain.)21:25
dansmithkashyap: also, we've paved the way for you to be able to backport this with minimal change, so it'd be cool if we could just not argue over minutia21:25
openstackgerritSylvain Bauza proposed openstack/nova-specs master: Proposes NUMA topology with RPs  https://review.openstack.org/55292421:25
dansmithlots of people have opined at this point21:25
kashyapdansmith: Sure, I'm not saying otherwise (on your earlier point).21:25
kashyapdansmith: Oh, I actually _did_ make the LOG.warning thing21:26
*** edmondsw has quit IRC21:26
kashyapLocally21:26
kashyapdansmith: But I'm just trying to discus in good spirit, as it seems to make logical sense given the existing structure21:26
* kashyap thinks a bit more21:27
*** dave-mccowan has quit IRC21:27
dansmithkashyap: one could argue that if we made you do it as a workaround flag this would be moot,21:27
dansmithso arguing for it further might work against us here :)21:28
kashyapdansmith: C'mon :-)21:28
kashyapdansmith: I'm amenable to reason (contrary to what you seem to imply :P)21:28
kashyapBut we know that the 'workaround' is just needless work for the poor deployment folks.  That's why you concurred w/ me on that21:29
kashyapAnyway.21:29
*** vipul has quit IRC21:29
melwittI thought we were restricting choices to 'pcid' through the config option choices anyway, no? why do we need this check?21:30
dansmithmelwitt: we can't via config21:30
kashyapmelwitt: We are restricting the choices, indeed.21:30
dansmithfor listopt21:30
kashyapAh, not via config, though.21:30
dansmiththat's the point of the thread21:30
melwittI replied to the ML with an example where we do. does that not work?21:30
kashyapSorry, haven't checked the thread yet.  (It's late, and I'm slowly getting back to thinking in English, after 3-ish hours of straight Dutch.)21:31
openstackgerritEric Berglund proposed openstack/nova master: PowerVM: Add proc_units_factor conf option  https://review.openstack.org/55468821:31
dansmithmelwitt: ah I see now, I guess kashyap was confused?21:31
melwittokay, when you get a chance to check the thread, I'd try it out and see if it works. danpb used that technique to limit ListOpt choices for VNC auth_schemes for the console TLS stuff21:32
* kashyap goes to quickly read the email archive21:33
cfriesenkashyap: I would suggest that it would make sense to do your check at LibvirtDriver.init_host(), then in a followup patch move the sanity checks from LibvirtDriver._get_guest_cpu_model_config() to init_host().21:33
dansmithcfriesen: looks to me like it will be checked early during config parsing now21:33
openstackgerritEric Fried proposed openstack/nova master: Slugification utilities for placement names  https://review.openstack.org/55662821:33
*** yamahata has quit IRC21:33
dansmithwhich is what we originally suggested21:33
cfriesensure, if we can restrict it via the config parsing for backport that'd be even better.21:34
*** vipul has joined #openstack-nova21:34
kashyapmelwitt: Ah, this one: https://github.com/openstack/nova/blob/cd15c3d/nova/conf/vnc.py#L226,23221:34
melwittyes21:35
kashyapmelwitt: Interesting pointer; I'll give it a whirl and see what comes21:35
melwittcool, hope it works, else we have a bug in the vnc opts too :P21:35
*** vipul has quit IRC21:36
kashyapLOL21:37
* kashyap hits the hay before the date changes21:37
*** vipul has joined #openstack-nova21:42
*** burt has quit IRC21:44
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Migrate tempest-dsvm-cells job to an in-tree job definition  https://review.openstack.org/55665621:44
*** gouthamr has joined #openstack-nova21:45
*** ttsiouts_ has quit IRC21:46
*** felipemonteiro_ has joined #openstack-nova21:49
mriedemso uh,21:49
mriedemsahid would likely explode if i mentioned this, but https://review.openstack.org/#/c/458820/ could arguably require a microversion right?21:49
mriedemi.e. i create an sriov port in neutron with trusted=true,21:49
mriedemand try to create a server with that port, but nova api isn't new enough to move that in the pci request for scheduling,21:50
mriedemso i get a server without a trusted VF21:50
mriedemthought about this because of the bandwidth-aware scheduling stuff that relies on the qos policy on the ports in neutron, which impacts scheduling behavior in nova21:51
openstackgerritChris Dent proposed openstack/nova master: [placement] Filter resource providers by forbidden traits in db  https://review.openstack.org/55647221:52
openstackgerritChris Dent proposed openstack/nova master: Support forbidden traits in allocation_candidates in db  https://review.openstack.org/55666021:52
*** tssurya has quit IRC21:52
* mriedem should probably just pretend he didn't ask or notice this because it's a discussion he doesn't really want to have21:52
*** felipemonteiro__ has quit IRC21:53
cdentedleafe, efried, jaypipes: that ^ batch of stuff is the initial db support for forbidden traits. most of the rest of the code is done too, but needs to be extracted from a lump of random stuff. I'm not super confident I've got enough tests yet.21:53
efriedack21:54
*** cdent has quit IRC22:03
*** esberglu has quit IRC22:04
*** esberglu has joined #openstack-nova22:04
openstackgerritMatt Riedemann proposed openstack/osc-placement stable/queens: Do not depend on jenkins user in devstack gate  https://review.openstack.org/55666622:05
*** felipemonteiro_ has quit IRC22:05
openstackgerritMatt Riedemann proposed openstack/osc-placement stable/queens: Migrate legacy-osc-placement-dsvm-functional job in-tree  https://review.openstack.org/55663522:05
*** esberglu has quit IRC22:09
*** AlexeyAbashkin has joined #openstack-nova22:12
*** Guest22224 has quit IRC22:12
*** AlexeyAbashkin has quit IRC22:16
*** mlavalle has quit IRC22:17
openstackgerritEric Fried proposed openstack/nova master: Handle agg generation conflict in report client  https://review.openstack.org/55666922:19
efrieddansmith, cdent, jaypipes, edleafe ^22:20
*** rcernin has joined #openstack-nova22:20
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Create/lookup API services in cell0 on WSGI app startup  https://review.openstack.org/55667022:20
*** salv-orlando has quit IRC22:22
*** salv-orlando has joined #openstack-nova22:23
mriedemdansmith: i can't convince myself that there would be any upgrade impact with this ^22:27
mriedemeven if you had mistakenly started up API services pointing at cell122:27
*** salv-orlando has quit IRC22:27
*** dave-mccowan has joined #openstack-nova22:29
dansmithwell, you'd have some nova-api type services that will still list out of a service listing22:29
dansmithfrom cell122:29
mriedemservice list filters out api services22:29
dansmithwe don't need this wsgi_app stuff for metadata?22:29
mriedemhttps://github.com/openstack/nova/blob/88f6c3b7b892f2a05066ac6f0e3353f4ce80f6b0/nova/api/openstack/compute/services.py#L4822:29
dansmithhmm22:29
mriedemis nova-metadata global or per-cell?22:30
melwittI think it's global22:31
dansmithyeah, it hits api db22:31
dansmithI really didn't think services would filter out api, that's kindof confusing to me22:31
mriedemthe os-services REST API is mostly biased to compute services22:32
mriedemi.e. things you can enable/disable22:32
mriedemand service group stuff22:32
dansmithit shows scheduler22:32
mriedemi know, but...22:32
dansmithwhich is probably why I'm thinking that,22:32
dansmithalthough,.22:32
dansmithnow that I think of it,22:32
mriedemthat all predates host mappings too22:32
mriedemand this api relies on host mappings to do any actions on services22:32
dansmithwe didn't even have api service records until we needed it for SERVICE_VERSION22:32
dansmithso that makes sense now22:32
mriedemso it's restricted to compute22:32
mriedemthis is as close as we get to nova-metadata being global for cells v2 in our docs https://docs.openstack.org/nova/latest/user/cellsv2-layout.html#neutron-metadata-api-proxy22:34
dansmithso I guess no upgrade impact, through a weird set of reasons22:34
mriedemalternatively to this, i could base it on if CONF.database.connection is None22:34
mriedembut..22:34
mriedembut that just seems weird22:35
dansmithI guess I'm not sure why we should make this change22:35
mriedemanyway, there might be more fallout before https://review.openstack.org/#/c/555346/ is done22:35
dansmithI mean, it's okay I guess,22:35
mriedemease of configuration/deployment i guess?22:36
dansmithbut it seems like more of a departure to have [database] be unconfigured22:36
mriedemhttps://bugs.launchpad.net/nova/+bug/175747222:36
openstackLaunchpad bug 1757472 in OpenStack Compute (nova) "Required to define database/connection when running services for nova_api cell" [Medium,In progress] - Assigned to Matt Riedemann (mriedem)22:36
dansmithI guess22:36
mriedemwould have to ask belmiro, but i also just triaged another duplicate of this same bug22:36
mriedemif i've got access to the api db and cell0 is in there, then i don't really need the config22:37
dansmithis that really the only place you'll blow up by not having that there?22:37
mriedemwe'll see22:37
mriedemthe service wouldn't start in devstack w/o it22:37
dansmithyeah22:38
mriedemi just rev'ed the devstack patch22:38
dansmithI don't really see the justification, especially since config is where db urls and credentials are _supposed_ to be22:38
dansmithbut if it's really just that one place, then I guess meh22:38
*** germs has joined #openstack-nova22:38
*** germs has quit IRC22:38
*** germs has joined #openstack-nova22:38
mriedemit certainly makes the db sync for cell0 a pain in the ass https://review.openstack.org/#/c/555346/3/lib/nova@74222:40
mriedemif you're not using simple_cell_setup anyway22:40
dansmithwell, --all-cells will make that easier22:41
dansmithbut that's also kindof a weirdness22:41
dansmithanyway, whatever22:41
dansmithsee what else breaks I guess22:41
*** germs has quit IRC22:43
openstackgerritmelanie witt proposed openstack/nova master: Add periodic task to clean expired console tokens  https://review.openstack.org/32538122:52
openstackgerritmelanie witt proposed openstack/nova master: Use ConsoleAuthToken object to generate authorizations  https://review.openstack.org/32541422:52
openstackgerritmelanie witt proposed openstack/nova master: Convert websocketproxy to use db for token validation  https://review.openstack.org/33399022:52
*** hongbin has quit IRC22:58
*** sdague has quit IRC23:07
*** yangyapeng has joined #openstack-nova23:09
*** r-daneel has quit IRC23:10
cfriesenwhy do we still call plug_vifs() when  we call _create_domain_and_network() with vifs_already_plugged=True ?23:11
*** AlexeyAbashkin has joined #openstack-nova23:12
*** yangyapeng has quit IRC23:14
*** danpawlik has quit IRC23:16
*** AlexeyAbashkin has quit IRC23:16
*** gouthamr has quit IRC23:18
*** yassine has joined #openstack-nova23:18
*** salv-orlando has joined #openstack-nova23:23
*** yangyapeng has joined #openstack-nova23:25
*** salv-orlando has quit IRC23:28
*** yangyapeng has quit IRC23:31
*** _ix has quit IRC23:45
*** andreas_s has joined #openstack-nova23:50
*** germs has joined #openstack-nova23:51
*** germs has quit IRC23:51
*** germs has joined #openstack-nova23:51
*** READ10 has joined #openstack-nova23:52
*** andreas_s has quit IRC23:54
*** vipul has quit IRC23:55
*** germs has quit IRC23:57

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