| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-07 | |||
| 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 | |
| 15:39:17 | bauzas | oops | |
| 15:39:20 | bauzas | the instance record | |
| 15:39:38 | bauzas | mriedem: aren't we persisting the requested networks into the instance record ? | |
| 15:40:18 | mriedem | no | |
| 15:40:22 | mriedem | the info cache is in the instance | |
| 15:40:27 | mriedem | which is after you've allocated netowrks | |
| 15:40:28 | mriedem | o na host | |
| 15:40:49 | bauzas | if we aren't able to discover the networks, then https://review.openstack.org/#/c/554218/ needs to explain that for existing records, we should just rebuild the instance like if the user wasn't asking for networks | |
| 15:40:56 | bauzas | mriedem: gotcha | |
| 15:41:36 | mriedem | if we rebuild from cell0 ,we have to persist requested networks | |
| 15:41:40 | mriedem | otherwise you've changed the original user request | |
| 15:41:46 | mriedem | which you might as well just not support the feature | |
| 15:42:13 | mriedem | especially if i'm creating a server with 20 ports for NFV megaawesome | |
| 15:42:24 | bauzas | mriedem: sure | |
| 15:42:30 | gibi | mriedem: could we keep the BuildRequest in the db if the instance lands in cell0 and persist the networks there? | |
| 15:42:42 | bauzas | mriedem: but for existing instances, how can we know what the user asked ? | |
| 15:42:51 | bauzas | mriedem: if we haven't persisted that | |
| 15:43:09 | gibi | bauzas: port.device_id == instance.uuid | |
| 15:43:19 | bauzas | that's my question | |
| 15:43:32 | bauzas | and then a possible data migration | |
| 15:45:05 | mriedem | gibi: that fucks up a lot of logic in the api | |
| 15:45:22 | mriedem | build request needs to remain temporary until we pick a cell | |
| 15:45:29 | openstackgerrit | Curt Moore proposed openstack/nova-specs master: Add spec for downloading images via RBD https://review.openstack.org/572805 | |
| 15:45:44 | mriedem | bauzas: you'd likely have to persist the requested networks in the request spec | |
| 15:45:50 | mriedem | like everything else that comes in on the POST /servers request | |
| 15:46:05 | mriedem | except bdms and config drive and the other 50 things you can request when creating a server... | |
| 15:46:25 | mriedem | but that stuff gets stored on the instance, where as requested_networks don't | |