| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-19 | |||
| 18:22:21 | spatel | I didn't configure ceilometer because i wasn't sure i need that component because its private cloud and we don't need billing | |
| 18:22:55 | sean-k-mooney | spatel: that is a common missconceptions ceilometer is for telemetry not billing | |
| 18:23:09 | sean-k-mooney | that said its not nessisarly the best solution for telemetry either | |
| 18:24:10 | spatel | i was worried it will eat my resources | |
| 18:24:19 | sean-k-mooney | if you decide to use collectd you could look into https://github.com/openstack/collectd-openstack-plugins to plublis metrics to celometer or gnocci but collectd can also advertise the stata it monitors over snmp or toher protocols | |
| 18:24:54 | sean-k-mooney | spatel: yes that is a concern with celimiter. it does not scale well which is why i generally dont recomend it as my first choice | |
| 18:25:14 | spatel | Agreed ++ | |
| 18:25:31 | spatel | i had same concern so i didn't bother to install | |
| 18:26:09 | sean-k-mooney | ya so in general i would check out collectd and see if it meets your needs | |
| 18:26:26 | spatel | I am going to try collectd sure! | |
| 18:26:49 | sean-k-mooney | my former team enhanced the collectd libvirt plugin to allow reporting stats for vms using the uuid field instead of the id field | |
| 18:27:02 | sean-k-mooney | the uuid filed is set to the nova instance uuid | |
| 18:27:17 | sean-k-mooney | so its easy to do a 1:1 mapping between the stats and the workload | |
| 18:27:40 | spatel | hmm! interesting i think i have to look into collectd now | |
| 18:28:04 | spatel | also i was thinking push collectd data to influx + grafana so i have good dashboard | |
| 18:28:08 | sean-k-mooney | you can also have collectd use its network plugin to send the stats to influxdb and then use graphana to visualise the results | |
| 18:28:15 | sean-k-mooney | jinks | |
| 18:28:32 | sean-k-mooney | :) that is a good solution | |
| 18:28:49 | spatel | yup! | |
| 18:29:15 | sean-k-mooney | are you familar with OPNFV? | |
| 18:29:23 | spatel | no much | |
| 18:29:54 | sean-k-mooney | thats ok its rather vast in scope like openstack | |
| 18:30:12 | sean-k-mooney | spatel: i just wanted to highlight the barometer project https://wiki.opnfv.org/display/fastpath/Barometer+Home | |
| 18:31:01 | spatel | reading.. | |
| 18:32:13 | sean-k-mooney | spatel: they have be working with integrating collect graphana and other tools for openstack monitoring for telco/NFV usecases | |
| 18:32:16 | sean-k-mooney | https://www.youtube.com/watch?v=-82UShFiBBM | |
| 18:32:26 | spatel | sean-k-mooney: very interesting... also i had question about SR-IOV VF nic stats, it doesn't tell you how much data flowing through your VF | |
| 18:32:57 | sean-k-mooney | spatel: that depend on the nic | |
| 18:33:18 | spatel | I have Qlogic so i doubt it has that feature | |
| 18:33:23 | sean-k-mooney | so most nics dont have enough hardware counters to gatar stats on all the VFs from the host side | |
| 18:34:00 | sean-k-mooney | spatel: if you are able to run collectd in the guest however it can monitor the kernel stats and give you that info | |
| 18:34:50 | spatel | Yes! that is what i am doing currently! guest base snmp monitoring | |
| 18:34:59 | sean-k-mooney | spatel: one other tool that you might also find userful in this space is skydive. http://skydive.network/ | |
| 18:35:35 | spatel | hmm! looking cool | |
| 18:35:51 | spatel | we are using observium and Cisco DCNM | |
| 18:36:49 | spatel | hmm! they have openstack support too | |
| 18:37:11 | sean-k-mooney | skydive was developed in the last 2 years ago specificly for cloud and conterised enviornments but it began to mature just after i deployed my last cloud so i have not used it myself | |
| 18:38:29 | spatel | Can i use for Cisco switches and router? | |
| 18:38:52 | spatel | look like they use agent do i doubt | |
| 18:38:58 | sean-k-mooney | i belive so. it uses multiple protocols to do its monitoring | |
| 18:40:05 | sean-k-mooney | if thet cisco switch support sflow i belive it would work | |
| 18:40:39 | spatel | We have all Cisco nexus switches and they do sflow :) i am going to explore it now | |
| 18:41:41 | spatel | Do you guys using collectd to monitor your compute nodes? | |
| 18:41:46 | mriedem_afk | awaugama: as far as i know if you set the cpu_allocation_ratio in nova.conf on the nova-compute service, it should mirror that to the new OR existing resource provider in placement | |
| 18:41:57 | mriedem | if it's nit mirroring those updates i think that's a bug | |
| 18:42:16 | mriedem | SteelyDan: on that bug, tbc, i think they got confused about "scheduling" | |
| 18:42:32 | mriedem | it's not scheduling anything, they just power on an instance on a stopped compute and the rpc cast is sent to the void | |
| 18:42:32 | awaugama | mriedem: that's what I thought would happen. sean-k-mooney you think it won't update existing ones? | |
| 18:43:09 | sean-k-mooney | awaugama: im not sure. | |
| 18:43:22 | mriedem | cfriesen: yes the bug is saying they power on the instance, the api changes the task_state, but b/c the compute is down, we never finish the task and it's "stuck" | |
| 18:43:46 | sean-k-mooney | awaugama: it will do one of two things either it will overright it allways with the config value or it will only use the config value on creattion fo the rp | |
| 18:43:47 | mriedem | fixing that would mean needing to check the compute service status for every instance action... | |
| 18:44:19 | sean-k-mooney | awaugama: both cases are "wronge" depending on who you ask hench the sepc for initall allcoation ratios https://review.openstack.org/#/c/552105/ | |
| 18:44:56 | mriedem | on every periodic, we update the resource class inventory allocation ratio based on config that we send to placement https://github.com/openstack/nova/blob/5b815eec4c5fc8c19863aa38b1d1920705b17bfa/nova/compute/resource_tracker.py#L108 | |
| 18:45:09 | mriedem | https://github.com/openstack/nova/blob/5b815eec4c5fc8c19863aa38b1d1920705b17bfa/nova/compute/resource_tracker.py#L952 | |
| 18:45:24 | mriedem | the question is if prov_tree.update_inventory(nodename, inv_data) has a bug thinking that nothing changed | |
| 18:45:25 | mriedem | b/c it's a cache | |
| 18:45:34 | mriedem | and the reportclient itself has a cache of the provider tree | |
| 18:46:04 | mriedem | https://github.com/openstack/nova/blob/5b815eec4c5fc8c19863aa38b1d1920705b17bfa/nova/scheduler/client/report.py#L1501 | |
| 18:46:08 | mriedem | "The specified ProviderTree is compared against the local cache. Any changes are flushed back to the placement service. " | |
| 18:47:37 | awaugama | makes sense | |
| 18:48:23 | mriedem | the bug is probably here https://github.com/openstack/nova/blob/5b815eec4c5fc8c19863aa38b1d1920705b17bfa/nova/scheduler/client/report.py#L1575-L1576 | |
| 18:48:40 | mriedem | if we have a single compute node resource provider and that doesn't change, both of those sets will be empty | |
| 18:48:43 | cfriesen | mriedem: as I said in the bug, that won't actually fix it, just make the race window smaller. | |
| 18:48:47 | mriedem | and the for loops below won't flush any changes to placement | |
| 18:48:54 | mriedem | cfriesen: isure | |
| 18:48:56 | mriedem | *sure | |
| 18:48:59 | mriedem | b/c of the service group api | |
| 18:49:03 | mriedem | unless you force down the service | |
| 18:49:47 | mriedem | https://github.com/openstack/nova/blob/stable/queens/nova/compute/resource_tracker.py#L883 | |
| 18:49:47 | mriedem | awaugama: in queens we weren't using that provider tree stuff | |
| 18:50:11 | mriedem | https://github.com/openstack/nova/blob/stable/queens/nova/scheduler/client/report.py#L1112 | |
| 18:50:33 | mriedem | https://github.com/openstack/nova/blob/stable/queens/nova/scheduler/client/report.py#L850 | |
| 18:50:34 | cdent | because it is friday and I don't feel like filtering, can I just say: god I hate caches, why do we do caches? | |
| 18:50:44 | mriedem | idk | |
| 18:50:53 | mriedem | to avoid calling the placement API 500 times per periodic? | |
| 18:51:13 | mriedem | i just know caches are very tricky | |
| 18:51:15 | mriedem | brittle | |
| 18:51:19 | sean-k-mooney | cdent: so the processor has another way to mess with your view of a sequtially constent exectuion of your program | |
| 18:51:41 | awaugama | mriedem: so basically it's a stale value and placement is never refreshing to pick up the new conf setting? | |
| 18:52:01 | awaugama | or the rp isn't refreshing? | |
| 18:52:31 | sean-k-mooney | cdent: hehe since you are here can i get your input on https://review.openstack.org/#/c/610034/ | |
| 18:52:35 | mriedem | https://github.com/openstack/nova/blob/stable/queens/nova/compute/provider_tree.py#L124 | |
| 18:52:51 | sean-k-mooney | cdent: actully perhaps the placement channel would be better. | |
| 18:53:00 | mriedem | awaugama: i think the scheduler report client in master/rocky is thinking nothing is changing | |
| 18:53:04 | cdent | yeah, join me over there because I think that may be fixed | |
| 18:53:22 | mriedem | i just had doritos, you probably don't want to kiss me | |
| 18:53:25 | mriedem | at least not open mouth | |
| 18:53:57 | awaugama | this channel gets weird on Fridays | |
| 18:54:25 | mriedem | awaugama: i think on master/rocky the problem is we're not getting here https://github.com/openstack/nova/blob/5b815eec4c5fc8c19863aa38b1d1920705b17bfa/nova/scheduler/client/report.py#L1646 | |
| 18:54:41 | mriedem | awaugama: it should be pretty easy to recreate this | |
| 18:55:02 | awaugama | mriedem: I think finucannot was able to reproduce on his system | |
| 18:55:13 | awaugama | think he was just using devstack | |
| 18:55:45 | mriedem | that or https://github.com/openstack/nova/blob/5b815eec4c5fc8c19863aa38b1d1920705b17bfa/nova/scheduler/client/report.py#L1112 is short circuirting | |
| 18:55:47 | mriedem | *circuiting | |
| 18:56:06 | mriedem | at one point i had a debug patch for a bunch of this b/c it's really hard to know wtf is going on without any logs | |
| 18:56:51 | awaugama | mriedem, I had to redeploy my system for another feature test, I can see about reproducing next week | |
| 18:56:54 | awaugama | with logs | |
| 18:56:54 | mriedem | i'll see if i can dredge that up | |
| 18:57:55 | mriedem | awaugama: https://review.openstack.org/#/c/597560/ | |