| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-08 | |||
| 13:18:41 | sticker | i'm sure i'm not the only one that would be bitten by it | |
| 13:19:28 | bauzas | oops, wrong link I meant https://docs.openstack.org/nova/latest/admin/remote-console-access.html#serial-console | |
| 13:19:53 | bauzas | sticker: and yeah, I understand your concern | |
| 13:21:23 | sticker | bauzas: all good.. thanks for looking at it :) | |
| 13:23:09 | jaypipes | morning supernovas | |
| 13:25:01 | openstackgerrit | Merged openstack/nova stable/pike: Fix pike GA prelude release note https://review.openstack.org/541498 | |
| 13:27:50 | bauzas | jaypipes: I don't feel like I was about to explode in the next years | |
| 13:28:02 | bauzas | and don't treat me of black hole | |
| 13:29:07 | efried | Heh. Good morning jaypipes | |
| 13:29:44 | efried | jaypipes: I should have something pretty interesting coming down the "pipes" for you later today | |
| 13:30:15 | efried | jaypipes: But if you get a few minutes, I'd like to pick your brain about this concept of "aggregate distance" to represent [anti-]affinity. | |
| 13:30:22 | efried | ...at some point today. | |
| 13:33:46 | jaypipes | efried: ok, sounds good to me. I'll be working on the spec for solving mgagne's problems around host aggregate allocation ratios. | |
| 13:33:59 | efried | Cool | |
| 13:34:20 | cdent | efried: just to throw a thing in your brain on that: I'd like to see anti-affinity and affinity represented internally as numbers on the same scale -something to +something, rather than two different scales. If that's possible. I'm not certain it is, but mathematically it could make for a simpler representation | |
| 13:34:48 | cdent | I also wonder if the UI should represent it as one scale, but that may be too much to bear. | |
| 13:35:11 | efried | cdent: I agree with that as a long-term goal for some generic mechanism. | |
| 13:37:36 | efried | cdent: My concern is that this "aggregate distance" solution - which may give us that - is going to be an order of magnitude tougher to implement, model, and use than what I talked about a couple days ago with edleafe and sean-k-mooney and cfriesen. | |
| 13:37:40 | bauzas | jaypipes: have you seen my workaround for the aggregate ratios ? | |
| 13:37:56 | bauzas | jaypipes: tl;dr set on every compute ratios to 9999.0 | |
| 13:37:57 | efried | cdent: But that's why I want to understand the "aggregate distance" thing before I go off and write up that spec. | |
| 13:38:06 | efried | cdent: Is that a concept you comprehend? | |
| 13:38:23 | cdent | efried: it is not fresh in my mind | |
| 13:38:27 | efried | k | |
| 13:40:01 | bauzas | jaypipes: needs some SQL-fu on execution plans https://review.openstack.org/#/c/531117/8/nova/db/sqlalchemy/api.py | |
| 13:41:53 | bauzas | jaypipes: basically, say I have a long list of rows with no index on timestamps (AFAIK), is it OK to just filter by some things and then ordering by those timestamps ? | |
| 13:42:09 | bauzas | because the temp table should be small | |
| 13:48:13 | efried | bauzas: Timestamps are internally represented as long integers, I believe. Which SQLs are really good at sorting. Are you concerned about performance or about data integrity? | |
| 13:48:24 | bauzas | performance | |
| 13:48:37 | efried | Yeah, compared to some of the other stuff we're doing, should be a drop in the bucket. | |
| 13:48:40 | bauzas | when I was an operator, I *never* sorted by dates | |
| 13:48:59 | efried | I could be wrong of course :) | |
| 13:49:07 | bauzas | it's just a perf killer | |
| 13:49:28 | bauzas | but if you put a where clause *before* the order, that should be fine | |
| 13:49:31 | efried | bauzas: Did you use SQL Server 2008 perchance? | |
| 13:49:46 | bauzas | efried: SQL2K even | |
| 13:50:11 | bauzas | I mean, I was in a company that was doing ASP and SQL Server 2K | |
| 13:50:15 | bauzas | then PHP | |
| 13:50:40 | efried | bauzas: The other thing to consider is whether there's actually any need to sort. Are the rows created in chronological order already? | |
| 13:50:45 | bauzas | can you just imagine how much I loved my job | |
| 13:50:56 | efried | bauzas: Heh, that sounds like my gig from 2000 to 2003 | |
| 13:51:10 | bauzas | ... it was in 2011 ... | |
| 13:51:13 | efried | actually from 1998 | |
| 13:51:20 | bauzas | call it tech deby | |
| 13:52:23 | efried | So yeah, if the rows are already sorted in chrono order, you can cheat. Either don't sort, because they'll already come back in the right order; or sort by the primary key ID (assuming that's an auto int). | |
| 13:53:41 | bauzas | anyway | |
| 13:53:51 | bauzas | looks like the index can solve most of the problem | |
| 13:53:59 | bauzas | given it's on the top patch, I +Wd | |
| 13:54:11 | bauzas | but I'm curious if that index was needed | |
| 13:55:09 | bauzas | in general, we put indexes on dates because we like to ask in a where clause something like "where created > today - 1yr" | |
| 13:55:18 | bauzas | but here, it's a order by | |
| 13:55:36 | bauzas | so AFAIK in the SQL execution plan, it goes at the last | |
| 13:55:44 | mriedem | bauzas: if you're talking about https://review.openstack.org/#/c/530429/, it's used in a filter | |
| 13:55:46 | mriedem | for changes-since | |
| 13:55:54 | bauzas | mriedem: yeah | |
| 13:56:15 | bauzas | ok, so the order by is required | |
| 13:56:20 | bauzas | oops | |
| 13:56:26 | bauzas | so the index is required anyway | |
| 13:56:34 | mriedem | the index is for the filter, | |
| 13:56:37 | mriedem | we order by created_at | |
| 13:56:39 | mriedem | not updated_at | |
| 13:56:41 | bauzas | but I'm still curious | |
| 13:57:51 | bauzas | meeting time in 3 mins, right? | |
| 13:58:01 | gibi | right | |
| 13:58:28 | bauzas | cool | |
| 14:07:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Workaround glanceclient bug when CONF.glance.api_servers not set https://review.openstack.org/541008 | |
| 14:07:38 | mordred | mriedem: yes, I would like it if GET /flavors/detail included the extra specs - but it's not *super* important so I certainly wouldn't prioritize it just for me :) | |
| 14:09:05 | mriedem | mordred: just getting user feedback; our product team wants it because they have a time limit on loading flavors in the UI, and they have to first get all flavors and then for each one, get their extra specs, and that can timeout the UI panel | |
| 14:09:34 | mriedem | i actually found a blueprint from 4 years ago for the same thing when we were doing nova v3 api | |
| 14:12:10 | mordred | mriedem: yah - I have the same issue in shade (minus the timelimit) because I was dumb and made the default behavior of list_flavors be to add the extra-specs by default - so doing a list_flavors on a cloud with a lot of flavors takes *forever* | |
| 14:13:12 | mordred | mriedem: I swapped the default behavior when we merged the shade code into the sdk repo, but I do think it would be nice to just get it all at once | |
| 14:13:30 | mriedem | we actually load it all up from the db too, so we have it in the api, we just never returned it | |
| 14:16:16 | mriedem | ameeda: should be an easy bug to fix https://bugs.launchpad.net/nova/+bug/1746386 | |
| 14:16:18 | openstack | Launchpad bug 1746386 in OpenStack Compute (nova) "Bindep does not catch missing libpcre3-dev on Ubuntu" [Low,Confirmed] | |
| 14:16:39 | ameeda | mriedem: thanks a lot | |
| 14:27:19 | ingy | mordred: o/ | |
| 14:35:35 | jianghuaw | bauzas, mriedem: I guess we should pick up this small patch which only corrects the example for the vGPU config option: https://review.openstack.org/#/c/539183/ | |
| 14:37:02 | bauzas | jianghuaw: right, I catched it but forgot to update it | |
| 14:37:16 | bauzas | jianghuaw: FWIW, we don't need brackets | |
| 14:37:34 | jianghuaw | bauzas, yes. | |
| 14:37:45 | mordred | ingy: heya! | |
| 14:38:00 | bauzas | jianghuaw: I mean, we don't need quotes | |
| 14:38:29 | jianghuaw | it should work regardless there is quotes. | |
| 14:38:37 | ingy | mordred: hi. msged you yesterday but not sure you got it. | |
| 14:39:17 | ingy | cdent told me to look for you here... | |
| 14:40:06 | jianghuaw | bauzas, I mean oslo will parse it correctly. | |
| 14:40:08 | mriedem | jianghuaw: another question inline | |
| 14:41:47 | openstackgerrit | Adrien Cunin proposed openstack/nova master: Fixed auto-convergence option name in doc https://review.openstack.org/542237 | |
| 14:42:26 | jianghuaw | mriedem, yes. I will update it. thanks. | |
| 14:43:16 | cdent | mriedem: I'm continuing my explorations with slamming placement etc. and am now wondering: What are the reasons (if any) that we don't allow nova-scheduler to have worker processes? | |
| 14:43:52 | bauzas | cdent: IIRC, that was because we were having racinesses | |
| 14:44:02 | bauzas | I can find old threads | |
| 14:44:10 | cdent | bauzas: thanks | |
| 14:44:26 | mriedem | here you go https://review.openstack.org/#/c/159382/ | |
| 14:44:29 | mriedem | cdent: bauzas: ^ | |
| 14:44:40 | mriedem | that's a huawei patch so i've got'er starred :) | |
| 14:44:44 | bauzas | ideally, I just feel we should pursue the idea to drop the whole n-sch service and do the thing in the conductor | |
| 14:45:04 | stephenfin | dansmith: Highlighted the RPC 5.0-ish things I'm aware of here https://review.openstack.org/#/c/541005/ | |
| 14:45:13 | mriedem | cdent: fwiw, i've had a todo sitting here to update nova-next in devstack to run with 2 nova-scheduler processes | |
| 14:45:21 | dansmith | stephenfin: thanks will look in a sec | |