Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-24
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 allocations https://review.openstack.org/457534
13:02:39 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: CLI for inventories https://review.openstack.org/457533
13:02:40 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: CLI for aggregates (v1.1) https://review.openstack.org/505643
13:02:40 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: CLI for usages https://review.openstack.org/457535
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:41 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: CLI for resource classes (v1.2) https://review.openstack.org/511182
13:02:42 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: [WIP] CLI for traits (v1.6) https://review.openstack.org/514643
13:02:42 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: [WIP] RP delete inventories (v1.5) https://review.openstack.org/514642
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:43 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: [WIP] Resource class set (v1.7) https://review.openstack.org/514644
13:02:44 openstackgerrit Andrey Volkov proposed openstack/osc-placement master: [WIP] CLI allocation candidates (v1.10) https://review.openstack.org/514647
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: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 ProviderSummaryList object https://review.openstack.org/514198
13:04:44 openstackgerrit Alex Xu proposed openstack/nova master: Add _get_traits_by_rp_ids method https://review.openstack.org/511184
13:04:45 openstackgerrit Alex Xu proposed openstack/nova master: Add AggregatedProviderSummary and AggregatedProviderSummaryList objects https://review.openstack.org/514200
13:04:45 openstackgerrit Alex Xu proposed openstack/nova master: Add more caches for the ProviderSummary https://review.openstack.org/514199
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:46 openstackgerrit Alex Xu proposed openstack/nova master: placement: rewrite AllocationCandidates.get_by_filters https://review.openstack.org/479766
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:04:47 openstackgerrit Alex Xu proposed openstack/nova master: Add has_resources method to the AggregatedProviderSummary object https://review.openstack.org/514650
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 dansmith mriedem: but with claims in pike it'll mess him up
13:31:24 bauzas for step #1 Ocata, a single cellv2 with multiple cellsv1 could work, right?
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 mriedem it will work,
13:35:43 bauzas sorry about the original confusion
13:35:47 mriedem because as dan just said,
13:35:52 dansmith it'll be massively inefficient though
13:35:55 mriedem the db is only going to return compute nodes with uuids in some list
13:36:12 bauzas ah yeah correct, we lookup per cell
13:36:56 dansmith belmoreira: what is your preference? would you rather some inefficiencies for a while to keep a global placement so you can easily switch,
13:37:07 dansmith or would you prefer separate placements and avoid committing right away,

Earlier   Later