| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-07 | |||
| 12:52:19 | mdbooth_ | mriedem: And completely remove the need for the notification thing | |
| 12:53:11 | mriedem | right, so if i remove the libvirt stuff from the commit message are you good? | |
| 12:54:20 | mdbooth_ | mriedem: I wasn't that bothered about the commit message, tbh. | |
| 12:54:38 | mriedem | so what are we going to do to get you into this beautiful car today | |
| 12:54:45 | mdbooth | Hehe | |
| 12:54:53 | mriedem | i'll throw in the undercoat for free | |
| 12:55:15 | mdbooth | Can you gimme a minute to punt the other ping I just got to somebody else? | |
| 12:55:44 | mriedem | sure, i've heard artom is available | |
| 12:55:55 | mriedem | speaking of artom, http://status.openstack.org/elastic-recheck/#1775491 | |
| 12:58:10 | openstackgerrit | Jan Gutter proposed openstack/nova-specs master: Spec to implement vRouter HW offloads https://review.openstack.org/567148 | |
| 13:01:02 | mriedem | dansmith: are you going to propose a backport for this? https://review.openstack.org/#/c/572195/ | |
| 13:02:19 | jmccarthy | Not sure what is going on here, but I'm seeing this issue at the moment https://bugs.launchpad.net/kolla/+bug/1774409 | |
| 13:02:20 | openstack | Launchpad bug 1774409 in kolla "neutron_dhcp_agent accumulates zombie processes " [Undecided,New] | |
| 13:02:46 | jmccarthy | i.e. creating and deleting networks accumulates zombies .. any ideas ? | |
| 13:02:50 | mriedem | jmccarthy: better to ask in the #openstack-neutron channel? | |
| 13:03:04 | jmccarthy | mriedem: Oh ! I'll do that :) Thanks ! | |
| 13:05:11 | openstackgerrit | Jan Gutter proposed openstack/nova-specs master: Spec to implement vRouter HW offloads https://review.openstack.org/567148 | |
| 13:23:05 | openstackgerrit | Chris Dent proposed openstack/nova master: Use nova.db.api directly https://review.openstack.org/543262 | |
| 13:28:48 | mdbooth | mriedem: Related, but not strictly the same thing I think. I was checking how we end up unsetting the 'detaching' state and I came across this: | |
| 13:28:51 | mdbooth | http://git.openstack.org/cgit/openstack/cinder/tree/cinder/volume/api.py#n1567 | |
| 13:29:41 | dansmith | mriedem: yep | |
| 13:29:52 | mdbooth | In the tempest test, we swap one of the volumes, then we check if Nova still thinks that the other server is still attached to the original volume, which it apparently does | |
| 13:30:04 | mdbooth | However, I think this code might mean that *cinder* thinks it's not | |
| 13:30:54 | mdbooth | It looks like cinder is doing a detach(old)/attach(new) for all attachments, even though we only migrated one of them. | |
| 13:38:06 | mdbooth | However, the above would only be in the case of the direct nova call, because if it went via cinder there would be a migration record | |
| 13:43:41 | mriedem | mdbooth: that's only if nova calls that migration completion code | |
| 13:44:12 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5626 | |
| 13:44:29 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5661 | |
| 13:44:48 | mriedem | if the swap isn't initiated from cinder for a retype or volume migration, we don't call that callback method in cinder | |
| 13:53:11 | mdbooth | mriedem: Good point. I wonder where we unset that detaching state, then. | |
| 13:53:42 | mdbooth | ..we explicitly delete the attachment | |
| 13:56:04 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: Change consecutive build failure limit to a weigher https://review.openstack.org/573239 | |
| 13:56:43 | mriedem | mdbooth: i think when the attachment record is deleted http://git.openstack.org/cgit/openstack/cinder/tree/cinder/volume/api.py#n2188 | |
| 13:57:05 | mriedem | if there are no more attachments, the volume is available | |
| 13:57:13 | mriedem | if there are other attached attachments, the volume goes back to in-use | |
| 13:57:49 | mriedem | mordred: it's time that we need some API super users to peruse this spec https://review.openstack.org/#/c/557369/ - i'm going to put it on the ML too | |
| 13:58:07 | mriedem | mordred: what nova api should do when listing servers and we have down cells | |
| 14:02:16 | mordred | mriedem: I have it open to read | |
| 14:02:26 | mriedem | <3 | |
| 14:06:33 | openstackgerrit | Dan Smith proposed openstack/nova stable/pike: Change consecutive build failure limit to a weigher https://review.openstack.org/573248 | |
| 14:09:05 | mriedem | dansmith: we should backport https://review.openstack.org/#/c/569127/ to queens probably | |
| 14:09:16 | mriedem | it would help with your backport https://review.openstack.org/#/c/573239/ too | |
| 14:09:51 | dansmith | well I already fixed the conflict, but okay | |
| 14:10:58 | dansmith | I guess that means I have to do both of these over | |
| 14:11:29 | mriedem | the pike one shouldn't have any impact from that max attempts thing | |
| 14:11:31 | mriedem | since that was queens only | |
| 14:11:43 | dansmith | the hash will change | |
| 14:11:48 | dansmith | on the queens one | |
| 14:11:50 | mriedem | sure | |
| 14:14:25 | mriedem | you can use this for that max_attempts backport https://bugs.launchpad.net/nova/+bug/1775625 | |
| 14:14:27 | openstack | Launchpad bug 1775625 in OpenStack Compute (nova) queens "nova-scheduler calculates alternative hosts incorrectly" [Medium,Triaged] | |
| 14:14:27 | mriedem | for the paperwork | |
| 14:14:28 | efried | wtf dansmith this is like the second time this week you're online before 8. | |
| 14:15:07 | dansmith | efried: up at 6am every.single.day.dude. | |
| 14:17:20 | mdbooth | Does anything ever create RequestContext except n-api? | |
| 14:18:03 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: Change consecutive build failure limit to a weigher https://review.openstack.org/573239 | |
| 14:18:04 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: Fix interpretation of max_attempts for scheduling alternates https://review.openstack.org/573254 | |
| 14:18:13 | dansmith | mriedem: ^ does that make you happy? | |
| 14:18:45 | mdbooth | dansmith: happy seems like a stretch goal :) | |
| 14:19:32 | dansmith | mdbooth: it was a setup for him to say nothing makes him happy | |
| 14:19:47 | mdbooth | dansmith: And I ruined it... Sorry dude. | |
| 14:19:47 | mriedem | i'm currently unable to stand up in polite company | |
| 14:19:55 | dansmith | mriedem: lol | |
| 14:20:04 | dansmith | mriedem: too far. | |
| 14:20:06 | mdbooth | haha | |
| 14:20:15 | mriedem | hey, you threw the softball | |
| 14:21:31 | openstackgerrit | Dan Smith proposed openstack/nova stable/pike: Change consecutive build failure limit to a weigher https://review.openstack.org/573248 | |
| 14:33:29 | kashyap | Hi folks, when someone gets time, can anyone else comment on the 'params' dict thing here: https://review.openstack.org/#/c/567258/ | |
| 14:34:02 | kashyap | The "tests pass", etc. But I'm undecided on that single point. | |
| 14:37:50 | stephenfin | kashyap: I'd be inclined to agree too. However, if you want to keep it to a separate cleanup patch, I imagine that would be ok (and maybe better - it's beefy enough as-is) | |
| 14:39:06 | kashyap | stephenfin: Okay, good to know. Making an additional patch on top of it means, removing what I just added in this one. That doesn't sound so clean. | |
| 14:39:25 | kashyap | But yeah, I also didn't wanted to make this existing patch already too clumsy and big. | |
| 14:39:53 | stephenfin | kashyap: Your call :) | |
| 14:40:35 | kashyap | But I also don't want to forget the "keep changes relatively small and split up patches" to make reviewing easy. :-) | |
| 14:40:49 | kashyap | Okido, I'll work something out tomm. and post it. | |
| 14:40:52 | kashyap | Thanks for the comment. | |
| 14:44:03 | openstackgerrit | Chen proposed openstack/python-novaclient master: Remove PyPI downloads https://review.openstack.org/573278 | |
| 14:45:43 | mriedem | booya https://review.openstack.org/#/q/topic:remove_pypi_downloads+(status:open+OR+status:merged) | |
| 14:47:00 | openstackgerrit | Merged openstack/nova master: add mtu to libvirt xml for ethernet and bridge types https://review.openstack.org/553072 | |
| 14:52:12 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Add PENDING vm state https://review.openstack.org/554212 | |
| 15:00:13 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459 | |
| 15:28:58 | johnthetubaguy | bauzas looking at the comments you made on the rebuild cell0 instance spec: https://review.openstack.org/#/c/554218 | |
| 15:29:09 | johnthetubaguy | and gibi: ^ | |
| 15:29:21 | bauzas | yup ? | |
| 15:29:22 | johnthetubaguy | you make some great points, but not sure how we move things forward | |
| 15:29:58 | johnthetubaguy | I was wondering about data migrations, after adding a new field, is that needed? probably not till we want to bump the object version I guess? | |
| 15:30:24 | bauzas | johnthetubaguy: about the persisted networks you mean ? | |
| 15:32:59 | bauzas | johnthetubaguy: the online data migration you ask is for setting the field for the existing req_spec records, right? | |
| 15:33:17 | bauzas | johnthetubaguy: that's why I thought about a lazy-loadable attribute | |
| 15:33:38 | bauzas | because there are two things | |
| 15:34:05 | bauzas | 1/ the instance is being created but then not getting a compute, then going into cell0 | |
| 15:34:18 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Change consecutive build failure limit to a weigher https://review.openstack.org/573248 | |
| 15:34:20 | bauzas | so, then, we're sure, the requested_networks is good | |
| 15:34:44 | mriedem | dansmith: ^ updated the commit message to note the other difference in that backport | |
| 15:34:54 | bauzas | 2/ the instance is now rebuilded, so there are some new possible networks | |
| 15:35:02 | bauzas | then, the field could be stale | |
| 15:35:30 | bauzas | johnthetubaguy: but for the data migration just because of a new field, we don't need it | |
| 15:35:57 | johnthetubaguy | bauzas: yeah, I just went through a similar though process, I think its fine without the migration | |
| 15:36:07 | dansmith | mriedem: oh actually I didn't notice that got faulted in | |
| 15:36:19 | dansmith | not sure that's going to work as-is | |