Thursday, 2019-07-11

openstackgerritMatt Riedemann proposed openstack/nova master: Convert nova-next to a zuul v3 job  https://review.opendev.org/67019600:00
*** zhubx has quit IRC00:00
*** zhubx has joined #openstack-nova00:01
*** boxiang has joined #openstack-nova00:06
*** zhubx has quit IRC00:08
*** zhubx has joined #openstack-nova00:09
*** zhubx has quit IRC00:10
*** zhubx has joined #openstack-nova00:10
*** boxiang has quit IRC00:10
*** slaweq has joined #openstack-nova00:11
*** hemna has quit IRC00:12
*** hemna has joined #openstack-nova00:12
*** mriedem has quit IRC00:15
*** slaweq has quit IRC00:15
*** lbragstad has quit IRC00:16
openstackgerritArtom Lifshitz proposed openstack/nova master: Revert resize: wait for events according to hybrid plug  https://review.opendev.org/66717700:31
openstackgerritArtom Lifshitz proposed openstack/nova master: Pass migration to finish_revert_migration()  https://review.opendev.org/66863100:31
openstackgerritArtom Lifshitz proposed openstack/nova master: [DNM] testing bug/1813789 revert resize events  https://review.opendev.org/66444200:31
*** boxiang has joined #openstack-nova00:35
*** zhubx has quit IRC00:36
*** gyee has quit IRC00:47
*** zhubx has joined #openstack-nova00:54
*** hongbin has joined #openstack-nova00:57
*** boxiang has quit IRC00:57
*** hemna has quit IRC00:59
*** boxiang has joined #openstack-nova01:00
*** zhubx has quit IRC01:00
*** hemna has joined #openstack-nova01:02
*** hemna has quit IRC01:08
*** hemna has joined #openstack-nova01:08
*** imacdonn has quit IRC01:14
*** imacdonn has joined #openstack-nova01:14
*** ricolin has joined #openstack-nova01:23
*** spatel has joined #openstack-nova01:30
*** zhubx has joined #openstack-nova01:44
*** lei-zh has joined #openstack-nova01:44
*** boxiang has quit IRC01:47
*** boxiang has joined #openstack-nova01:48
*** zhubx has quit IRC01:49
*** irclogbot_0 has joined #openstack-nova02:06
*** slaweq has joined #openstack-nova02:11
*** irclogbot_0 has quit IRC02:13
*** slaweq has quit IRC02:16
*** irclogbot_3 has joined #openstack-nova02:16
*** hemna has quit IRC02:17
*** altlogbot_1 has joined #openstack-nova02:18
*** irclogbot_3 has quit IRC02:19
*** hemna has joined #openstack-nova02:19
*** zhubx has joined #openstack-nova02:20
*** boxiang has quit IRC02:20
*** mvkr_ has joined #openstack-nova02:23
*** mvkr has quit IRC02:25
*** rcernin has quit IRC02:29
*** dklyle has joined #openstack-nova02:32
*** BjoernT has quit IRC02:34
*** altlogbot_1 has quit IRC02:34
*** rcernin has joined #openstack-nova02:46
*** dklyle has quit IRC02:59
openstackgerritBrin Zhang proposed openstack/nova-specs master: Support for changing deleted_on_termination after boot  https://review.opendev.org/58033603:05
*** brault has joined #openstack-nova03:08
*** slaweq has joined #openstack-nova03:11
*** brault has quit IRC03:12
*** slaweq has quit IRC03:15
*** irclogbot_0 has joined #openstack-nova03:20
*** whoami-rajat has joined #openstack-nova03:20
*** psachin has joined #openstack-nova03:20
*** whoami-rajat has quit IRC03:24
*** whoami-rajat has joined #openstack-nova03:25
*** irclogbot_0 has quit IRC03:25
*** zhubx has quit IRC03:27
*** lei-zh1 has joined #openstack-nova03:32
*** lei-zh has quit IRC03:34
*** psachin has quit IRC03:38
*** rcernin has quit IRC03:39
*** hongbin has quit IRC03:44
*** spatel has quit IRC03:50
*** altlogbot_0 has joined #openstack-nova03:54
*** dannins has joined #openstack-nova03:54
*** rcernin has joined #openstack-nova03:55
*** altlogbot_0 has quit IRC03:59
openstackgerritTakashi NATSUME proposed openstack/nova stable/rocky: doc: Fix a parameter of NotificationPublisher  https://review.opendev.org/67022504:03
openstackgerritTakashi NATSUME proposed openstack/nova stable/queens: doc: Fix a parameter of NotificationPublisher  https://review.opendev.org/67022604:05
*** slaweq has joined #openstack-nova04:11
*** udesale has joined #openstack-nova04:13
*** slaweq has quit IRC04:16
*** BjoernT has joined #openstack-nova04:16
*** _alastor1 has quit IRC04:24
*** lei-zh1 has quit IRC04:50
*** pcaruana has joined #openstack-nova04:55
*** lei-zh has joined #openstack-nova05:00
*** ccamacho has quit IRC05:33
*** Luzi has joined #openstack-nova05:43
*** BjoernT has quit IRC05:49
*** lei-zh has quit IRC06:01
*** lei-zh has joined #openstack-nova06:05
*** slaweq has joined #openstack-nova06:11
*** ccamacho has joined #openstack-nova06:14
*** slaweq has quit IRC06:16
*** altlogbot_0 has joined #openstack-nova06:18
*** altlogbot_0 has quit IRC06:23
*** altlogbot_0 has joined #openstack-nova06:24
*** bbowen_ has joined #openstack-nova06:27
*** bbowen_ has quit IRC06:28
*** bbowen has quit IRC06:28
*** altlogbot_0 has quit IRC06:29
*** dpawlik has joined #openstack-nova06:29
*** rpittau|afk is now known as rpittau06:33
*** ricolin has quit IRC06:39
*** luksky11 has joined #openstack-nova06:39
*** belmoreira has joined #openstack-nova06:46
*** slaweq has joined #openstack-nova06:46
*** ricolin has joined #openstack-nova06:46
*** maciejjozefczyk has joined #openstack-nova06:53
*** altlogbot_2 has joined #openstack-nova06:56
openstackgerrithuanhongda proposed openstack/nova stable/pike: [Stable Only] libvirt: Handle volume API failure in post_live_migration  https://review.opendev.org/67001606:57
*** altlogbot_2 has quit IRC07:01
*** ivve has joined #openstack-nova07:04
*** tetsuro has joined #openstack-nova07:06
*** yaawang has quit IRC07:07
*** yaawang has joined #openstack-nova07:08
*** helenafm has joined #openstack-nova07:10
*** ccamacho has quit IRC07:12
*** ccamacho has joined #openstack-nova07:12
*** awalende has joined #openstack-nova07:13
*** irclogbot_3 has joined #openstack-nova07:16
*** rcernin has quit IRC07:17
*** tssurya has joined #openstack-nova07:19
*** irclogbot_3 has quit IRC07:21
*** lei-zh has quit IRC07:22
*** irclogbot_1 has joined #openstack-nova07:24
*** irclogbot_1 has quit IRC07:27
*** lei-zh has joined #openstack-nova07:28
*** xek_ has joined #openstack-nova07:39
*** lei-zh has quit IRC07:40
*** belmoreira has quit IRC07:40
*** lei-zh has joined #openstack-nova07:41
openstackgerrithuanhongda proposed openstack/nova stable/pike: [Stable Only] libvirt: Handle volume API failure in post_live_migration  https://review.opendev.org/67001607:41
*** tetsuro has quit IRC07:42
*** belmoreira has joined #openstack-nova07:46
*** altlogbot_0 has joined #openstack-nova07:48
*** altlogbot_0 has quit IRC07:49
*** tetsuro has joined #openstack-nova07:51
*** irclogbot_0 has joined #openstack-nova07:52
*** irclogbot_0 has quit IRC07:55
*** ralonsoh has joined #openstack-nova07:59
*** ttsiouts has joined #openstack-nova08:05
*** elod has quit IRC08:07
*** cdent has joined #openstack-nova08:08
*** irclogbot_1 has joined #openstack-nova08:08
*** elod has joined #openstack-nova08:08
*** suzhengwei_ has joined #openstack-nova08:10
*** tkajinam has quit IRC08:10
*** suzhengwei_ has quit IRC08:12
*** irclogbot_1 has quit IRC08:12
*** suzhengwei_ has joined #openstack-nova08:13
*** suzhengwei_ has quit IRC08:15
*** ociuhandu has joined #openstack-nova08:15
*** ttsiouts has quit IRC08:17
*** ttsiouts has joined #openstack-nova08:18
*** udesale has quit IRC08:30
*** udesale has joined #openstack-nova08:31
*** xek_ has quit IRC08:35
*** derekh has joined #openstack-nova08:40
*** suzhengwei has joined #openstack-nova08:41
*** tetsuro has quit IRC08:45
*** tetsuro has joined #openstack-nova08:48
*** mdbooth has joined #openstack-nova08:49
*** suzhengwei has quit IRC08:50
*** tetsuro has quit IRC08:53
openstackgerritShilpa Devharakar proposed openstack/nova master: Support filtering of hosts by forbidden aggregates  https://review.opendev.org/66795208:55
*** dtantsur|afk is now known as dtantsur08:57
*** mdbooth has quit IRC08:59
*** xek has joined #openstack-nova09:02
openstackgerritTakashi NATSUME proposed openstack/nova master: Fix no propagation of nova context request_id  https://review.opendev.org/66271509:03
*** udesale has quit IRC09:08
*** udesale has joined #openstack-nova09:09
*** lei-zh1 has joined #openstack-nova09:10
*** lei-zh has quit IRC09:11
*** damien_r has joined #openstack-nova09:12
*** dpawlik has quit IRC09:12
*** dpawlik has joined #openstack-nova09:13
*** dpawlik has quit IRC09:18
*** damien_r has quit IRC09:18
*** dpawlik has joined #openstack-nova09:18
*** FlorianFa has joined #openstack-nova09:36
*** udesale has quit IRC09:37
openstackgerritBalazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations  https://review.opendev.org/63795509:37
*** udesale has joined #openstack-nova09:38
*** belmoreira has quit IRC09:39
*** udesale has quit IRC09:40
*** udesale has joined #openstack-nova09:41
*** mdbooth has joined #openstack-nova09:46
*** irclogbot_0 has joined #openstack-nova09:48
*** mkrai_ has joined #openstack-nova09:49
*** mkrai__ has joined #openstack-nova09:50
*** irclogbot_0 has quit IRC09:51
*** cdent has quit IRC10:00
*** udesale has quit IRC10:02
*** udesale has joined #openstack-nova10:02
*** udesale has quit IRC10:03
*** udesale has joined #openstack-nova10:03
*** shilpasd has joined #openstack-nova10:04
*** psachin has joined #openstack-nova10:13
*** ttsiouts has quit IRC10:19
*** ttsiouts has joined #openstack-nova10:20
*** belmoreira has joined #openstack-nova10:24
*** ttsiouts has quit IRC10:25
*** altlogbot_0 has joined #openstack-nova10:26
*** belmoreira has quit IRC10:28
*** altlogbot_0 has quit IRC10:29
*** yonglihe has quit IRC10:29
openstackgerritEric Fried proposed openstack/os-resource-classes master: Propose ACCELERATOR_{FPGA|GPU} resource classes  https://review.opendev.org/65746410:32
*** janki has joined #openstack-nova10:32
*** altlogbot_3 has joined #openstack-nova10:34
*** davidsha has joined #openstack-nova10:35
openstackgerritYongli He proposed openstack/nova master: clean up orphan instances  https://review.opendev.org/62776510:39
*** altlogbot_3 has quit IRC10:39
*** altlogbot_0 has joined #openstack-nova10:40
*** irclogbot_3 has joined #openstack-nova10:40
*** lpetrut has joined #openstack-nova10:45
*** altlogbot_0 has quit IRC10:45
*** irclogbot_3 has quit IRC10:45
*** brinzhang_ has quit IRC10:48
*** belmoreira has joined #openstack-nova10:50
*** mkrai__ has quit IRC10:52
*** mkrai_ has quit IRC10:52
*** altlogbot_0 has joined #openstack-nova10:56
ralonsohhi folks, can I have your attention to https://review.opendev.org/#/c/641670/?10:58
ralonsohthank you in advance!10:58
*** altlogbot_0 has quit IRC11:01
*** lpetrut has quit IRC11:01
*** lpetrut has joined #openstack-nova11:03
*** belmoreira has quit IRC11:06
*** belmoreira has joined #openstack-nova11:09
*** lei-zh1 has quit IRC11:15
*** belmoreira has quit IRC11:17
*** tbachman has quit IRC11:18
*** tesseract has joined #openstack-nova11:21
*** belmoreira has joined #openstack-nova11:24
*** _erlon_ has joined #openstack-nova11:24
*** belmoreira has quit IRC11:27
openstackgerritBalazs Gibizer proposed openstack/nova master: Move consts from neutronv2/api to constants module  https://review.opendev.org/66894511:27
*** belmoreira has joined #openstack-nova11:28
openstackgerritBalazs Gibizer proposed openstack/nova master: Translatable output strings in heal allocation  https://review.opendev.org/66892511:28
*** priteau has joined #openstack-nova11:29
*** belmoreira has quit IRC11:30
*** tbachman has joined #openstack-nova11:37
*** ttsiouts has joined #openstack-nova11:38
openstackgerritBalazs Gibizer proposed openstack/nova master: Use neutron contants in cmd/manage.py  https://review.opendev.org/66894611:39
openstackgerritBalazs Gibizer proposed openstack/nova master: Add 'resource_request' to neutronv2/constants  https://review.opendev.org/66894711:39
*** udesale has quit IRC11:39
openstackgerritBalazs Gibizer proposed openstack/nova master: Use the safe get_binding_profile  https://review.opendev.org/66981711:45
*** tbachman has quit IRC11:45
*** tbachman has joined #openstack-nova11:50
*** altlogbot_3 has joined #openstack-nova11:56
*** tbachman has quit IRC11:59
*** altlogbot_3 has quit IRC12:01
*** ttsiouts has quit IRC12:12
*** priteau has quit IRC12:13
*** ttsiouts has joined #openstack-nova12:13
*** tbachman has joined #openstack-nova12:15
*** janki has quit IRC12:21
openstackgerritStephen Finucane proposed openstack/nova stable/stein: docs: Correct issues with 'openstack quota set' commands  https://review.opendev.org/67009612:25
openstackgerritStephen Finucane proposed openstack/nova stable/rocky: docs: Correct issues with 'openstack quota set' commands  https://review.opendev.org/67009712:26
openstackgerritStephen Finucane proposed openstack/nova stable/queens: docs: Correct issues with 'openstack quota set' commands  https://review.opendev.org/67010012:27
*** irclogbot_3 has joined #openstack-nova12:33
shilpasdefried: dansmith: requesting to further review https://review.opendev.org/#/c/667952/712:33
*** irclogbot_3 has quit IRC12:35
alex_xuefried: after review the vpmem, I want to point the Luyao to move the vpmem ns assigment inside the resource tracker. https://review.opendev.org/#/c/662702/4/nova/compute/manager.py@2200, want to hear you opionion whether it is right direction I pointed to12:39
*** jmlowe has quit IRC12:40
*** luksky11 has quit IRC12:41
*** hamzy has quit IRC12:42
*** janki has joined #openstack-nova12:43
*** janki has quit IRC12:45
openstackgerritStephen Finucane proposed openstack/nova master: docs: Scrub available quotas  https://review.opendev.org/67012512:47
openstackgerritStephen Finucane proposed openstack/nova master: docs: Rewrite quotas documentation  https://review.opendev.org/66716512:47
*** helenafm has quit IRC12:50
*** altlogbot_1 has joined #openstack-nova12:51
*** altlogbot_1 has quit IRC12:53
*** abhishekk has joined #openstack-nova12:53
openstackgerritya.wang proposed openstack/nova master: Add method 'get_all_required_traits' to scheduler utils  https://review.opendev.org/67029712:59
openstackgerritya.wang proposed openstack/nova master: vCPU mdoels selection  https://review.opendev.org/67029812:59
openstackgerritya.wang proposed openstack/nova master: Add compatibility checks for CPU mode and CPU models and extra flags  https://review.opendev.org/67029912:59
openstackgerritya.wang proposed openstack/nova master: Support report multi CPU model traits  https://review.opendev.org/67030012:59
*** helenafm has joined #openstack-nova13:00
openstackgerritTakashi NATSUME proposed openstack/nova master: Fix no propagation of nova context request_id  https://review.opendev.org/66271513:00
efriedalex_xu: looking...13:03
alex_xuefried: thanks!13:04
efriedalex_xu: instance_claim is a good idea, I think. Aptly named, protected by COMPUTE_RESOURCE_SEMAPHORE... but where is bauzas claiming VGPUs?13:05
bauzasefried: on a meeting atm13:05
efriedI would have expected that to be the same as vpmems13:05
efriedno worries bauzas, I can look.13:06
alex_xuefried: actually, I just find the vgpu allocation have race problem13:06
alex_xuI talk that with bauzas yesterday13:06
efriedah, okay. So it sounds like vgpu needs to be moved to instance_claim as well13:06
efrieddo we have a bug for that yet?13:06
*** shilpasd has quit IRC13:07
*** yaawang has quit IRC13:07
alex_xunot yet, I can file a bug13:07
efriedalex_xu: hold on, isn't COMPUTE_RESOURCES_SEMAPHORE held throughout the `with instance_claim` block?13:10
efriedoh, no, never mind13:10
efriedinstance_claim isn't itself a context manager; it returns one.13:11
*** belmoreira has joined #openstack-nova13:12
alex_xuefried: here is the bug, that help you understand the problem https://bugs.launchpad.net/nova/+bug/183620413:12
openstackLaunchpad bug 1836204 in OpenStack Compute (nova) "The allocation of VGPU has race problem" [Undecided,New]13:12
*** belmoreira has quit IRC13:12
alex_xuefried: also the vpmem isn't quite same with vgpu in the resize case, we need to allcoate vpmem for migration the data from the src host. so we need to assign a pmem in the beginning of resize https://review.opendev.org/#/c/662709/4/nova/compute/manager.py@435913:13
*** shilpasd has joined #openstack-nova13:13
efriedin that case do we want to fold it into resize_claim?13:14
alex_xuyes, and that doesn't sounds good we add new virt interface just for allocae a pmem.13:14
alex_xuand there isn't a way to resolve the race problem just by listing libvirt domain13:14
efriedalex_xu: We shouldn't be putting this libvirt-specific code into the rt anyway13:15
alex_xusince we assign vpmem without create libvirt domain on the dst host in the beginning of resize13:15
efrieda virt driver interface to say "claim the things in this allocation" would seem appropriate.13:15
efriedit doesn't need to be vpmem specific13:15
alex_xuefried: yes, so I'm thinking we should use virt.get_available_resources reporting the vpmem to the rt, then rt will track the assignement13:16
alex_xuefried: ok, I see you point13:16
alex_xuanother problem is we also need some code to handle the rollback like we spawn the instance failed13:17
efriedyup, the methods would need to be symmetrical. claim_for_instance/unclaim_for_instance13:17
efriedand the virt driver doesn't really need to do anything with the device other than mark it as "used" in whatever way it sees fit.13:18
alex_xuefried: yea, that we can do13:18
alex_xuefried: should we call that claim_for_instance inside rt.instance_claim?13:19
*** belmoreira has joined #openstack-nova13:19
efriedtotally13:19
efriedand resize_claim13:19
alex_xucool13:19
efriedbut13:19
efriedI think we should probably create this framework outside of the vpmem series13:19
efriedand put the vgpu stuff into it13:19
efriedand then build the vpmem series on top of that13:20
*** arxcruz|rover is now known as arxcruz|ruck13:20
sean-k-mooneyefried: well im not sure that is true in all cacses13:20
alex_xuyea, that makes sense13:20
efriedBecause we already know the vgpu stuff is "working" (other than the race condition"13:20
efried)13:20
sean-k-mooneythat the virt driver does not need to do anything13:20
efriedsean-k-mooney: That's the point, though13:20
efriedthe virt driver gets to decide what all it needs to do13:20
efriedthe RT cannot (and should not need to) know that.13:20
sean-k-mooneybut the RT would need to know about numa affintiy and other constrtits13:21
efriedE.g. this would be a great time to kick off cyborg fpga programming.13:21
kashyapAnyone from Ubuntu / Debian packaging here?13:21
kashyapWe need some packaging work done in Debian & Ubuntu (I did it in Fedora) for the firmware packages.13:22
* kashyap will write a short email to the list, with an update and an example of what's required.13:22
efriedkashyap: coreycb is who mriedem said was his go-to for that13:22
alex_xusean-k-mooney: in the future the placement will know about the numa affinity13:22
kashyapefried: Noted13:23
sean-k-mooneyyes but it doesnte right now13:23
kashyapcoreycb: Hi, let me know when you have a block of 15 minutes to chat about some packaging work.13:23
efriedright, the fact that the RT has to know about NUMA affinity today is a bastardization13:23
sean-k-mooneyefried: not really13:23
efriedsean-k-mooney: remember, I come from a world where libvirt isn't the only virt driver in existence :P13:23
sean-k-mooneysure but that does not mean that all legacy systems are bad13:24
coreycbkashyap: can you point me to the source?13:24
efriedDidn't say that at all.13:24
efriedNUMA affinity is simply Not A Thing in pvm. So the fact that all that logic is in the RT is kind of incestuous from that perspective.13:24
sean-k-mooneyhyperv support numa affintiy13:25
sean-k-mooneyalthough i dont know if they use the RT for that13:25
kashyapcoreycb: Hi, see my Fedora PullRequest here: https://src.fedoraproject.org/rpms/edk2/pull-request/313:25
efriedmissing the point. "Give my VM 5 VCPU" is universal. "NUMA nodes" is not.13:25
kashyapcoreycb: It is essentially to ship JSON  "firmware descriptor" files.13:26
sean-k-mooneyand PVM systems still have non umiform memory access unless the hardware has only one memory contoler13:26
sean-k-mooneythey jsut dont expose it13:26
kashyapcoreycb: My commit message contains all the details.  I'll actually write an e-mail to 'openstack-discuss' list, perhaps13:26
efriedI've mostly retired this soapbox since leaving PowerVM, but it's still an issue.13:26
kashyapcoreycb: As SUSE also needs to the packaging work.  (They're aware of it; I informed them in Denver.)13:27
sean-k-mooneyya i know it should be optional13:27
sean-k-mooneyand not enforced on driver that dont care13:27
efriedyes, that's exactly the point. PowerVM systems don't (need to) expose NUMA-isms.13:27
coreycbkashyap: ok so they're part of qemu source?13:27
*** jmlowe has joined #openstack-nova13:27
efriedright; and it's not much of a comfort that drivers that don't care can "just ignore" those code paths13:27
kashyapcoreycb: Yes.  Currently in Git.  Will be part of 4.1 -- due in Auguest.13:27
efriedthat doesn't always work13:27
kashyap(As noted in the commit message.)13:27
efriedlike the convolutions that were necessary to make sure the sysfs code paths didn't get activated on PowerVM systems when doing PCI passthrough.13:28
sean-k-mooneyefried: anyway old argment we are changing this eventually13:28
coreycbkashyap: i'll try to sync you up with cpaelzer. he does our qemu/libvirt packaging.13:28
sean-k-mooneywell we were not allowed to make those systems only work for libvirt13:28
sean-k-mooneysince virt driver are not allowed created db tables13:28
kashyapcoreycb: "Our"?  I'm not sure you're of Ubuntu or Debian or...13:29
coreycbkashyap: ubuntu13:29
*** luksky11 has joined #openstack-nova13:29
sean-k-mooneyif the libvirt driver was allowed to have its own db table like neturon allows its ml2 driver to do then libvirt would have had its own RT13:29
coreycbkashyap: well we contribute to both though13:29
sean-k-mooneyanyway brb13:30
kashyapcoreycb: (Nod)13:30
alex_xuefried: sean-k-mooney so the virt_driver.claim_for_instance/unclaim_for_instance still makes sense?13:30
*** BjoernT has joined #openstack-nova13:31
efriedalex_xu: sean-k-mooney: This is an interesting point. Whatever tracking the virt driver is doing (in memory) will need to be a) rebuilt when the compute service is restarted; and b) able to survive an instance reboot, because the same information will be necessary to rebuild the XML.13:31
efriedso what happens if we hard stop a VM and then restart the compute service and try to restart the VM?13:31
efriedwithout a real persistence mechanism, this may get flaky.13:31
dansmithlibvirt itself is a persistence mechanism13:32
*** rafaeldtinoco has joined #openstack-nova13:32
alex_xuyea, the compute service will sync some status I think13:33
efriedbut kind of like what we've done pushing allocations onto the virt driver via what is effectively a callback (update_provider_tree), the results of which the RT uses to push to hard storage (placement db), I wonder if this claiming could do the same thing.13:33
efriedsorry, s/allocations/inventories etc./13:33
efriedthe artifacts RT pushes to hard storage (in this case the nova db) would have to be opaque to the RT.13:34
alex_xuthat claim is about specific device, the placement doesn't care about13:34
efriedyes, I'm drawing a parallel13:34
efriedI'm saying: {the way placement is used as the persistence mechanism for provider inventories etc} is equivalent in principle to {the way the nova db would need to be used for claim/assignment information we're discussing}13:35
alex_xuactually we needn't persistent the claim and assigment in nova db, since libvirt persistent the info as dansmith said13:36
efriedYou mean via the domain XML?13:37
alex_xuyes, we read all assigned devices from the domain xml in the startup of compute service13:38
efriedBut we rebuild the domain XML when we hard reboot the instance, right?13:38
*** shilpasd has quit IRC13:38
efriedSo if the instance is hard stopped, and then we restart the compute service, we have to rebuild the domain XML from somewhere.13:38
*** lbragstad has joined #openstack-nova13:39
efriedor am I misunderstanding that lifecycle flow completely?13:39
alex_xuefried: if you just stop the instance, the xml still in libvirt. do you mean remove the domain from the libvirt?13:39
dansmithbut the xml doesn't go away until you rebuild it, so you can read it, then do your regeneration13:39
efriedokay, cool. Then I guess we're okay.13:39
efriedbut13:39
dansmithwe depend on libvirt keeping the domain xml for us in lots of cases13:40
efriedin this flow, the claim needs to happen before spawn is invoked13:40
efriedi.e. before we even start to build the domain xml13:40
efriedso the claim info will need to be stored temporarily somewhere else13:40
alex_xuyes13:40
*** irclogbot_3 has joined #openstack-nova13:40
alex_xuin memory13:40
efriedand then we can flush it once the instance is alive13:40
efriedokay, that wfm.13:41
stephenfinbauzas: (Because I don't have a deployment available to test this on) Can standard, non-admin users specify the availability zone an instance lands in?13:41
bauzasstephenfin: that's the whole purpose of AZs :)13:41
efriedalex_xu: Are you planning to work on this?13:41
alex_xuyes, I can take a look that13:41
stephenfinbauzas: okay, phew. So they can specify an AZ but not a destination host/node within that AZ, yeah?13:42
stephenfinBy default, that is13:42
bauzasstephenfin: to tell a way how to land somewhere you don't know but different from some other way you don't want13:42
*** mriedem has joined #openstack-nova13:42
*** belmoreira has quit IRC13:42
bauzasstephenfin: yeah it's borked, because the AZ hack is a terrible way13:42
* kashyap wonders if there is a mailing list tag for distros13:42
bauzasso, yeah, we're accepting users to set an AZ name but they're trampled if they use ':'13:42
stephenfinbauzas: yeah, that's why https://review.opendev.org/#/c/666767/ and its predecessor exists, presumably13:43
bauzasstephenfin: I need to take a look on those things13:43
bauzasefried: alex_xu: my meeting is done, wazzup ?13:43
stephenfinbauzas: I'm rewriting the AZ/host aggregate docs atm. They're not done but when they are, you'll be the first person I ping for reviews ;) https://review.opendev.org/#/c/667133/13:43
bauzas(well I have other meetings in 20 mins, so my time is counted :( )13:44
efriedbauzas: We were just discussing the race condition whereby two instances could try to assign the same vgpu13:44
efriedtalking about moving the vgpu "assignment" (though actually not the assignment, see below) into instance_claim13:44
bauzasefried: k, basically alex_xu made a good point13:44
bauzasefried: that's overthinking I feel13:44
bauzasstephenfin: ack, bump me with review requests tomorrow :)13:44
efriedtldr we're talking about adding claim_for_instance/unclaim_for_instance to the ComputeDriver interface, since only the specific virt driver can know how to identify the specific device, and what needs to be done to "reserve" it.13:45
*** belmoreira has joined #openstack-nova13:45
*** irclogbot_3 has quit IRC13:45
efriedIn the case of the libvirt driver for vgpus, it would be sufficient to mark it in an in-memory dict as belonging to the instance13:45
*** BjoernT_ has joined #openstack-nova13:46
efriedthen purge that dict entry during spawn, since that information can be gleaned from the domain XML thereafter.13:46
*** takashin has quit IRC13:46
efriedthis takes hypervisor-specific code out of the RT, which is ++13:46
efriedand fixes the race13:46
efriedand is reusable for other things like vpmem13:47
*** BjoernT has quit IRC13:47
bauzasefried: FWIW, this is somehow related to the spec you love :)13:47
efriedwhich, vgpu affinity?13:47
*** hamzy has joined #openstack-nova13:47
bauzasefried: correct, as we check things in instance_claim() already13:48
bauzasefried: and that's what I really want to amend for vGPUs13:48
*** whoami-rajat has quit IRC13:48
efriedyeah, basically "figure out which specific thingy on the system is going to be assigned to the instance for a particular unit of resource class in an allocation" should be the purview of the virt driver.13:48
bauzasas I said, the vGPU weigher and the object update aren't necessary13:49
efriedbecause only the virt driver has a view to "specific thingy on the system"13:49
bauzassec, giving you a link13:49
* efried awaits link13:49
sean-k-mooneybauzas: its even more related to the draft i wrote for that13:50
*** takashin has joined #openstack-nova13:52
sean-k-mooneyefried: i think bauzas means https://review.opendev.org/#/c/650963/9/specs/train/approved/libvirt-vgpu-numa-affinity.rst13:52
*** whoami-rajat has joined #openstack-nova13:52
bauzashttps://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2223 eventualls calls https://github.com/openstack/nova/blob/master/nova/compute/claims.py#L22013:53
bauzasefried: ^13:53
*** yaawang has joined #openstack-nova13:54
bauzasefried: so what you'd like is that the device assignment (ie. the mdev choice of https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6416) would be called by something close to https://github.com/openstack/nova/blob/master/nova/compute/claims.py#L220 ?13:55
bauzasif so, I'm not opposed to13:55
*** shilpasd has joined #openstack-nova13:55
bauzasbut xen needs substantial changes too13:56
*** artom has quit IRC13:56
*** udesale has joined #openstack-nova13:56
coreycbkashyap: cpaelzer added it to his 20.04 virt stack work. thanks for the heads up.13:57
efriedbauzas: I would like it if the hypervisor-specific aspects of all of that were in the virt driver -- but yes, to fix the race, the "mdev choice" needs to happen somewhere inside instance_claim.13:57
kashyapcoreycb: Cool.  I'll send a note to the list as well once I get around13:57
coreycbok13:57
kashyapAlso need to remind the SUSE folks.  And Debian13:57
efriedbauzas: I'll take this opportunity to point out that _test_numa_topology is far from hypervisor-agnostic.13:58
bauzasefried: that's what I said yes13:58
sean-k-mooneypersonally i think we should be calling calim_for_instacnce form the conductor by they way way before we get to the compute node after we select the host but before we call spawn13:58
bauzasoh13:58
bauzassurze13:58
bauzasbut that's a waaaay more complicated13:58
efriedbaby steps13:58
sean-k-mooneyefried: babysteps that predate placement13:58
sean-k-mooneywe keep putting that off13:58
*** artom has joined #openstack-nova13:59
sean-k-mooneyit prevents all the races that placemetn will eventurally solve13:59
* alex_xu begins to dream that beautiful day14:00
sean-k-mooneyif we do claim for instance in teh conductor via an rpc to the compute we nolonger race on any pci or numa resouce14:00
mriedemmeeting?14:00
artommeating.14:00
efriedoh, craaap14:00
alex_xuok, that is my fault :)14:01
*** ccamacho has quit IRC14:03
mnaseri'm really curious if there's a possible case where nova-compute gets a request an complains abut InstanceActionNotFound_Remote14:11
mnaserit means that the instane action was *not* created (or committed to db) when the rpc request was recieved ?14:13
*** donnyd_pto is now known as donnyd14:21
*** spatel has joined #openstack-nova14:23
*** spatel has quit IRC14:23
*** mkrai_ has joined #openstack-nova14:25
*** mkrai__ has joined #openstack-nova14:25
*** hongbin has joined #openstack-nova14:26
mriedemcheck the request id - the actions are keyed by request id so if the request id isn't the same for some reason it wouldn't be found14:27
mriedeme.g. a periodic task in compute using an admin context with a generated request id hitting some method that expects an action to exist14:28
*** spatel has joined #openstack-nova14:31
*** Luzi has quit IRC14:32
bauzasefried: FWIW https://review.opendev.org/#/c/552924/14:46
*** ociuhandu has quit IRC14:47
bauzasit needs a bit of caring ^14:47
efriedah, nice bauzas, thanks.14:47
bauzasmriedem: https://review.opendev.org/#/c/645520/35/doc/api_samples/servers/v2.74/server-create-req-with-only-host.json I thought we were no longer accepting to only provide a host field without also providing the node name ?14:52
bauzaslemme look at the spec14:52
openstackgerritMatt Riedemann proposed openstack/nova master: Convert nova-next to a zuul v3 job  https://review.opendev.org/67019614:52
bauzasmriedem: hell, yeah, I already had that concern https://review.opendev.org/#/c/645458/18/specs/train/approved/add-host-and-hypervisor-hostname-flag-to-create-server.rst@12514:53
mriedembauzas: not sure what you're talking about14:54
bauzasmriedem: asking a destination by only the 'host' field14:54
mriedemso what? for non-ironic the host == hypervisor_hostname14:55
mriedemso why require the user to specify both?14:55
mriedemthat's just shitty ux imo14:55
bauzasmriedem: I'm all good with only providing the node name14:55
bauzaswhat I'm concerned is by only asking for a service name14:55
bauzasand depending on the virt driver, the service name can be different from the node name14:56
mriedemonly for ironic, right?14:56
bauzasI don't recall which one specifically14:56
mriedemif you're using kvm, requesting the server land on a particular host is the same as asking that it land on a given node since they are the same thing14:57
mriedemif you're using ironic, you can ask that it land on a particular compute service host meaning it will use a particular ironic cluster, you don't care which node,14:57
*** awalende has quit IRC14:57
mriedemor you can ask for a node and we'll lookup the host14:57
mriedemor you can ask for both if you know exactly where it goes14:57
mriedemas you'd do today for ironic14:58
mriedemwith the forced stuff for the JsonFilter14:58
mriedemquery hint14:58
*** awalende has joined #openstack-nova14:58
sean-k-mooneybauzas: we still hit the schdler so if we just pass the service name the schduler could chose a host managed by that ironic compute service14:59
sean-k-mooneyand ya i know that the hyperviors hosts can move between teh compute service but its proably still makes sense14:59
mriedemi really really don't want to encode/enforce some dumb "you have to specify both host and node because of ironic" thing in the api15:00
bauzasI just feel we're regressing with https://review.opendev.org/#/c/645520/35/nova/scheduler/host_manager.py15:00
mriedemhow?15:00
sean-k-mooneyoh and mriedem already said that above :)15:00
*** tbachman has quit IRC15:01
*** lyarwood has quit IRC15:01
*** kenperkins has joined #openstack-nova15:03
kenperkinscan someone point me to where in the instance create codepath the password gets generated when not provided?15:03
*** awalende has quit IRC15:04
sean-k-mooneydo we always generate one?15:04
sean-k-mooneyi assumed not15:04
kenperkinsif we don't where does it come from?15:05
bauzasmriedem: actually, if we need to keep the same UX as it is now, nodename is optional15:05
kenperkinsmaybe it's baked into the image? <thinking>15:05
sean-k-mooneysome images have it backed in yes15:05
sean-k-mooneywe may always generate one but i was not expecting us too15:05
artomdonnyd, so, just to be clear, http://project.fortnebula.com/ is your personal project with your personal hardware, and... you're the sole sysadmin for it?15:06
donnydyep15:07
kenperkinssean-k-mooney https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L581 perhaps?15:07
kenperkinsthen here i think https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L120615:07
artomdonnyd, I'm worried about gate resources with a 1 person bottleneck :) For your sanity as much as cloud stability15:08
donnydartom: I am also the sole funder, maintainer, electrician, and cooling engineer15:08
donnydLOL15:08
*** tbachman has joined #openstack-nova15:08
sean-k-mooneykenperkins: https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.inject_password15:08
*** abhishekk has quit IRC15:08
sean-k-mooneykenperkins: by defualt we do not inject admin password in the vm wit libvirt15:09
artomdonnyd, the bus factor is *really* high with you :)15:09
kenperkinswhere is the default libvirt config in code? :D15:09
donnydWell openstack isn't very hard, so maintenance is pretty low15:09
sean-k-mooneyand its a libvirt specific option so other virt dirvres proably dont do this15:09
sean-k-mooneydonnyd: artom just be aware that we cant have any voting jobs without at least 2 providers15:10
mriedembauzas: hypervisor_hostname *is* optional in the new microversion15:10
mriedemas is host15:10
artomdonnyd, I'll trust you on that one - my experience has been with devstack mostly, and maintenance is definitely *not* low15:10
mriedemsame as it is with the zone:host:node hack15:10
mriedemyou can specify zone:host only, or zone::node only15:10
kenperkins@sean-k-mooney thx for the pointer re: libvirt config15:10
mriedemthe *only* difference is in how the scheduler processes it15:10
bauzasmriedem: yeah, that's what I just said15:10
artomsean-k-mooney, yeah, that's fine, just having a thing in experimental that we can run as-needed is a great 1st step15:11
sean-k-mooneykenperkins: https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L139 it there but we should not change it15:11
sean-k-mooneyin code that is15:11
bauzasforce_hosts supports only host, and evacuate/livemigrate do support only host too15:11
sean-k-mooneykenperkins: feel free to set it in you local config15:11
*** pcaruana has quit IRC15:11
mriedembauzas: force_hosts is only *hosts* because we also have the force_nodes field15:11
mriedemyou can also just have force_nodes15:11
mriedemb/c zone::node15:12
bauzasyup, and https://github.com/openstack/nova/blob/master/nova/compute/api.py#L958 allows you to only check the HostMapping15:12
mriedemi don't see what evacuate and live migrate really have to do with this, you can't force those anymore on the latest microversion15:12
*** _alastor1 has joined #openstack-nova15:12
mriedemand node doesn't really matter for those since migrations aren't supported for ironic anyway15:12
mriedemevacuate might be, but who knows if it actually works15:12
kenperkinswait, that contradicts a little bit sean-k-mooney; that link says that `False`: Allow the injection of an admin password for instance only at ``create`` and15:13
kenperkins``rebuild`` process.15:13
*** bbobrov has joined #openstack-nova15:13
kenperkinswhich reads like one value is only create/rebuild, the other is at any time15:13
*** shilpasd has quit IRC15:13
bauzasmriedem: well, we use the same internal object than livemig/evac https://review.opendev.org/#/c/645520/35/nova/compute/api.py@105615:13
mriedembauzas: yes i know15:13
mriedemand cold migrate15:13
donnydartom: Just lmk if you need anything custom, or a space to play15:14
mriedemand rebuild if we'd get https://review.opendev.org/#/c/650376/ in15:14
donnydjust an FYI I can only offer ipv6 access publically15:14
sean-k-mooneykenperkins: the docs say "False: Disallows the injection. Any via the REST API provided admin password will be silently ignored."15:14
artomdonnyd, flavors with 2 NUMA nodes. This implies nested virt.15:14
donnydI don't have a bunch of ipv4 address because they cost lots of the $$$15:14
sean-k-mooneykenperkins: https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L158-L15915:14
donnydI can work up anything needed15:15
*** ttsiouts has quit IRC15:15
donnydThis gear was for a big data project I was working on, so if its just going to sit there... might as well do something fun with it15:15
sean-k-mooneydonnyd: the power load form ci testing can be high15:16
*** ttsiouts has joined #openstack-nova15:16
artomdonnyd, so, being blunt, is the gear availability "stable"? Or there's a chance that it'll get repurposed/offlined at some point in the future?15:16
artomI realize we always have that doubt with any nodepool provider15:17
artomBut it seems it'll be higher with 1 dude than, say, Vexxhost15:17
artomdonnyd, don't get me wrong, I'm genuinely grateful that you're doing this, and frankly that no other company has stepped up before (including my own)15:17
artom*and frankly angry15:18
donnydWell we started small at 10 instances, and from what I can measure (which is quite a lot) it seemed to me to be about 150W per 10 instances so about 1500W at scale15:18
donnydbut we will go slow and test to see what is sustainable15:18
bauzasmriedem: my only concern is that we don't replicate the same logic than in evac/rebuild/livemig and set the host field on the Destination object if not provided like in https://github.com/openstack/nova/blob/master/nova/compute/api.py#L462715:18
bauzasthat's why I can regression something like https://review.opendev.org/#/c/645520/35/nova/scheduler/host_manager.py15:18
mriedemthat happens in the scheduler15:19
sean-k-mooneyartom: well intel ran an nfv ci for 4 years15:19
sean-k-mooneyit should be comming back later this year15:19
mriedembauzas: see resources_from_request_spec15:19
artomsean-k-mooney, past tense being the key word there ;)15:19
mriedemhttps://review.opendev.org/#/c/645520/35/nova/scheduler/utils.py@52815:19
donnydAt some point in the future sure... but it will likely be when this gear is used up completely and no longer functional15:19
mriedembauzas: you haven't been around, but ^ handles that15:19
*** tbachman has quit IRC15:20
bauzasmriedem: thanks, just saw it15:20
*** tbachman has joined #openstack-nova15:20
bauzasokay, I'm all good then15:20
sean-k-mooneywell i left and it had already been outsouce + osic happend and the lab that hosted it got decomissioned so ya.15:20
*** BLZbubba has joined #openstack-nova15:21
BLZbubbahi guys, what is the proper way to switch the default nova acceleration from tcg to kvm?15:22
openstackgerritStephen Finucane proposed openstack/nova master: docs: Rewrite host aggregate, availability zone docs  https://review.opendev.org/66713315:22
openstackgerritStephen Finucane proposed openstack/nova master: tox: Keeping going with docs  https://review.opendev.org/67033215:22
sean-k-mooneyBLZbubba: set virt_type=kvm  in the [libivrt] section in the nova.conf15:23
sean-k-mooneythen restart the compute agent15:23
sean-k-mooneyand hard reboot any vms on the host15:23
*** gyee has joined #openstack-nova15:23
BLZbubbathank you, i couldn't quite get the right google search terms to find that one15:24
donnydWell I am just happy I can help in whatever way I can... and it's both professionally and personally fun for me15:24
sean-k-mooneyBLZbubba: https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.virt_type15:25
donnydLMK how I can help15:25
sean-k-mooneyBLZbubba: it should be defaulting to kvm by the way not the tcg backend15:27
*** udesale has quit IRC15:28
*** mlavalle has joined #openstack-nova15:29
*** takashin has left #openstack-nova15:30
BLZbubbasean-k-mooney: this is the centos el7 version, maybe they were going for compatibility out of the box or something; who knows.  the config had virt_type=qemu15:32
Zarahi! I'm trying to work out why user roles would affect speed of api calls; does anyone know where docs for that area would live? (I'm having this problem: https://ask.openstack.org/en/question/123025/nova-api-calls-slow-for-non-admin-users ; asked in #openstack but no responses, so this is my last hope :) )15:34
sean-k-mooneyBLZbubba: its proably your installer not centos that changed it15:35
mriedemstephenfin: i've dropped the -2s on the ec2 removal patches15:35
stephenfinmriedem: Cheers15:35
sean-k-mooneyZara: it proably resulting in addtional or more expencive calls to keystone to validate teh authtoken that is in the request has the correct roles15:36
*** dtantsur is now known as dtantsur|afk15:36
openstackgerritStephen Finucane proposed openstack/nova master: docs: Rewrite host aggregate, availability zone docs  https://review.opendev.org/66713315:36
*** mkrai__ has quit IRC15:39
*** mkrai_ has quit IRC15:39
*** kenperkins has quit IRC15:39
stephenfinbauzas: There's the AZ doc rework promised, if you care to bookmark for later https://review.opendev.org/#/c/667133/15:40
bauzasack15:40
*** helenafm has quit IRC15:43
*** maciejjozefczyk has quit IRC15:47
Zarasean-k-mooney: hm, it seems odd since keystone itself seems to work fast (the POST auth/tokens calls seem to be the same length; it's the GET /servers/detail that's slow for the different roles. I'd've thought the token posting would be slow. maybe a dodgy assumption)15:47
mriedemlisting servers is going to be slower for admins b/c the api returns more data15:51
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Convert nova-next to a zuul v3 job  https://review.opendev.org/67019615:51
mriedemalso depends on if you're using all_tenants filtering in the request15:51
stephenfingibi: Is my comment about docs here correct? https://review.opendev.org/#/c/657796/15:52
sean-k-mooneymriedem: well not jsut admins right. if you are uing custom roles to expose more data different roles could be slower depending on what is being returned for that role15:53
sean-k-mooneybut ya that is proably more likely the reason for the delta in performance15:53
mriedemsean-k-mooney: of course15:54
Zarait's the other way around, though; the member role is the slow one and the admin role is the fast one15:54
mriedemsounds like it's time to do some profiling15:55
*** lpetrut has quit IRC15:56
mriedemtssurya: can't we have some functional test on https://review.opendev.org/#/c/645611/ ?15:57
*** pcaruana has joined #openstack-nova15:57
mriedemefried: don't we have some rules about removing things from a runway slot if they've been in merge conflict for over a week and the author is not responsive?15:58
mriedem"The code author must be ready for quick iteration on the patch reviews and responding to review comments. The author will be consulted before moving the blueprint to a runway to make sure the next 2 weeks are suitable for quick iteration on the reviews. If the next 2 weeks are not suitable, the next blueprint in line will be tried and the deferred blueprint will maintain its place in line."15:59
efriedmriedem: if not, we should.15:59
mriedemok i'm going to remove the sev stuff15:59
tssuryamriedem: hmm I guess we could, I'll add some using your fake driver suggestion15:59
efriedmriedem: I've poked aspiers a couple of times about the merge conflict, so yeah.15:59
efriedthanks15:59
sean-k-mooneymriedem: i think in general if the authour is not responcive that is enough to kick it15:59
sean-k-mooneyassuming it has -1 form a core15:59
tssuryaand I guess I have to bump microversion16:00
sean-k-mooneye.g. it need to be reworked but no active engagment form the owner16:00
*** belmoreira has quit IRC16:03
*** francoisp has quit IRC16:04
*** altlogbot_1 has joined #openstack-nova16:05
*** francoisp has joined #openstack-nova16:06
*** altlogbot_1 has quit IRC16:07
*** jmlowe has quit IRC16:08
*** ttsiouts has quit IRC16:14
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Convert nova-next to a zuul v3 job  https://review.opendev.org/67019616:15
*** tssurya has quit IRC16:18
*** luksky11 has quit IRC16:19
*** factor has quit IRC16:20
*** rpittau is now known as rpittau|adk16:20
*** rpittau|adk is now known as rpittau|afk16:20
mriedemartom: pro tip, if rebasing https://review.opendev.org/#/c/667177/ is not necessary, don't do it16:21
sean-k-mooneymriedem: gerrit need a diff diff setting16:21
*** spatel has quit IRC16:22
sean-k-mooneye.g. generate teh diff for the old patch against old base + new patch against new base and display the diff of those two diff per file16:22
sean-k-mooneyaka the eye ball diff we currently do but automated16:23
*** ivve has quit IRC16:23
melwittyeah, been wanting that to exist for years. does git-review support something like that locally? I keep forgetting16:24
sean-k-mooneynot that i know of but it could16:25
sean-k-mooneya 4 way diff is not that uncommon a thing16:25
Zara(thanks for the suggestions so far btw; I disappeared to stare at the output of `nova list --debug` :) )16:26
dansmithgit review does have a thing16:27
artommriedem, I know, not sure what happened16:31
artomI guess I was careless16:32
artomI must have `git rebase -i` to edit that middle patch, and forgotten that I'd updated the remote?16:33
* artom relocates for a bit16:33
mriedemgit review -R16:33
*** davidsha has quit IRC16:33
artomAha, noted16:33
*** tesseract has quit IRC16:36
*** artom has quit IRC16:38
*** mlavalle has quit IRC16:40
openstackgerritDustin Cowles proposed openstack/nova master: Introduces SDK to IronicDriver and uses for node.get  https://review.opendev.org/64289916:42
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for node.list  https://review.opendev.org/65602716:42
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for validating instance and node  https://review.opendev.org/65602816:42
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for setting instance id  https://review.opendev.org/65969016:42
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for add/remove instance info from node  https://review.opendev.org/65969116:42
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for getting network metadata from node  https://review.opendev.org/67021316:42
*** altlogbot_3 has joined #openstack-nova16:45
efriedmriedem: artom: or in .gitconfig, so you don't have to remember -R each time:16:45
efried[gitreview]16:45
efriedrebase = false16:45
melwittmriedem: do you know if the add/remove security group to/from instance API is a candidate for deprecation? was just looking at this abandoned patch after noticing the bug in launchpad https://review.opendev.org/53551016:46
mriedemefried: i don't personally want it in config since i make the decision each time16:46
mriedemmelwitt: i want to say it wasn't in https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/deprecate-api-proxies.html because it's an operation on the server which is not deprecated16:48
mriedemeven if it's a proxy to neutron16:48
mriedembut we're not very consistent about that b/c the floating IP things in https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/deprecate-multinic-proxy-api.html are similar16:49
*** altlogbot_3 has quit IRC16:49
melwittmriedem: yeah, was thinking similar. at first I was comparing to attach interface but that's different bc you can't do that without nova. whereas it looks like you could do the add/remove secgroup to port without nova16:49
mriedemaddFloatingIP and removeFloatingIP would be in the same group as add/removeSecurityGroup on a server16:49
melwittok, yeah. just wanted to ask bc the patch was abandoned on that basis (the potential for deprecation). otherwise, someone said they had tested the patch and it worked to fix the concurrent update problem16:51
*** psachin has quit IRC16:52
*** hemna has quit IRC17:04
*** d34dh0r53 has quit IRC17:05
*** artom has joined #openstack-nova17:10
*** weshay is now known as weshay|rover17:12
*** ralonsoh has quit IRC17:17
*** factor has joined #openstack-nova17:23
*** altlogbot_2 has joined #openstack-nova17:23
*** altlogbot_2 has quit IRC17:25
*** hemna has joined #openstack-nova17:28
*** lbragstad has quit IRC17:30
*** fhalbach is now known as aram1s17:30
*** altlogbot_3 has joined #openstack-nova17:31
*** jmlowe has joined #openstack-nova17:34
*** altlogbot_3 has quit IRC17:35
*** altlogbot_2 has joined #openstack-nova17:37
*** tbachman has quit IRC17:39
*** tbachman has joined #openstack-nova17:40
*** altlogbot_2 has quit IRC17:41
*** d34dh0r53 has joined #openstack-nova17:42
*** altlogbot_0 has joined #openstack-nova17:43
*** altlogbot_0 has quit IRC17:45
*** tbachman has quit IRC17:46
*** tbachman has joined #openstack-nova17:48
*** hemna has quit IRC17:53
*** artom has quit IRC17:57
mriedemefried: i'm +2 on gibi's big heal_allocations change now https://review.opendev.org/#/c/637955/3518:04
efriedoh goodie18:05
mriedemi'm sure you can just rubber stamp it with no effort18:05
efriedI'm sure18:05
efriedbeen waiting for you to quit hammering at it before looking again18:05
efriedI'm sure it's nigh unrecognizable now.18:05
mriedemnot since you last looked on18:05
mriedem*no18:05
mriedemmore tests,18:06
mriedemand the rollback stuff was changed18:06
mriedemhe first tries to update ports before allocations and if the port updates fail or allocation update fails the port updates are rolled back18:06
efriedokay, all of that sounds familiar.18:07
efriedI'll hit it now.18:07
*** hemna has joined #openstack-nova18:08
*** ociuhandu has joined #openstack-nova18:10
*** hemna has quit IRC18:14
*** hemna has joined #openstack-nova18:16
mriedemi'm working on a fup patch for my nits18:18
*** hemna has quit IRC18:20
openstackgerritMatt Riedemann proposed openstack/nova master: Follow up for "nova-manage: heal port allocations"  https://review.opendev.org/67036118:21
*** tbachman has quit IRC18:26
*** tbachman has joined #openstack-nova18:28
openstackgerritMerged openstack/nova master: Add host and hypervisor_hostname flag to create server  https://review.opendev.org/64552018:35
*** ociuhandu has quit IRC18:42
*** luksky11 has joined #openstack-nova18:44
*** bnemec has quit IRC18:45
*** cdent has joined #openstack-nova18:46
*** bnemec has joined #openstack-nova18:47
*** derekh has quit IRC19:05
*** artom has joined #openstack-nova19:13
*** lbragstad has joined #openstack-nova19:21
*** irclogbot_0 has joined #openstack-nova19:29
*** irclogbot_0 has quit IRC19:33
*** bnemec has quit IRC19:38
*** altlogbot_3 has joined #openstack-nova19:39
*** hemna has joined #openstack-nova19:39
*** altlogbot_3 has quit IRC19:41
*** jistr has quit IRC19:43
*** jistr has joined #openstack-nova19:45
*** bnemec has joined #openstack-nova19:46
efriedmriedem: gonna need your help understanding a thing here...19:50
efriedneutron.update_port(uuid, body=body)19:51
efriedis this a patch-style update or a replace?19:51
efriedi.e. does it only change the fields that are present in the body?19:51
mriedemartom: sean-k-mooney: dansmith: https://review.opendev.org/#/c/667177/1020:01
mriedemefried: replace20:01
artomzomgies20:02
mriedemefried: are you worried about overwriting something in the binding profile during the rollback from the time we originally got the port?20:02
efriedmriedem: Actually I'm worried about blowing away the whole content of the port *except* the binding:profile['allocation'] when we're trying to set that guy.20:02
mriedemefried: wait,20:03
mriedemefried: link me to the line20:03
efriedmriedem: yes, sec.20:03
mriedembut we do port binding updates like this in the neutronv2/api code as well20:03
*** jistr has quit IRC20:03
efriedmriedem: https://review.opendev.org/#/c/637955/35/nova/cmd/manage.py@1896 and continuation https://review.opendev.org/#/c/637955/35/nova/cmd/manage.py@192620:04
*** jistr has joined #openstack-nova20:05
melwittI didn't think it's like placement where anything not in the payload will get "erased" like a replace20:05
efriedwell, there's a bug somewhere then. Because either we blow away everything but the allocation on the initial pass, or we do nothing on the rollback.20:05
efriedbut mriedem yes indeed, I see port updates in neutronv2/api.py which are similar in spirit.20:06
melwitthttps://developer.openstack.org/api-ref/network/v2/?expanded=update-port-detail#update-port20:07
efriedmelwitt: I read that; are you seeing something in there that implies "partial update"?20:08
efried(I admit I didn't scrutinize it)20:08
mriedemefried: agree that https://review.opendev.org/#/c/637955/35/nova/cmd/manage.py@1896 looks like trouble20:08
mriedemhttps://developer.openstack.org/api-ref/network/v2/index.html?expanded=update-port-detail#revisions20:08
mriedemneutron does have revisions and an If-Match header20:08
mriedemlike generations in placement and etags20:09
mriedemanyway, that's more about what i thought you were going to bring up20:09
efriedI guess I would sort of hope you're not effing out of band with whatever ports you're trying to heal20:10
efriedbut yeah, it would be nice to handle generations too.20:10
mriedemlooking at where this is used https://github.com/openstack/nova/blob/ff0feed25d56c8ccd2298d5b5b82e636880fa986/nova/network/neutronv2/api.py#L9220:11
mriedemit looks like we only ever modify the full binding:profile and then send back our updates20:11
mriedemnot just pieces of it20:11
efriedso like, update_port knows to replace the thing for the top-level key you're sending, but doesn't go deeper?20:12
mriedemi would assume that the neutron API takes the value for whatever key in the PUT /ports/{port_id} request and replaces the value, not parts of the value20:12
efriedin which case the second one (rollback) is fine, but the first one is broken?20:12
mriedemit would assume so20:12
*** irclogbot_2 has joined #openstack-nova20:13
efried"whatever key in the PUT request" -- the key that's in there is 'port'.20:13
efriedyou mean the one under 'port'?20:13
mriedemyes20:13
efriedokay20:13
mriedemkeys in the port resource body20:13
efriedokay, so the first one is borked. I shall -1 accordingly. Thanks.20:14
*** irclogbot_2 has quit IRC20:16
cdentall this fiddling suggests some kind of heal integration test would be a nice thing20:21
cdentif one could be conceived20:21
efriedI think mriedem wrote one recently. Though I sort of doubt it went anywhere near this deep.20:22
mriedemgibi has a patch for that eventually20:22
mriedemfiddle me timbers20:22
efriedcdent: https://review.opendev.org/#/c/667994/20:22
mriedemhttps://review.opendev.org/#/c/669879/20:22
mriedemdrats20:22
efrieddifferent patches20:23
mriedemoh right, gibi's builds on mine20:23
cdentyeah, the depth is apparently not quite depthy?20:23
efriedcdent: look at gibi's followon, it does a little better20:24
mriedemi didn't dig into his actual test changes20:24
mriedemif i can get https://review.opendev.org/#/c/670196/ then eventually we could break apart the post_test_hook mega script into a smaller series of exercises20:24
mriedemso it's more manageable20:24
cdentthat would be nice20:25
cdentgibi's follow does look like an improvement.20:25
efriedgood call cdent. I've commented accordingly in gibi's patch.20:26
* cdent isn't sure what he called20:26
cdenti've been on the hook this week for a bunch of internal bug handling, and omg, i can't even20:27
cdenteverything is horrible, everywhere20:27
cdenti had a nice afternoon fishing, though20:27
efriedlike, fishing in the water for fish?20:27
efriedor something job-related that's virtually like fishing?20:28
efried(i.e. excruciatingly boring and unrewarding)20:28
cdenthttps://tank-binaries.s3.amazonaws.com/08e47f8678ed462d95e5a273d927c77a.jpe20:30
cdentsister's sister's family down for the week, invited for some deep sea fishing20:30
cdentthat was my dinner20:30
*** dklyle has joined #openstack-nova20:31
*** pcaruana has quit IRC20:31
*** igordc has joined #openstack-nova20:32
melwittefried: sorry, I missed your earlier message bc I guess my znc server disconnected.. I was referring to the wording like, "replaces the fixed_ip attribute when you specify it in the request body" which I took to mean it will replace fixed_ip if you specify it in the body but will not erase the fixed_ip if the field is not specified in the request body20:34
*** BjoernT_ has quit IRC20:39
*** whoami-rajat has quit IRC20:48
openstackgerritEric Fried proposed openstack/os-resource-classes master: Propose FPGA and PGPU resource classes  https://review.opendev.org/65746420:56
*** hamzy has quit IRC20:56
*** eharney has quit IRC20:57
efriedmelwitt: okay, cool, thanks for pointing that out.21:01
*** altlogbot_2 has joined #openstack-nova21:01
efried...though that makes it by no means obvious that similar behavior applies to the whole API.21:02
melwittyeah, I find the doc not comprehensive. was just guessing based on those bits21:03
melwittalso, I'm not advocating guessing. was just thinking aloud21:03
*** xek has quit IRC21:04
efriedIma open a doc bug for that21:04
efriedI just skimmed the front matter too, and there doesn't appear to be anything there.21:05
*** altlogbot_2 has quit IRC21:05
openstackgerritDustin Cowles proposed openstack/nova master: Introduces SDK to IronicDriver and uses for node.get  https://review.opendev.org/64289921:07
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for node.list  https://review.opendev.org/65602721:07
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for validating instance and node  https://review.opendev.org/65602821:07
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for setting instance id  https://review.opendev.org/65969021:07
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for add/remove instance info from node  https://review.opendev.org/65969121:07
openstackgerritDustin Cowles proposed openstack/nova master: Use SDK instead of ironicclient for getting network metadata from node  https://review.opendev.org/67021321:07
*** dklyle has quit IRC21:10
*** _erlon_ has quit IRC21:12
*** derekh has joined #openstack-nova21:13
*** derekh has quit IRC21:13
*** hongbin has quit IRC21:16
openstackgerritMatt Riedemann proposed openstack/nova master: Add functional test for resize crash compute restart revert  https://review.opendev.org/67039321:18
mriedemartom: sean-k-mooney: ^ weee21:18
efriedmelwitt, mriedem, cdent: FYI https://bugs.launchpad.net/neutron/+bug/183626321:23
openstackLaunchpad bug 1836263 in neutron "doc: PUT /ports/{port_id} updates selectively" [Undecided,New]21:23
*** irclogbot_2 has joined #openstack-nova21:23
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Convert nova-next to a zuul v3 job  https://review.opendev.org/67019621:24
* cdent leaves a totally useless comment for no other reason than truculence21:24
*** irclogbot_2 has quit IRC21:26
* mriedem mows21:26
*** mriedem has quit IRC21:26
cdentI read that as mowes, as in I'm gonna mowe some tasty chicken21:27
*** mlavalle has joined #openstack-nova21:29
*** irclogbot_0 has joined #openstack-nova21:29
*** irclogbot_0 has quit IRC21:32
*** cdent has quit IRC21:34
*** takashin has joined #openstack-nova21:47
*** tbachman has quit IRC21:50
*** tbachman has joined #openstack-nova22:06
*** hamzy has joined #openstack-nova22:07
*** altlogbot_3 has joined #openstack-nova22:19
*** irclogbot_3 has joined #openstack-nova22:19
*** tbachman has quit IRC22:20
*** altlogbot_3 has quit IRC22:23
*** irclogbot_3 has quit IRC22:24
*** betherly has joined #openstack-nova22:29
*** betherly has quit IRC22:34
*** luksky11 has quit IRC22:37
*** tkajinam has joined #openstack-nova22:52
*** lbragstad has quit IRC22:52
*** slaweq has quit IRC22:56
*** altlogbot_1 has joined #openstack-nova22:57
*** altlogbot_1 has quit IRC22:59
*** irclogbot_2 has joined #openstack-nova23:01
*** mlavalle has quit IRC23:03
*** _mlavalle_2 has joined #openstack-nova23:04
*** irclogbot_2 has quit IRC23:06
*** slaweq has joined #openstack-nova23:08
*** irclogbot_2 has joined #openstack-nova23:09
*** slaweq has quit IRC23:12
*** rcernin has joined #openstack-nova23:13
*** irclogbot_2 has quit IRC23:16
*** betherly has joined #openstack-nova23:23
*** betherly has quit IRC23:28
*** _mlavalle_2 has quit IRC23:37
*** betherly has joined #openstack-nova23:44
*** betherly has quit IRC23:49

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