| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-27 | |||
| 00:34:59 | openstackgerrit | Merged openstack/nova stable/rocky: Fix listing deleted servers with a marker https://review.opendev.org/690721 | |
| 00:35:20 | openstackgerrit | Merged openstack/nova stable/stein: Replace time.sleep(10) with service forced_down in tests https://review.opendev.org/696175 | |
| 00:43:23 | openstackgerrit | melanie witt proposed openstack/nova stable/rocky: Replace time.sleep(10) with service forced_down in tests https://review.opendev.org/696217 | |
| 01:07:09 | openstackgerrit | Merged openstack/nova master: zuul: Make functional job inherit from openstack parents https://review.opendev.org/688425 | |
| 01:07:15 | openstackgerrit | Merged openstack/nova master: zuul: Remove unnecessary 'tox_install_siblings' https://review.opendev.org/695235 | |
| 01:08:23 | openstackgerrit | Dustin Cowles proposed openstack/nova master: WIP: Provider Config File: Enable loading and merging of provider configs https://review.opendev.org/693460 | |
| 02:05:10 | openstackgerrit | melanie witt proposed openstack/nova stable/rocky: Replace time.sleep(10) with service forced_down in tests https://review.opendev.org/696217 | |
| 05:04:36 | openstackgerrit | jichenjc proposed openstack/nova master: libvirt: avoid cpu check at s390x arch https://review.opendev.org/696228 | |
| 06:47:24 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/694717 | |
| 08:51:11 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to allow live migration with ports https://review.opendev.org/696245 | |
| 08:51:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle multiple bindings https://review.opendev.org/696246 | |
| 08:51:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Do not mock setup net and migrate inst in NeutronFixture https://review.opendev.org/696247 | |
| 09:37:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove 'nova-network' binary https://review.opendev.org/686816 | |
| 09:37:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Blast most references to nova-network https://review.opendev.org/686817 | |
| 09:37:29 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove associate, disassociate network APIs https://review.opendev.org/686814 | |
| 09:37:29 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove references to nova-net service from tests https://review.opendev.org/686818 | |
| 09:38:47 | kashyap | stephenfin: Isn't 'dissociate' a real word, too? | |
| 09:39:00 | stephenfin | bauzas: Got time for a daily dose of nova-network removal fun? https://review.opendev.org/#/c/686817/ | |
| 09:39:41 | kashyap | stephenfin: He said elsewhere he's off for 10-ish minutes as he's changing IPs | |
| 09:40:30 | kashyap | (Okay, 'dissociate' and 'disassociate' are synonyms, as expected. No gradational difference.) | |
| 09:40:50 | stephenfin | ^ yeah, figured it would be a UK/US English thing | |
| 09:43:00 | bauzas | stephenfin: I can, once I figure out how to unbreak my internal network :) | |
| 10:05:24 | openstackgerrit | Edward Hope-Morley proposed openstack/nova stable/rocky: Force refresh instance info_cache during heal https://review.opendev.org/679271 | |
| 10:09:12 | bauzas | with a new IPv4 address | |
| 10:11:30 | gibi | bauzas: some feedback on https://review.opendev.org/#/c/670112/ but mosly it looks good. If you respin ping me and I will +2 it | |
| 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 | gibi | https://bugs.launchpad.net/nova/+bug/1852759 | |
| 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: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 | 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:05 | efried | https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/utils.py#L141-L143 | |
| 14:53:05 | efried | ...then would there be any other reason to use RequestSpec.requested_resources instead? | |
| 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 | it looks like | |
| 15:07:33 | efried | --> in _provision_instances we populate the RequestSpec.requested_resources, but only with part of the info available | |