Saturday, 2019-05-04

« Friday, 2019-05-03 Index Sunday, 2019-05-05 »
*** mriedem has quit IRC00:04
*** wwriverrat has quit IRC00:17
*** wwriverrat has joined #openstack-nova00:17
*** betherly has joined #openstack-nova00:41
*** betherly has quit IRC00:46
*** _alastor_ has quit IRC00:55
*** betherly has joined #openstack-nova01:03
*** wwriverrat has quit IRC01:04
*** betherly has quit IRC01:08
*** jiaopengju_1 has joined #openstack-nova01:10
*** jiaopengju_2 has quit IRC01:13
*** betherly has joined #openstack-nova01:24
*** tssurya has quit IRC01:27
*** gmann has quit IRC01:28
*** betherly has quit IRC01:29
*** lbragstad has quit IRC01:35
*** bauzas has quit IRC01:36
*** bauzas has joined #openstack-nova01:38
*** jiaopengju_2 has joined #openstack-nova02:02
*** jiaopengju_1 has quit IRC02:05
*** sapd1_x has joined #openstack-nova02:06
*** betherly has joined #openstack-nova02:07
*** awalende has joined #openstack-nova02:09
*** vdrok has quit IRC02:09
*** vdrok has joined #openstack-nova02:11
*** brinzhang has joined #openstack-nova02:11
*** betherly has quit IRC02:11
*** awalende has quit IRC02:13
openstackgerritMerged openstack/nova master: libvirt: Always disconnect volumes after libvirtError exceptions  https://review.opendev.org/65571202:22
*** whoami-rajat has quit IRC02:28
*** betherly has joined #openstack-nova02:38
*** betherly has quit IRC02:43
openstackgerritMerged openstack/nova master: Add nova-status upgrade check for minimum required cinder API version  https://review.opendev.org/64975903:05
*** betherly has joined #openstack-nova03:10
*** betherly has quit IRC03:14
*** hongbin has quit IRC03:20
*** jiaopengju_2 has quit IRC03:27
*** JamesBenson has joined #openstack-nova03:48
*** gmann has joined #openstack-nova04:13
*** JamesBenson has quit IRC04:28
*** pcaruana has joined #openstack-nova04:53
*** dakshina-ilangov has joined #openstack-nova05:07
*** hemna has joined #openstack-nova05:53
*** hemna has quit IRC05:58
*** _alastor_ has joined #openstack-nova06:09
*** JamesBenson has joined #openstack-nova06:29
*** JamesBenson has quit IRC06:33
*** _alastor_ has quit IRC06:42
*** hemna has joined #openstack-nova07:11
*** hemna has quit IRC07:16
*** dakshina-ilangov has quit IRC07:26
*** gmann has quit IRC08:02
*** awalende has joined #openstack-nova08:09
*** awalende has quit IRC08:14
*** igordc has quit IRC09:00
openstackgerritMerged openstack/nova master: Delete the placement code  https://review.opendev.org/61821509:16
*** whoami-rajat has joined #openstack-nova09:58
*** brinzhang has quit IRC10:49
*** gmann has joined #openstack-nova12:05
*** awalende has joined #openstack-nova12:09
*** KH-Jared has quit IRC12:10
*** awalende has quit IRC12:13
lyarwood\o/12:14
openstackgerritLee Yarwood proposed openstack/nova stable/stein: libvirt: Always disconnect volumes after libvirtError exceptions  https://review.opendev.org/65710912:23
openstackgerritLee Yarwood proposed openstack/nova stable/rocky: libvirt: Always disconnect volumes after libvirtError exceptions  https://review.opendev.org/65711012:23
openstackgerritLee Yarwood proposed openstack/nova stable/queens: libvirt: Always disconnect volumes after libvirtError exceptions  https://review.opendev.org/65711112:24
*** ccamacho has quit IRC12:30
*** sean-k-mooney has joined #openstack-nova12:41
*** awalende has joined #openstack-nova12:44
*** awalende has quit IRC12:48
openstackgerritsean mooney proposed openstack/nova master: Libvirt: add nfv job  https://review.opendev.org/65219712:58
openstackgerritsean mooney proposed openstack/nova master: Libvirt: add nfv job  https://review.opendev.org/65219713:21
openstackgerritMatt Riedemann proposed openstack/nova master: Enable cross-cell resize in the nova-multi-cell job  https://review.opendev.org/65665613:39
*** slaweq has joined #openstack-nova13:44
*** cfriesen has joined #openstack-nova14:05
*** efried has joined #openstack-nova14:10
*** altlogbot_2 has quit IRC14:10
*** jaypipes has left #openstack-nova14:10
*** jaypipes has quit IRC14:10
*** altlogbot_1 has joined #openstack-nova14:11
*** ricolin has joined #openstack-nova14:14
*** slaweq has quit IRC14:21
*** cfriesen has quit IRC14:26
*** _alastor_ has joined #openstack-nova14:29
*** sean-k-mooney has quit IRC14:29
*** slaweq has joined #openstack-nova14:32
*** mriedem has joined #openstack-nova14:32
*** gmann has quit IRC14:34
*** artom has joined #openstack-nova14:42
*** artom has quit IRC14:50
*** cdent has joined #openstack-nova14:54
*** sean-k-mooney has joined #openstack-nova14:54
*** artom has joined #openstack-nova14:55
*** wwriverrat has joined #openstack-nova14:57
mriedemrm_work: do you happen to know if oath needed to disable versioned notifications because of load on the MQ?14:58
*** ricolin has quit IRC14:58
*** ricolin has joined #openstack-nova14:59
*** lbragstad has joined #openstack-nova14:59
*** _alastor_ has quit IRC15:02
rm_workmriedem: Not positive but I can track down an answer for you easily enough ;)15:02
*** takashin has joined #openstack-nova15:02
*** cfriesen has joined #openstack-nova15:03
*** jangutter has joined #openstack-nova15:04
efriedcfriesen: I put a comment on the TPM patch, if you could take a look please. Unless I'm way off, may require a slight design change...15:07
mriedemthanks, wasn't sure who to ask15:07
*** lbragstad has quit IRC15:08
cfriesenefried: will take a look, thanks15:08
*** mlavalle has joined #openstack-nova15:10
*** wwriverrat has quit IRC15:11
*** ricolin has quit IRC15:13
lyarwoodstephenfin: https://review.rdoproject.org/r/#/c/16234/ - now that placement has gone.15:16
*** abhishekk has joined #openstack-nova15:16
*** bnemec has quit IRC15:17
lyarwoodstephenfin: cheers15:18
stephenfinlyarwood: Done15:18
efriedhttp://paste.openstack.org/raw/750586/ \o/15:18
*** _alastor_ has joined #openstack-nova15:20
openstackgerritMerged openstack/nova stable/stein: libvirt: Stop ignoring unknown libvirtError exceptions during volume attach  https://review.opendev.org/65704915:20
*** itlinux has quit IRC15:21
*** ricolin has joined #openstack-nova15:23
stephenfinefried: Only three patches standing between us and https://review.opendev.org/#/c/651306/8 too :)15:24
stephenfinAlso, CI /o\15:24
cdentefried and or mriedem : if you could register an opinion on whether I should do the same changes to all the functional jobs as https://review.opendev.org/#/c/657074/ that would be keen. No rush, simply that it is in flight.15:24
efriedstephenfin: yeah, I need to get back to that series (and a zillion others)15:25
cdentmoar delegation15:25
stephenfinack. It'll be back in a runway in a few weeks too15:25
efriedstephenfin: We've also got mox, privsep, and fake-libvirt cleanups which ought to be pretty much ready to go.15:25
stephenfinefried: Aye, though privsep is blocked by some comments from you that mikal hasn't address yet. I've been tackling the libvirt version enum cleanup ones from mriedem/kashyap already15:26
efriedoh, is that where I left privsep? cool15:27
efried:)15:27
*** bnemec has joined #openstack-nova15:27
*** ricolin has quit IRC15:27
efriedlooks like there are two I could push15:27
cfriesenefried: is the TPM version actually an issue?  given that it's emulated, all hosts can provide both TPM versions.  if the guest doesn't care, they can just ask for version 1.215:30
*** ricolin has joined #openstack-nova15:32
openstackgerritMerged openstack/nova stable/stein: libvirt: Avoid using os-brick encryptors when device_path isn't provided  https://review.opendev.org/65646215:35
*** ricolin has quit IRC15:36
rm_workmriedem: seems that we just never enabled notifications to begin with? ¯\_(ツ)_/¯15:40
rm_workwhere can I go look in our deployment tooling/config to see? :D15:40
rm_workwhat config option is it?15:41
mriedemrm_work: https://docs.openstack.org/nova/latest/configuration/config.html#notifications15:41
mriedemhttps://docs.openstack.org/nova/latest/configuration/config.html#notifications.notification_format specifically is what i'm looking for15:41
efriedcfriesen: Well, that's what I was asking you, I guess.15:42
mriedemalso this https://docs.openstack.org/nova/latest/configuration/config.html#oslo-messaging-notifications15:42
efriedcfriesen: Is it not the case that 2.0 is only available (emulatable) at certain versions of... things (qemu, libvirt, ...)?15:42
mriedemrm_work: notifications are enabled by default so maybe you're just generating them but not consuming them. to disable them, [oslo_messaging_notifications]/driver=noop15:43
efriedcfriesen: Basically: is the model the thing the user primarily cares about, or is the version?15:43
rm_workok, yeah i think that's likely15:44
openstackgerritLee Yarwood proposed openstack/nova stable/stein: Include all network devices in nova diagnostics  https://review.opendev.org/65712515:44
cfriesenefried: the version of libvirt that introduced TPM support adds support for both, and the TPM emulator supports both, so they should always be available.  I want to double-check with sean-k-mooney and kashyap but I think the initial concern would be the version as the two versions are quite different.15:46
efriedcfriesen: Oh, so the implementation (which I haven't gotten to yet, sorry) is using the version trait to effect the proper emulated version?15:48
efriedI guess if both versions are available, it would have to.15:48
cfriesenefried: yeah, the virt driver uses the version trait when generating the libvirt XML15:50
*** IvensZambrano has joined #openstack-nova15:51
efriedcfriesen: Okay. This was probably already discussed during design and I'm just late to the party. If hosts are advertising both versions, and users care about the version (are in fact locked to just one) then the current design is fine.15:51
mriedemsmcginnis: can you stop in the nova room to talk about openlab for 5 minutes?15:52
smcginnismriedem: Sure. Right now?15:52
mriedemif possible yeah15:52
mriedem20715:52
smcginnisOMW15:52
rm_workmriedem: seems we leave the default15:53
openstackgerritMatt Riedemann proposed openstack/nova master: Remove ComputeDriver.macs_for_instance method  https://review.opendev.org/65273715:53
openstackgerritMatt Riedemann proposed openstack/nova master: Remove macs kwarg from allocate_for_instance  https://review.opendev.org/65274915:53
mriedemrm_work: ok thanks15:54
mriedemsean-k-mooney: fyi several things are marked as experimental here https://docs.openstack.org/nova/latest/user/feature-classification.html#nfv-cloud-features15:55
mriedemhttps://docs.openstack.org/nova/latest/user/feature-classification.html#matrix-hpc15:55
mriedemhttps://docs.openstack.org/nova/latest/admin/huge-pages.html doesn't mention anything about being experimental or not tested15:55
*** sapd1_x has quit IRC15:57
cfriesenefried: A guest could have support for both versions, but unless they're specifically wanting 2.0 functionality then 1.2 should be fine.   You raised another issue though, moving operators away from speaking placement-ese in flavors/images.  Was that still an issue?  This was loosely modelled after the CPU features traits which are explicitly placement-ese.15:59
*** jbernard has quit IRC16:00
*** jbernard_ has joined #openstack-nova16:00
*** shuquan has joined #openstack-nova16:01
efriedcfriesen: It's not crucial to me that there be zero placement-ese in flavors. For simple things like this (requiring a single trait) it's fine, and is why we enabled support for it. It's complex placement-ese I want to avoid, instead having nova translate more operator-ese thingies to placement-ese.16:02
*** dtroyer has joined #openstack-nova16:02
cfriesenefried: makes sense.  I'll reply to your review comment with a summary for others who look at it.16:03
efriedcfriesen: Thank you sir.16:04
efriedcfriesen: Wait, "A guest could have support for both versions, but unless they're specifically wanting 2.0 functionality then 1.2 should be fine." <== so it's possible I only care about "give me TIS"?16:05
efriedIf that's the case, I'd still be in favor of making the trait optional (and set up by the request filter)16:06
openstackgerritLee Yarwood proposed openstack/nova master: WIP/DNM objects: Remove get_by_volume_id from BlockDeviceMapping  https://review.opendev.org/65712716:06
cfriesenefried: I think the guest support is different for TIS-on-1.2 vs TIS-on-2.0, but let me confirm with sean/kashyap16:07
*** ccamacho has joined #openstack-nova16:07
efriedcfriesen: Okay. None of this should be a huge delta in the impl/spec IIUC. If it turns out to be, I can live with it as is.16:08
kashyapcfriesen: Hi, what exactly you want to double-check?  You said "support for both" up-thread -- what are you referring to?16:08
* kashyap just signed into IRC; so still catching up w/ the scroll16:08
efriedkashyap: We're talking about the use cases for TPM. What is it that the operator cares about?16:08
efriedkashyap: Is "Give me TIS, I don't care if it's 1.2 or 2.0" a possibility?16:08
*** amodi has joined #openstack-nova16:08
cfriesenor do they care primarily about 1.2 vs 2.0, and then crb/tis if they're on 2.016:09
cfriesen(the spec was written assuming the second)16:09
kashyapefried: I don't know the answer to your second question -- need to go do some QEMU sluething for it16:09
*** lbragstad has joined #openstack-nova16:10
kashyapefried: The use cases for TPM, my limited understanding is that: they are a "big deal" recently:16:11
kashyapefried: The idea is that you have a tiny co-processor that can do crypto, but with company-specified policies.16:11
cfriesenkashyap: we can talk to sean-k-mooney, he doesn't seem to be paying attention to IRC. :)16:12
*** gmann has joined #openstack-nova16:12
efriedhe's paying attention to the room, like I should be :P16:13
*** ricolin has joined #openstack-nova16:13
kashyapefried: The use cases are disk encryption — e.g. MS's BitLocker, and "Clevis" (https://github.com/latchset/clevis), TLS key storage (openssl-engine-tpm), etc.16:13
kashyapefried: But I agree: there should be some clear write-up about "use cases from an OpenStack operator PoV"16:14
efriedkashyap: That would be nice, but I don't want to go crazy here, or block the work pending said writeup.16:15
efriedkashyap: Really the only thing I care about is whether there exists a use case where the VM doesn't care which version it gets.16:15
rm_workOn behalf of Octavia, we're a little confused about the "deleting a bound port" problem. johnsom is responding to the email right now, but I wonder if higher bandwidth discussion while a lot of us are here would make sense? I guess the email thread is fine otherwise16:15
*** lbragstad has quit IRC16:16
kashyapefried: Yeah, noted.  And yes, we should explicitly document the answer to your question.16:16
efriedrm_work: We have time on the agenda this afternoon if you'd like to get together16:17
*** eharney has joined #openstack-nova16:17
melwittrm_work: it means if you delete a port via the neutron REST API without first detaching it from the server it's attached to. if you do this and the port had QoS settings on it, nova will leak resources in placement (because there's no way for us to delete them if you didn't go through the detach port API or the delete server API)16:17
rm_workefried: Is this really a nova issue, or is it a neutron issue? Or is it totally cross-project?16:17
*** Luzi has joined #openstack-nova16:17
*** ricolin has quit IRC16:17
efriedrm_work: The leaked allocations are an issue in placement, which would affect subsequent nova boots with QoS-enabled neutron ports :)16:18
*** bnemec has quit IRC16:18
melwittrm_work: one of the takeaways from the discussion is that neutron can deprecate the ability to delete ports that are still attached (and avoid the issue). as you similarly can't delete a volume that is still attached in cinder16:19
efriedrm_work: It's really "always" been bad that you could do this (delete a port without considering what it's attached to), but it never mattered enough to do anything about. Now that the port is tied to real allocations in placement, it constitutes a leak and that kinda pushes it over the edge to where we should really do something.16:19
rm_workthe reason we do this directly is that there are several cases where a port detach in nova will simply fail to complete16:19
rm_workat which point, we can either orphan the entire port, or we can just delete it16:20
melwittI guess if a port detach in nova fails to complete, there's a bug that needs to be fixed16:20
rm_workexample A: nova compute node is down16:21
efriedWhen the detach fails to complete, is the instance still deleted?16:21
efriedIf the failure path still removes the allocations from placement, then it would be fine for you to force-delete the port.16:21
melwittif compute is down it would get cleaned up at the next run of the 'reap' periodic task on compute16:21
rm_workbut we can't wait that long16:22
rm_workthis is usually during time-sensitive failover operations16:22
melwittbut this is another case where it would help to add start_immediately=True to the reap periodic16:22
rm_worki think in all cases that we do a port delete the VM that it was attached to WILL be deleted anyway16:22
efriedactually, gibi_cape: doesn't the allocation go away whenever the instance is deleted? So the actual problem scenario is when we're detaching a port without deleting the instance?16:22
melwittthat way the first run would happen when compute first comes up16:22
rm_workbecause we only delete these ports when we are also deleting a VM16:22
melwittgotcha16:23
gibi_capeefried, rm_work: the leaked allocation is reclaimed when the instance is deleted16:23
rm_workunless I am missing a flow <_<16:23
efriedrm_work: If you're deleting the VM, and that succeeds, then we're good.16:23
rm_workok then so long as that is our workflow, we should not be hard-prevented from doing the port deletion16:23
efriedrm_work: So the way the proposed change would affect you is you would have to change the way you do that port detach.16:23
rm_workit comes down to a timing issue16:23
*** bnemec has joined #openstack-nova16:23
*** baderbuddy has joined #openstack-nova16:23
rm_workon our side, we're not going to wait for the detach to succeed in nova before we delete the port16:24
rm_workwe're going to move on with our cleanup16:24
rm_workwaiting would be problematic when we're in the middle of a time sensitive flow16:24
efriedrm_work: "not be hard-prevented" - right; but in order to do it after this change, you would have to change either code or policy (depending on how it's decided to implement)16:24
rm_workyeah, if it's policy, fine16:24
rm_workthat's doable (we're already a service admin account)16:24
rm_workif it's a code change, what does that mean -- changing to doing a detach first? because that's unlikely to happen16:25
openstackgerritgaryk proposed openstack/nova master: VMware: populate datastore refs at init  https://review.opendev.org/57468816:25
efriedChanging code to do two calls: 1) null the "owner" field, 2) delete op as you have it today16:25
rm_workespecially if you're telling us that it's really not a problem anyway given what we're doing in the big picture16:25
rm_workok, so just an owner null -- assuming there's no real delay in that, then that seems doable, one extra call isn't the end of the world16:26
efriedIf code change is the direction we go, nova will have to do the same thing. mriedem expressed not feeling great about that. If it's possible to do this with policy, I'm guessing that will be preferred all around.16:26
gibi_capedo we want to fix this-> < rm_work> the reason we do this directly is that there are several cases where a port detach in16:27
gibi_cape                 nova will simply fail to complete16:27
gibi_capedo we have some way to reproduce that?16:28
rm_worksee johnsom's just-sent email for a more complete example16:28
rm_worki believe it's reproducable yes16:28
gibi_caperm_work: looking16:28
*** eharney has quit IRC16:29
*** eharney has joined #openstack-nova16:29
*** ccamacho has quit IRC16:30
rm_workthe biggest one we can definitively reproduce would be a powered off compute host16:30
rm_workthis is a problem whether we are about to delete the port post-detach, or if we are going to re-use it16:31
rm_work(it's ESPECIALLY a problem if we want to re-use it)16:31
rm_workwe've seen scenarios where a compute host was powered off for 12-24 hours16:31
rm_workit's theoretically possible that it might NEVER come up -- and what would happen to our port in that case?16:31
efriedrm_work: Does the instance get deleted from the database?16:32
openstackgerritmelanie witt proposed openstack/nova master: Use run_immediately=True for _cleanup_running_deleted_instances  https://review.opendev.org/65713216:32
rm_workit sticks in "deleting" vm state16:32
efriedrm_work: But if the point is that this whole thing is centered around you wanting to delete the VM, and you're going to delete it as soon as that's possible, then you're fine.16:33
efriedThe proc/mem/disk resources are just as leaked as the bandwidth resources in this case where the VM is undeletable.16:34
rm_workthough what happens if we *do* need to delete the port?16:34
rm_workerr sorry, if we do need to re-use the port?16:34
rm_workit's the same bug, just unrelated to the placement-leakage issue16:34
gibi_caperm_work: how do you re-use the port when the compute is down?16:34
rm_work(since you were asking about the specific nova bug)16:34
rm_workmove it to another compute16:35
rm_workso the case would be if we are using one port as our main ingress (instead of AAP)16:35
rm_workso if a compute host is powered off, we need to move that port over to another working VM16:35
efriedgibi_cape: Do we reclaim the allocations when a port is detached?16:35
gibi_caperm_work: if nova is not involved in this move then nova cannot make sure that the resource needs of the port also moved16:35
rm_workbut a detach will just fail to complete16:35
gibi_capeefried: if the port is detached in nova then yes we delete the port allocation in placement16:36
rm_workso we can't reattach the port to a different VM16:36
efriedrm_work: Right, it sounds like this scenario is not possible.16:36
efriedYou can't detach it if you can't talk to the compute16:36
efrieddid I understand correcctly?16:36
rm_workok, so that's not a solvable issue in nova?16:36
rm_workwhat if that compute host never comes back up? in case of hardware failure, this is possible16:37
rm_workis that port gone forever?16:37
*** baderbuddy has quit IRC16:37
gibi_caperm_work: if the compute never comes up then the resoruce leak in placement is not relevant as nobody else could you the leaked resource16:38
mriedemzzzeek: sort of a random mysql uniqueness / primary key question for you when you have a sec16:38
cfriesennew etherpad: https://etherpad.openstack.org/p/nova-ptg-train-216:38
rm_workright, not really talking about the placement-specific issue anymore16:38
rm_workthis is about the bug that was behind our reasoning16:38
rm_workthere's multiple impacts on our side from the same bug16:38
rm_workone of them was that we just force-delete the port to handle cleanup on our side16:39
rm_workbut the other is that we necessarily lose the port16:39
*** panda has quit IRC16:41
gibi_caperm_work: I'm not fully understand what you really want to achieve with moving the bound port from one VM / compute to another. For me a neutron port feels like just a logical entity that easy to create / re-create16:41
melwittgibi_cape: they can't ever change IPs :)16:41
gibi_capemelwitt: thanks16:42
rm_workcorrect16:42
rm_workwe NEED to maintain the IP or we're sunk16:42
kashyapstephenfin: I saw your comment scroll-by, on removing the needless libvirt version constants: I have a half-baked branch with some WIP.  Or have you already posted something?16:44
kashyapstephenfin: Trying to ensure we're doing duplicating work :-)16:44
stephenfinkashyap: Nah, I'm not writing anything. Just reviewing your and mriedem's patches16:45
kashyapstephenfin: Ah, like that16:45
gibi_caperm_work: if the VM on the down compute recovers later how that VM will be recovered from networking perspective? On the compute side the vif is still attached, but the neutron port is moved and attached to another VM.16:45
kashyapstephenfin: All clear.  Thanks, more clean-ups coming to a Firefox tab near you16:45
rm_workgibi_cape: we don't care, that VM is going to be deleted anyway16:45
rm_workonce we move the port, we consider the old VM "dead" to us16:46
rm_workwe'll always be issuing a VM delete on it16:46
rm_workvery much cattle16:46
gibi_caperm_work: OK. then the policy thing could work. Octavia can do the port delete in neutron with the extra policy as Octavia makes sure the VM is deleted so the leaked resource is recovered by the VM delete16:47
rm_workI think that would be the best approach16:47
rm_workthough it WOULD be awesome if we could figure out a solution to the underlying nova "bug"16:47
rm_workI know you folks may not consider it a bug, but from our perspective, it sure seems that way16:47
rm_workif a detach would just ... "complete" even if the compute host is unreachable, it'd make us very happy :)16:48
gibi_caperm_work: would be nice to have a bug report on that or / and talk about this in the nova room16:48
rm_workok -- though i believe we've brought it up before and were told that was expected behaviour16:49
rm_workbut I suppose filing it officially would at least provide history for a decision even if it's still the same16:49
*** panda has joined #openstack-nova16:49
gibi_caperm_work: I don't have the historical context16:50
gibi_caperm_work: so I agree that written bug report would be nice16:50
*** wwriverrat has joined #openstack-nova16:51
*** wwriverrat has quit IRC16:51
openstackgerritChris Dent proposed openstack/nova master: Make nova-tox-functional-py36 reusable  https://review.opendev.org/65707416:51
rm_workwe'll make sure to write something up, hopefully today16:51
*** wwriverrat has joined #openstack-nova16:52
gibi_caperm_work: thanks16:52
mriedemsean-k-mooney: mnaser: i might have figured out a reason for the port binding update failure that rcolvin was hitting https://bugs.launchpad.net/nova/+bug/1822884/comments/2116:55
openstackLaunchpad bug 1822884 in OpenStack Compute (nova) "live migration fails due to port binding duplicate key entry in post_live_migrate" [Undecided,In progress] - Assigned to sean mooney (sean-k-mooney)16:55
*** whoami-rajat has quit IRC16:55
mriedemi have a recreate for it in my nova-multi-cell resize change16:55
gibi_caperm_work: replied on ML too16:57
rm_workyeah, that seems right to me17:03
shuquanrbd disks: convert from source format to raw https://review.opendev.org/#/c/640271/   https://review.openstack.org/#/c/642667/17:07
*** IvensZambrano has quit IRC17:08
*** cgoncalves has joined #openstack-nova17:09
openstackgerritBalazs Gibizer proposed openstack/nova master: Log when port resource is leaked during port delete  https://review.opendev.org/65707917:10
*** ralonsoh has joined #openstack-nova17:13
*** ricolin has joined #openstack-nova17:13
*** awalende has joined #openstack-nova17:17
*** awalende_ has joined #openstack-nova17:18
*** pcaruana has quit IRC17:18
*** wwriverrat has quit IRC17:19
*** awalende has quit IRC17:21
openstackgerritTushar Patil proposed openstack/nova-specs master: Support filtering of allocation_candidates by forbidden aggregates  https://review.opendev.org/60996017:25
kashyapefried: cfriesen; johnthetubaguy: Thanks, folks!17:27
*** ricolin has quit IRC17:28
cfriesencan anyone point me at what's breaking the nova-live-migration test for https://review.opendev.org/#/c/621646/ ?   I can't tell if it's an issue with my patch or a zuul issue.17:28
mriedemcfriesen: http://logs.openstack.org/46/621646/21/check/nova-live-migration/8a081f1/logs/devstacklog.txt.gz#_2019-05-02_22_32_53_98317:29
mriedemhttp://status.openstack.org/elastic-recheck/#182708317:29
*** shuquan has quit IRC17:30
cfriesenmriedem: thanks17:30
*** ricolin has joined #openstack-nova17:34
*** ralonsoh has quit IRC17:38
*** eharney has quit IRC17:39
openstackgerritMerged openstack/nova-specs master: Support filtering of allocation_candidates by forbidden aggregates  https://review.opendev.org/60996017:43
openstackgerritBalazs Gibizer proposed openstack/nova master: pull out functions from _heal_allocations_for_instance  https://review.opendev.org/65545717:47
openstackgerritBalazs Gibizer proposed openstack/nova master: reorder conditions in _heal_allocations_for_instance  https://review.opendev.org/65545817:47
openstackgerritBalazs Gibizer proposed openstack/nova master: Prepare _heal_allocations_for_instance for nested allocations  https://review.opendev.org/63795417:47
openstackgerritBalazs Gibizer proposed openstack/nova master: pull out put_allocation call from _heal_*  https://review.opendev.org/65545917:47
openstackgerritBalazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations  https://review.opendev.org/63795517:47
*** ricolin has quit IRC17:48
openstackgerritMerged openstack/nova master: Improve test coverage of nova.privsep.utils.  https://review.opendev.org/65528117:49
kashyapcfriesen: Do you know what johnthetubaguy meant by the phrase "fragment hypervisor"?17:49
openstackgerritDan Smith proposed openstack/nova master: Add image type request filter  https://review.opendev.org/65641317:49
openstackgerritDan Smith proposed openstack/nova master: Enable image type query support in nova-next  https://review.opendev.org/65690317:49
openstackgerritDan Smith proposed openstack/nova master: Add docs for image type support request filter  https://review.opendev.org/65702517:49
cfriesenkashyap: nope. :)17:51
openstackgerritStephen Finucane proposed openstack/nova master: docs: Rework the PCI passthrough guides  https://review.opendev.org/63524317:54
*** _alastor_ has quit IRC17:56
*** artom has quit IRC18:06
*** artom has joined #openstack-nova18:06
*** artom has quit IRC18:06
*** artom has joined #openstack-nova18:07
*** bnemec has quit IRC18:09
*** Luzi has quit IRC18:09
*** pcaruana has joined #openstack-nova18:10
*** cdent has quit IRC18:10
*** pcaruana has quit IRC18:10
*** abhishekk has quit IRC18:15
*** mlavalle has quit IRC18:20
*** slaweq has quit IRC18:21
*** awalende has joined #openstack-nova18:29
*** artom has quit IRC18:31
*** awalende_ has quit IRC18:31
*** mriedem has quit IRC18:31
sean-k-mooneydansmith: https://etherpad.openstack.org/p/nova-ptg-train-governance18:31
*** jangutter has quit IRC18:32
*** awalende has quit IRC18:33
*** takashin has quit IRC18:35
*** amodi has quit IRC18:35
*** jangutter has joined #openstack-nova18:36
*** ricolin has joined #openstack-nova18:37
*** cfriesen has quit IRC18:38
*** imacdonn has quit IRC18:38
*** imacdonn has joined #openstack-nova18:39
*** jangutter has quit IRC18:41
*** ricolin has quit IRC18:42
*** lbragstad has joined #openstack-nova18:44
*** bnemec has joined #openstack-nova18:51
*** cdent has joined #openstack-nova18:52
*** lbragstad has quit IRC19:11
*** dklyle has joined #openstack-nova19:13
*** takashin has joined #openstack-nova19:14
*** dklyle has quit IRC19:18
*** jangutter has joined #openstack-nova19:21
*** cfriesen has joined #openstack-nova19:23
*** gmann has quit IRC19:42
*** jangutter has quit IRC19:57
*** takashin has quit IRC20:00
*** sean-k-mooney has quit IRC20:02
*** takashin has joined #openstack-nova20:03
*** cfriesen has quit IRC20:03
openstackgerritMerged openstack/nova stable/stein: libvirt: Always disconnect volumes after libvirtError exceptions  https://review.opendev.org/65710920:08
*** jangutter has joined #openstack-nova20:13
*** igordc has joined #openstack-nova20:17
*** jangutter has quit IRC20:17
*** slaweq has joined #openstack-nova20:26
openstackgerritMerged openstack/nova master: Add image type capability flags and trait conversions  https://review.opendev.org/65271020:32
*** awalende has joined #openstack-nova20:34
*** awalende has quit IRC20:38
*** wwriverrat has joined #openstack-nova20:52
*** wwriverrat has quit IRC20:52
*** wwriverrat has joined #openstack-nova20:53
*** altlogbot_1 has quit IRC20:56
*** artom has joined #openstack-nova20:58
*** altlogbot_1 has joined #openstack-nova20:59
*** altlogbot_1 has quit IRC21:04
*** altlogbot_1 has joined #openstack-nova21:05
*** slaweq has quit IRC21:07
*** igordc has quit IRC21:07
*** igordc has joined #openstack-nova21:07
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8)  https://review.opendev.org/57531121:08
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9)  https://review.opendev.org/57558121:08
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (10)  https://review.opendev.org/57601721:09
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (11)  https://review.opendev.org/57601821:09
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (12)  https://review.opendev.org/57601921:09
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13)  https://review.opendev.org/57602021:09
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14)  https://review.opendev.org/57602721:10
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15)  https://review.opendev.org/57603121:10
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16)  https://review.opendev.org/57629921:10
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17)  https://review.opendev.org/57634421:10
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18)  https://review.opendev.org/57667321:11
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19)  https://review.opendev.org/57667621:11
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20)  https://review.opendev.org/57668921:11
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21)  https://review.opendev.org/57670921:11
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22)  https://review.opendev.org/57671221:12
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py  https://review.opendev.org/56615321:12
*** baderbuddy has joined #openstack-nova21:18
*** bnemec has quit IRC21:18
*** baderbuddy has quit IRC21:24
*** wwriverrat has quit IRC21:30
*** takashin has left #openstack-nova21:34
*** cdent has quit IRC21:37
*** bnemec has joined #openstack-nova21:38
*** artom has quit IRC21:43
*** sean-k-mooney has joined #openstack-nova22:07
*** awalende has joined #openstack-nova22:11
*** slaweq has joined #openstack-nova22:32
openstackgerritMerged openstack/nova master: Improve metadata performance  https://review.opendev.org/61543522:38
*** sean-k-mooney has quit IRC22:44
openstackgerritMerged openstack/nova stable/stein: Eventlet monkey patching should be as early as possible  https://review.opendev.org/64731022:49
*** awalende has quit IRC22:49
openstackgerritEric Fried proposed openstack/nova-specs master: Train Cycle Themes  https://review.opendev.org/65717123:30
*** efried has quit IRC23:40
*** ircuser-1 has quit IRC23:41
« Friday, 2019-05-03 Index Sunday, 2019-05-05 »

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