| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-07 | |||
| 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 | mriedem | for the paperwork | |
| 14:14:27 | openstack | Launchpad bug 1775625 in OpenStack Compute (nova) queens "nova-scheduler calculates alternative hosts incorrectly" [Medium,Triaged] | |
| 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 | mriedem | i'm currently unable to stand up in polite company | |
| 14:19:47 | mdbooth | dansmith: And I ruined it... Sorry dude. | |
| 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 | |
| 15:36:25 | mriedem | we don't have requested_networks on request spec today, and gibi is adding them in but not persisting them for the bw based scheduling stuff | |
| 15:36:37 | johnthetubaguy | bauzas: so block_device_mapping, isn't it the same deal, its just the initial one in there? | |
| 15:36:51 | mriedem | bdms aren't in reqspec eithre | |
| 15:37:09 | mriedem | however, | |
| 15:37:13 | mriedem | i believe bdms get stored in cell0 o nfailure | |
| 15:37:13 | johnthetubaguy | so I keep getting build_request and request_spec mixed up maybe | |
| 15:37:20 | mriedem | build_request is gone once the instance is in a cell | |
| 15:37:33 | gibi | johnthetubaguy, mriedem: yes, as I want to avoid the situation when a later operation reads the requested_networks from the RequestSpec taht is stale | |
| 15:37:47 | johnthetubaguy | yeah, maybe build request is where we want this | |
| 15:38:07 | mriedem | https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L1074 | |
| 15:38:18 | mriedem | bdms get put into cell0 on failure so we can detach volumes when you delete the failed server | |
| 15:38:30 | mriedem | s/detach/unreserve/ | |
| 15:38:48 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1971 | |
| 15:38:59 | bauzas | the question is, can we discover the requested networks for existing req_spec records ? | |
| 15:39:13 | bauzas | we have the instance field, right? | |
| 15:39:16 | mriedem | requested networks are not persisted | |