| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-06 | |||
| 19:18:43 | mnaser | well | |
| 19:18:49 | mnaser | we've always deprecated things | |
| 19:19:14 | mnaser | so i don't see why this would be any different | |
| 19:19:33 | mnaser | if anything this is way more critical than any other config disappearing | |
| 19:21:16 | mriedem | you mean as in deprecated but still rely on nova.conf in extracted placement, and drop support for placement using nova.conf in T? | |
| 19:22:00 | mnaser | mriedem: load in order of /etc/placement.conf => /etc/nova/nova.conf in S with a giant warning | |
| 19:22:01 | mnaser | drop that in T | |
| 19:22:33 | mriedem | i believe that's what jaypipes asked for on the review | |
| 19:23:36 | jaypipes | correct. | |
| 19:24:13 | mnaser | i really hope to try and loop in other deployment tools into this | |
| 19:24:15 | mnaser | i.e. tripleo | |
| 19:24:35 | mriedem | beyond config, the other major thing is obviously the db | |
| 19:25:08 | mriedem | if placement does use nova.conf in stein (use/supports as a bridge), it would rely on the [api_database]/connection config | |
| 19:25:57 | mnaser | yeah and also | |
| 19:26:00 | mriedem | looks like that code is still there | |
| 19:26:01 | mnaser | wasnt placement_database a thing | |
| 19:26:07 | mnaser | but i think that was removed cause it wasn't wired | |
| 19:26:09 | mriedem | in openstack/placement, to support that | |
| 19:26:11 | mnaser | i cant remember if it was fixed | |
| 19:26:22 | mriedem | CONF.placement_database is a thing in rocky | |
| 19:26:29 | mriedem | optional thing | |
| 19:26:31 | mnaser | ok so that's back | |
| 19:26:37 | mriedem | yes | |
| 19:26:42 | mnaser | so the logic to determine the db source would be useful there | |
| 19:26:48 | mriedem | if not set, it still uses the nova_api db | |
| 19:27:05 | mnaser | i remember some deployment tools actually creating a placement db | |
| 19:27:08 | mnaser | and pointing that stuff to it | |
| 19:27:10 | mriedem | https://github.com/openstack/placement/blob/master/placement/db_api.py#L27 | |
| 19:27:24 | mriedem | yeah i think i remember that, maybe kolla? | |
| 19:27:44 | mriedem | i do remember it triggering that we needed to remove some shit from the nova config that was missed when that was originally reverted | |
| 19:28:52 | mnaser | mriedem: i added a comment with my pov | |
| 19:31:59 | jaypipes | mriedem: again, my primary concern is the use of default values if /etc/placement.conf doesn't exist and how that would be quite difficult to diagnose if there were changed values in the /etc/nova.conf for placement-related stuffs. | |
| 19:32:50 | mnaser | yeah i can imagine that being so confusing | |
| 19:33:55 | mriedem | there's not actually a ton of configuration options for placement, mostly policy, db, and some other small things, | |
| 19:34:06 | mriedem | but yeah if your db is pointing at the wrong thing, i.e. nothing, you're f'ed | |
| 20:18:54 | efried | edmondsw: You'll be interested in this discussion from the nova mtg this morning: http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-09-06-14.00.log.html#l-120 | |
| 20:20:09 | efried | edmondsw: TL;DR: we should proceed as if cyborg ain't a thing, and worry about integrating with cyborg later as it matures. | |
| 20:20:41 | efried | edmondsw: Which means pretty much sticking with the direction of the spec(s) as written. | |
| 20:20:50 | efried | which is good timeline-wise :) | |
| 20:21:08 | edmondsw | that sounds good to me, assuming we'll be able to squeeze cyborg in when the time comes without reinventing too much | |
| 20:21:19 | edmondsw | s/assuming/hoping/ ? | |
| 20:21:53 | efried | yeah, that was my concern, but it's between that rock and the hard place of trying to anticipate $world-with-cyborg before that's a thing. | |
| 20:22:07 | edmondsw | yep | |
| 20:22:20 | edmondsw | I see many interesting PTG conversations in your future... | |
| 20:22:43 | edmondsw | wish I could be there | |
| 21:01:01 | gryf | +++++++++++++++++ | |
| 21:32:59 | mnaser | fun fact | |
| 21:33:02 | mnaser | console logs disappear on live migration | |
| 21:33:19 | mnaser | themoreyouknow.gif | |
| 21:47:37 | mriedem | you're welcome | |
| 21:53:59 | mriedem | so i thought artom changed direction on numa-aware live migration https://review.openstack.org/#/c/599587/ ? | |
| 21:54:04 | mriedem | because the re-proposed spec is the same old thing | |
| 21:54:21 | mriedem | stephenfin: ^ | |
| 21:54:31 | mriedem | btw, GET /artom is a 404 | |
| 21:54:33 | mriedem | wtf? | |
| 22:05:09 | openstackgerrit | Merged openstack/nova-specs master: Add serial numbers for local disks https://review.openstack.org/595247 | |
| #openstack-nova - 2018-09-07 | |||
| 00:32:25 | alex_xu | good morning nova | |
| 01:07:04 | openstackgerrit | Elancheran S proposed openstack/nova stable/pike: Add apply_cells to nova-manage https://review.openstack.org/599050 | |
| 01:18:24 | openstackgerrit | fupingxie proposed openstack/nova master: Add an example to add more pci devices in nova.conf https://review.openstack.org/592243 | |
| 02:08:16 | openstackgerrit | Zhenyu Zheng proposed openstack/nova-specs master: Add live-migration-force-after-timeout-stein spec https://review.openstack.org/600608 | |
| 02:18:53 | openstackgerrit | Zhenyu Zheng proposed openstack/nova-specs master: Spec to add per instance timeout for LM - Stein https://review.openstack.org/600613 | |
| 03:01:26 | openstackgerrit | Merged openstack/nova stable/rocky: Fix a failure to format config sample https://review.openstack.org/600336 | |
| 03:09:08 | openstackgerrit | Zhenyu Zheng proposed openstack/nova-specs master: Detach and attach boot volumes - Stein https://review.openstack.org/600628 | |
| 03:30:30 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Resource retrieving: add changes-before filter https://review.openstack.org/591976 | |
| 05:38:46 | openstackgerrit | Merged openstack/nova master: Fix TypeError in nova-manage cell_v2 list_cells https://review.openstack.org/599861 | |
| 05:46:59 | openstackgerrit | fupingxie proposed openstack/nova master: Add an example to add more pci devices in nova.conf https://review.openstack.org/592243 | |
| 06:26:36 | openstackgerrit | Zhenyu Zheng proposed openstack/nova-specs master: Detach and attach boot volumes - Stein https://review.openstack.org/600628 | |
| 06:28:31 | openstackgerrit | fupingxie proposed openstack/nova master: Delete allocations for instances that have been moved to another node https://review.openstack.org/582899 | |
| 06:43:58 | openstackgerrit | Zhenyu Zheng proposed openstack/nova-specs master: Add live-migration-force-after-timeout-stein spec https://review.openstack.org/600608 | |
| 06:44:13 | openstackgerrit | fupingxie proposed openstack/nova master: Delete allocations for instances that have been moved to another node https://review.openstack.org/582899 | |
| 06:53:20 | openstackgerrit | fupingxie proposed openstack/nova master: Delete allocations for instances that is not in this node https://review.openstack.org/582899 | |
| 06:55:06 | openstackgerrit | Zhenyu Zheng proposed openstack/nova-specs master: Spec to add per instance timeout for LM - Stein https://review.openstack.org/600613 | |
| 07:03:54 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: Do not dump all instances in the scheduler https://review.openstack.org/598611 | |
| 07:04:48 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: Do not dump all instances in the scheduler https://review.openstack.org/598611 | |
| 07:08:44 | artom | Actually, sahid, if you're awake already, you might know this. Can NUMA resources be claimed without using a MoveClaim context? | |
| 07:08:51 | openstackgerrit | Chen proposed openstack/nova master: doc: update info for hypervisors https://review.openstack.org/599554 | |
| 07:10:29 | sahid | artom: not sure what you mean? i thnk we have two ways to claim resources but you can implement a new one if necessary | |
| 07:11:20 | artom | sahid, so, for cold migration for instance, there's code in the conductor that essentially says, "with rt.cold_migration_claim: <do cold migration>" | |
| 07:11:35 | artom | And IIUC this claim context is how resources are claimed on the destination node | |
| 07:12:01 | artom | Is there a less opaque way of doing, for example by calling something like rt.claim_these_resources_on_the_compute_host? | |
| 07:12:28 | artom | I'm essentially trying to avoid having to understand claim contexts :D | |
| 07:15:00 | sahid | artom: well... i did not have yet finish my coffe but i would say, you will have to reuse moveclaim that to avoid rewriting everything, | |
| 07:15:24 | artom | sahid, aha, thanks! That's... what I was afraid of :( | |
| 07:16:45 | sahid | artom there is nothing so complicted in moveclaim, basically we just create a migration object context and update resources on destination host based on the instance that we are migrating | |
| 07:17:22 | artom | sahid, heh, you keep saying that, and I just can never bring myself to go through that code and understand what's going on and what else it affects | |
| 07:17:40 | artom | sahid, maybe a bjns when you have time so you can bring me up to speed | |
| 07:18:00 | sahid | what is blocking you? | |
| 07:18:19 | artom | Besides my own stupidity and laziness? ;) | |
| 07:18:38 | sahid | ahahah :) | |
| 07:19:35 | artom | So, the context is, I'm updating the live migration spec for Stein, and I was pinning my hopes on placement to claim resources on the dest | |
| 07:20:31 | artom | But! Placement is only qualitative - ie, you can say I'm claiming 2 NUMA nodes, but you can't say I'm claiming NUMA node 0 and 3, and pinning CPUs 1-4 and 4-8 | |
| 07:20:52 | artom | So we'll need claims on the compute node regardless, even in the distance future when placement starts doing NUMA for us | |
| 07:21:33 | artom | Because for NUMA we need to know *which* specific resources are being claimed, not just how many | |
| 07:21:49 | artom | The mellanox guys want to do live migration with SRIOV, and they have the same problem | |
| 07:22:59 | artom | I'll continue updating the spec, and them, if you're willing, come back with a more concrete list of questions than just "HALP!!11" | |
| 07:23:37 | sahid | so basically i would say first you will have to update hardware.fit_instance_to_host() to work with placement | |
| 07:24:55 | sahid | well actually i have some doubt you can achieve that work with placement right now | |
| 07:25:13 | artom | Well, the conversion of hardware/resource_tracker to use placement will come later, for now there isn't even a spec for Stein for NUMA RPs in placement (though Sylvain did have one proposed for Rocky) | |
| 07:25:29 | artom | sahid, yeah, it's for later, the pieces aren't in placement yet | |
| 07:25:40 | sahid | ok so i would say forget about placement, we will be able to update our code at time | |