Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-27
10:12:47 bauzas gibi: I work on a customer issue since 2 days, but sure, thanks
10:13:23 gibi bauzas: ack
11:04:45 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: [stable-only] Disable cinder-backup service in nova-next job https://review.opendev.org/690593
11:53:07 jangutter "bauzas: with a new IPv4 address", I read that minutes after reading https://arstechnica.com/gadgets/2019/11/europe-is-fresh-out-of-ipv4-addresses/
11:57:12 s10 Is it expected with https://review.opendev.org/#/q/I856a3032c83fc2f605d8c9b6e5aa3bcfa415f96a to get errors from the nova-compute on empty hosts like "Could not retrieve compute node resource provider" in code path "if not allocations:"? There are no allocations on hosts without instances, but resource provider exists.
12:11:01 s10 This error came only to the stable/rocky and stable/queens backports.
12:30:04 gibi s10: there is a bug and a fix proposed https://review.opendev.org/#/c/694581/
12:31:00 openstack Launchpad bug 1852759 in OpenStack Compute (nova) rocky "false error log at compute restart during error out stuck instances" [Low,In progress] - Assigned to Balazs Gibizer (balazs-gibizer)
12:31:00 gibi https://bugs.launchpad.net/nova/+bug/1852759
12:35:28 openstackgerrit Surya Seetharaman proposed openstack/nova master: Include removal of ephemeral backing files in the image cache manager https://review.opendev.org/689422
12:38:55 alex_xu tssurya: I'm not sure whether it is bug. I guess we only trigger that code path when nova side allow normal user can look up other user quota
12:40:09 alex_xu or keystone side policy shrink the authorization
12:40:18 tssurya alex_xu: we have a ML discussion here http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011184.html
12:40:28 tssurya would be great to hear your thoughts too
12:40:40 alex_xu tssurya: cool, i will check
12:55:03 openstackgerrit Balazs Gibizer proposed openstack/nova stable/rocky: Fix false ERROR message at compute restart https://review.opendev.org/694581
13:25:34 openstackgerrit Merged openstack/nova stable/stein: Join migration_context and flavor in Migration.instance https://review.opendev.org/696083
13:29:05 openstackgerrit Balazs Gibizer proposed openstack/nova master: Mask the token used to allow access to consoles https://review.opendev.org/220622
13:29:53 gibi melwitt, mriedem: I have updated ^^
13:32:15 openstackgerrit Brin Zhang proposed openstack/nova master: WIP: Support re-configure the delete_on_termination in server https://review.opendev.org/693828
14:43:52 efried gibi: you got a minute?
14:44:07 gibi efried: sure
14:44:17 efried I was looking at one of the cyborg patches last night
14:44:38 efried and it led me to looking at how bandwidth resource groups are being sent around
14:44:52 efried which I had never looked at before (I didn't review the original bw series for $reasons)
14:46:03 efried it looks like we're doing this thing where we populate RequestSpec.requested_resources...
14:46:31 gibi yepp
14:46:50 efried ...rather than just populating the ResourceRequest directly from the flavor/image
14:47:15 gibi the bandwidth request is coming from neutron not from flavor/image
14:47:19 efried which makes sense I guess because we need to get the... yes
14:48:01 efried but theoretically...
14:48:15 efried is there a reason we would need to populate requested_resources that way?
14:48:35 efried The difference being that requested_resources is going to be persisted in the RequestSpec as part of the Instance?
14:48:47 efried whereas the ResourceRequest is ephemeral?
14:49:03 gibi RequestSpec.requested_resources is ephemar too
14:49:15 gibi it is explicitly not persisted with the rest of the RequestSpec
14:49:48 gibi as far as I see ResourceRequest is only created right before we generate the a
14:49:54 gibi generate the a_c query
14:50:15 gibi while RequestSpec is created a lot earlier and also kept around a lot more
14:50:25 gibi e.g. sent down to the compute after scheduling
14:51:42 gibi I think this ML post is at least partially realted http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005920.html
14:53:05 efried ...then would there be any other reason to use RequestSpec.requested_resources instead?
14:53:05 efried https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/utils.py#L141-L143
14:53:05 efried gibi: I think what I'm asking (and maybe dansmith also could weigh in on this) is: In general if it's possible simply to use the flavor/image-meta to construct the request groups, like what these guys do:
14:53:26 dansmith efried: that was supposed to be a hack
14:53:53 efried dansmith: which was? the thing I linked?
14:53:55 dansmith because the requested_resources stuff wasn't ready for ... something
14:53:59 dansmith efried: doing it via the flavor
14:54:53 gibi efried: how do you use flavor/image-meta to construct the bandwidth related request groups?
14:55:14 efried gibi: oh, you wouldn't necessarily for bw, I don't know.
14:55:21 dansmith efried: https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/request_filter.py#L188
14:55:27 efried presumably that one is more involved, requires going back to neutron API etc.
14:56:01 efried dansmith: that makes it sound like using the *request spec* is the hacky one.
14:56:32 efried i.e. if we want to make sure we don't persist the "interpreted request groups", they're better off being put in the ResourceRequest constructor.
14:56:48 dansmith efried: it's using the *flavor* in the request_spec, instead of requested_resources
14:57:08 gibi efried: there is a gap, an itch, something. We have flavor to describe the nova related resource requst, we have the neutron port that describes the networking related resource request. And we need a common, internal place where we collect these. And that should be the RequestSpec. But today we have different ways to collect the resource request there
14:57:30 dansmith efried: there was a big thing when we merged that code, something that couldn't be done with requested_resources because of traits in the unnumbered group or some such, so that flavor-based approach was the workaround until that got resolved
14:57:38 dansmith efried: I'm sure mriedem remembers, but he's out
14:57:43 gibi we store a flavor in the RequestSpec but also a list of RequestGroups
14:58:40 gibi dansmith, efried: at the moment the requested_resources list does not have _all_ the request groups represented as resources reqeusted throigh the flavor are not added to the requested_resources
14:59:00 gibi so there is no unnumbered group there either
14:59:14 dansmith gibi: I don't remember the details, I could try to find that review
14:59:18 efried Right -- no matter what, ResourceRequest.__init__ is going to parse the flavor.
14:59:26 dansmith gibi: but we couldn't request the trait via requested_resources
14:59:58 gibi dansmith: yes, as you would need to add that to the unnumbered group but there is no unnumbered group in the requested_resources
15:00:24 dansmith ah okay I see
15:00:32 gibi efried: yes, at the end ResourceRequest.__init__ uses the flavor,image and the requested_resources to construc the a_c query
15:01:06 dansmith https://review.opendev.org/#/c/656413/2/nova/scheduler/request_filter.py@105
15:01:38 dansmith anyway, since the (ab)use of the flavor is only transient, not stored or exposed anywhere, it makes it fairly obscure what is going on, IMHO
15:01:55 gibi https://github.com/openstack/nova/blob/23995b4f9945aa242f6a9e7bd5bc700c27f31eb2/nova/objects/request_spec.py#L491
15:02:05 gibi here is a TODO that is hard to fix ^^
15:02:19 gibi as per my mail http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005920.html
15:02:51 openstackgerrit Merged openstack/nova stable/stein: Add --dry-run option to heal_allocations CLI https://review.opendev.org/693199
15:07:33 efried ---> *then* appends RequestSpec.requested_resources into the ResourceRequest
15:07:33 efried ---> calls ResourceRequest.__init__ with the RequestSpec, (that ignores the requested_resources and only processes the flavor/image)
15:07:33 efried --> from select_destinations we call resources_from_request_spec which
15:07:33 efried --> in _provision_instances we populate the RequestSpec.requested_resources, but only with part of the info available
15:07:33 efried it looks like
15:07:34 efried then we call GET /a_c
15:08:32 gibi yepp that sounds like it
15:08:53 efried _provision_instances happens on the conductor side?
15:09:28 gibi I think it happens at the nova-api side
15:09:52 efried sorry, yeah, this whole thing happens on the controller side, duh.
15:10:21 gibi it is called from nova.api.openstack.compute.servers.ServersController.create during boot
15:38:54 efried gibi, bauzas, stephenfin: do y'all want to have a meeting tomorrow or should I cancel? (US folk will be out)
15:39:07 stephenfin I don't have anything to bring up
15:39:15 gibi me neither but I can be present
15:39:38 efried let me see if anyone has put topics on the agenda. If not, I'll cancel.
15:40:55 efried it looks like shilpasd wants to talk about disk provider stuff.
15:41:08 gibi I reviewd the sharing disk spec today it looks good to me
15:41:19 gibi but somebody else should check at least the API impact part
15:41:20 stephenfin Because it's stuck?
15:41:29 stephenfin Maybe we can unstick it now
15:41:39 gibi the API impact part needs eyes I would say
15:41:39 efried I don't know. I saw gibi's review but haven't dug in
15:42:01 gibi bauzas was involved but he is busy downstream recently
15:42:08 efried If nothing else it gives her a scheduled time to talk to a couple of cores. So, gibi would you mind running that meeting?
15:42:19 gibi efried: I can do that, yes
15:42:26 efried thank you sir.
15:53:38 bauzas gibi: efried: thanks

Earlier   Later