16:00:20 <mlavalle> #startmeeting neutron_performance
16:00:21 <openstack> Meeting started Mon Apr  8 16:00:20 2019 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:24 <openstack> The meeting name has been set to 'neutron_performance'
16:01:03 <rubasov> hi
16:01:07 <dougwig> o/
16:01:10 <jrbalderrama> hello!
16:01:12 <slaweq> hi
16:01:17 <bcafarel> o/
16:01:24 <haleyb> hi
16:01:40 <mlavalle> hey guys, how are you?
16:02:04 <mlavalle> it seems we are all here
16:02:12 <mlavalle> #topic Updates
16:02:32 <mlavalle> I have updates and questions for jrbalderrama....
16:02:51 <jrbalderrama> shoot!
16:03:25 <mlavalle> but before getting into it, does any one else have any other updates from their assigned tasks / activities?
16:03:55 * mlavalle don't want to hog the meeting
16:03:55 <rubasov> mlavalle: I don't have anything ongoing now
16:04:17 <slaweq> I have quick update about https://review.openstack.org/#/c/615350/
16:04:30 <slaweq> I recently respin this patch and started looking into it
16:04:37 <mlavalle> rubasov: yeap. thanks
16:04:49 <slaweq> basically with some patches for rally and osprofiler it works
16:05:00 <slaweq> problem is that report doesn't look good
16:05:29 <mlavalle> what do you mean?
16:05:38 <slaweq> see http://logs.openstack.org/50/615350/35/check/neutron-rally-task/4c515b9/results/workloads/0_NeutronNetworks_create_and_list_networks.html#/NeutronNetworks.create_and_list_networks/output
16:05:49 <slaweq> osprofiler report is not stylished properly
16:06:09 <slaweq> so I deployed devstack with rally and all those patches
16:06:22 <slaweq> and tried to generate same report manually
16:06:39 <slaweq> and it looked as it should be, with all osprofiler style
16:07:16 <slaweq> so I will slowly continue  debugging this during next weeks
16:07:31 <dougwig> does the hand run include python callstacks, and not just sql?
16:08:14 <slaweq> dougwig: it contains the same data
16:08:29 <slaweq> but report looks "better" simply
16:08:37 <mlavalle> it is formatting, right?
16:08:44 <mlavalle> I mean, what it's missing
16:09:17 <slaweq> mlavalle: yes, it's formatting but I'm not "frontend expert" so it's hard for me to understand exactly what is missing there (and why)
16:10:43 <mlavalle> but to tell you the truth, besies fromatting, this is starting to look good
16:10:49 <mlavalle> besides^^^^
16:11:00 <mlavalle> http://logs.openstack.org/50/615350/35/check/neutron-rally-task/4c515b9/results/workloads/
16:11:09 <slaweq> yes
16:11:42 <mlavalle> look at this one http://logs.openstack.org/50/615350/35/check/neutron-rally-task/4c515b9/results/workloads/19_NeutronSecurityGroup_create_and_list_security_group_rules.html#/NeutronSecurityGroup.create_and_list_security_group_rules
16:12:24 <mlavalle> with graphs and all
16:12:43 <mlavalle> Great work and progress!
16:12:50 <dougwig> +1
16:12:52 <mlavalle> what do others thing?
16:13:00 <rubasov> +1
16:13:47 <slaweq> thx, I hope I will have some updates on next meeting too, and this will finally be ready :)
16:13:54 <mlavalle> Most of the report looks great
16:14:24 <mlavalle> it is just the scenario data tab that seems to need some improvement
16:14:47 <slaweq> yes, all other tabs are just standard rally report
16:14:51 <mlavalle> but other than that, it looks really nice
16:14:58 <slaweq> but we have to embeed somehow osprofiler report in this one tab
16:15:57 <mlavalle> but there is no missing os profiler data in the scenario data, if I undertand correctly
16:15:59 <mlavalle> right?
16:16:05 <mlavalle> it's just formatting
16:16:10 <slaweq> correct
16:16:47 <mlavalle> so I'd say in this regard, we have two to do's for the next two weeks:
16:17:28 <mlavalle> 1) slaweq is being super nice and will try to improve the formatting of the tab with osprofiler data
16:17:49 <slaweq> I will :)
16:18:34 <mlavalle> 2) But more importantly, I encourage the rest of the team to start looking at the os profiler data, get familiar with it and start trying to draw conclusions
16:18:45 <mlavalle> what do you think?
16:19:17 <slaweq> +1
16:19:34 <mlavalle> what do others think
16:19:35 <mlavalle> ?
16:19:39 <rubasov> sounds good
16:20:20 <bcafarel> agree on point 1 :) I will add osprofiler results in "tabs to go through" list too
16:21:54 <mlavalle> slaweq: what of the patches we are depending on?
16:22:49 <slaweq> it is one patch from rally and one from osprofiler
16:22:51 <mlavalle> are there any plans to merge them in their respective projects
16:22:55 <mlavalle> ?
16:22:55 <slaweq> both are in "depends on" of https://review.openstack.org/#/c/615350/
16:23:23 <slaweq> yes, I will ping authors of those patches to get it merged soon
16:23:43 <slaweq> but not I see that one of those patches may be the reason of this missing styling :)
16:23:47 <slaweq> I will investigate it
16:24:19 <mlavalle> Great work slaweq
16:24:24 <mlavalle> Thanks for the update
16:25:33 <mlavalle> On my side I continued working with EnOS
16:25:52 <mlavalle> and got stuck with two or thre things:
16:26:13 <mlavalle> and I was hoping that jrbalderrama would attend the meeting
16:27:12 <jrbalderrama> mlavalle: what are the issues you faced?
16:27:29 <mlavalle> 1) I 've playing with a system with three nodes: controller, network and compute. As a sanity check, I tried to boot instances and found a copuple of problems
16:28:24 <mlavalle> the first one was that the the nova scheduler ImagePropertiesFilter was returning 0 hosts
16:29:40 <mlavalle> I am using the cirros.uec imgae that EnOS deployed in glance
16:30:41 <mlavalle> I noticed that the image in glance has some properties that I usually don't see in devstack
16:31:01 <mlavalle> so I uploaded a cirros image by hand
16:32:04 <mlavalle> with that, I fixed the ImagePropertiesFilter issue, but now I am getting http://paste.openstack.org/show/749011/ from compute service
16:33:13 <mlavalle> In line 9 you can see that there is libvirt container, that should provide the KVM support, right?
16:33:30 <mlavalle> or am I missing something?
16:34:05 <mlavalle> I understand that this ight be a kolla-ansible issue, but I want to see if jrbalderrama might have some insight
16:35:20 <jrbalderrama> I'm not familiar with the nova/ansible dependencies. However we faced some isues with some images that are not compatible with libvirt
16:36:33 <mlavalle> I was looking at this section of the docs
16:36:39 <mlavalle> https://enos.readthedocs.io/en/stable/tutorial/index.html#unleash-the-operator-in-you
16:37:09 <mlavalle> and that is why I decided to use the cirros.uec image, because that's the example used in the doc
16:37:44 <mlavalle> that image is supposed to work, right?
16:38:03 <jrbalderrama> Yes, the image installed with devstack should work
16:38:25 <mlavalle> mhhhh, ok I'll ping the kolla-ansible guys
16:39:18 <jrbalderrama> In parallel, we can check if there is a problem with the image you used. Is that image available (public)?
16:40:51 <mlavalle> yes it is. in this page https://download.cirros-cloud.net/0.4.0/
16:41:12 <mlavalle> I used  cirros-0.4.0-x86_64-disk.img
16:41:23 <mlavalle> which is the image that devstack uses
16:41:53 <mlavalle> This is the command I used wget --progress=dot:giga -c http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img -O cirros-0.4.0-x86_64-disk.img
16:42:11 <mlavalle> which I just copied from a devstack log
16:42:35 <jrbalderrama> thank you for the feedback we will check and then come back to you
16:42:38 <mlavalle> well, I just adjusted the output file
16:43:46 <jrbalderrama> and other thing you want to discuss about enos?
16:44:04 <mlavalle> my real goal over the past few days was to start doing benchmarking, following https://enos.readthedocs.io/en/stable/benchmarks/index.html
16:44:54 <mlavalle> This assumes that I have installed rally and rally-openstack in the system where I have EnOS, right?
16:45:07 <mlavalle> or those EnOS take care of Rally?
16:45:28 <jrbalderrama> Yes everything is packed
16:45:52 <mlavalle> so it's just a matter of defining the workload file?
16:46:12 <mlavalle> that is run.yml in the workload folder, right?
16:46:29 <jrbalderrama> exacly, the idea is after the config/install then you declare the workload
16:47:11 <mlavalle> I'll prabably start running rally scenarios that don't require instances
16:47:23 <mlavalle> but eventually we will need instances
16:47:41 <mlavalle> because providing ports to instances is our biggest use case
16:47:44 <mlavalle> right?
16:48:56 <njohnston> yep
16:49:05 <jrbalderrama> we will check enos, fix it if required, and work together on the benchmarks
16:49:21 <mlavalle> ok that's my update for this meeting
16:49:28 <mlavalle> thanks jrbalderrama
16:49:45 <mlavalle> #topic On demand agenda
16:49:58 <mlavalle> any other topics we should discuss today?
16:50:38 <mlavalle> ok
16:50:44 <mlavalle> Thanks for attending
16:50:58 <slaweq> o/
16:51:01 <rubasov> thank you, bye
16:51:17 <mlavalle> by the way, jrbalderrama will be with us in Denver during the PTG
16:51:30 <slaweq> great
16:51:43 <slaweq> will be great to meet with You :)
16:52:04 <jrbalderrama> we will have the ocasion to discuss f2f!
16:52:19 <mlavalle> Bye
16:52:23 <jrbalderrama> bye
16:52:25 <mlavalle> #endmeeting