Wednesday, 2018-11-28

openstackgerritMerged openstack/nova master: Add regression test for bug 1550919  https://review.openstack.org/59173300:05
openstackbug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9)00:05
*** jaosorior has quit IRC00:05
*** hoonetorg has quit IRC00:09
*** tetsuro has joined #openstack-nova00:11
*** hoonetorg has joined #openstack-nova00:22
*** erlon has joined #openstack-nova00:32
*** mlavalle has quit IRC00:37
*** k_mouza has joined #openstack-nova00:42
*** brinzhang has joined #openstack-nova00:43
*** sean-k-mooney has quit IRC00:44
*** bhagyashris has joined #openstack-nova00:56
*** sean-k-mooney has joined #openstack-nova00:58
*** wolverin_ has quit IRC00:59
*** wolverineav has joined #openstack-nova01:00
*** wolverineav has quit IRC01:02
*** wolverineav has joined #openstack-nova01:02
*** amab has quit IRC01:04
*** k_mouza has quit IRC01:06
*** k_mouza has joined #openstack-nova01:09
*** annp has joined #openstack-nova01:14
*** k_mouza has quit IRC01:28
*** erlon has quit IRC01:54
*** cfriesen has quit IRC02:00
*** mschuppert has quit IRC02:25
*** mrsoul has quit IRC02:25
*** Dinesh_Bhor has joined #openstack-nova02:33
*** hongbin has joined #openstack-nova02:36
*** psachin has joined #openstack-nova02:41
*** mhen has quit IRC02:42
*** mhen has joined #openstack-nova02:45
*** ileixe has joined #openstack-nova03:03
openstackgerritChris Dent proposed openstack/nova master: Use external placement in functional tests  https://review.openstack.org/61794103:11
openstackgerritChris Dent proposed openstack/nova master: Delete the placement code  https://review.openstack.org/61821503:11
*** wolverineav has quit IRC03:12
*** wolverineav has joined #openstack-nova03:17
*** wolverineav has quit IRC03:24
*** cdent has quit IRC03:28
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove Placement API reference  https://review.openstack.org/61443703:38
*** diga has joined #openstack-nova03:47
*** wolverineav has joined #openstack-nova03:53
*** wolverineav has quit IRC03:59
*** hoangcx has joined #openstack-nova04:11
*** hongbin_ has joined #openstack-nova04:23
*** hongbin has quit IRC04:24
openstackgerritGhanshyam Mann proposed openstack/nova master: DNM: Testing nova gate on Bionic (Ubuntu LTS 18.04)  https://review.openstack.org/62045404:36
*** hongbin has joined #openstack-nova04:37
*** hongbin_ has quit IRC04:38
*** hongbin has quit IRC04:40
*** artom has quit IRC04:42
*** artom has joined #openstack-nova04:46
*** janki has joined #openstack-nova04:48
*** diga has quit IRC04:49
*** lpetrut has joined #openstack-nova04:51
*** udesale has joined #openstack-nova04:54
*** pcaruana has joined #openstack-nova05:09
*** sridharg has joined #openstack-nova05:26
*** lpetrut has quit IRC05:28
*** imacdonn has quit IRC05:30
*** imacdonn has joined #openstack-nova05:30
*** k_mouza has joined #openstack-nova05:36
*** imacdonn has quit IRC05:38
*** imacdonn has joined #openstack-nova05:38
*** k_mouza has quit IRC05:40
*** brinzhang has quit IRC05:45
*** cfriesen has joined #openstack-nova05:45
*** brinzhang has joined #openstack-nova05:46
*** ratailor has joined #openstack-nova06:00
gmannnova api office hour06:00
gmann#startmeeting nova api06:00
openstackMeeting started Wed Nov 28 06:00:33 2018 UTC and is due to finish in 60 minutes.  The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot.06:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.06:00
*** openstack changes topic to " (Meeting topic: nova api)"06:00
openstackThe meeting name has been set to 'nova_api'06:00
*** ileixe has quit IRC06:00
gmannPING List: gmann, alex_xu06:00
gmannwho all here today06:00
gmannwe are starting office hour after long time...06:01
*** ileixe has joined #openstack-nova06:01
gmannseems alex_xu not here. i will do some bug triage during this  office hour.06:04
gmannsome update- i have updated the subteam tracking etherpad with latest updates - Section API- https://etherpad.openstack.org/p/stein-nova-subteam-tracking06:05
*** gyee has quit IRC06:20
*** moshele has joined #openstack-nova06:21
*** moshele has quit IRC06:26
*** jarodwl has joined #openstack-nova06:35
*** jaosorior has joined #openstack-nova06:36
*** ileixe has quit IRC06:41
*** ileixe has joined #openstack-nova06:41
*** udesale has quit IRC06:43
*** udesale has joined #openstack-nova06:44
openstackgerritjichenjc proposed openstack/nova master: Validate security group in API layer  https://review.openstack.org/62047306:45
*** udesale has quit IRC06:45
*** udesale has joined #openstack-nova06:46
*** psachin has quit IRC06:47
*** brinzh has joined #openstack-nova06:52
*** brinzhang has quit IRC06:56
gmanndid 2 bug triage and 3rd in progress. will send the updates on ML. ending the office hour06:56
gmann#endmeeting06:56
*** openstack changes topic to "Current runways: io-semaphore-for-concurrent-disk-ops / reshape-provider-tree / initial-allocation-ratios -- This channel is for Nova development. For support of Nova deployments, please use #openstack."06:56
openstackMeeting ended Wed Nov 28 06:56:38 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)06:56
openstackMinutes:        http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-11-28-06.00.html06:56
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-11-28-06.00.txt06:56
openstackLog:            http://eavesdrop.openstack.org/meetings/nova_api/2018/nova_api.2018-11-28-06.00.log.html06:56
*** udesale has quit IRC06:57
*** rcernin has quit IRC06:57
*** Luzi has joined #openstack-nova07:00
*** wolverineav has joined #openstack-nova07:01
*** slaweq has joined #openstack-nova07:04
*** wolverineav has quit IRC07:06
*** dpawlik has joined #openstack-nova07:16
openstackgerritZhenyu Zheng proposed openstack/nova master: Per-instance serial number  https://review.openstack.org/61995307:17
*** dpawlik has quit IRC07:20
*** cfriesen has quit IRC07:22
*** dpawlik has joined #openstack-nova07:24
*** adrianc has joined #openstack-nova07:30
*** adrianc has quit IRC07:32
*** adrianc has joined #openstack-nova07:33
openstackgerritZhenyu Zheng proposed openstack/nova master: Bump compute service to indicate attach/detach root volume is supported  https://review.openstack.org/61475007:40
openstackgerritVieri proposed openstack/python-novaclient master: add python 3.6 unit test job  https://review.openstack.org/62050907:41
*** alex_xu has quit IRC07:50
*** udesale has joined #openstack-nova07:53
*** alex_xu has joined #openstack-nova07:55
kashyapartom: Thanks for the review.07:58
*** udesale has quit IRC07:58
alex_xugmann: from this https://docs.openstack.org/nova/rocky/user/block-device-mapping.html#block-device-mapping-v2, we don't have deleted_on_termination param for bdmv2. Also we don't have that param for bdmv2 in nova cli. but I can pass that param by the API directly, does it support from the beginning or we leak something?07:59
kashyapalex_xu: Hi, when you get a moment, mind having a look at this: https://review.openstack.org/#/c/62032708:02
alex_xukashyap: got it, will try08:04
gmannalex_xu: humm, checking08:04
kashyapalex_xu: Thanks08:04
*** skatsaounis has joined #openstack-nova08:04
alex_xukashyap: np08:05
alex_xugmann: thanks08:06
alex_xugmann: actually, I'm reviewing this spec https://review.openstack.org/#/c/58033608:07
*** sahid has joined #openstack-nova08:07
gmannalex_xu: delete_on_termination is bdmv1 attribute which is allowed for bdmv2 also08:09
gmannalex_xu: you can see that in doc you mentioned also under Block device mapping v1 (aka legacy)ΒΆ section08:09
*** udesale has joined #openstack-nova08:11
alex_xugmann: so v2 inhertis all the attributes from v1, right?08:14
gmannalex_xu: yeah, https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/api/openstack/compute/schemas/servers.py#L9008:15
alex_xugmann: it is strange that we don't have delete_on_termination on the CLI08:18
gmannalex_xu: humm it is error ?08:18
alex_xugmann: i don't know08:19
*** jangutter has joined #openstack-nova08:21
*** xek_ has joined #openstack-nova08:22
gmannalex_xu: i can see it is supported in CLI - https://github.com/openstack/python-novaclient/blob/58b3ac457aa817da28c757b4845bc39e565139dd/novaclient/v2/shell.py#L13808:24
*** ralonsoh has joined #openstack-nova08:33
openstackgerritYikun Jiang proposed openstack/nova master: Change the default values of XXX_allocation_ratio  https://review.openstack.org/60280308:36
openstackgerritYikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF  https://review.openstack.org/60280408:36
*** tssurya has joined #openstack-nova08:41
*** sridharg has quit IRC08:57
*** tetsuro has quit IRC09:03
*** sridharg has joined #openstack-nova09:10
*** owalsh_ is now known as owalsh09:12
*** k_mouza has joined #openstack-nova09:13
*** eandersson has quit IRC09:13
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup  https://review.openstack.org/60396909:22
openstackgerritGhanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup  https://review.openstack.org/60396909:23
*** whoami-rajat has joined #openstack-nova09:28
*** bhagyashris has quit IRC09:45
*** ttsiouts has joined #openstack-nova09:59
*** ttsiouts has quit IRC10:02
*** ttsiouts has joined #openstack-nova10:03
*** ttsiouts has quit IRC10:03
*** ttsiouts has joined #openstack-nova10:03
*** ttsiouts has quit IRC10:06
*** ttsiouts has joined #openstack-nova10:07
openstackgerritYikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF  https://review.openstack.org/60280410:09
*** tobias-urdin has quit IRC10:10
*** artom has quit IRC10:11
*** cdent has joined #openstack-nova10:11
*** ttsiouts has quit IRC10:12
*** derekh has joined #openstack-nova10:12
*** ttsiouts has joined #openstack-nova10:13
*** ttsiouts has quit IRC10:14
*** ttsiouts has joined #openstack-nova10:15
*** tobias-urdin has joined #openstack-nova10:15
*** k_mouza has quit IRC10:18
*** ttsiouts has quit IRC10:18
*** k_mouza has joined #openstack-nova10:18
*** ttsiouts has joined #openstack-nova10:19
*** ttsiouts has quit IRC10:21
*** ttsiouts has joined #openstack-nova10:22
*** k_mouza has quit IRC10:22
*** ttsiouts has quit IRC10:22
*** erlon has joined #openstack-nova10:29
*** noonedeadpunk has joined #openstack-nova10:31
openstackgerritYikun Jiang proposed openstack/nova master: Add ratio online data migration when load compute node  https://review.openstack.org/61349910:33
openstackgerritYikun Jiang proposed openstack/nova master: Add compute_node ratio online data migration script  https://review.openstack.org/60999510:33
*** jarodwl has quit IRC10:33
*** jarodwl has joined #openstack-nova10:34
*** jistr is now known as jistr|mtg10:34
noonedeadpunkHi everyone.10:36
*** wolverineav has joined #openstack-nova10:37
*** k_mouza has joined #openstack-nova10:38
noonedeadpunkI've faced with a problem (not sure if it's a bug or not), when nova in Q generates config, which is not compatible with libvirt 4 (which is a default for ubuntu). So VM creation results in error "'serial' is deprecated, please use the corresponding option of '-device' instead"10:39
*** k_mouza has quit IRC10:41
openstackgerritChris Dent proposed openstack/nova master: Use external placement in functional tests  https://review.openstack.org/61794110:41
*** adrianc has quit IRC10:41
*** k_mouza has joined #openstack-nova10:42
*** wolverineav has quit IRC10:42
openstackgerritChris Dent proposed openstack/nova master: Delete the placement code  https://review.openstack.org/61821510:42
*** davidsha has joined #openstack-nova10:48
*** skatsaounis has left #openstack-nova10:48
*** ygk_12345 has joined #openstack-nova10:58
*** adrianc has joined #openstack-nova11:05
*** ttsiouts has joined #openstack-nova11:13
*** ttsiouts has quit IRC11:18
*** ygk_12345 has quit IRC11:18
*** chason has quit IRC11:31
openstackgerritBrin Zhang proposed openstack/nova-specs master: Support for changing deleted_on_termination after boot  https://review.openstack.org/58033611:33
*** chason has joined #openstack-nova11:36
openstackgerritGhanshyam Mann proposed openstack/nova stable/rocky: Migrate nova v2.0 legacy job to zuulv3  https://review.openstack.org/62057111:39
*** Dinesh_Bhor has quit IRC11:42
*** dave-mccowan has joined #openstack-nova11:44
*** tbachman has quit IRC11:45
openstackgerritGhanshyam Mann proposed openstack/nova stable/queens: Migrate nova v2.0 legacy job to zuulv3  https://review.openstack.org/62057811:47
openstackgerritGhanshyam Mann proposed openstack/nova stable/pike: Migrate nova v2.0 legacy job to zuulv3  https://review.openstack.org/62057911:53
openstackgerritGhanshyam Mann proposed openstack/nova stable/rocky: Migrate nova v2.0 legacy job to zuulv3  https://review.openstack.org/62057112:01
openstackgerritGhanshyam Mann proposed openstack/nova stable/pike: Migrate nova v2.0 legacy job to zuulv3  https://review.openstack.org/62057912:02
openstackgerritGhanshyam Mann proposed openstack/nova stable/queens: Migrate nova v2.0 legacy job to zuulv3  https://review.openstack.org/62057812:02
*** moshele has joined #openstack-nova12:06
*** ttsiouts has joined #openstack-nova12:11
*** ttsiouts has quit IRC12:12
*** ttsiouts has joined #openstack-nova12:13
*** sridharg has quit IRC12:14
*** sridharg has joined #openstack-nova12:14
*** ttsiouts has quit IRC12:17
*** janki has quit IRC12:20
*** sridharg has quit IRC12:24
*** ratailor has quit IRC12:26
*** artom has joined #openstack-nova12:29
*** jaypipes has joined #openstack-nova12:31
openstackgerritGhanshyam Mann proposed openstack/nova stable/pike: DNM: For testing only  https://review.openstack.org/62059212:32
*** brinzh has quit IRC12:34
*** takamatsu has quit IRC12:37
*** ttsiouts has joined #openstack-nova12:38
*** takamatsu has joined #openstack-nova12:43
jrollflwang: at oath we eventually changed the catalog, it was fine12:49
*** beagles is now known as beagles_mtgs12:55
*** ttsiouts has quit IRC12:56
*** moshele has quit IRC12:56
*** ttsiouts has joined #openstack-nova12:56
*** k_mouza has quit IRC13:02
*** artom has quit IRC13:03
*** ttsiouts has quit IRC13:12
*** munimeha1 has joined #openstack-nova13:13
*** ttsiouts has joined #openstack-nova13:13
*** artom has joined #openstack-nova13:16
*** ttsiouts has quit IRC13:18
*** munimeha1 has quit IRC13:19
*** jistr|mtg is now known as jistr13:21
*** k_mouza has joined #openstack-nova13:28
*** takamatsu has quit IRC13:29
*** takamatsu has joined #openstack-nova13:30
*** tbachman has joined #openstack-nova13:33
*** ttsiouts has joined #openstack-nova13:33
*** moshele has joined #openstack-nova13:37
*** diga has joined #openstack-nova13:42
*** Dinesh_Bhor has joined #openstack-nova13:43
*** takamatsu has quit IRC13:44
*** takamatsu has joined #openstack-nova13:48
*** jarodwl has quit IRC13:49
*** jarodwl has joined #openstack-nova13:50
*** janki has joined #openstack-nova13:55
*** eharney has joined #openstack-nova13:56
*** diga has quit IRC13:56
*** moshele has quit IRC14:04
*** ttsiouts has quit IRC14:08
*** ttsiouts has joined #openstack-nova14:09
*** Dinesh_Bhor has quit IRC14:10
*** janki has quit IRC14:11
*** ttsiouts_ has joined #openstack-nova14:11
*** janki has joined #openstack-nova14:12
*** ttsiouts has quit IRC14:13
*** wolverineav has joined #openstack-nova14:14
*** wolverineav has quit IRC14:19
*** mriedem has joined #openstack-nova14:23
*** ttsiouts_ has quit IRC14:23
*** ttsiouts has joined #openstack-nova14:24
*** udesale has quit IRC14:24
*** udesale has joined #openstack-nova14:25
*** adrianc has quit IRC14:27
*** ttsiouts has quit IRC14:28
mriedemcouple of easy patches here that need another core https://review.openstack.org/#/c/620165/ https://review.openstack.org/#/c/620170/14:34
*** ttsiouts has joined #openstack-nova14:39
gmannmriedem: melwitt nova-next job does not run in queens but seems like it supposed to run there - https://github.com/openstack/nova/blob/master/.zuul.yaml#L14014:42
gmannreason is- job migration patch got merged in rocky - https://review.openstack.org/#/c/541474/14:42
gmannand it was mistakenly added in stable/queens check and gate pipeline list here - https://review.openstack.org/#/c/604134/14:43
gmannnova-next job definition is not present in stable/queens but listed in check and gate pipeline.14:43
*** dklyle has quit IRC14:47
gmannto run it on queens, we need to backport these 2 in queens - https://review.openstack.org/#/c/541474/ https://review.openstack.org/#/c/513160/14:47
*** Sundar has joined #openstack-nova14:49
*** sridharg has joined #openstack-nova14:49
Sundarefried: Please ping me when you have the time.14:50
efriedSundar: I'm here. What's up?14:50
*** jackding has joined #openstack-nova14:51
Sundarefried: Are you aligned with the decision to drop os-acc? I am trying to make sure we have a quorum of Nova developers.14:52
*** adrianc has joined #openstack-nova14:53
gmannstephenfin: what is use of bug-tag in openstackdocstheme? - https://review.openstack.org/#/c/619434/214:53
gmanni did not find where it was linked on doc/buglink14:54
artomgmann, he's on PTO14:54
gmannartom: ohk. thanks. added him in review.14:54
Sundarjaypipes: Please let me know when you have some time to follow up from last week.14:55
jaypipesSundar: I am here.14:57
Sundarjaypipes: I am trying to reconcile your views with what everybody else is saying. You wanted to see os-acc as a small library that works by itself. Whereas others don;t see a need for os-acc at all :) #link http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-11-20.log.html#t2018-11-20T17:47:2114:58
jaypipesSundar: correct.15:00
*** cfriesen has joined #openstack-nova15:00
Sundarjaypipes: Could I understand your motivation? Nova virt drivers will do the actual attachment for accelerators, as with networking. All device-specific actions should be in Cyborg.15:00
SundarDO you agree?15:00
efriedSundar: It seems reasonable, if nova only needs to talk to the cyborg API, to nix os-acc.15:00
jaypipesSundar: I was under the impression os-acc would function similarly to os-vif, where os-vif provides the data models that are used to understand what and how network interfaces are brought up on the host.15:01
efriedSundar: My impression of os-acc was that it would be the clearinghouse for platform- and virt-specific plugins to do discovery and attachment.15:01
efriedyeah, what jaypipes said.15:01
Sundarjaypipes: Yes, that's how we started. As the discussion progressed, and the spec was reviewed, it became clear that most of the work would be done by Cyborg APIs.15:02
jaypipesSundar: which I completely disagree with.15:02
jaypipesSundar: I have continued to maintain I see very little use in a Cyborg REST API at the moment.15:02
mriedemgmann: yes https://review.openstack.org/#/c/604134/1/.zuul.yaml is a bad backport15:03
jaypipesSundar: let me tell you why.15:03
mriedemgmann: the commit message in https://review.openstack.org/#/c/541474/ sounds like we don't need it in queens15:04
mriedemthe queens comment in https://github.com/openstack/nova/blob/master/.zuul.yaml#L140 might be wrong15:04
jaypipesSundar: focusing on the REST API in Cyborg right now means you are constrained by versioning in a way that just focusing on iterating a workable object/data model would not constrain you.15:04
Sundarjaypipes: Without Cyborg APIs, how would one initiate device configuration, whether it is for a GPU, FPGA, ...?15:04
mriedemgmann: https://review.openstack.org/#/c/396186/ isn't in queens15:04
jaypipesSundar: IMHO, a REST API is just a giant distraction right now for Cyborg.15:04
efriedjaypipes: The way I see it, we need a way to follow the thread of an ARQ from [set of resources and traits] to [actual accelerator instance plugged into a VM].15:05
jaypipesSundar: what does Cyborg do "under the covers" in its drivers?15:05
jaypipesSundar: *that* is what I think os-acc should be doing.15:05
dansmithbauzas: gonna circle back on https://review.openstack.org/#/c/599587 right?15:06
efriedjaypipes: Nova is going to be driving that workflow, but cyborg needs to be the one to make some of those transitions (like, "I landed on a host; pick me a specific device and configure it") and needs to be made aware of the ones Nova makes (like, "I plugged accelerator X into VM Y").15:06
gmannmriedem: ok. then we can remove the nova-next from queen pipeline list also + that job comment fix. i observed  it while backporting the nova v2 job.15:06
Sundarjaypipes: Are you saying that os-acc should have its own device-specific drivers and run the show by itself? Or that it should call into Cyborg drivers, without involving any REST API?15:06
bauzasdansmith: yup, I'm just reviewing it15:06
*** mlavalle has joined #openstack-nova15:06
efriedjaypipes: *some* kind of API seems like the appropriate way to do that.15:06
dansmithbauzas: awesome, thanks15:06
jaypipesSundar: that is correct.15:06
mriedemgmann: yeah it's either that or backport the devstack and nova change15:07
jaypipesSundar: I've said a number of times that I wish Cyborg would just accept that Nova is its sole consumer right now, stop working on some "stand-alone Cyborg" thing and just function like a Nova virt driver for right now. That way, you can iterate more quickly, actually get something that works (as opposed to just abstract, non-working things) and go from ther15:07
*** sridharg has quit IRC15:07
gmannmriedem: i can give backport try also if you think it is worth to run on queens.15:08
*** sridharg has joined #openstack-nova15:08
mriedemgmann: i backported the devstack change, you can backport https://review.openstack.org/#/c/513160/ if you want15:09
mriedemit has merge conflicts15:09
mriedemi'm guessing the nova-next/devstack testing just missed the queens GA15:09
mriedembut the feature itself is in nova in queens15:09
mriedemso it would probably be good to test it...15:09
Sundarjaypipes: There are are several use cases for accelerators without direct Nova involvement. For example, we may want to set up OVS offload in an accelerator in a host, but that doesn't involve assigning to a VM.15:09
jaypipesSundar: there might be, yes. I'15:10
jaypipesm saying I don't care about those use cases and I feel they are a giant distraction from getting anything working in Nova/Cyborg at the moment.15:10
gmannmriedem: +1. will do tomorrow.15:11
mriedemgmann: thanks15:11
sean-k-mooneySundar: "use cases for accelerators without direct Nova involvement" are by definition out side the scope of the nova/cyborge interaction sepc15:11
efriedjaypipes: Are you suggesting maintaining ARQ data in nova databases and manipulating them via OVOs within the nova code?15:11
jaypipesSundar: let me put this in the most direct way possible... I do not think it's appropriate to call a REST API to set up a local device on a host.15:12
mriedemsounds like you want a thing that's like PlacementDirect15:12
mriedemAPI interface is the same, but it doesn't go over http15:13
Sundarjaypipes: As efried said above, manipulating devices from a virt driver means the device data is in Nova db. Is that what you are advocating?15:13
Sundarsean-k-mooney: We were talking about stand-alone Cyborg15:14
jaypipesSundar: I would rather just get the small amount of code that is Cyborg's accelerators/drivers/ module (https://github.com/openstack/cyborg/blob/master/cyborg/accelerator/drivers/fpga/intel/driver.py), pull it into some library called "os-acc" and call it directly.15:15
*** dpawlik has quit IRC15:16
jaypipesSundar: especially since it's basically just shelling out to some unknown /usr/bin/fpgaconf program which I assume is some Intel-specific binary15:16
jaypipesSundar: which is essentially what os-vif is, BTW... it just shells out to Linux binaries like "ip" or "ovsctl" etc.15:17
jaypipesSundar: which is why I say I'd like an os-vif for accelerators...15:18
*** mgariepy has quit IRC15:18
*** mgariepy has joined #openstack-nova15:19
Sundarjaypipes: That means all the PCI details (#PFs, #VFs, etc.) and other data for programming devices etc. are all in Nova db.15:21
*** ivve has joined #openstack-nova15:21
jaypipesSundar: which is exactly where they already are.15:21
jaypipesSundar: because Nova is the thing that owns compute node resources.15:21
efriedjaypipes: Please tell me you're not suggesting using/augmenting the existing database schemata15:22
Sundarjaypipes: I thought there was a desire to pull all that complexity into a separate project. What do you see as the role for Cyborg in your model?15:23
sean-k-mooneyefried: that is a diffent topic15:23
sean-k-mooneyyou could be we can do better15:23
efriedsean-k-mooney: It is exactly the topic.15:23
jaypipesSundar: on a sidenote, could you tell me where I can find the source code for fpgaconf? I can't seem to locate it..15:23
jaypipesefried: no, I'm not. I'm just saying that's where we *already* store this information.15:24
efriedsean-k-mooney: We know we want the existing pci subsystem to diaf. Trying to retrofit it for cyborg purposes will just make it live on, like something from Walking Dead.15:24
sean-k-mooneyefried: you can passthough gpugs and fpgas with nova pci pathough today15:24
sean-k-mooneyefried: we just cant program fpgas15:24
efriedAlso, we know we want to separate eventually, so the tighter the integration with nova databases, the more painful that will be.15:25
artomsean-k-mooney, yo, check downstream IRC, I'd like to skip our meeting since very few are around15:25
efriedAs with placement, we should at the very least make it a separate database.15:25
jaypipesSundar: there is definitely a desire to standardize and clean up the mess that is the PCI device management code (and CPU pinning, NUMA topology, etc) code in Nova. I have never had a desire to create a new REST service to manage this data, however.15:25
efriedbut cyborg is already a separate project, and already has existing use cases for operation and tracking/programming of devices independent of nova15:26
Sundarjaypipes: While OPAE SDK has been released i github, I am not sure that all tools like fpgaconf got open sourced. I'll check and get back.15:26
efriedso why wouldn't we just put the new database there to begin with?15:26
jaypipesSundar: thx15:26
jaypipesefried: perhaps there is. I'm trying to say that I think it's premature to do RESTful stuff versus cleaning up the device management and plugging/assignment code in nova.15:28
jaypipesefried: I'm straining to think of a use case where I'd want programmatic listing and showing of device details across all my compute infrastructure. Other than just knowing what devices are there and what resources they provide (which is already taken care of by the placement service), I'm wondering what the use is of a REST API over this data.15:29
*** sridharg has quit IRC15:30
Sundarjaypipes: if you were to apply that to networking, would you not want to see the details of the NICs, and manage their diversity in a structured way?15:31
*** sridharg has joined #openstack-nova15:32
jaypipesSundar: if you're talking about capabilities of NICs or bandwidth of physnets on NICs, we already have that in the placement DB.15:32
jangutterSundar: commenting as an engineer working for a NIC vendor, customers broadly fall into two categories: "Make everything look the same" and "handle this node specially".15:33
jangutterSundar: it would be nice to be able to say "provide me with a networking resource capable of _x_", but broadly, most requests to us have been to make things more uniform, not less.15:34
Sundarjaypipes: jangutter: My point is, just as we have Neutron for networking etc., the diversity of accelerators is best handled by a separate project, rather than fold all in Nova. Esp. since there are use cases that don;t involve Nova, even if you don't agree with it.15:35
mriedemas a casual observer, it sounds like the dilemma is doing something quick and dirty to get something done without a cyborg REST API, vs make a perfect external system that nova can leverage, which would likely delay this even longer15:36
*** beagles_mtgs is now known as beagles15:37
mriedemand if the former is done, how complicated is the extraction/decoupling later15:37
dansmithnot sure it's a dilemma,15:37
mriedemand i think what was mentioned last week,15:37
dansmithas I think only jaypipes is the one that feels it should go that way15:37
dansmith(AFAICT at least)15:37
mriedemwas someone could already be doing a PoC for the former to see how it looks so we have an informed decision to make15:37
mriedemas the latter is much more work i'd think15:38
dansmithmriedem: yup, I think we probably all agree on that point15:38
dansmithwell, except maybe Sundar  :)15:38
* jaypipes wonders why there is a need for a REST API in order to execute /usr/bin/fpgaconf with some CLI options.15:39
Sundarmriedem: dansmith: I am working on a POC, a simple one focusing only on the Nova - Cyborg calls. It needs official clearance within my company before I can share it15:39
mriedemthe point of the rest api was so that the data and drivers live within cyborg, not nova, and nova hits those drivers over the API15:39
mriedemif we could put a shim in like PlacementDirect, great15:40
dansmithSundar: yeah that's not going to work very well for collab, but.. good luck :/15:40
jangutterSundar: I don't think that anybody disputes that it's better to have a separate entity to handle out-of-Nova scope things. The trick is that Nova already has a way to pass PCI devices to instances. There's also existing code in os-vif that gets called "on plug events".15:40
mriedemwe talked about all of this last week when we said we didn't need an os-acc library and could just use python-cyborgclient15:40
sean-k-mooneydansmith: well i have some leaning towrad a libary solution too15:40
mriedemand i was also confused why we needed to hit a rest api to get to the cyborg drivers, i.e. why it wasn't more like os-brick15:40
dansmithI'm fine with the programming part being in a library instead of an agent if we want15:41
dansmithmriedem: it's quite a bit more complicated than just manipulating standard system things to connect to an iscsi target15:41
mriedemright that was explained last week15:41
mriedemprobably about this time :)15:41
dansmithbut I don't think the tracking of devices, workflow to program, clean, etc these devices belongs in nova15:42
mriedemi don't really think we should build on that existing stuff within nova either,15:42
mriedemb/c once something is built on it, it makes it harder to clean it up later (it already is taking forever)15:42
mriedemand that pci code went in in juno15:42
*** udesale has quit IRC15:43
artomJust... pay a bunch of interns, and stick a CORBA thing in front.15:43
*** udesale has joined #openstack-nova15:43
jaypipesartom: lol15:43
jangutterartom: don't joke, xml will come out.15:43
mriedemi was going to add, "says the guy that isn't working on cleaning any of it up"15:43
mriedemfor myself15:43
sean-k-mooneyartom: just no...15:43
mriedemif we're talking xml, CIM model model this all so nicely!15:44
mriedem*would model15:44
artomIf no one can agree on what to do, maybe if we all agree on what *not* to do, and then do that...15:44
*** panda|rover is now known as panda|pto15:45
sean-k-mooneyi think at this point we would all like to see a POC  rather then talk in abstract terms about it in a loop15:46
dansmithyup15:46
* artom goes off to find interns.15:46
jangutterwe're falling into the trap of agreeing on stuff: which means it won't happen.15:46
jaypipesSundar: what's the likelihood of your PoC being available this year?15:46
jaypipesSundar: I understand you need permission from legal?15:46
SundarI'd like some agreement on the general direction of the POC. At the PTG, there was alignment on defining REST calls, and I wrote that up in a spec that is being reviewed. The discussion here seems more philosophical. I suggest that the POC should focus on clarifying the spec.15:48
artomSundar, I think at some point you'll have to accept that work might get wasted :(15:49
dansmithSundar: while everything is just words in a document, the discussion can get pretty philosophical pretty quick, as you have no doubt noticed15:49
artomI've been observing this discussion from afar since... Dublin?15:49
sean-k-mooneySundar: can we do a simple poc of booting a vm with just a fixed fuction pci device15:49
Sundarjaypipes: Yes, it requires legal clearance. I may get a requirement to follow a process, or likely multiple processes. I am hoping that, confining it to upstream code and no real devices will make it go faster15:49
artomBite the bullet, write some code, share it15:50
artomIf the code gets scrapped and needs to be rewritte, so be it15:50
sean-k-mooneySundar: the intel fpga stuff may but nova and cyborg working together dont15:50
jaypipesSundar: that's generally not what PoCs are, but ok :) My suggestion is to demo Nova actually being able to /usr/bin/fpgaconf some device. If you want to go through the trouble of getting all the REST API stuff done in order for Nova to shell out to /usr/bin/fpgaconf, go for it. :)15:50
jmloweIf anybody remembers my slow placement api problem from a couple of days ago, it seems that NAT in the 4.15 kernel that ships with ubuntu 18.04 is problematic at scale15:53
cdentjmlowe: I am a) relieved to hear that, b) sorry for your luck15:54
cdentcan you define "at scale"?15:55
mriedemcern runs centos right?15:56
mriedemtssurya: ^15:56
jmloweI have a quick question about versioned notifications, if a notification has been transitioned to versioned and the setting is for legacy does that mean the notification will never be emitted?15:56
mriedemjmlowe: what is the value of this option https://docs.openstack.org/nova/latest/configuration/config.html#notifications.notification_format15:57
mriedemin your nova.conf15:57
jmlowecdent: I was falling over at ~280, threshold is probably significantly lower, ubuntu 16.04 didn't cause problems15:57
gibijmlowe: if you configured nova to emit legacy notifications only then nova only emts the legacy ones15:57
gibijmlowe: we did not removed the legacy notifications, and we did not plan to remove them15:58
*** awaugama has joined #openstack-nova15:58
jmloweI have unversioned, was looking at rocky release notes and saw that instance exits has been transitioned and that's the one event I really need to consume with ceilometer/panko which doesn't do versioned yet15:59
openstackgerritMatt Riedemann proposed openstack/nova-specs master: Support volume-backed server rebuild  https://review.openstack.org/53240715:59
mriedemjmlowe: just leave as unversioned then,15:59
mriedemas gibi said, we haven't removed the unversioned notifications15:59
gibijmlowe: if https://docs.openstack.org/nova/latest/configuration/config.html#notifications.notification_format is configured to both or unversioned then nova still sends the old instance.exists16:00
mriedemmost, if not all, openstack projects that consume notifications from nova are still using unversoined notifications16:00
mriedemdansmith: i'm +2 on the volume-backed rebuild spec now https://review.openstack.org/#/c/532407/16:01
jmloweok, perfect, thanks, needed a sanity check to make sure before I happily upgraded myself into a sisyphean custom patch cycle16:02
*** davidsha has quit IRC16:02
jmlowemriedem: my exploding rabbit queues say otherwise16:03
jmlowemriedem: versioned notifications for ceilometer are still tagged as a wishlist bug16:04
mriedemjmlowe: umm16:06
mriedemif you're using unversioned, there should be no difference16:07
Sundarjaypipes: I found the source for fpgaconf.c : https://github.com/OPAE/opae-sdk/tree/master/tools/base/fpgaconf16:07
jmlowemriedem: that was learned the hard way16:07
mriedemjmlowe: can you expand? did you upgrade and the format option was using 'both'?16:07
mriedemi remember godaddy saying in boston that the instance.exists notifications in particular hammer their MQ16:08
sean-k-mooneySundar: could we do a poc usign a FakeDriver the simulates a fake device and uses that to test this end to end and there for remove the hardware depency16:09
sean-k-mooneywe have asked this in the past16:10
sean-k-mooneyit woudl be useful for ci if nothing else16:10
jmloweNow on queens, upgraded in place starting from liberty, didn't really pay attention, just assumed everything would work, the versioned notifications queue grew without bound until I finally got smart an capped nova with legacy notifications16:10
mriedemok, so it was sending both then16:11
jmlowewhatever the default is16:12
mriedemit's 'both'16:12
mriedemgibi: i almost wonder if we should change the default to unversioned...16:12
mriedemi know we want people to use versioned, but there aren't any projects working on that16:12
mriedemor,16:12
mriedemmaybe we should start a 'performance / scale considerations' doc in nova for stuff like this16:13
mriedem"rabbit got you down? check your notifications settings."16:13
gibimriedem: does changing the default in a bugfix is safe from config compatibility perspective?16:14
jmloweThat may thwart my ambitions to be a obscenely high paid consultant16:15
bauzasmriedem: artom: there ? I have a concern on https://review.openstack.org/#/c/599587/16:15
*** Luzi has quit IRC16:15
bauzasmost of my comments are nits but the last one is important16:15
bauzasartom: mriedem: https://review.openstack.org/#/c/599587/8/specs/stein/approved/numa-aware-live-migration.rst@32716:15
*** tbachman has quit IRC16:16
bauzasthe question is : once we implement this, we will change how we will accept live migrations16:16
bauzasshould we signal it ?16:16
sean-k-mooneybauzas: how do you mean16:16
bauzasor just drop a release note saying "by Stein, NUMA-aware live migrations will be unaccepted"16:16
artombauzas, we could make it configurable, sort like what stephenfin is proposing with https://review.openstack.org/#/c/611088/16:17
mriedemdidn't this already come up in https://review.openstack.org/#/c/611088/16:17
mriedemyeah16:17
*** ttsiouts has quit IRC16:17
artombauzas, but... why? Why would anyone want to live migrate in the middle of an upgrade with mixed computes?16:17
*** sridharg has quit IRC16:17
artomLive migrate *knowing* that things will mostly likely go south16:17
sean-k-mooneyartom: it not that uncommon16:18
*** ttsiouts has joined #openstack-nova16:18
bauzasartom: it's a possibility yes16:18
bauzasthat's even a common pattern16:18
sean-k-mooneyin that case they are likely specifyign the host as they are freeing up old host to upgrade16:18
*** sridharg has joined #openstack-nova16:18
bauzasoperators do a lot of migrations when they upgrade16:18
dansmithartom: live migration during an upgrade is the primary mechanism that most people use16:18
dansmithartom: *lots* of people refuse to upgrade a compute node until they've moved everything off of it16:19
bauzastbh, I'm fine with dropping a release note saying there will be an impact16:19
artomdansmith, fair enough16:19
bauzasgiven worloads should move from old to new16:19
bauzasand not from new to old16:19
sean-k-mooneybauzas: we could do what we did for multiple port bindings and just fall back to the old behavior16:19
*** marvin_mhg has joined #openstack-nova16:20
bauzasoh shit, the problem is with old to new16:20
bauzasnot the contrary, my bad16:20
*** marvin_mhg has quit IRC16:20
artomI just don't see how we can realistically handle that16:20
bauzasso, yeah, we could shoot operators in the foot16:20
bauzasartom: we could make a flag during the upgrade16:20
artomKeep the old code paths intact while somehow adding claims and all the new XML stuff16:21
bauzasand say 'if you need so, it's on you, folks"16:21
*** marvin_mhg has joined #openstack-nova16:21
sean-k-mooneyartom: for old to new we can fallback to the old behvior16:21
bauzasnew to old isn't a problem16:21
bauzasnew to new isn't a problem16:21
artomsean-k-mooney, can we? How do we even implement that?16:21
bauzasold to new is the problem16:21
sean-k-mooneye.g. claim nothing and tell people to migrate again after migrate to fix everything16:22
bauzasso yeah, we somehow need to keep the broken behaviour16:22
artomIt's going to be way ugly with a whole bunch of conditionals all over the place16:22
bauzasartom: I know, it's freaking ugly16:22
bauzasbut I don't see operators be happy with what you propose :p16:22
artomUnless we do the new stuff in entirely new RPC calls/casts16:22
*** ttsiouts has quit IRC16:22
gibimriedem, jmlowe: I reported https://bugs.launchpad.net/nova/+bug/180565916:22
openstackLaunchpad bug 1805659 in OpenStack Compute (nova) "nova notifications hammering the message bus" [Undecided,New]16:22
sean-k-mooneyartom: its what we did for multiple port bindings. we check if a field exitsing in the migrate data if not we do the old stuff if its there we do the new way16:22
artombauzas, yeah, probably true16:23
dansmithartom: that's how we do things gracefully16:23
bauzascouldn't you drop the move claim if the RPC argument is not there ?16:23
dansmithartom: i.e. pass a flag, and if it's missing, assume it's an old compute and do the old thing16:23
artomdansmith, what is? New RPC version?16:23
dansmithyou can't see the rpc version on the receiving end16:23
dansmithyou need a flag16:23
bauzaswhat dansmith said and me :)16:23
dansmithdo_the_new_thing=True16:23
bauzasthat's what we generally do16:23
artomdansmith, I don't disagree, but it's going to be a mess16:23
bauzasartom: I can point you some code I wrote that does the signaling16:23
dansmithartom: it's how you have to do it16:24
dansmithit's how everything we do that involves old/new services works16:24
bauzasartom: sure, but we somehow need to know that the live migration comes from an old compute hence us releasing the check16:24
*** dpawlik has joined #openstack-nova16:24
bauzasand not doing the claim16:24
mriedemif you have an old dest compute, the migrate_data won't have the numa stuff from the claim right?16:25
*** marvin_mhg has quit IRC16:25
mriedemso the source (if new) can't rely on it16:25
artommriedem, other way around, new dest, old source16:25
artomSo source won't send the updated XML, but dest will have claimed for it16:25
*** moshele has joined #openstack-nova16:25
artomSo we need to do conditional claiming based on source compute version16:25
mriedemi think that's what the file-backed memory live migration does...16:26
bauzasyou could make the migrate_data parameter a sentinel16:26
mriedemit checks the compute service version for the source from the dest16:26
*** gaoyan has joined #openstack-nova16:26
artomAlright, lemme update the spec16:26
bauzasartom: just change this16:27
*** gyee has joined #openstack-nova16:27
bauzasother things were nits16:27
bauzasjust for documenting the spec16:27
artomAlright if I keep it kinda high-level? So "conditional claim", but without specifying what that condition will look like (flag, version checking, etc)?16:27
bauzaslater when we review16:27
dansmithartom: you can't check the version16:27
mriedemartom: this is the code i'm thinking of https://github.com/openstack/nova/blob/62245235bc15da6abcdfd3df1c24bd856d69fbb4/nova/virt/libvirt/driver.py#L663616:27
artomdansmith, I guess not on the compute, eh?16:27
artomOnly conductor, so it has to be flag16:27
bauzasmriedem: we don't want to fail16:28
*** gaoyan has quit IRC16:28
dansmithartom: I'm not sure what you mean16:28
bauzasmriedem: we want to blindly accept the migration and not claim16:28
mriedembauzas: you don't want to claim on the dest if the source isn't going to use it16:28
mriedemright?16:28
*** ttsiouts has joined #openstack-nova16:28
bauzasthat's right16:28
artomdansmith, can the dest compute check the source compute version?16:28
artomAnd do the new thing only if the source compute is hew?16:28
artom*new16:28
dansmithartom: don't do it that way16:28
mriedemmy point is, ^ is how the dest checks the source compute version today - that pattern could be re-used, not the specific failure thing16:28
dansmithartom: because version pinning might mean you have a new compute, but it didn't send something new16:29
artomdansmith, oh right16:29
artomWait up though16:29
bauzasartom: https://github.com/openstack/nova/blob/master/nova/scheduler/manager.py#L9316:29
bauzasartom: that's one example of a flag (the _sentinel value)16:30
dansmiththe file-backed stuff chooses not to migrate at all if the target isn't going to support it I think, but in your case you have to allow it, you just need to do the old thing16:30
mriedemif the source isnt going to suppor it16:30
mriedem*support16:30
bauzasshit, I need to bail out16:30
bauzasI just dropped my poop and then I leave16:30
bauzasexcellent16:30
dansmithbauzas: um...16:31
artomYou panda16:31
artomEats poops and leaves16:31
artomNo wait, it's "shoots"16:31
mriedemdansmith: i think the point is, from the dest, if the source is old, we don't claim on the dest and we don't put the numa things in migrate_data,16:31
artomDammit ><16:31
bauzascontext is https://www.meetup.com/fr-FR/Groupe-dutilisateurs-Python-Grenoble/events/256520367/16:31
mriedembecause and old source isn't going to use those anyway, and also wouldn't know to rollback the claim or whatever16:31
bauzasfor once we have a meetup that talks OpenStack here...16:31
dansmithmriedem: it really needs to work both ways, whether the source is old or new16:32
mriedemif the dest is old,16:32
mriedemand the source is new,16:32
mriedemmigrate_data won't have the new numa field in it,16:32
artomIf the source is new it's fine, dest will just ignore the new field16:32
mriedemand the new source node just won't do any of the new stuff16:32
*** sridharg has quit IRC16:32
artom(Which reminds me, it means we need to do claims on the dest)16:32
artom(And cleanup)16:33
mriedemreminds you? the spec already says the claims happen on the dest16:33
mriedemthey have to happen on the dest16:33
dansmiththe spec should probably have the old/new src/dst truth table in it if it doesn't already16:33
artomI mean, in the code16:33
mriedem++ on that16:33
artomAny of the new stuff we do needs to be in code that runs on the dest16:33
mriedemartom: i'm not sure what you're saying16:33
mriedemyes the claim needs to happen on the dest16:33
mriedemlike the spec says :)16:33
artomDoes it? I thought I left it at "implementation detail"16:34
*** sridharg has joined #openstack-nova16:34
mriedemoy16:34
*** udesale has quit IRC16:34
mriedem"Any of the new stuff we do needs to be in code that runs on the dest" is also not accurate16:34
jaypipesSundar: ty sir!16:34
artomWell, yeah16:34
mriedemobviously there will be new code on the source to generate the xml, using data from the dest, to send the xml to the dest16:34
artomCreating claims and cleaning them16:34
artomHas to be done on the dest16:34
bauzasI'm fine with leaving details for the implementation16:34
bauzasI just want to make sure we all agree on the behaviour for upgrades16:35
mriedemcreate yes, i'm not entirely sure about clean (drop_move_claim), but sure16:35
*** sridharg has quit IRC16:35
bauzaswhich is, whatever we write, in case a live migration happens from a Rocky node to a Stein node, we will just blindly accept the migration and not do the claim16:35
mriedemas noted in my review comments, rollback doesn't always cleanup on the dest16:35
mriedemtoday anyway16:35
bauzasartom: ^16:35
*** sridharg has joined #openstack-nova16:35
dansmithbauzas: I thought you dropped poop and left?16:35
dansmithI must have misunderstood :)16:36
artomOK, I think I need to go back to the spec after a bit of thinking16:36
artomdansmith, he's relishing his poop16:36
bauzasdansmith: hah, I just feel I need to discuss a bit more16:36
* dansmith is so confused16:36
mriedemartom: probably easiest to just start with a mixed compute upgrade table or something,16:36
mriedemwith (1) old source, old dest - what happens? (2) old source, new dest, what happens, (3) new source, old dest, (4) new source, new dest16:37
dansmitha truth table, like I said16:37
bauzas+116:37
artomYeah, sounds like a good idea16:37
bauzasthe rest can be left for implementation16:37
bauzasanyway, I'm just flushing my stuff now16:37
bauzassee ya16:37
mriedemif we do that, i'm not entirely sure how much we need https://review.openstack.org/#/c/611088/ now16:38
artommriedem, you're assuming the NUMA live migration code lands in Stein :)16:39
artomI know I'm an all-star, but common16:39
*** ttsiouts has quit IRC16:39
*** ttsiouts has joined #openstack-nova16:40
*** ttsiouts has quit IRC16:41
artomPheeding first though, I'm phamished16:41
cdentdoes first come before or after phirst?16:41
artomAww man, I missed the "phirst" opportunity :(16:42
*** dpawlik has quit IRC16:42
artomPhirst the thirts, than the phamine16:42
artom*thirst16:42
* artom gives up16:42
*** tssurya has quit IRC16:45
*** moshele has quit IRC16:47
*** sridharg has quit IRC16:48
*** tbachman has joined #openstack-nova16:50
*** lbragstad has quit IRC17:02
*** dpawlik has joined #openstack-nova17:03
*** pcaruana has quit IRC17:03
*** lbragstad has joined #openstack-nova17:05
*** dpawlik has quit IRC17:07
*** jangutter has quit IRC17:09
openstackgerritEric Fried proposed openstack/nova master: Rip the report client out of SchedulerClient  https://review.openstack.org/61704217:13
openstackgerritEric Fried proposed openstack/nova master: Rip out the SchedulerClient  https://review.openstack.org/61704917:13
mriedemcdent: i think https://bugs.launchpad.net/nova/+bug/1805408 might be a duplicate, see inline17:14
openstackLaunchpad bug 1805408 in OpenStack Compute (nova) "ServerGroupTestV21.test_boot_servers_with_anti_affinity and related tests can race" [Undecided,New]17:14
*** KeithMnemonic has quit IRC17:14
*** sahid has quit IRC17:17
cdentmriedem: yeah, I think you're right. It just shows up somewhat differently in the context of the placement extraction, but i think that's just noise17:22
cdenti've marked it17:22
*** jackivanov has quit IRC17:28
mriedemso i'm pretty sure we've said we can't change 404s to be 400s just because it's a better fit without a microversion, right?17:29
cdentmriedem: generally true, but fudging is often exercised17:29
cdentthe fear is someone branching on the status code, which you can easily imagine in that particular case17:30
mriedemyeah, this seems pretty obvious what i'm looking at,17:30
mriedemtrying to disable a non-nova-compute service results in HostMappingNotFound which results in a 40417:30
mriedemyou can't disable non-nova-compute services, so really it's a bad request17:30
mriedemi want to provide a better error message than 'host mapping not found' since that's not the problem really17:31
mriedembut also wondering if i should change the response code at the same time to be a 40017:31
cdentit should only ever be a 404 if the actual URL is a 404, not something within17:31
cdentso yeah, this sounds kind of 400 ish17:32
dansmithwait, what?17:36
mriedemhttps://bugs.launchpad.net/nova/+bug/180516417:36
openstackLaunchpad bug 1805164 in OpenStack Compute (nova) rocky "Confusing error message when trying to disable non-nova-compute service" [Low,Triaged]17:36
dansmithdisabling a non-compute service is still a 404 right? since the url to a non-compute service wouldn't exist?17:36
mriedemthe service id isn't in the URL for older microversoins17:37
mriedeme.g. PUT /os-services/disable17:37
mriedemthe host/binary is in the body17:37
dansmithah yeah, was just pulling up the ref17:37
dansmithyeah, okay17:37
mriedemand anyway, we return 400 if you try doing PUT /os-services/{service_id} with a non-compute service with microversion >= 2.5317:37
mriedemso this would be consistent with that17:37
dansmithyn17:38
dansmithum17:38
dansmithcan you GET the service by id?17:38
dansmithfor non-computes?17:38
dansmithapi-ref doesn't show that you can, but I wonder if it's a missing doc17:39
mriedemyou can GET /os-services17:39
mriedemnot a specific service17:39
dansmithbut you can PUT it?17:39
dansmithweird17:39
mriedemthere was lots of weird to be dealt with in https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/service-hyper-uuid-in-api.html17:40
dansmithpoint being PUT /os-services/id where id is not a compute is kinda 404ish right? if you can't update non-compute services?17:40
dansmithif you can't GET them it's hard to say either way17:40
mriedemshrug17:40
mriedemyou can definitely GET them via list, but not directly via show right17:40
dansmithyeah I mean get by id17:41
*** janki has quit IRC17:41
*** adrianc has quit IRC17:43
*** moshele has joined #openstack-nova17:47
*** abhishekk has joined #openstack-nova17:53
mriedemhere it comes17:54
openstackgerritMatt Riedemann proposed openstack/nova master: Provide a useful error message when trying to update non-compute services  https://review.openstack.org/62066717:54
mriedemfor all your ridicule17:54
dansmithmriedem: I commented on the rebuild spec.. I can fix my own nits but had a legit question17:57
dansmithif you can answer I'll fix my nits and approve17:57
*** k_mouza_ has joined #openstack-nova17:57
*** Sundar has quit IRC17:58
mriedemmelwitt: i've triaged at least 2 more bugs about the rocky install guide missing the mention of installing nova-consoleauth b/c it's still needed, i've duplicated them against https://bugs.launchpad.net/nova/+bug/1793255 but not sure what your plans were for putting some kind of note in the install guides about, "hey, you might still need to install nova-consoleauth, see the workaround option for details"17:59
openstackLaunchpad bug 1793255 in OpenStack Compute (nova) rocky "nova-consoleauth missing from Rocky install guide; unable to use VNC" [High,In progress] - Assigned to melanie witt (melwitt)17:59
mriedemdansmith: before i look, let me guess: what do we do about running it through the scheduler?18:00
dansmithno18:00
*** k_mouza has quit IRC18:01
*** k_mouza_ has quit IRC18:01
mriedemdansmith: replies inline18:05
dansmithmriedem: thanks, replied18:10
dansmithmriedem: so I can fix my mechanical nits, but it seems like both our meatier comments deserve some actual new words. agree?18:10
mriedemi replied again to make sure i'm following you18:11
mriedemif we're on the same page, i'll update it18:12
dansmithoh, so, re-reading I may have missed something18:13
dansmiththe procedure says "delete the existing volume attachment",18:13
dansmithwhich I thought meant "the BDM" but that's not the case -- that means the attachment on the cinder side right?18:13
*** rtjure has joined #openstack-nova18:13
mriedemcorrect18:13
dansmithI was worried we might lost the linkage to the volume if we failed to create a temporary BDM at the right spot, and/or fail to allow re-replacing that18:13
dansmithbut this makes more sense18:13
mriedemand it's what we already do today for rebuild18:14
dansmithokay fair enough18:14
dansmithfor non-root you mean18:14
mriedemthe rollback procedure wasn't called out18:14
mriedemyes18:14
mriedemwell,18:14
mriedemyou can rebuild a volume-backed server today too,18:14
mriedemas long as the image doesn't change18:14
dansmithyeah18:14
mriedemwe detach all the bdms, destroy the guest, spawn the guest and attach the volumes again18:14
dansmithokay I'm with you, I was just projecting too much bdm in there18:14
mriedemthe last part 'completes' the attachment by giving cinder the host connector18:14
dansmithdetach or delete/18:15
mriedemdetach18:15
mriedemthe bdms are fixed18:15
mriedemthe volume attachment record is transitory18:15
dansmithright, so we still have the linkage between the instance and the volume it should be attached to yes?18:15
mriedemso we'll update the bdm.attachment_id during the rebuild18:15
mriedemyes18:15
dansmithright, okay, gotcha18:15
mriedemwe do that dance to keep the volume 'ours'18:15
dansmithyeah18:15
*** abhishekk has quit IRC18:18
mriedemdansmith: do you agree that if the image changes, we should run it through the scheduler as we do for image-backed servers?18:21
dansmithmriedem: yeah I said that didn't I?\18:21
mriedemyou said...something,18:21
mriedemi was trying to  confirm18:22
dansmithI said "same policy-enforcment as the image-backed ones"18:22
mriedembut ok i'll update the spec with more wordz18:22
dansmithI ain't speakin' no jive18:22
mriedemyou said conflictory18:22
mriedemmy nose started bleeding18:22
dansmithhaha, okay I was speakin' jive18:22
dansmithhaha18:22
*** wolverineav has joined #openstack-nova18:23
*** ralonsoh has quit IRC18:25
*** moshele has quit IRC18:26
*** wolverineav has quit IRC18:50
openstackgerritMerged openstack/nova master: Give drop_move_claim() correct docstring  https://review.openstack.org/62017018:50
*** wolverineav has joined #openstack-nova18:51
mriedemdansmith: having thought about this over lunch, i'm not really sure if we can/should try to update the host connector back into the attachments if rebuild fails - the volume would be in 'error' status, so i'm not sure if we should mess with it. rebuilding the server again later would just delete the empty volume attachment and start over with a new one18:58
dansmithmriedem: okay I didn't think we would, because we'd be putting attachment info back in that is no longer valid (i.e. couldn't be deleted again when you retry) right?18:59
mriedemwe can delete it again when we retry19:00
mriedemit's just a CRUD operation on the volume attachment record19:00
*** dklyle has joined #openstack-nova19:03
*** whoami-rajat has quit IRC19:07
*** lbragstad has quit IRC19:08
*** lbragstad has joined #openstack-nova19:12
*** lbragstad has quit IRC19:12
*** lbragstad has joined #openstack-nova19:14
*** lbragstad has quit IRC19:14
*** erlon has quit IRC19:15
*** lbragstad has joined #openstack-nova19:16
*** lbragstad has quit IRC19:16
*** cdent has quit IRC19:17
*** k_mouza has joined #openstack-nova19:21
*** mdbooth_ has joined #openstack-nova19:26
*** dklyle has quit IRC19:27
*** mdbooth has quit IRC19:29
*** erlon has joined #openstack-nova19:30
openstackgerritMatt Riedemann proposed openstack/nova-specs master: Support volume-backed server rebuild  https://review.openstack.org/53240719:40
mriedemdansmith: updated ^ i'll wait to +219:40
*** erlon has quit IRC19:52
*** eharney has quit IRC19:59
*** wolverineav has quit IRC20:05
openstackgerritMatt Riedemann proposed openstack/nova master: Restore nova-consoleauth to install docs  https://review.openstack.org/60515420:06
*** wolverineav has joined #openstack-nova20:07
*** eharney has joined #openstack-nova20:11
openstackgerritMatt Riedemann proposed openstack/nova master: Restore nova-consoleauth to install docs  https://review.openstack.org/60515420:14
*** wolverineav has quit IRC20:16
openstackgerritMatt Riedemann proposed openstack/nova master: Restore nova-consoleauth to install docs  https://review.openstack.org/60515420:22
*** lbragstad has joined #openstack-nova20:30
mnasersimple backport needing some votes - https://review.openstack.org/#/c/619351/ (stable/rocky already merged)20:30
*** openstackgerrit has quit IRC20:36
*** awaugama has quit IRC20:43
*** k_mouza has quit IRC20:44
melwittmriedem: by default, people shouldn't have to install nova-consoleauth on a fresh install _unless_ they've enabled the [workarounds]enable_consoleauth option. I added a comment to the review20:48
*** wolverineav has joined #openstack-nova20:48
melwittI'm going to compare when those bugs were opened vs when the change that made nova-consoleauth optional merged to stable/rocky20:49
mriedemboth were opened this month20:50
mriedemthe duplicates20:50
melwittok. I had tested that nova-consoleauth is no longer needed via this devstack change https://review.openstack.org/607070 back when I worked on the patch that made it optional20:52
melwittgoing to look at the duplicates now20:52
*** tbachman has quit IRC21:02
*** wolverineav has quit IRC21:02
*** k_mouza has joined #openstack-nova21:04
*** wolverineav has joined #openstack-nova21:06
*** openstackgerrit has joined #openstack-nova21:14
openstackgerritMatt Riedemann proposed openstack/nova master: Mention size limit on user data in docs  https://review.openstack.org/62070021:14
flwangmriedem: does nova support configuring the volume type when booting?21:15
mriedemflwang: with microversion 2.67 in stein yes https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id6021:15
flwangis it a big feature? possible to do cherrypick? to old nova version?21:16
flwangmriedem: any chance you know the commit link?21:20
*** eharney has quit IRC21:20
*** wolverineav has quit IRC21:22
*** wolverineav has joined #openstack-nova21:23
*** wolverineav has quit IRC21:23
*** wolverineav has joined #openstack-nova21:23
mriedemflwang: you're asking me if we can backport an API feature change?21:23
mriedemyou've been around openstack long enough to know that is a blatant violation of stable branch policy21:24
*** tbachman has joined #openstack-nova21:24
mriedemwhatever you want to fork in your product though...go ahead :)21:24
*** mchlumsky has quit IRC21:25
*** tbachman_ has joined #openstack-nova21:27
*** tbachman has quit IRC21:29
*** tbachman_ is now known as tbachman21:29
flwangmriedem: no, i'm just lazy, so just ask if it's a big one, so that we can backport it in our private repo21:29
flwangnow i have got all the commits21:30
flwangit's big one, seems no chance to backport :(21:30
efriedjaypipes: Responded on https://review.openstack.org/#/c/617042/ - lmk if that doesn't make sense.21:30
efriedjaypipes: btw, if it's specifically the use of the @property decorator you object to, I can change it to _get_report_client() for consistency with _get_resource_tracker(). I just wanted to take the opportunity to save some horizontal space, since we're already having trouble fitting things like https://review.openstack.org/#/c/617042/6/nova/compute/manager.py@a76621:32
jaypipesefried: answered. yeah, we can remove all that now and just set reportclient once.21:35
efriedjaypipes: Okay, cool. fup?21:35
jaypipesyup. lemme re-vote (though I still think it would be cool to have those two patches separate)21:36
*** lbragstad has quit IRC21:37
jaypipesefried: +221:37
*** lbragstad has joined #openstack-nova21:37
efriedjaypipes: Thanks! Re removing that flushing of the RT, I'm slightly leery of trying to do that change myself - how will we know it didn't break things? Though perhaps we could instead just self.reportclient.clear_cache() now that that's a thing.21:38
mriedemheh, finally got an official bug for the regression in ocata where aggregate allocation ratios are no longer honored https://bugs.launchpad.net/nova/+bug/180412521:38
openstackLaunchpad bug 1804125 in OpenStack Compute (nova) "Nova placement disregards nova aggregate metadata" [Medium,Triaged]21:38
jaypipesefried: maybe. just try it? :) I'm telling you I added that code comment back when the RT was still being converted by me to pass nodename for all the methods and track multiple compute nodes (instead of having multiple instances of the RT)21:39
openstackgerritJack Ding proposed openstack/nova master: [WIP] Flavor extra spec and image properties validation  https://review.openstack.org/62070621:40
efriedjaypipes: um, afaict, we only get ComputeHostNotFound from get_node_uuid (in resource_tracker.py) - and I can't see where that guy is used at all. So that whole exception path may be completely unreachable.21:49
*** rcernin has joined #openstack-nova21:50
*** takashin has joined #openstack-nova21:50
openstackgerritMerged openstack/nova-specs master: Support volume-backed server rebuild  https://review.openstack.org/53240721:51
jaypipesefried: not a bit unlikely :)21:57
flwangmriedem: jaypipes: is there a config option in nova.conf to set the default volume type?22:02
*** rcernin has quit IRC22:03
jaypipesflwang: sorry, I have node idea :( mriedem probably is your best bet. (I didn't even think we *supported* volume types actually..)22:04
openstackgerritEric Fried proposed openstack/nova master: WIP: Use a static resource tracker in the compute manager  https://review.openstack.org/62071122:04
efriedjaypipes: Let's see how the gate feels about that ^22:04
flwangjaypipes: nova supports it in master(stein)22:04
mriedemflwang: no, cinder has a config for the default volume type22:05
mriedemnova only passes the volume type through, otherwise nova creates volumes w/o any volume type and you get the default from cinder22:06
jaypipesefried: lol nice commit message.22:07
efried:P22:07
flwangmriedem: that makes sense, thank you very much22:07
efriedjaypipes: btw, I'm hoping you can review that whole series at some point. You're the A-1 expert in these code paths, I think.22:07
efriedjaypipes: This is to solve the whole thing about CERN's traffic problems.22:08
efried...that we put off in queens with that resource_provider_association_refresh conf var22:08
openstackgerritMatt Riedemann proposed openstack/nova master: Nova the aggregate allocation ratio restriction in scheduler docs  https://review.openstack.org/62071322:09
jaypipesefried: ack.22:11
jaypipesefried: working on em....22:11
efriedthx22:11
*** rcernin has joined #openstack-nova22:12
mriedemi have -1ed22:14
mriedempull that get_node_uuid removal out22:15
*** xek_ has quit IRC22:19
openstackgerritEric Fried proposed openstack/nova master: Turn off rp association refresh in nova-next  https://review.openstack.org/61603322:20
mriedemzzzeek: could use your input on this postgresql issue if you have a sec https://review.openstack.org/#/c/619061/122:21
mriedemi threw in a thing that works, but i'm not sure it's the right way22:21
efriedmriedem: so do it, just do it separately?22:21
mriedemefried: yes, outside of that series22:21
efriedack22:22
mriedemyou could throw it in topic branch remove-migration-allocation-compat to line it all up nicely22:22
mriedemhttps://review.openstack.org/#/q/topic:remove-migration-allocation-compat+(status:open+OR+status:merged)22:22
openstackgerritEric Fried proposed openstack/nova master: WIP: Use a static resource tracker in the compute manager  https://review.openstack.org/62071122:23
*** artom has quit IRC22:26
openstackgerritEric Fried proposed openstack/nova master: Remove get_node_uuid  https://review.openstack.org/62071522:27
efriedmriedem: there ya go. Don't say I never did anything for ya.22:28
*** artom has joined #openstack-nova22:28
efriedspeaking of which, what's the interest rate on shiny nickels?22:29
*** artom has quit IRC22:29
mriedemit's low22:29
mriedemit's always in my backpack though22:29
mriedemyou just need to remind me in person sometime22:29
*** artom has joined #openstack-nova22:29
mriedemor give me your address and i'll ship it down22:29
mriedemmaybe in a xmas card?!22:29
efriedThat would be awesome. What's a stamp these days, 40-odd cents? And you're not supposed to mail cash. Oh, and f xmas.22:30
efriedI'll put it on the etherpad for Denver22:30
mriedemgood idea22:31
mriedemi'll write you a check for $.0522:31
efriedIT HAS TO BE SHINY22:32
efriedput glitter or something22:32
mriedemwe do have glitter22:33
mriedempens, glue, you name it22:33
mriedemi will richard shermans this check up for you22:33
mriedemha, wrong guy22:33
mriedemsimmons22:33
mriedemsimmons22:33
mriedemjaypipes: you may enjoy that slip ^22:34
mriedemFOOTBAW22:34
jaypipeshaha22:35
*** derekh has quit IRC22:43
*** derekh has joined #openstack-nova22:44
*** derekh has quit IRC22:44
*** slaweq has quit IRC22:46
*** tbachman has quit IRC22:46
*** tbachman has joined #openstack-nova22:46
*** mlavalle has quit IRC22:50
*** tbachman has quit IRC22:51
*** slaweq has joined #openstack-nova22:54
*** mlavalle has joined #openstack-nova22:55
mriedemmordred: we should only need the endpoint type (volumev3) and interface (public) to look up a service catalog entry right? we don't need the service name for that,22:59
*** slaweq has quit IRC22:59
mordredthat is correct22:59
mriedemunless you have multiple endpoints pointed at the same type and interface but with different names or something?22:59
mriedemtrying to sort out what i can do for https://bugs.launchpad.net/nova/+bug/180362722:59
openstackLaunchpad bug 1803627 in OpenStack Compute (nova) "Nova requires you to name your volumev3 service cinderv3" [Undecided,New]22:59
jaypipesefried: I'm quite concerned about https://review.openstack.org/#/c/615677/23:00
mordredthe only time service name is ever useful for anything is if a cloud has gotten itself into a bad place and has more than one endpoint with the same service type like rackspace public cloud did during their transition from legacy to openstack23:00
mordredmriedem: looking23:00
*** wolverineav has quit IRC23:01
mordredmriedem: oh - I can help work on that patch tomorrow (it's too late today)23:01
mriedemnp thanks23:01
efriedjaypipes: Looking23:01
mriedemi'm going to post something quick23:01
*** wolverineav has joined #openstack-nova23:02
efriedmriedem, mordred: We ought to be able to fix that by exploiting some of the fancy schmancy discovery code in ksa, nah?23:02
mordredI mean - efried will probably beat me to it - but getting rid of that catalog_info parameter at least is a step in teh right direction23:02
mordredefried: yup!23:02
sorrisonmriedem: re cinder catalog in nova.conf yes the only way we can get it to work is by setting endpoint_template23:02
efriedYou ought to be able to a) name your service any of the list of valid things, and b) search for the endpoint using any of that same list of valid things.23:02
mordredyup. and you should absolutely be able to omit service_name which should default to None23:03
jaypipesefried: unless I'm totally bonkers... but AFAIK, when Ironic is in the mix, that ProviderTree can contain thousands of root providers.23:03
*** wolverineav has quit IRC23:03
efriedand yeah, long-standing TODO to get rid of all that bizarro client construction gorp23:03
*** wolverineav has joined #openstack-nova23:03
mordredand you should not only be able to omit service-type- you should really always omit service-type because using different service types is CRAZY - but you should be able to configure it anyway23:04
mordredefried: I started looking at all that before the summit, then had thanksgiving23:04
mordredI'd love to make a patch for y'all with a strawman of ripping a ton of gorp out23:04
efriedI'll be happy to review same, but I'm not likely to have time to code it up myself, alas.23:05
efriedI'm up to here23:05
mordredcool. well - you did the last one - so it's my turn this time I think23:06
mriedemefried: remember you had https://review.openstack.org/#/c/508345/23:06
mriedembut very out of date by now23:06
efriedoo, indeed23:06
mordredmriedem: yeah - I'll likely start by seeing if I can update that :)23:06
* mordred loves deleting things23:07
efriedjaypipes: Hum, I see your point. I did have it rigged at some point to just invalidate the tree of the failing provider. That turned out to be nontrivial and hacky, which is why I went the "invalidate everything" route. But yeah, I may have to restore that logic :(23:08
*** k_mouza has quit IRC23:15
*** mlavalle has quit IRC23:15
openstackgerritMatt Riedemann proposed openstack/nova master: Make [cinder]/catalog_info no longer require a service_name  https://review.openstack.org/62073823:16
mriedemsorrison: see how ^ floats your boat23:16
sorrisonmriedm: looks very buoyant, thanks!23:17
*** N3l1x has quit IRC23:17
sorrisonDoes anyone about any big openstack installs that connect to rabbitMQ with SSL, we've been having a lot of fun with https://bugs.launchpad.net/oslo.messaging/+bug/1800957/ so far it seems use of SSL for rabbit is very low23:20
openstackLaunchpad bug 1800957 in oslo.messaging "Upgrading to pike version causes rabbit timeouts with ssl" [Undecided,Incomplete] - Assigned to Ken Giusti (kgiusti)23:20
mriedemsorrison: i seem to remember klindgren saying something similar a long time ago23:28
mriedemso maybe SpamapS has an idea?23:28
*** tbachman has joined #openstack-nova23:29
openstackgerritMatt Riedemann proposed openstack/nova master: Make [cinder]/catalog_info no longer require a service_name  https://review.openstack.org/62073823:33
mriedemcfriesen: jackding: fyi hpet related https://bugs.launchpad.net/nova/+bug/180508723:37
openstackLaunchpad bug 1805087 in OpenStack Compute (nova) "libvirt+KVM: High CPU usage on Windows 10 (1803) guests" [Undecided,New]23:37
*** erlon has joined #openstack-nova23:38
mriedemturns out it's not just windriver OS images that need hpet23:38
SpamapSsorrison: mriedem yes GoDaddy does use TLS for RabbitMQ. I don't work there anymore though.23:42
*** wolverineav has quit IRC23:42
SpamapSWith cells v1, and cells of up to 1000 hv's.23:42
openstackgerritMatt Riedemann proposed openstack/nova master: Note the aggregate allocation ratio restriction in scheduler docs  https://review.openstack.org/62071323:43
sorrisonSpamapS: thanks. I'll send klindgren an email and get some more info off him23:43
SpamapSFor cells v2 the TLS should still be in use, but the cells v2 deployment wasn't quite scaled out when I was there.23:43
SpamapSsorrison: out of curiosity, what issue are you seeing?23:44
*** wolverineav has joined #openstack-nova23:44
sorrisonSpamapS: See https://bugs.launchpad.net/oslo.messaging/+bug/1800957/ basically timeouts waiting for replies23:45
openstackLaunchpad bug 1800957 in oslo.messaging "Upgrading to pike version causes rabbit timeouts with ssl" [Undecided,Incomplete] - Assigned to Ken Giusti (kgiusti)23:45
openstackgerritMatt Riedemann proposed openstack/nova master: Provide a useful error message when trying to update non-compute services  https://review.openstack.org/62066723:45
sorrisonSpamapS: been having a lot of fun as we didn't see this in testing and I'm still unsure why it happens, but I at least have found a reliable set of versions that work (basically the ocata versions)23:46
SpamapSsorrison: Yeah the big deploy at GoDaddy was still running Liberty when I left about 6 weeks ago.23:47
SpamapSthe smaller deployment was Pike with cells v2.23:48
SpamapSRabbitMQ is basically the most hated thing on the OpenStack team at GoDaddy, so, I'm not sure anybody will give you a nuanced answer. ;)23:48
sorrisonyeah I am aware of klindgren hate for rabbit, it's been stable for us over the last couple years up until pike upgrade23:49
sorrisonwe (nectar) have cellsv1, 13 cells ~1000 hypervisors23:50
*** wolverineav has quit IRC23:51
*** slaweq has joined #openstack-nova23:54
*** tbachman has quit IRC23:55

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