| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-14 | |||
| 08:48:23 | Kevin_Zheng | and it makes no sense to write all those, and I also considered making a function that takes in params, and generates a dict, but there are still many fields that varies, like exception name, message etc, I also check how ANY works, it is basically just delete it, so I guess the best way is to just delete it with a callback function, and it could also be used in other future tests if needed | |
| 08:48:30 | Kevin_Zheng | sure, thanks for the review. | |
| 09:01:52 | BlackDex | Hello there. I'm trying to get vmware to work with nova, but i'm not getting the networking part. And the docs i see on openstack.org arn't the helpfull | |
| 09:02:03 | BlackDex | someone here knows where i can look for more info? | |
| 09:02:44 | BlackDex | i already checked: https://docs.openstack.org/ocata/config-reference/compute/hypervisor-vmware.html#vmware-networking | |
| 09:20:09 | openstackgerrit | Shilpa Devharakar proposed openstack/python-novaclient master: Modify novaclient to support basic attributes https://review.openstack.org/572285 | |
| 09:43:29 | openstackgerrit | Alexandre arents proposed openstack/nova master: Preserve images_type of instance during live migration https://review.openstack.org/570528 | |
| 10:50:07 | openstackgerrit | zhangdaolong proposed openstack/nova master: Fix error log output information parameters. https://review.openstack.org/575277 | |
| 10:56:58 | ygl | hi all | |
| 10:57:09 | ygl | a tenant has created a vm . when I as admin do nova list --all-tenants, it is not showing up. But when I do nova list --tenant <tenant-name> , only it is showing up then. why is it not showing in --all-tenants list ? | |
| 10:57:22 | ygl | can some one help me please | |
| 10:57:53 | ygl | is it a bug in mitakak ? | |
| 11:25:05 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268 | |
| 11:25:06 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send resource allocations in the port binding https://review.openstack.org/569459 | |
| 11:25:07 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 11:50:48 | openstackgerrit | Shilpa Devharakar proposed openstack/python-novaclient master: Modify novaclient to support basic attributes https://review.openstack.org/572285 | |
| 12:00:41 | openstackgerrit | Alexandre arents proposed openstack/nova master: Preserve images_type of instance during live migration https://review.openstack.org/570528 | |
| 12:01:51 | openstackgerrit | Merged openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 12:03:37 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Use ThreadPoolExecutor for max_concurrent_live_migrations https://review.openstack.org/563505 | |
| 12:07:31 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Compute: add support to abort queued live migration https://review.openstack.org/568542 | |
| 12:08:26 | bauzas | gibi: hola | |
| 12:08:31 | gibi | bauzas: hey | |
| 12:08:42 | bauzas | gibi: why do we need to have a separate notification call for https://review.openstack.org/#/c/563269/7/nova/compute/manager.py ? | |
| 12:10:46 | gibi | bauzas: it instantiate a rebuild specific notification payload class https://review.openstack.org/#/c/563269/26/nova/compute/utils.py@739 | |
| 12:11:05 | gibi | bauzas: that is the only difference from the generic call | |
| 12:11:48 | gibi | I mean https://review.openstack.org/#/c/563269/26/nova/compute/utils.py@734 | |
| 12:30:32 | bauzas | gibi: sure, but the action is always the same ? | |
| 12:32:23 | gibi | bauzas: if the action mean calling a specific constructor then my answer is no. if you mean instantiating a payload class and then a notification class and then calling emit() then yes | |
| 12:32:40 | gibi | so the high level pattern is the same | |
| 12:32:59 | gibi | and this pattern could be factored out as a generic thing | |
| 12:33:16 | gibi | parameterized with payload class and notification class | |
| 12:33:20 | bauzas | gibi: sure, that's why I don't like to see a compute modification | |
| 12:33:25 | bauzas | anyway | |
| 12:33:52 | openstackgerrit | Corey Bryant proposed openstack/nova master: Fix execute mock for test_convert_image_with_errors https://review.openstack.org/575305 | |
| 12:34:17 | crazik | hi @ll | |
| 12:35:57 | crazik | is there any way to clean migration list? | |
| 12:45:41 | gibi | Kevin_Zheng: I left a suggesting in https://review.openstack.org/#/c/564092 | |
| 13:04:10 | mriedem | jmlowe: melwitt: i was thinking about that microversion troubleshooting issue, and we could put something in here https://developer.openstack.org/api-guide/compute/microversions.html or we also have a troubleshooting section in the admin guide https://docs.openstack.org/nova/latest/admin/support-compute.html | |
| 13:04:28 | mriedem | latter is probably better | |
| 13:07:01 | mriedem | jmlowe: also, not sure but we could consider logging something in here https://github.com/openstack/nova/blob/2b9c7970fcdd9c7747656d662319c811a9895c20/nova/api/openstack/__init__.py#L101 | |
| 13:07:14 | mriedem | if you're using v2 compat mode and users are hitting your cloud with microversion requests which are just being ignored | |
| 13:10:55 | gibi | mriedem: hi! I found an issue in https://review.openstack.org/#/c/563269/26/nova/tests/functional/notification_sample_tests/test_instance.py@1019 I can jump on it and fix it if you wish | |
| 13:11:24 | mriedem | gibi: go for it, i haven't gotten that far yet, was planning to review that today | |
| 13:11:30 | openstackgerrit | Merged openstack/nova stable/queens: [Stable Only] Initialise failed_builds in IronicNodeState https://review.openstack.org/574997 | |
| 13:11:34 | mriedem | i've been fixing the small things in this series myself to keep it going | |
| 13:12:12 | gibi | mriedem: OK | |
| 13:33:48 | openstackgerrit | Eric Fried proposed openstack/os-vif master: doc: Mention second arg to (un)plug in docs https://review.openstack.org/575151 | |
| 13:38:43 | artom | sahid, so, about NUMA live migration | |
| 13:39:19 | artom | Coming from a place of complete ignorance of the resource tracker and claims, and having quickly talked this over with mriedem and dansmith last night, my understanding was that we'd need to resource tracker to track live migrations in order to do claims, and that it's a massive rabbit hole we don't want to get into | |
| 13:39:55 | artom | The easier solution is to ignore claims entirely and wait for NUMA to be done in placement, and let the scheduler update allocations (we already do that for live migration, but not for NUMA resources) | |
| 13:40:20 | artom | sahid, you seem to be saying that doing claims for live migration isn't as massive a rabbit hole as we think it is? | |
| 13:40:40 | melwitt | mriedem: good ideas | |
| 13:42:12 | sahid | artom: well my thinking is that we have everything ready in claim, it's going to do all the work that you are doing, check the new numa topology and store it | |
| 13:42:37 | artom | sahid, yeah, I saw it being used for cold migrations | |
| 13:42:53 | artom | I still need to wrap my head around how to use it properly | |
| 13:43:09 | sahid | artom: did you see my last comment? | |
| 13:43:23 | artom | sahid, you mean about _move_claim in resource_tracker? | |
| 13:43:35 | artom | That's a "private" method, I can't just call that directly, surely? | |
| 13:44:15 | sahid | artom: you just have to create a public one that will prepare it and pass everyting needed | |
| 13:45:42 | artom | sahid, right, duh :/ | |
| 13:45:53 | artom | sahid, I'll see if I can make sense of it | |
| 13:45:59 | artom | I do like the idea of reusing existing code | |
| 13:46:03 | artom | (obviously) | |
| 13:47:14 | sahid | more of that, you can't just really check in pre-live-migration, a live-migration process can take time so you have to make destination node to return accurate resources | |
| 13:47:23 | sahid | which is basically one of the role of the claim thing | |
| 13:47:46 | artom | I just don't want this to turn into a massive piece of work that'll get replaced by placement next cycle | |
| 13:48:10 | artom | sahid, oh yeah, we've know from the start that it was going to be racy | |
| 13:48:36 | artom | https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html#alternatives the para before that | |
| 13:48:57 | sahid | more of that if all of that is going to be replaced by placement so it's better to continue with the same mech | |
| 13:49:26 | mriedem | artom: sahid: the point of "claiming" resource allocations in the scheduler via placement is so we don't have to do the racy late claim on the compute | |
| 13:49:34 | mriedem | eventually all of that claims code gets dropped | |
| 13:49:40 | mriedem | in the RT i mean | |
| 13:50:03 | mriedem | once we have numa / pci modeling in placement / scheduler and once we no longer have the caching scheduler | |
| 13:50:15 | melwitt | nova meeting in 10 minutes | |
| 13:50:21 | mriedem | that's not going to happen in rocky though | |
| 13:54:26 | artom | mriedem, sahid, yeah, that's sort of the thing I'm trying to decide - how much work would it be to do RT claims for live migration *now*, knowing that it'll all get dropped in Stein (?) in favor of placement | |
| 13:54:48 | mriedem | artom: no guarantees on dropping that claims code in stein | |
| 13:54:50 | mriedem | i doubt it honestly | |
| 13:54:53 | artom | Last night it was apparently "a lot of work, don't bother" | |
| 13:55:03 | artom | But sahid's saying it's not that hard | |
| 13:55:28 | mriedem | numa has to be modeled in placement inventory first, and i don't think that spec landed in rocky | |
| 13:55:44 | mriedem | so you're looking at reporting numa inventory to placement from the comptues in stein at the earliest | |
| 13:56:04 | mriedem | we *might* be able to drop the caching scheduler in stein because we have heal_allocations now | |
| 13:56:29 | dansmith | I don't think that adding this to live migration regresses the claim situation at all righ? | |
| 13:56:41 | dansmith | we can already migrate instances where we have no resources today | |
| 13:56:53 | dansmith | being able to do instances with numa doesn't make that worse, right? | |
| 13:57:30 | mriedem | i'm not really following, and i'd really need to read the spec before actually intelligently discussing what was proposed for this | |
| 13:58:29 | mriedem | melwitt: jmlowe: ok i can try to hack some quick thing into the troubleshooting guide for "why aren't my microversion-based requests being honored?" | |
| 13:58:46 | artom | mriedem, https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html It's a quick read, I pinky-swear | |
| 13:58:58 | jmlowe | I answered my own question on ask openstack about this | |
| 13:59:06 | mriedem | jmlowe: link? | |
| 13:59:17 | jmlowe | karma 1, so it may never see the light of day | |
| 13:59:30 | mriedem | jmlowe: might still be good to put into our troubleshooting docs | |
| 13:59:47 | mriedem | since we probably don't leverage the fact we have those at all enough | |
| 13:59:51 | jmlowe | absolutely | |
| 14:00:16 | jmlowe | https://ask.openstack.org/en/question/114805/why-is-nova-ignoring-microvesions/#114806 | |
| 14:00:20 | mriedem | artom: i plan on getting to it eventually, just busy atm | |
| 14:00:24 | mriedem | jmlowe: thanks | |
| 14:00:31 | artom | mriedem, heh, no worries :) | |
| 14:00:46 | jmlowe | also the follow up https://ask.openstack.org/en/question/114808/why-is-nova-cli-not-using-https/#114809 | |