Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-08
14:34:45 mriedem cdent: comment 16 is the summary on the perf part of it
14:34:58 efried gibi: It probably makes sense in context, for someone who has that flow (1)(2)(3) in their head. I'll just leave a note on the review for future me and +2. Thanks for bearing with me.
14:35:14 gibi efried: thanks
14:35:32 cdent mriedem: yeah, thanks that helps
14:36:14 mriedem unrelated to listing servers, there are known inefficiencies down in the nova/network/neutronv2/api.py code where nova makes a bunch of small targeted requests to neutron for resources rather than bigger batch requests
14:37:25 mriedem stuff like https://review.opendev.org/#/c/465792/
14:38:30 cdent excellent, thanks
14:38:53 mriedem there is an abandoned wip patch related to that from someone at huawei that did a much more extensive refactor to batch up the queries
14:39:16 cdent shame about that
14:39:22 mriedem well, it was pretty crazy
14:39:34 mriedem they are probably running it in their public cloud though...
14:39:50 mriedem this: https://review.opendev.org/#/c/457845/
14:39:54 cdent I bet, but if it could someday see the light of day (in a better form?) that would be grand
14:40:59 mriedem if someone were serious about that effort, i think we'd want some before and after profiling numbers like what you did in placement to justify the effort
14:41:31 mriedem i know windriver cared about that stuff because they have users with vms that have like 16 ports attached
14:41:44 mriedem *nfv users
14:42:36 cdent I suspect that it would be of benefit to vmware with their n-thousand instances in one nova-compute mess, but...human resources...
14:45:22 gibi stephenfin: quick question in https://review.opendev.org/#/c/686801/3//COMMIT_MSG@9
14:45:25 mriedem alternatively neutron grows an api that is essentially a view
14:45:42 mriedem i think ^ was bantered about since icehouse days
14:45:51 stephenfin gibi: Yup, that's what I meant. My bad
14:46:17 gibi stephenfin: no worries, I just wanted to 100% sure you did what you wanted to do
14:46:24 stephenfin all good :)
14:46:39 gibi :)
14:56:41 mriedem cdent: i've restored https://review.opendev.org/#/c/465792/ to see if i can rebase that since apparently i got it working with kevinbenton's help at one point, and then see if i can tease out some before/after times in a local devstack
14:56:57 mriedem my guess is the server would need to have a few ports attached to notice any different
14:56:59 mriedem *difference
15:01:49 dansmith mriedem: I was under the impression from your doc that "tox -e api_samples" would create samples I used in the new test I added
15:02:39 mriedem s/your/the/
15:02:55 mriedem it should generate samples under tox/docs/api_samples yeah
15:03:00 mriedem for the functional api samples tests you run
15:03:11 dansmith do I need to create the microversion dir or something?
15:03:17 mriedem yeah i think so
15:03:21 dansmith tox -eapi_samples didn't seem to actually run anything though, actually
15:03:35 mriedem b/c it's tox -e api-samples
15:03:36 mriedem not api_samples
15:03:40 mriedem is that a typo in the doc?
15:03:45 dansmith gah
15:03:51 dansmith no
15:04:12 dansmith typo on my end, coupled with I guess I still have that old tox that doesn't complain
15:04:13 mriedem you must have a busted version of tox because that would normally fail if you specify an env that doesn't exist
15:04:17 mriedem yup
15:04:32 mriedem i've got 3.8.0
15:04:44 dansmith I've got 3.crusty
15:06:52 dansmith still no dice, it fails with looking for those files
15:07:16 dansmith microversion directory was created (by me) and empty
15:09:06 dansmith do I need to create my tpl file manually?
15:09:59 gmann dansmith: yes, template file you need to create, tox env will generate the doc sample file for you
15:10:11 dansmith gmann: okay the docs don't make that very clear
15:10:24 efried alex_xu, bauzas: responded in https://review.opendev.org/#/c/685857/ (feature liaisons)
15:10:34 bauzas cool, on a meeint
15:10:38 bauzas meeting*
15:11:47 cdent efried: did you check if x-server-management url was used anywhere? it appears to be part of the reason why you've appended /auth to the auth_url and that jarred while reviewing
15:12:07 efried jarred like hell when I was writing it too :(
15:12:44 efried cdent: I checked my devstack before and after the patch, and the headers coming back with the version document are the same with keystone/password
15:13:23 efried cdent: note that the noauth middleware exists solely for test, which is confusing that it's a) not under a test/ subdir, and b) documented as conf'able. That confused (me and) stephenfin as well.
15:13:44 cdent yeah, I've left a comment about that
15:13:52 cdent and then fell in this x-server-management hole
15:14:01 cdent I think it is 9yo ancient history
15:15:21 efried cdent: I can't actually find reference to that header in keystone[auth|middleware]
15:15:39 cdent it's not anywhere in .tox/py37 when i grep
15:15:47 cdent see: https://wiki.openstack.org/wiki/Obsolete:API for the main reference i could find
15:16:47 openstackgerrit Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_dest compute method https://review.opendev.org/633293
15:16:47 openstackgerrit Matt Riedemann proposed openstack/nova master: Add PrepResizeAtDestTask https://review.opendev.org/627890
15:16:48 openstackgerrit Matt Riedemann proposed openstack/nova master: FUP for I66d8f06f19c5c631e33208580428aa843abb38d2 https://review.opendev.org/678951
15:16:48 openstackgerrit Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_source compute method https://review.opendev.org/634832
15:16:49 openstackgerrit Matt Riedemann proposed openstack/nova master: Add PrepResizeAtSourceTask https://review.opendev.org/627891
15:16:49 openstackgerrit Matt Riedemann proposed openstack/nova master: Add finish_snapshot_based_resize_at_dest compute method https://review.opendev.org/635080
15:16:50 openstackgerrit Matt Riedemann proposed openstack/nova master: Add FinishResizeAtDestTask https://review.opendev.org/635646
15:16:50 openstackgerrit Matt Riedemann proposed openstack/nova master: Execute CrossCellMigrationTask from MigrationTask https://review.opendev.org/635668
15:16:51 openstackgerrit Matt Riedemann proposed openstack/nova master: Plumb allow_cross_cell_resize into compute API resize() https://review.opendev.org/635684
15:16:51 openstackgerrit Matt Riedemann proposed openstack/nova master: Filter duplicates from compute API get_migrations_sorted() https://review.opendev.org/636224
15:16:52 openstackgerrit Matt Riedemann proposed openstack/nova master: Start functional testing for cross-cell resize https://review.opendev.org/636253
15:16:52 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle target host cross-cell cold migration in conductor https://review.opendev.org/642591
15:16:53 openstackgerrit Matt Riedemann proposed openstack/nova master: Validate image/create during cross-cell resize functional testing https://review.opendev.org/642592
15:16:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Add zones wrinkle to TestMultiCellMigrate https://review.opendev.org/643450
15:16:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Add negative test for cross-cell finish_resize failing https://review.opendev.org/643451
15:16:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Refresh instance in MigrationTask.execute Exception handler https://review.opendev.org/669012
15:16:55 openstackgerrit Matt Riedemann proposed openstack/nova master: Add negative test for prep_snapshot_based_resize_at_source failing https://review.opendev.org/669013
15:16:56 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add confirm_snapshot_based_resize_at_source compute method https://review.opendev.org/637058
15:17:02 efried cdent: results in codesearch all look crusty too.
15:17:19 cdent rackspace thing
15:18:28 efried last edit on that wiki page was 2013, but the content about that header wasn't changed since 2010.
15:18:46 efried (assume that's what you meant by 9yo)
15:21:21 artom dansmith, are you using the service user in your image pre-cache series?
15:21:44 dansmith artom: no, but I think the service token thing is automatic if configured no? /cc mriedem
15:22:05 dansmith artom: meaning not specifically, but service token will be important for this to work in a lot of cases
15:22:18 artom I thought you had to specifically get it? I'm trying to find other examples in the code
15:23:01 efried gibi: stephenfin: I'm going to edit the commit message on https://review.opendev.org/#/c/686801/ without rebasing everything on top of it and then fast approve it, cool?
15:23:16 mgagne mriedem: we no longer use the middleware you mentioned (to force volume-backed flavor)
15:23:28 gibi efried: cool with me
15:23:39 mriedem artom: it's built in if configured
15:23:40 dansmith artom: to use the service user as your credentials I think so, but isn't there some new thing that lets the service use its token to allow use of an expired user token?
15:23:43 dansmith I thought that was automatic
15:24:38 mriedem mgagne: oh really, what changed?
15:24:47 efried dansmith: You have to do a thing in code to get service user melded into your context. I don't think we're doing that for cinder yet. But once that's done, it will happen automatically if the service user is set up in your conf.
15:25:12 artom mriedem, so it's automagic from our POV? Ie, if we hit the image API with an expired token, it'll convert to use the nova service user?
15:25:14 dansmith efried: okay that doesn't jive with what mriedem just said
15:25:16 mriedem artom: see https://github.com/openstack/nova/blob/master/nova/service_auth.py#L36
15:25:26 mriedem efried: this is glance

Earlier   Later