| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-24 | |||
| 12:58:36 | efried | Yeah, the answer was "no", but edleafe thought you would remember why it was decided that way. | |
| 12:58:41 | cdent | the defacto standards with query params is that multiple of the same param should work, but it is not something we really do in nova | |
| 12:59:06 | mriedem | only for sort key/dir i think | |
| 12:59:47 | efried | cdent Well, at least for GET /allocation_candidates and GET /resource_providers?resources= it doesn't work. | |
| 12:59:50 | efried | You'll only get the last one. | |
| 13:00:28 | cdent | yes, that’s a) intentional b) because of the way it is coded c) a fairly arbitrary choice | |
| 13:01:05 | efried | Okay, wfm | |
| 13:01:07 | cdent | the confusion being avoided is whether a list is created by commas or multiple params, and since most people didn’t feel comfy with multiple params, commas was chosen, exclusively | |
| 13:01:50 | openstackgerrit | Merged openstack/nova master: Remove duplicate error info https://review.openstack.org/510719 | |
| 13:02:39 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for inventories https://review.openstack.org/457533 | |
| 13:02:39 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for allocations https://review.openstack.org/457534 | |
| 13:02:40 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for usages https://review.openstack.org/457535 | |
| 13:02:40 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for aggregates (v1.1) https://review.openstack.org/505643 | |
| 13:02:41 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for resource classes (v1.2) https://review.openstack.org/511182 | |
| 13:02:41 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: RP list: member_of and resources parameters (v1.3, v1.4) https://review.openstack.org/511183 | |
| 13:02:42 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] RP delete inventories (v1.5) https://review.openstack.org/514642 | |
| 13:02:42 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] CLI for traits (v1.6) https://review.openstack.org/514643 | |
| 13:02:43 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] Resource class set (v1.7) https://review.openstack.org/514644 | |
| 13:02:43 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] Allocations set: add project_id and user_id (v1.8) https://review.openstack.org/514645 | |
| 13:02:44 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] Usages per project and user (v1.9) https://review.openstack.org/514646 | |
| 13:02:44 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 13:02:45 | openstackgerrit | priyaduggirala proposed openstack/nova master: Rename parameters in call() of nova/image/glance.py https://review.openstack.org/508533 | |
| 13:04:43 | openstackgerrit | Alex Xu proposed openstack/nova master: Add _get_provider_ids_with_any_resource method https://review.openstack.org/514197 | |
| 13:04:44 | openstackgerrit | Alex Xu proposed openstack/nova master: Add _get_traits_by_rp_ids method https://review.openstack.org/511184 | |
| 13:04:44 | openstackgerrit | Alex Xu proposed openstack/nova master: Add ProviderSummaryList object https://review.openstack.org/514198 | |
| 13:04:45 | openstackgerrit | Alex Xu proposed openstack/nova master: Add more caches for the ProviderSummary https://review.openstack.org/514199 | |
| 13:04:45 | openstackgerrit | Alex Xu proposed openstack/nova master: Add AggregatedProviderSummary and AggregatedProviderSummaryList objects https://review.openstack.org/514200 | |
| 13:04:46 | openstackgerrit | Alex Xu proposed openstack/nova master: placement: rewrite AllocationCandidates.get_by_filters https://review.openstack.org/479766 | |
| 13:04:46 | openstackgerrit | Alex Xu proposed openstack/nova master: Enable _get_usages_by_provider_and_rc not filter on the resource class id https://review.openstack.org/514649 | |
| 13:04:47 | openstackgerrit | Alex Xu proposed openstack/nova master: Add has_resources method to the AggregatedProviderSummary object https://review.openstack.org/514650 | |
| 13:04:47 | openstackgerrit | Alex Xu proposed openstack/nova master: Add as_allocation_request_obj method to AggregatedProvierSummary obj https://review.openstack.org/514651 | |
| 13:11:09 | mriedem | sdague: at the ptg you said you were good with getting this az name schema fix into stable https://review.openstack.org/#/q/I9b0d8e8d4b3ab2cb3d578c22fa259e0e7c0d325b | |
| 13:12:39 | belmoreira | dansmith: mriedem: I'm looking on how to have placement with cellsV1. Need some guidance. | |
| 13:15:13 | belmoreira | My understanding is that I will need to have a separated placement service + nova_api DB + keystone for each child cell. Is this correct? | |
| 13:22:40 | mriedem | belmoreira: i've always thought of placement as global to nova, but it's only used by the "cell" filter scheduler i guess, so it might make sense to only be per-child cell with cells v1 | |
| 13:22:50 | mriedem | the global api parent cell scheduler won't rely on placement | |
| 13:23:13 | mriedem | belmoreira: i don't know about keystone being per child cell | |
| 13:23:23 | mriedem | is that what you already do today? | |
| 13:23:51 | mriedem | nova_api db should be global | |
| 13:24:01 | mriedem | since build requests are created in the api cell | |
| 13:24:22 | mriedem | belmoreira: which release are you targeting here? | |
| 13:24:40 | belmoreira | mriedem: let me clarify | |
| 13:25:36 | belmoreira | I'm running nova newton release. We have one nova_api DB (requirement in newton) that is global | |
| 13:26:16 | belmoreira | when upgraded I didn't enable placement but it's a requirement before moving to Ocata/Pike | |
| 13:27:07 | mriedem | belmoreira: yeah so in ocata, the only things that talk to placement are nova-scheduler in the cell and nova-compute | |
| 13:27:52 | bauzas | we always thought placement as being global, like we also said for the scheduler | |
| 13:27:53 | mriedem | so placement could be deployed per-cell, but if you can, it's probably smart to deploy it globally to make the transition easier to cells v2 | |
| 13:28:00 | belmoreira | because nova-scheduler is per cell in cellsV1 do I need a placement per cell? | |
| 13:28:23 | mriedem | bauzas: with cells v1 there are 2 levels of scheduling | |
| 13:28:27 | bauzas | mriedem: if placement would be per cell, that would mean 2 layer of scheduling, which I disagree | |
| 13:28:33 | bauzas | mriedem: yup I know and I don't like it :) | |
| 13:28:34 | mriedem | there already is | |
| 13:28:48 | mriedem | like i said, if you deploy placement globally, i think it'll be easier in the long-run | |
| 13:28:53 | mriedem | to transition to cells v2 | |
| 13:28:56 | belmoreira | I was always thinking in the placement as global... but I'm not seeing how to make it work with cellsV1 | |
| 13:29:00 | bauzas | mriedem: but the consensus we had long in the past with alaski and dansmith was that 2 scheduling layers was a terrible idea | |
| 13:29:01 | mriedem | b/c with cells v2 there is only 1 scheduler | |
| 13:29:25 | dansmith | belmoreira: why can't you point all the child cells at the global api? | |
| 13:29:26 | mriedem | belmoreira: just think of it like any other global service | |
| 13:29:30 | dansmith | er, global placement api | |
| 13:29:34 | bauzas | so, AFAIR, we discussed about just having a CellFilter | |
| 13:29:48 | bauzas | which would filter per cell or somehow like that | |
| 13:30:01 | dansmith | bauzas: what does that have to do with what belmoreira is asking? | |
| 13:30:24 | bauzas | maybe I misunderstood | |
| 13:30:37 | belmoreira | if I point them to the global placement doesn't it means that I do the transition to cellV2 in Ocata? | |
| 13:30:43 | dansmith | belmoreira: no | |
| 13:30:55 | belmoreira | because then I need to do all the node/cells mappings | |
| 13:30:59 | dansmith | oh | |
| 13:31:00 | dansmith | hmm | |
| 13:31:03 | bauzas | wait | |
| 13:31:07 | mriedem | no | |
| 13:31:14 | mriedem | placement doesn't know anything about host mappings | |
| 13:31:24 | bauzas | for step #1 Ocata, a single cellv2 with multiple cellsv1 could work, right? | |
| 13:31:24 | dansmith | mriedem: but with claims in pike it'll mess him up | |
| 13:31:30 | mriedem | dansmith: he's moving to ocata | |
| 13:31:41 | dansmith | mriedem: I know | |
| 13:31:53 | dansmith | mriedem: but if he builds all this data in ocata, he'll be forced to move to v2 in pike immediately | |
| 13:32:12 | mriedem | well, cells v2 is required in ocata too | |
| 13:32:17 | mriedem | we have a blocker migration for that in the api db | |
| 13:32:20 | belmoreira | dansmith I'm fine moving to cellsV2 in pike | |
| 13:32:36 | dansmith | mriedem: for v2 setup yeah, | |
| 13:32:52 | dansmith | but the thing that global placement will affect for him is the scheduling in pike | |
| 13:33:03 | dansmith | otherwise it's just accounting in newton-ocata, and should be fine to be global | |
| 13:33:10 | dansmith | if he's going to switch in pike, then that should be okay | |
| 13:33:20 | mriedem | because scheduler in cell1 could pick a compute node in cell2? | |
| 13:33:26 | bauzas | dansmith: wait | |
| 13:33:33 | dansmith | wait, ocata did placement-based selection actually didn't it? | |
| 13:33:36 | dansmith | just no claims | |
| 13:33:40 | mriedem | correct | |
| 13:33:47 | dansmith | right, damn, I forgot about that | |
| 13:33:50 | bauzas | dansmith: if he still runs cells-scheduler (v1), he will end up in a nova_api service which is a single cell | |
| 13:33:55 | mriedem | belmoreira: you're using the FilterScheduler in the child cells right? | |
| 13:34:16 | belmoreira | mriedem: yes | |
| 13:34:25 | bauzas | dansmith: so, maybe I see where he's going, multiple placement APIs, each of them per cellv1 ? | |
| 13:34:31 | dansmith | bauzas: right | |
| 13:34:46 | belmoreira | bauzas: That's my point | |
| 13:34:49 | bauzas | that would be the easiest I feel | |
| 13:35:10 | dansmith | so if he has a global placement, ocata scheduler will get back hosts from all cells, and then try to do a ComputeNode lookup of those in the cell and only find some of them | |
| 13:35:36 | bauzas | sure, that won't work, hence placement per cell | |
| 13:35:43 | bauzas | sorry about the original confusion | |