| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-08 | |||
| 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: CLI for traits (v1.6) https://review.openstack.org/514643 | |
| 11:40:08 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 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:09 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 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: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 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:59 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: [WIP] Get resource provider by uuid or name https://review.openstack.org/527791 | |
| 12:04:59 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 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? | |
| 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* | |