| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-15 | |||
| 16:34:35 | artom_ | jaypipes, wanna talk about https://review.openstack.org/#/c/552722/1/specs/rocky/approved/live-migration-with-cpu-pinning.rst@16? | |
| 16:37:06 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: Spec for isolating configuration of placement database https://review.openstack.org/552927 | |
| 16:37:39 | cdent | stephenfin: addressed your suggestions on ^ | |
| 16:41:07 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Unmap compute nodes when deleting host mappings in delete cell operation https://review.openstack.org/542964 | |
| 16:42:08 | mriedem | tssurya: would you like to propose a backport to stable/queens for ^ ? | |
| 16:43:14 | tssurya | mriedem: yes I will do it | |
| 16:45:24 | openstackgerrit | Alvaro Lopez Garcia proposed openstack/nova master: Ensure that periodic reclaim cleans DB deleted instances https://review.openstack.org/323250 | |
| 16:46:13 | cfriesen | sahid_: I'm back. So on power_off() we _destroy() the instance (but leave it defined) and remove the serial ports from ALLOCATED_PORTS. Then on power_on() we hard reboot the instance, which calls _destroy() again, which removes the ports from ALLOCATED_PORTS again, which might result in removing ports currently in use by another instance. | |
| 16:46:42 | jaypipes | artom_: sure, what's up? | |
| 16:47:16 | openstackgerrit | sahid proposed openstack/nova master: libvirt: slow live-migration to ensure network is ready https://review.openstack.org/497457 | |
| 16:47:24 | cfriesen | sahid: I assume we call _hard_reboot() to clean up as many things as possible about the instance (given the comment by mdbooth in _hard_reboot()) | |
| 16:47:27 | openstackgerrit | Eric Fried proposed openstack/nova master: ProviderTree.{add|remove}_{traits|aggregates} https://review.openstack.org/553475 | |
| 16:48:05 | efried | dansmith, jaypipes, cdent, edleafe: One half of the result of the "need to be able to merge traits/aggs" discussion ^ | |
| 16:48:55 | cfriesen | sahid_: I'm wondering whether we should do the serial port removal from ALLOCATED_PORTS in _undefine_domain() instead. | |
| 16:49:16 | openstackgerrit | Eric Fried proposed openstack/nova master: update_provider_tree devref and docstring updates https://review.openstack.org/553476 | |
| 16:49:31 | efried | dansmith, jaypipes, cdent, edleafe, mriedem: The other half ^ | |
| 16:49:52 | efried | ...and now to send out that dev ML note, so I don't get in trouble with mriedem... | |
| 16:51:15 | tssurya | mriedem: there is a small problem with the backport, I guess the above patch sits on this one -> https://review.openstack.org/#/c/540073/ , so will backport both | |
| 16:51:30 | artom | jaypipes, so, what I think I failed in communicating is that getting NUMA resources modelled in placement and claimed by the scheduler (Sylvain's spec) is a dependency of my spec | |
| 16:51:53 | artom | jaypipes, and what I *think* you're saying is that, we can continue using the current compute-node-claims-the-resources way for now | |
| 16:53:10 | openstackgerrit | Surya Seetharaman proposed openstack/nova stable/queens: Extending delete_cell --force to delete instance_mappings https://review.openstack.org/553478 | |
| 16:53:18 | sahid_ | cfriesen: i think you also have to look at the method where we define domain xml | |
| 16:53:25 | edleafe | efried: looking... | |
| 16:54:18 | sahid_ | cfriesen: get_config_xml or somethinf | |
| 16:54:50 | openstackgerrit | sahid proposed openstack/nova master: libvirt: slow live-migration to ensure network is ready https://review.openstack.org/497457 | |
| 16:54:53 | jaypipes | artom: I don't think it's necessary to depend on bauzas' spec. I think that would endanger making progress on fixing live migration for NUMA/pinning | |
| 16:56:14 | artom | jaypipes, right, so leave the NUMA RPs thing to itself, and just fix the pin mappings for now. I'd tend to agree, for what it's worth - feels like a more incremental step, and not a major overhaul | |
| 16:57:20 | jaypipes | artom: ++ | |
| 16:57:28 | cfriesen | sahid_: in the _hard_reboot() case we call destroy(), which does _destroy() and then cleanup(), and that will undefine the instance. Arguably that's the point where we should remove the TCP port from ALLOCATED_PORTS. Then we generate new xml with new TCP ports and all should be happy. | |
| 16:57:49 | jaypipes | artom: and all I was asking was that you make a little more explicit in the spec what is and what isn't "claimed". | |
| 16:58:06 | cfriesen | sahid_: removing the TCP ports from ALLOCATED_PORTS while they're still defined in the domain is just asking for trouble. | |
| 16:58:33 | artom | jaypipes, totally fair. | |
| 16:58:37 | openstackgerrit | Merged openstack/nova stable/pike: doc: fix the link for the evacuate cli https://review.openstack.org/542856 | |
| 16:58:58 | artom | jaypipes, err, you're using "claimed" because the compute node doesn't actually talk to placement to "claim" the pinned pCPUs, right? | |
| 17:01:32 | sahid_ | cfriesen: if you can make all of that better i will be happy to review any of the your patches | |
| 17:01:40 | jaypipes | artom: no, I'm saying that "claim resources" means something very specific in the scheduler -- it is the call to placement to PUT /allocations/{instance_uuid}. And that does *not* include any NUMA resources right now. So I want the spec to be clear about that. When you say "claim in the scheduler", that's not actually what happens. The "claim on the compute" is the old way of allocating resources from the compute node to the instance by writing | |
| 17:01:40 | jaypipes | the record to the compute_nodes cell DB table. that is still done for NUMA and PCI resources in the resource tracker's instance_claim() method. | |
| 17:02:45 | sahid_ | dansmith: i updated the patch related to live-migration, the point is to have if possible something like an agrement on one of the version so i could make it tested internally | |
| 17:03:41 | artom | jaypipes, thanks for setting me straight :) | |
| 17:03:41 | dansmith | sahid_: I already said the implementation looks right, barring the gaps in testing | |
| 17:04:26 | cfriesen | sahid_: cool, if I get some time I'll hold you to that. :) | |
| 17:05:06 | cfriesen | jaypipes: artom: this spec only talks about CPU pinning, but we also need to recalculate the destination NUMA node for hugepage-backed instances even without CPU pinning. | |
| 17:05:11 | sahid_ | dansmith: i would like avoid any difference, so if you have a moment please have a look in the last version | |
| 17:05:15 | sahid_ | cfriesen: :) | |
| 17:06:34 | artom | cfriesen, jaypipes, so should we just extend this to NUMA live migration, all the while keeping the old claim on the compute way of allocating resources? | |
| 17:07:09 | dansmith | sahid_: you didn't answer my question about the neutron events in the tests | |
| 17:07:29 | claudiub|2 | dansmith: hellou. Ehm, I saw that we don't allow certain DB operations in nova (drops and alters). I'm trying to add an item to an enum, but afaik, that requires an alter. Or is there a better way to do it? | |
| 17:08:34 | dansmith | claudiub|2: yeah, we banned alters because they're not (usually) additive and doable online.. I think we had one in the past we exempted because we confirmed with jaypipes that it was lightweight.. does yours fit that description? | |
| 17:08:58 | cfriesen | artom: yes, I think it's really NUMA-aware live migration. | |
| 17:09:27 | claudiub|2 | nope, I'm trying to add an item to the Migration.migration_type enum. | |
| 17:09:51 | dansmith | claudiub|2: oh just adding something to an existing enum? | |
| 17:09:57 | claudiub|2 | yep | |
| 17:10:01 | dansmith | jaypipes: ^ hopefully that is not a big deal to do online? | |
| 17:10:28 | claudiub|2 | this is the commit: https://review.openstack.org/#/c/185961/4 but postgresql seems unhappy about it. | |
| 17:10:32 | jaypipes | dansmith: no, it's virtually instantaneous | |
| 17:10:37 | dansmith | jaypipes: ack | |
| 17:10:57 | dansmith | claudiub|2: so I think there should be at least one more exception in whatever test that is, so you can copy that for yours I think | |
| 17:11:02 | artom | cfriesen, not a bad idea :) | |
| 17:11:17 | jaypipes | honestly, we really shouldn't be using the ENUM type anyway... but meh | |
| 17:11:38 | artom | So, I have to bounce of a lunch thing, and ideally I'd have liked more discussion about this before rewriting the spec, but I think I'll just bite the bullet and rewrite the spec :) | |
| 17:12:29 | dansmith | jaypipes: yeah I'm not a fan myself | |
| 17:13:48 | claudiub|2 | dansmith: ack, done that, but it seems like postgresql is dropping the column on alter, for some reason, and this exception is raised: oslo_db.exception.DBError: (psycopg2.InternalError) cannot drop type migration_type because other objects depend on it | |
| 17:13:48 | claudiub|2 | DETAIL: table migrations column migration_type depends on type migration_type | |
| 17:13:52 | cfriesen | artom: I'm just updating the review with some comments right now. gimme a couple minutes | |
| 17:14:05 | dansmith | claudiub|2: I don't think I can help you with that one :) | |
| 17:14:11 | dansmith | claudiub|2: but I don't think it's any of our doing | |
| 17:15:24 | claudiub|2 | I sea. | |
| 17:16:18 | openstackgerrit | Surya Seetharaman proposed openstack/nova stable/queens: Unmap compute nodes when deleting host mappings in delete cell operation https://review.openstack.org/553496 | |
| 17:16:38 | claudiub|2 | jaypipes: do you have any ideas? ^ | |
| 17:18:15 | openstackgerrit | Merged openstack/nova master: Update deprecated log-config option in docs https://review.openstack.org/551825 | |
| 17:20:43 | mriedem | efried: how do i get an endpoint url from a ksa adapter object? | |
| 17:21:06 | efried | mriedem: stand by. | |
| 17:21:30 | cfriesen | artom: okay, updated the review with some extra info | |
| 17:21:58 | efried | mriedem: .get_endpoint() | |
| 17:25:21 | sean-k-mooney | mriedem: exposing the vlans for trunk ports in metadata, i think the kuryr team did but honest answer is i dont know | |
| 17:25:46 | tssurya | dansmith, mriedem: since I had to rebase this regression (https://review.openstack.org/#/c/550967/) bug on top of the new purge command got merged before this, does this mean we will have to backport that new command into queens too ? | |
| 17:26:38 | dansmith | tssurya: generally just fix up the backport and note the reason for the conflicts in the commit message | |
| 17:26:54 | dansmith | I wouldn't be too opposed to backporting the purge stuff personally, but it's technically not a candidate | |
| 17:26:55 | tssurya | dansmith: okay thanks | |
| 17:27:07 | tssurya | yea I can fix up the backport | |
| 17:27:20 | tssurya | I didn't know if it was an allowed practice | |
| 17:27:20 | dansmith | tssurya: if you survey some other backports you'll see some "Conflicts:" examples | |
| 17:27:38 | tssurya | dansmith: thanks will look them up | |
| 17:27:49 | dansmith | tssurya: example: https://review.openstack.org/#/c/540145/ | |
| 17:28:16 | jaypipes | claudiub|2: added review note. | |
| 17:28:25 | tssurya | dansmith: perfect thank you! | |
| 17:28:31 | claudiub|2 | \o/ thanks. :D | |
| 17:56:23 | cfriesen | are there any known issues with nic tagging in Newton? | |
| 17:57:07 | stephenfin | artom: ^ ? | |
| 17:57:09 | cfriesen | I'm failing schema validation, wondering if it's something we screwed up but I don't see us changing anything in that area. | |
| 17:57:19 | cfriesen | (by "we" I mean my organization) | |
| 17:58:12 | cdent | jaypipes: you might enjoy this buglet: https://bugs.launchpad.net/nova/+bug/1756151 | |
| 17:58:13 | openstack | Launchpad bug 1756151 in OpenStack Compute (nova) "placement os-traits sync checked every request" [Low,Triaged] | |
| 18:03:02 | cfriesen | stephenfin: artom: ah yes, microversion 2.37 broke tagging, and 2.42 added it back in. | |
| 18:13:15 | mriedem | melwitt: have you heard anything new about a project update session at the summit? | |
| 18:15:09 | melwitt | mriedem: no, I'm gonna ask anne about it | |
| 18:15:15 | mriedem | nova project update doesn't fall under the category of CI/CD, HPC or EDGE so probably not | |
| 18:15:19 | mriedem | i replied to the ML thread | |
| 18:15:25 | mriedem | quite dickishly | |
| 18:16:13 | melwitt | heh. I tried to find them in the summit schedule and found none | |