| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-25 | |||
| 18:59:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make TestRPC inherit from the base nova TestCase https://review.openstack.org/507239 | |
| 18:59:40 | mriedem | sdague: dansmith: ^ got distracted | |
| 19:01:43 | mriedem | damn pep8 | |
| 19:01:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make TestRPC inherit from the base nova TestCase https://review.openstack.org/507239 | |
| 19:14:40 | mriedem | alright danny boy, i've got a fresh devstack with the fake virt driver and noop quota driver, time to create 100 VMs | |
| 19:19:15 | sdague | mriedem: so, honestly, I wouldn't do it that way | |
| 19:19:25 | sdague | mriedem: let me take a different approach | |
| 19:26:57 | mriedem | i wonder if multi-create 100 vms will give me an http timeout | |
| 19:27:05 | cfriesen | policy question....would nova ever backport a microversion bump to a stable release? | |
| 19:27:19 | mriedem | nope | |
| 19:27:44 | mriedem | you want your embedded flavor thing in ocata don't you | |
| 19:27:59 | cfriesen | heh...nope. was just planning something | |
| 19:28:01 | sdague | cfriesen: microversions aren't really backportable | |
| 19:28:54 | cfriesen | was just wondering if I'd have to plan to be able to handle microversion bumps in bugfixes. | |
| 19:29:16 | cfriesen | this makes it easier | |
| 19:37:33 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239 | |
| 19:37:33 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add alternate hosts https://review.openstack.org/486215 | |
| 19:37:34 | openstackgerrit | Ed Leafe proposed openstack/nova master: Set the Pike release version for scheduler RPC https://review.openstack.org/507245 | |
| 19:42:02 | dansmith | mriedem: you're doing the fake virt devstack testing on my switch-to-the-new-thing patch? | |
| 19:42:38 | mriedem | dansmith: trying to get a baseline | |
| 19:42:44 | mriedem | straight curl with 100 instances is trivial | |
| 19:42:51 | mriedem | .004s | |
| 19:42:55 | mriedem | so booting 500 more | |
| 19:43:31 | mriedem | had to switch to curl to take out extra 5 seconds novaclient adds to nova list | |
| 19:43:41 | dansmith | heh | |
| 19:45:20 | openstackgerrit | Sean Dague proposed openstack/nova master: Break out BasicTestCase https://review.openstack.org/507253 | |
| 19:45:31 | sdague | mriedem: that's an alternative | |
| 19:53:44 | mriedem | commented | |
| 19:53:49 | mriedem | i like mine better but i'm biased | |
| 19:55:02 | openstackgerrit | ayoung proposed openstack/nova master: Admin API Policy contingent on is_admin_project https://review.openstack.org/384148 | |
| 19:55:44 | dansmith | I would rather not have another base-base-base test case class | |
| 19:55:56 | dansmith | I know it's not very OO, but we have a lot already | |
| 19:59:55 | mriedem | booting another 400 to get me to 1000 | |
| 20:00:00 | mriedem | i figure that's a nice round number, and is our default limit | |
| 20:00:37 | dansmith | mriedem: is that because you're not getting a large number to measure? | |
| 20:00:55 | mriedem | with 600 i'm getting up around 2 seconds | |
| 20:01:04 | melwitt | you're getting hundreds booted without any in ERROR state? | |
| 20:01:05 | dansmith | oh okay that's pretty reasonable | |
| 20:01:12 | mriedem | melwitt: f yeah | |
| 20:01:16 | mriedem | i'm da bomb | |
| 20:01:49 | melwitt | that's coolness | |
| 20:01:53 | mriedem | i have figured out how to hyperconverge this 8gb devstack vm | |
| 20:01:59 | mriedem | for hyper throughput | |
| 20:02:12 | mriedem | using state of the art best of breed solutions | |
| 20:02:52 | mriedem | melwitt: i can share my secret with you if you'll keep it quiet | |
| 20:03:00 | melwitt | heh | |
| 20:03:07 | mriedem | http://paste.openstack.org/show/621867/ | |
| 20:03:25 | mriedem | ha | |
| 20:05:49 | melwitt | ah, FakeDriver. good thinkin | |
| 20:08:27 | mriedem | also | |
| 20:08:37 | mriedem | (1) fake driver, (2) no quotas (3) no networking | |
| 20:08:41 | mriedem | because there are port quotas in neutron | |
| 20:08:46 | mriedem | default is 50 | |
| 20:09:16 | mriedem | so specify --nic none when doing nova boot | |
| 20:10:30 | mriedem | dansmith: when i pull your change down, i just have to restart the api right? | |
| 20:10:39 | melwitt | ah, right. cool | |
| 20:10:46 | dansmith | mriedem: yeah I would think so | |
| 20:11:07 | dansmith | er, yeah, definitely | |
| 20:11:26 | mriedem | 1000 | |
| 20:11:26 | mriedem | stack@devstack:~/devstack$ nova list | grep -c ACTIVE | |
| 20:11:38 | mriedem | alright, i guess i'll do curl like 10 times to get an average | |
| 20:14:37 | openstackgerrit | Ildiko Vancsa proposed openstack/nova-specs master: Add multiattach support to Nova https://review.openstack.org/499777 | |
| 20:23:22 | mriedem | dansmith: https://etherpad.openstack.org/p/nova-instance-list | |
| 20:23:31 | mriedem | takes 4.495s on average | |
| 20:23:35 | mriedem | to list 1000 instances | |
| 20:23:50 | mriedem | take a look at ^ and see if there is anything i'm doing wrong or should get before i pull your change down | |
| 20:24:02 | dansmith | you should multiply that value by ten | |
| 20:24:19 | mriedem | the average? | |
| 20:24:29 | dansmith | yes. | |
| 20:24:39 | mriedem | why | |
| 20:24:55 | dansmith | so that it will look really bad compared to whatever the number is that you get with my patch | |
| 20:25:04 | melwitt | haha | |
| 20:27:23 | mriedem | oh yeah server/details too | |
| 20:27:27 | mriedem | for the uber joins | |
| 20:28:04 | melwitt | +1 | |
| 20:28:05 | dansmith | I would hope that details would be the same for both | |
| 20:28:11 | dansmith | based on the internals | |
| 20:28:16 | mriedem | it's not | |
| 20:28:25 | dansmith | no, I mean, between this and my patch | |
| 20:28:32 | dansmith | mriedem: you won' | |
| 20:28:41 | dansmith | mriedem: you won't have two cells in your test with my patch right? | |
| 20:29:36 | dansmith | mriedem: something you might try to do is create 500 active and 500 that fail to schedule so you get them in cell0 and cell1 | |
| 20:29:36 | mriedem | correct, just cell0 and cell1 | |
| 20:29:40 | dansmith | and the compare those numbers | |
| 20:30:17 | mriedem | not sure how easy it would be to get them to fail to schedule w/o hacking the scheduler to just raise NoValidHost | |
| 20:30:27 | mriedem | not that that is hard | |
| 20:30:44 | dansmith | mriedem: you could create a flavor that has a billion vcpus or something right? | |
| 20:31:12 | mriedem | fake driver and noop quota driver | |
| 20:31:19 | mriedem | so i don't think that would matter | |
| 20:31:49 | mriedem | and w/o the core/ram/disk filter we don't check limits in the compute claim | |
| 20:32:05 | mriedem | although that woudn't help since then they'd be in the cell1 db | |
| 20:32:18 | mriedem | i could just stop nova-scheduler :) | |
| 20:36:12 | dansmith | mriedem: more vcpus than the compute has will make it fail | |
| 20:36:39 | dansmith | I'm just saying, I expect we might see a performance _gain_ with my stuff if you can arrange to have some instances in cell0 | |
| 20:36:50 | mriedem | true | |
| 20:36:52 | dansmith | on top of the correctness thing, since right now cell0 always sorts above | |
| 20:37:09 | mriedem | vcpus = 1000 is what's in the fake driver, so yeah | |
| 20:37:25 | mriedem | i'll create a flavor with 2000 CPUs | |
| 20:37:36 | mriedem | would need to delete 500 of these and then archive them | |
| 20:38:12 | dansmith | mriedem: remember the overcommit value | |