| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-08 | |||
| 10:35:37 | bauzas | but the reporter used a Pike version | |
| 10:42:47 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: RP list: member_of and resources parameters (v1.3, v1.4) https://review.openstack.org/511183 | |
| 10:42:47 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: RP delete inventories (v1.5) https://review.openstack.org/514642 | |
| 10:42:48 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 10:42:48 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for traits (v1.6) https://review.openstack.org/514643 | |
| 10:42:49 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 10:42:49 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646 | |
| 10:42:50 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] Get resource provider by uuid or name https://review.openstack.org/527791 | |
| 10:47:35 | sticker | bauzas: that reporter is me if you need any more info | |
| 10:47:53 | sticker | it actually stopped us from being able to live migrate instances when the permissions were root:root | |
| 11:07:36 | stephenfin | bauzas: https://bugs.launchpad.net/reno/+bug/1748164 | |
| 11:07:37 | openstack | Launchpad bug 1748164 in reno "Reno doesn't scale" [Undecided,New] | |
| 11:07:50 | stephenfin | I've found a _tonne_ of bugs in reno this morning :( | |
| 11:15:08 | openstackgerrit | Merged openstack/nova master: Remove a duplicate colon https://review.openstack.org/542109 | |
| 11:40:08 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 11:40:08 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for traits (v1.6) https://review.openstack.org/514643 | |
| 11:40:09 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 11:40:09 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646 | |
| 11:40:10 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] Get resource provider by uuid or name https://review.openstack.org/527791 | |
| 12:04:58 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646 | |
| 12:04:58 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 12:04:59 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 12:04:59 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] Get resource provider by uuid or name https://review.openstack.org/527791 | |
| 12:23:02 | m3m0 | Hello guys, I'm trying to install nova from source using the branch stable/pike on arch using python 2.7.14 and python 3.6.4 and I keep getting this error when trying to run ANY nova-manage command, even --help https://etherpad.openstack.org/p/nova_error_retry_on_request | |
| 12:23:38 | m3m0 | have you seen this? | |
| 13:14:30 | bauzas | sticker: hey | |
| 13:14:37 | bauzas | sorry was at lunch et al. | |
| 13:14:59 | bauzas | sticker: I just closed your bug because I tried to get some knowledge on what would the best option for config | |
| 13:15:14 | m3m0 | afer some debugging, I had to remove the parameter retry_on_request on 4 functions and it's "working" | |
| 13:15:23 | bauzas | and looks to me there is a consensus on having dynamic_ownership=1 as the base value for Nova | |
| 13:15:56 | sticker | bauzas: yeah, unfortunately for me, the NetApp recommendation is still to set that to 0 when integrating with their SAN :/ | |
| 13:16:16 | sticker | I'll have to find some other way around it | |
| 13:16:18 | bauzas | sticker: feels like it's a larger problem than just it looks like now | |
| 13:16:33 | bauzas | but I'm not a console expert, neither a libvirt one | |
| 13:17:44 | bauzas | sticker: one option for you would be to run a remote console and not ask for a single file | |
| 13:17:53 | bauzas | https://docs.openstack.org/nova/pike/admin/remote-console-access.html | |
| 13:18:10 | sticker | maybe i'll see if i can get some more detail and come back to it. when i hit the issue i wasn't able to live migrate anything (would just fail with a permissions error) | |
| 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? | |