Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-04
16:25:26 nammo melwitt: I see no error here
16:25:37 nammo melwitt: Can you please help?
16:26:10 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Debug race in delete-while-booting test https://review.openstack.org/461513
16:26:44 dansmith nammo: please see topic, this channel is for development
16:27:41 openstackgerrit Dan Smith proposed openstack/nova master: Move to proper target_cell calling convention https://review.openstack.org/458634
16:27:41 openstackgerrit Dan Smith proposed openstack/nova master: WIP: De-complicate some of the instance delete path https://review.openstack.org/458636
16:27:42 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Canary test against multi-cell devstack https://review.openstack.org/458537
16:27:42 openstackgerrit Dan Smith proposed openstack/nova master: Make target_cell() yield a new context https://review.openstack.org/458635
16:28:25 nammo dansmith: I see. Thanks
16:28:44 dansmith jaypipes: is the reason that first test worked because of the trait?
16:29:20 melwitt nammo: to close the loop on this, agree there's no problem in n-sch and you need to check your n-cpu logs for why it failed to spawn the instance on the selected host
16:29:34 mriedem dansmith: your access has been...granted
16:29:38 dansmith mriedem: thanks
16:30:13 nammo melwitt: Thanks :)
16:42:22 mriedem bauzas: jaypipes: edleafe: you guys will likely want to see this https://review.openstack.org/#/c/394857/ since it has to do with overhead calculation and overrides in the RT and virt drivers
16:43:25 edleafe mriedem: just reading the commit message on that seems like it's a misunderstanding
16:44:35 mriedem i'm -1ing now
16:45:49 mriedem edleafe: done - you can proofread it
16:45:50 mriedem :)
16:48:05 mriedem bauzas: replied in https://review.openstack.org/#/c/454899/ - that's how the online data migrations were done for adding uuid to aggregates and compute_nodes tables,
16:48:09 mriedem not sure that's worth a -1
16:48:16 mriedem but maybe others have strong opinions
16:49:37 dansmith mriedem: I kinda like them in the object file, but I don't think you should change it just for that
16:50:10 edleafe mriedem: added my own -1 and explanation
16:52:33 jaypipes dansmith: yes. first test passed because of the trait.
16:52:47 dansmith jaypipes: yeah, ack
16:58:04 openstackgerrit Jackie Truong proposed openstack/nova master: Encode encryption key passed to dmcrypt https://review.openstack.org/462674
17:00:53 openstackgerrit Jay Pipes proposed openstack/nova master: placement: tests for non-shared with shared https://review.openstack.org/461899
17:00:54 openstackgerrit Jay Pipes proposed openstack/nova master: placement: test for agg association not sharing https://review.openstack.org/461901
17:00:55 openstackgerrit Jay Pipes proposed openstack/nova master: placement: shared resources when finding providers https://review.openstack.org/461574
17:00:55 openstackgerrit Jay Pipes proposed openstack/nova master: placement: test non-shared out of inventory https://review.openstack.org/461900
17:00:56 openstackgerrit Jay Pipes proposed openstack/nova master: placement: get providers sharing capacity https://review.openstack.org/460798
17:01:16 jaypipes dansmith, edleafe, cdent: ok, I believe I've responded or fixed all your review comments on above series.
17:01:30 jaypipes other than the moving of the long SQL code comment somewhere...
17:01:37 dansmith jaypipes: gdi jay, you pushed too fast, I wanted to claim that review credit for my commit message nit :P
17:01:39 jaypipes we can bikeshed about where to move that later, ok?
17:02:00 jaypipes heh, sorry dansmith
17:02:09 dansmith *shakes fist*
17:02:18 dansmith mriedem is calling me out BY NAME in public so I have to up my game
17:02:53 edleafe jaypipes: for the record, I like the comment within the method. I just don't like a module-level method in the middle of the object class definitions
17:03:37 jaypipes edleafe: noted. :)
17:03:50 cdent blue
17:03:57 dansmith heh
17:13:07 dansmith jaypipes: in SQLandia, if I to a SELECT * WHERE longstring="uuidthing",
17:13:21 dansmith is that much more efficient than doing an IN check for a list of one?
17:13:23 openstackgerrit Ed Leafe proposed openstack/nova master: Add a convenience attribute for reportclient https://review.openstack.org/462679
17:13:23 openstackgerrit Ed Leafe proposed openstack/nova master: WIP: Don't delete allocation if instance being scheduled https://review.openstack.org/460177
17:13:28 edleafe dansmith: ^^
17:13:35 dansmith meaning SELECT * WHERE longstring IN ("uuidthing") or whatever the syntax is
17:13:43 dansmith edleafe: woot
17:13:48 edleafe dansmith: just addressed the comments. Will work on the rest now
17:13:50 mriedem on an indexed column
17:13:59 dansmith mriedem: ah, yeah, good point the index
17:14:13 mriedem dansmith: well, after https://review.openstack.org/#/c/454887/ that is
17:14:29 jaypipes dansmith: all optimizers I know of will rewrite the latter to the former.
17:14:44 dansmith jaypipes: ah, okay
17:14:57 dansmith actually, I think I remember seeing warnings about doing that
17:18:31 mriedem dansmith: if you see the patch after it, i could have ComputeNode.get_by_uuid call ComputeNodeList.get_all_by_uuids and internally handle the [uuid] and [0], but i just wondered about the IN performance
17:19:06 dansmith mriedem: yeah
17:20:08 mriedem but maybe this is a small enough difference that it doesn't really matter and we could just squash those two changes, and just hide it all in the object code
17:20:46 dansmith yeah, seems like it might be
17:21:09 mriedem http://stackoverflow.com/questions/9926433/mysql-performance-in-clause-vs-equals-for-a-single-value
17:21:23 mriedem "There is no difference between the MySQL statements, and the MySQL optimiser will transform the IN to the = when IN is just one element. Don't bother."
17:21:30 mriedem so what jaypipes said
17:22:33 openstackgerrit Dan Smith proposed openstack/nova master: WIP: De-complicate some of the instance delete path https://review.openstack.org/458636
17:22:34 openstackgerrit Dan Smith proposed openstack/nova master: Make target_cell() yield a new context https://review.openstack.org/458635
17:22:34 openstackgerrit Dan Smith proposed openstack/nova master: Move to proper target_cell calling convention https://review.openstack.org/458634
17:22:35 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Canary test against multi-cell devstack https://review.openstack.org/458537
17:25:58 peter-hamilton mriedem: sorry, i was out - not a problem, i just wanted to put it in the queue :)
17:55:09 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle uuid in HostAPI._find_service https://review.openstack.org/461519
17:55:09 openstackgerrit Matt Riedemann proposed openstack/nova master: db api: add service_get_by_uuid https://review.openstack.org/461428
17:55:10 openstackgerrit Matt Riedemann proposed openstack/nova master: objects: add ComputeNode.get_by_uuid method https://review.openstack.org/461448
17:55:10 openstackgerrit Matt Riedemann proposed openstack/nova master: objects: add Service.get_by_uuid method https://review.openstack.org/461429
17:55:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Add online data migration for populating services.uuid https://review.openstack.org/454899
17:55:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle uuid in HostAPI.compute_node_get https://review.openstack.org/461532
17:55:12 openstackgerrit Matt Riedemann proposed openstack/nova master: Add uuid to service.update notification payload https://review.openstack.org/461473
17:57:27 openstackgerrit Matt Riedemann proposed openstack/nova master: objects: add ComputeNode.get_by_uuid method https://review.openstack.org/461448
17:57:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle uuid in HostAPI._find_service https://review.openstack.org/461519
17:57:28 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle uuid in HostAPI.compute_node_get https://review.openstack.org/461532
17:57:29 openstackgerrit Matt Riedemann proposed openstack/nova master: Add uuid to service.update notification payload https://review.openstack.org/461473
17:58:18 dansmith mriedem: pushing the same set three times in a row is fooling nobody
17:58:29 mriedem 2 times in a row
17:58:44 dansmith N times in a row
18:04:58 mriedem gah, plus i screwed up the topic branch
18:05:32 efried mriedem mordred jaypipes [service catalog bp] I'd like to settle this issue of determining interface if not otherwise specified.
18:05:43 mriedem pistols at dawn it is
18:05:56 efried At some point in the early (at least in my involvement) discussions, there was talk of trying the known ones in order.
18:06:02 efried This is a dict lookup, so that's cheap.
18:06:14 mriedem maybe the idea with starting using internal first is to avoid defaulting to public in ksa?
18:06:16 efried But on the other side, there's "use the default from ksa"
18:06:30 efried ...which is "public", for whatever that's worth.
18:06:44 efried Can any of you remember the rationale behind the "loop through 'em" suggestion?
18:07:04 mriedem efried: that was mordred or jaypipes' idea i thought, but presumably to hit the internal/admin urls before public
18:07:09 efried mriedem Yeah, starting with "internal" seemed like a more... uh... "secure" idea.
18:07:15 mriedem since today ops are probably using internal/admin
18:08:08 efried Okay, right now I've got internal->public->admin; that's an easy swap. But question remains: do we want to do the loop thing at all?
18:09:10 mriedem i don't really feel strongly either way, looping over a hard-coded list which might not match what's actually in the service catalog seems weird to me
18:09:52 efried mriedem Yeah, that makes me a tad uncomfortable too. Maybe mordred can point us to a way to get that list from ksa.
18:10:51 mriedem https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/identity/base.py#L173
18:11:01 mriedem the docs say one thing but i'm pretty sure interface is open ended

Earlier   Later