| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-07 | |||
| 16:55:38 | cdent | bbs | |
| 16:56:09 | melwitt | I think affinity scheduling doesn't work for multi-cell | |
| 16:56:22 | bauzas | sean-k-mooney: well, it requires a real nova deployment tbh | |
| 16:56:36 | mriedem | melwitt: that would be broken since pike right? | |
| 16:56:44 | openstackgerrit | Merged openstack/nova master: Test case: new standard resource class unusable https://review.openstack.org/539732 | |
| 16:56:49 | melwitt | mriedem: yes | |
| 16:56:54 | melwitt | for multi-cell only | |
| 16:57:00 | sean-k-mooney | bauzas: to test schduling. not really it really just needs the right db entries | |
| 16:57:01 | bauzas | because retries mechanism w/ caching has to be compared vs. no retries w/ placement | |
| 16:57:19 | bauzas | sean-k-mooney: I disagree | |
| 16:57:46 | sean-k-mooney | bauzas: if you include retries you are not testing just schduling you are also mesuing boot time and other factors | |
| 16:57:55 | mriedem | melwitt: can an instance group have members in multiple cells? | |
| 16:57:59 | bauzas | sean-k-mooney: if you wanna compare apples and apples, fire 1000 instances concurrently and see how many are in ERROR state and how long it took for booting the successful ones | |
| 16:58:10 | bauzas | that's for me the success criteria for comparison | |
| 16:58:32 | bauzas | mriedem: melwitt: I think we discussed that but we never implemented a solution | |
| 16:58:46 | sean-k-mooney | bauzas: sound like a rally test to me :) which is also valid just if you want to compare just the schduler part that is not need | |
| 16:58:46 | melwitt | mriedem: hmm. not sure | |
| 16:59:06 | sean-k-mooney | bauzas: rally is proably more meaning full however | |
| 16:59:10 | bauzas | melwitt: mriedem: I'm pretty sure the affinity filters don't take the cells awareness in mind | |
| 16:59:31 | bauzas | sean-k-mooney: I don't care about the tooling, I care more about the criterias | |
| 16:59:49 | bauzas | you can achieve that with a single curl script | |
| 17:00:32 | melwitt | bauzas: it's not that, it's that the InstanceGroup.get_hosts method doesn't query all cells, so it won't pick up any group members in a multi-cell environment | |
| 17:00:43 | sean-k-mooney | bauzas: yes but you cant just run curl with filter schduler and then run it agin after chaning the config | |
| 17:00:48 | openstackgerrit | Jacek Tomasiak proposed openstack/python-novaclient master: Fix listing of instances above API max_limit https://review.openstack.org/534222 | |
| 17:00:59 | sean-k-mooney | the db needs to be reset to the same state e.g. redploy | |
| 17:01:11 | bauzas | melwitt: oh, because get_hosts() is looking up at the cell DB ? | |
| 17:01:27 | bauzas | I was thinking we migrated instance_groups table to the API DB | |
| 17:02:14 | melwitt | bauzas: we did, but it's looking for members (instances). we aren't targeting to any cell, so it's looking at "local DB" which the API doesn't have | |
| 17:02:56 | bauzas | ah sad | |
| 17:03:09 | bauzas | couldn't we just look at the instance mappings ? | |
| 17:03:19 | melwitt | mriedem: so I think in multi-cell since we're not targeting any cells for the get_hosts query (for instances) we will always get an empty list because the API doesn't have a local cell DB, yeah? | |
| 17:03:19 | bauzas | and then the host mappings ? | |
| 17:03:53 | bauzas | I voted on jaypipes's twitter question with "instance groups" | |
| 17:03:58 | bauzas | don't blame me | |
| 17:04:19 | melwitt | bauzas: maybe. I didn't think of that. I added a scatter-gather to query all cells as a first proposal | |
| 17:04:54 | bauzas | melwitt: well, my proposition was stupid | |
| 17:05:08 | bauzas | melwitt: because the instance/host relationship is stored in the child DB | |
| 17:05:28 | bauzas | since RequestSpec doesn't tell where your instance is located (fortunately) | |
| 17:05:39 | melwitt | oh, right | |
| 17:06:23 | mriedem | yeah the instance mapping record has no association to the host mapping record | |
| 17:06:43 | bauzas | melwitt: what we could optimize tho is the scatter-gather method you wrote to only check the related cells by looking at the instance mappings table | |
| 17:06:47 | mriedem | melwitt: so this looks ok, but we can skip cell0 in your scatter/gather call | |
| 17:07:00 | bauzas | like, get all the cells from that member list | |
| 17:07:15 | bauzas | and then, query each cell to get each host from that list of member | |
| 17:07:19 | bauzas | members* even | |
| 17:07:19 | mriedem | bauzas: i'm not sure how much that's going to save perf wise | |
| 17:07:26 | melwitt | mriedem: yeah ... I had been thinking we could have group members in ERROR state in cell0 *but* they would have no host so indeed I think could skip | |
| 17:07:35 | bauzas | mriedem: well, you're right | |
| 17:07:43 | bauzas | mriedem: I don't expect more than 80 cells per deployment | |
| 17:07:43 | mriedem | melwitt: gonna want dansmith to also look at this | |
| 17:07:52 | bauzas | if we consider the big guys | |
| 17:07:56 | mriedem | bauzas: where do you come up with that number? | |
| 17:08:01 | bauzas | CERN, nope ? | |
| 17:08:04 | mriedem | dude, | |
| 17:08:10 | bauzas | isn't that 80 cells v1 ? | |
| 17:08:15 | mriedem | you've forgotten about M'FING EDGE?! | |
| 17:08:17 | dansmith | bauzas: yeah I think that's right | |
| 17:08:23 | mriedem | 10K cells | |
| 17:08:26 | mriedem | AT THE EDGE | |
| 17:08:41 | bauzas | anyway, 10K is a processable number | |
| 17:09:07 | bauzas | ask Jay to refrain Verizon then | |
| 17:09:11 | mriedem | melwitt: ideally we'd have a functional regression test for this, but likely need to do that on top separately | |
| 17:09:23 | openstackgerrit | Dan Smith proposed openstack/nova master: Make host_manager use scatter-gather and ignore down cells https://review.openstack.org/539617 | |
| 17:09:23 | openstackgerrit | Dan Smith proposed openstack/nova master: Make service all-cells min version helper use scatter-gather https://review.openstack.org/539590 | |
| 17:10:12 | bauzas | oh man, I'd love to have a tox -ereleasenotes -- -HEAD | |
| 17:10:24 | bauzas | it takes a while now to compute on my box | |
| 17:10:39 | bauzas | and I don't care of very old branches | |
| 17:11:03 | bauzas | hrw: that explains why I haven't provided a PS yet ^ | |
| 17:11:19 | stephenfin | bauzas: Sounds like a feature request for reno | |
| 17:11:22 | melwitt | mriedem: ack | |
| 17:11:30 | stephenfin | "Add ability to _squash_ release notes | |
| 17:11:44 | bauzas | stephenfin: I'm French | |
| 17:11:55 | bauzas | stephenfin: so I prefer complaining rather than asking for change | |
| 17:12:00 | hrw | bauzas: I do virtualenvs a lot. so nova has own one with tox from pip | |
| 17:12:01 | stephenfin | :) | |
| 17:12:23 | bauzas | hrw: that's not the problem | |
| 17:12:36 | stephenfin | hrw: Ah, he's referring the to something like the 'fast8' tox target | |
| 17:12:45 | hrw | ah | |
| 17:12:50 | stephenfin | i.e. a quick way to build releasenotes that have changed in the past release | |
| 17:12:55 | stephenfin | rather than everything, every time | |
| 17:13:01 | bauzas | hrw: the problem is that the tox target for the relnotes takes litterally *all* the notes from the ice age when we started using reno and compute *all of them* | |
| 17:13:16 | hrw | ouch | |
| 17:13:44 | stephenfin | bauzas: Definite feature request. I'd like to see that too | |
| 17:13:47 | bauzas | for a big project like Nova, it's super long on a fast laptop | |
| 17:13:58 | stephenfin | We can pay dhellmann in fancy tea or something | |
| 17:14:26 | bauzas | the fun of that is that reno tells you that the run which took 5 mins succeded but left your note untouched because you forgot to commit it | |
| 17:14:43 | bauzas | so you do another run | |
| 17:16:23 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Cleanup tox.ini https://review.openstack.org/534382 | |
| 17:16:24 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Remove 'tools/releasenotes_tox.sh' https://review.openstack.org/534383 | |
| 17:17:20 | stephenfin | bauzas: If you wanted to speed it up somewhat, ^ | |
| 17:17:30 | stephenfin | (re-uses virtualenvs where possible, among other things) | |
| 17:17:30 | bauzas | aaaand you do another run because you named your section 'feature' and not 'features' | |
| 17:25:17 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Provide basic data for AArch64 support matrix/functionality https://review.openstack.org/541728 | |
| 17:25:38 | openstackgerrit | Patricia Domingues proposed openstack/nova master: load up the volume drivers by checking architecture https://review.openstack.org/541393 | |
| 17:26:22 | bauzas | hrw: mriedem: https://review.openstack.org/541728 | |
| 17:27:18 | hrw | bauzas: cool, thanks! | |
| 17:40:56 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: XenAPI: Provide support matrix and doc for VGPU https://review.openstack.org/540808 | |
| 17:41:03 | openstackgerrit | Dan Smith proposed openstack/nova master: Make service all-cells min version helper use scatter-gather https://review.openstack.org/539590 | |
| 17:41:04 | openstackgerrit | Dan Smith proposed openstack/nova master: Make host_manager use scatter-gather and ignore down cells https://review.openstack.org/539617 | |
| 17:42:43 | bauzas | mriedem: some doc I'd love to see merged before RC1 https://review.openstack.org/#/c/540808/5 | |