Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-15
17:34:30 dansmith okay
17:38:26 dansmith hmm, she's not around and it's friday.. perhaps someone else should just fix it up for her?
17:38:49 mriedem yeah first thing is pulling it from the gate
17:38:55 mriedem so i guess i'll jack the commit message
17:39:21 openstackgerrit Matt Riedemann proposed openstack/nova master: Plumbing required in servers ViewBuilder to construct partial results https://review.openstack.org/635146
17:39:51 openstackgerrit Lajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.69 https://review.openstack.org/637234
17:52:53 mriedem alright then, looks like i'm going to have lunch and then i'll add the links and such, and probably also fix up my comments in the docs patch at the end
17:53:18 mriedem so much for cross-cell resize fun today
19:34:47 mriedem dansmith: here it comes
19:35:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Plumbing required in servers ViewBuilder to construct partial results https://review.openstack.org/635146
19:35:03 openstackgerrit Matt Riedemann proposed openstack/nova master: API microversion 2.69: Handles Down Cells https://review.openstack.org/591657
19:35:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Add context.target_cell() stub to DownCellFixture https://review.openstack.org/637182
19:35:04 openstackgerrit Matt Riedemann proposed openstack/nova master: API microversion 2.69: Handles Down Cells Documentation https://review.openstack.org/635147
19:37:57 dansmith mriedem: omg -1 so hard
19:39:30 mriedem here it comes
19:39:40 openstackgerrit Matt Riedemann proposed openstack/nova master: Plumbing required in servers ViewBuilder to construct partial results https://review.openstack.org/635146
19:39:41 openstackgerrit Matt Riedemann proposed openstack/nova master: API microversion 2.69: Handles Down Cells https://review.openstack.org/591657
19:39:41 openstackgerrit Matt Riedemann proposed openstack/nova master: Add context.target_cell() stub to DownCellFixture https://review.openstack.org/637182
19:39:42 openstackgerrit Matt Riedemann proposed openstack/nova master: API microversion 2.69: Handles Down Cells Documentation https://review.openstack.org/635147
19:41:57 dansmith mriedem: and the ones above are unchanged so I can stamp them?
19:42:31 mriedem minor changes
19:42:38 mriedem the api samples had to change b/c of the links key in the response
19:44:58 dansmith sure, but I see other stuff too
19:45:00 dansmith anyway, looks okay
19:45:30 mriedem cdent: you want to propose for stable/rocky and friends? https://review.openstack.org/#/c/636701/
19:45:36 mriedem or send out the gary signal?
19:46:15 mriedem dansmith: i'm +2 on the docs change at the end if you want to flush it all
19:46:23 mriedem i think you do
19:48:32 dansmith 420 lines..
19:49:04 mriedem you live in portland, you can get down with that
19:49:49 dansmith heh
19:59:13 openstackgerrit Corey Bryant proposed openstack/nova master: add python 3.7 unit test job https://review.openstack.org/610694
19:59:53 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: API microversion 2.69: Handles Down Cells https://review.openstack.org/579563
20:01:00 dansmith mriedem: comments on the docs patch.. I could just +2 and we could discuss/fix later, but probably not as much of a rush on that one I'm thinking
20:04:38 tssurya mriedem, dansmith: you had to respin for the links part ? sorry about that and again my never-ending list of "thank you"'s
20:07:03 openstackgerrit Corey Bryant proposed openstack/python-novaclient master: add python 3.7 unit test job https://review.openstack.org/637290
20:11:31 mriedem dansmith: tssurya: i also just thought about this https://review.openstack.org/#/c/591657/44/nova/api/openstack/compute/services.py@78
20:13:38 tssurya mriedem: hmm so you want it to be false if those filters are passed ?
20:14:11 mriedem dansmith: yeah i'm ok with those docs changes
20:14:15 mriedem tssurya: idk, hence the question
20:14:34 mriedem tssurya: if we were being consistent, we'd set cell_down_support=False if there were any filters on the request
20:14:37 dansmith I don't really have an opinion on the servers stuff
20:14:40 dansmith er, services
20:14:54 mriedem but like i said, we're not filtering in the db query, we're doing it in python once we get results
20:14:58 mriedem so *shrug*?
20:16:18 tssurya yea
20:16:38 tssurya besides technically the edge cases are only for "listing servers" :D
20:17:10 tssurya at least in the docs and everywhere its only for the server details
20:19:46 mriedem oh well if the docs say so...
20:20:41 mriedem anyway i'm fine with the way it is, not really worth losing sleep over it
20:31:44 mriedem ConnectionError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Max retries exceeded with url: /packages/ed/39/15045ae46f2a123019aa968dfcba0396c161c20f855f11dea6796bcaae95/PyMySQL-0.9.3-py2.py3-none-any.whl (Caused by ReadTimeoutError("HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Read timed out. (read timeout=15)",))
20:31:44 mriedem looks like a whole bunch of 3rd party CIs are failing on this
20:43:30 fried_rice okay, but cmon, do we actually *need* PyMySQL?
20:43:55 melwitt nah
20:44:07 fried_rice tssurya: Did you see the patch I proposed to improve the ironic ufpt thing?
20:44:34 fried_rice gibi: Is it too late to make the bw part of the binding profile look more like the resource request syntax in extra specs?
20:45:10 tssurya fried_rice: saw the WIP, but didn't review it yet
20:45:36 fried_rice tssurya: Less about review, more about trying it in your env and seeing if it takes the 6h processing ironic nodes down to something sane.
20:46:07 tssurya haha we kind of hacked the bit of code that tries to do the N^2 thing already got the node up
20:46:11 tssurya for now
20:46:32 tssurya I will be able to try your patch only on Monday :(
20:46:42 fried_rice tssurya: yeah, IIUC you're only processing the one node, but that's not a long term solution.
20:46:44 fried_rice okay
20:47:04 tssurya but trust me getting that to work properly is our priority
20:47:08 fried_rice gibi: IMO that's a more consistent user experience; and then also we would get to use common code for parsing into RequestGroup etc.
20:47:21 tssurya your concern is for provider sharing right ?
20:48:10 fried_rice tssurya: That's one example. It's really a question of why that code is there in the first place: it's because upt is allowed to muck with anything in the ProviderTree object.
20:48:30 fried_rice tssurya: Like what if ironic actually *wanted* to dork with more than one node at a time?
20:53:00 tssurya fried_rice: since we are talking about why that code exists, can you give me a ore concrete example of when ironic would want that ?
20:53:21 tssurya like I am trying to understand more use cases for this whole thing
20:53:45 tssurya since I am pretty sure we don't need them for now right ?
20:53:54 tssurya or maybe I am missing some documentation
20:54:33 fried_rice tssurya: Yeah, I don't have a specific use case; I could only contrive hypothetical ones. It's just that update_provider_tree is a generic method which passes the *whole* ProviderTree object down to the virt driver for modification, and then update_from_provider_tree is responsible for flushing any changes back to placement.
20:54:50 fried_rice I really didn't want upt/ufpt to be tightly bound to specific virt drivers' implementations or needs in that regard.
20:55:11 fried_rice and it's specifically designed to be future-looking to when we have nested providers, sharing providers, etc.
20:55:24 fried_rice ...just like the code that broke your Queens performance :)
20:55:37 tssurya yea I get that, its just that for ironic I don't know how this would scale with the more nodes that we would keep adding in future
20:55:38 fried_rice ...which wasn't actually going to be used until... I think stein actually.
20:55:56 cdent mriedem: i'll either get to it or get gary, but yeah
20:55:59 fried_rice tssurya: Well, let's see how this does.
20:56:35 fried_rice tssurya: Note that there are already a number of anticipatory optimizations in that code.
20:56:53 fried_rice tssurya: Like the fact that we do local compares and only call out to placement if something has changed.
20:57:20 openstackgerrit melanie witt proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351
20:57:20 openstackgerrit melanie witt proposed openstack/nova master: Add user_id field to InstanceMapping https://review.openstack.org/633350
20:57:27 tssurya fried_rice: yea I mean as far as most of the things we do right now the flushes to placement are very less
20:57:29 fried_rice tssurya: I just didn't anticipate that iterating through a list would bring the service to its knees. Even if you had told me the list was going to be a couple thousand long.
20:58:43 tssurya fried_rice: of course yea we didn't know this as well until we timed this, our test env is not exactly the size of our actual prod env
21:03:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Check hosts have no instances for AZ rename https://review.openstack.org/509206
21:03:32 mriedem sounds like someone needs their nova-computes running on s390x mainframes
21:03:39 mriedem or Power9!
21:04:34 tssurya fried_rice: just saw your patch, so basically you are saving on the lookup time instead of iterating.. We will try this first thing Monday and let you know
21:04:57 openstackgerrit Matt Riedemann proposed openstack/nova master: Check hosts have no instances for AZ rename https://review.openstack.org/509206
21:05:21 fried_rice tssurya: Yes. We already have the list of UUIDs. Now instead of that loop taking O(N) to look up each node's provider object, it'll take O(1).
21:05:58 tssurya yeap nice
21:06:46 fried_rice tssurya: now, it's possible that that lookup wasn't the problem: it's possible that what's killing us is 1700 ProviderTree.data() calls (which copies the guts of the ProviderTree) plus 5100 compares of that information.
21:06:58 fried_rice that may be a tad harder to optimize.
21:08:08 fried_rice (...guts of the individual _Provider in the ProviderTree, that is)
21:15:18 tssurya yea you mean this part here (https://github.com/openstack/nova/blob/880327cc31fea7328d23355730d5458f3b74662b/nova/scheduler/client/report.py#L1440)
21:15:35 tssurya and then the set aggregates and inventories comparisions
21:24:34 melwitt mriedem: if I'm trying to remove the console-auth workaround in stein and nova-status upgrade check has the check for console auths, where it warns if compute services older than rocky are found and advises to set the [workarounds] option if so. if I'm removing the workaround, it seems like I should remove the upgrade check. is that right?

Earlier   Later