15:00:18 <rhochmuth> #startmeeting monasca
15:00:19 <openstack> Meeting started Wed Jan 25 15:00:18 2017 UTC and is due to finish in 60 minutes.  The chair is rhochmuth. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <openstack> The meeting name has been set to 'monasca'
15:00:28 <rhochmuth> https://etherpad.openstack.org/p/monasca-team-meeting-agenda
15:00:34 <rhochmuth> Agenda for Wednesday January 25 2016 (15:00 UTC)
15:00:34 <rhochmuth> 1.	Ocata schedule
15:00:34 <rhochmuth> 1.	python-monascaclient final release
15:00:34 <rhochmuth> 2.	psutils change
15:00:34 <rhochmuth> 1.	https://review.openstack.org/#/c/424771
15:00:35 <rhochmuth> 2.	https://review.openstack.org/#/c/407032/
15:00:35 <rhochmuth> 3.	https://review.openstack.org/#/c/424242/
15:00:36 <bklei> o\
15:00:36 <rhochmuth> 3.	Reviews:
15:00:36 <rhochmuth> 1.	https://review.openstack.org/#/c/418509/
15:00:37 <rhochmuth> 2.	https://review.openstack.org/#/c/422278/
15:00:37 <rhochmuth> 3.	https://review.openstack.org/#/c/419581/
15:00:38 <rhochmuth> 4.	Instrumenting Monasca with Prometheus
15:00:38 <rhochmuth> 1.	Wiki page with overview: https://wiki.openstack.org/wiki/Monasca/Instrumentation
15:00:39 <rhochmuth> 2.	https://blueprints.launchpad.net/monasca/+spec/prometheus-instrumentation
15:00:49 <rbak> o/
15:00:52 <witek> hi
15:00:52 <Kamil__> o/
15:01:12 <rhochmuth> Hello everyone, it looks like we have a good agenda today
15:01:20 <rhochmuth> Lot's of stuff happenin
15:01:26 <sc> busy agenda
15:01:46 <rhochmuth> i was expecting a few more folks to be honest
15:02:08 <timothyb89> hello all
15:02:24 <rhochmuth> there is one, hi timothyb89
15:02:33 <rhochmuth> are there 89 of you
15:02:49 <timothyb89> afraid not :)
15:02:55 <rhochmuth> thank goodness
15:03:08 <rhochmuth> jkeen r u here
15:03:30 <rhochmuth> we might as well get it started
15:03:42 <rhochmuth> #topic Ocata schedule
15:03:56 <witek> tomorrow is final release for client libraries
15:04:03 <witek> that is python-monascaclient
15:04:40 <rhochmuth> i;m looking at the list of open reviews for the python-monascaclient
15:04:41 <witek> is there anything that should be merged before?
15:04:45 <rhochmuth> https://review.openstack.org/#/q/status:open+python-monascaclient
15:05:12 <rhochmuth> How about this one?
15:05:12 <rhochmuth> https://review.openstack.org/#/c/398266/
15:05:45 <witek> that is on newton
15:05:52 <rhochmuth> ohh yeah, just saw that
15:06:29 <rhochmuth> i;m not seeing any in my quick review
15:07:11 <rhochmuth> do you concur
15:07:15 <witek> I will create a tag tomorrow
15:07:23 <rhochmuth> sounds good
15:07:36 <rhochmuth> we've got a release everyone!
15:07:49 <rhochmuth> thanks witek
15:08:06 <bklei> yes, thx for that work witek
15:08:08 <witek> also, do we want to create stable branches some time before final Ocata release?
15:08:43 <rhochmuth> i thought the branches were create for us?
15:08:58 <witek> no, not any more, AFAIK
15:09:17 <rhochmuth> thank goodness you are tracking this
15:09:34 <bklei> +1
15:09:46 <rhochmuth> well it kinda depends imho
15:09:46 <witek> we can apply for branches ourselves
15:10:05 <rhochmuth> if we branch, then for all bug fixes, we'll have to apply to two branches
15:10:19 <rhochmuth> however, for new development, that should only be applied to master
15:10:27 <rhochmuth> and not the final code that is used in ocata
15:10:54 <rhochmuth> so, in some respect, it makes sense to delay a branch up until the point at which a new feature is added
15:11:02 <rhochmuth> or some other makjor refactoring is one
15:11:13 <rhochmuth> but, i'm open to either way
15:11:28 <rhochmuth> it isn't like there is a lot of development occuring in the python-monascaclient
15:11:43 <rhochmuth> so, the savings in not branching now isn't that much
15:12:00 <witek> 13-17 February is the lates when we should have stable branch
15:12:04 <witek> latest
15:12:12 <rhochmuth> ohhh, that isn't much time anyway
15:12:26 <rhochmuth> you might as well get it done now
15:12:39 <rhochmuth> delaying isn't going to really buy us anything
15:13:01 <rhochmuth> and i'll be ablte to sleep better at night knowing the branch was created
15:13:04 <witek> projects that follow release-with-milestones (not us) have rc1 and stable branch 30 January - 3 February
15:13:35 <rhochmuth> that is next week
15:13:39 <witek> right
15:14:26 <rhochmuth> i think you are all clear for creating a stable branch
15:14:39 <witek> ok, will do next week then
15:14:40 <rhochmuth> i'm unaware of any new development for the python-monascaclient between now and then
15:14:50 <rhochmuth> thx witek
15:15:04 <witek> thanks, that's all
15:15:10 <rhochmuth> #topic psutils change
15:15:16 <rhochmuth> 1.	https://review.openstack.org/#/c/424771
15:15:16 <rhochmuth> 2.	https://review.openstack.org/#/c/407032/
15:15:16 <rhochmuth> 3.	https://review.openstack.org/#/c/424242/
15:15:26 <rbak> Alright, this is mine
15:15:44 <rbak> So we found that the behavior of psutils changed a couple months ago.
15:15:54 <rbak> It now collects used memory differently
15:16:30 <qwebirc11986> Is it difficult to adjust for the new behaviour?
15:17:06 <rbak> No, but there's a couple options and we need to make sure to implement on of them when we upgrade psutil
15:17:19 <bklei> it sort of invalidates the need for mem.used_real_mb
15:17:58 <rbak> We could either get rid of mem.used_real_mb, or keep that and get rid of mem.used_mb so the measurements for each metric are consistent
15:18:25 <rbak> Either way, this needs to happen when psutil is updated, which https://review.openstack.org/#/c/407032/ does
15:18:52 <mhoppal> yeah and we need to upgrade it if we want to run it in a container
15:19:06 <rbak> Any preference on which way to handle this?
15:19:06 <qwebirc11986> If  you have an opinion on which way to go could you put up a patch set that depends on that upgrade?
15:19:59 <rbak> Do we want to make this a separate patch or add it to the patch already changing the psutil version?
15:20:03 <qwebirc11986> I don't think we use used_real_mb anywhere.  I'm not sure I know what it means anyway over mem.used_mb
15:20:14 <rbak> That's fine with me
15:20:20 <rhochmuth> same questiong for me too
15:20:55 <rbak> The difference is the used_real used to subtract out buffers and cache, but now psutil does that automatically for used.
15:21:31 <bklei> and if we don't modify or delete mem.used_real_mb, it will be wrong -- double subtraction of buffers/cache
15:21:59 <rhochmuth> so, from an operational viewpoint, is there any strong reason to have both
15:22:13 <rhochmuth> it sounds like we were deriving what we really wanted
15:22:13 <rbak> I don't think so anymore
15:22:50 <rhochmuth> so, we had a metric that we were reporting that wasn't very useful
15:22:52 <bklei> for the metrics to retain their current meanings, we'd need to change both -- add back for mem.used_mb, and stop subtracting for mem.used_real_mb
15:23:03 <rhochmuth> we also derived the "real" metric we were interested in
15:23:34 <rhochmuth> so, i like the idea of dropping unused or not very useful metrics
15:24:00 <bklei> +1 -- so we remove mem.used_real_mb?
15:24:07 <rbak> Works for me
15:24:09 <rhochmuth> my guess is that there proabbly isn't anyone else using mem.used_mb right now
15:24:22 <rhochmuth> and having "real" in there is a bit odd
15:24:28 <witek> it is also important to keep monasca-agent backward compatible in respect of psutil version
15:24:35 <bklei> we'll just have to understand if you are graphing mem.used_mb, it'll take a dive after this change gets deployed
15:25:03 <qwebirc11986> Witek, why is it important to provide backwards compatibility if we're going to require versions > 5.0?
15:25:22 <rbak> witek: Whatever we do or don't do it will be backwards compatible in that it will work, but psutil changed behavior and so the metrics are going to report differently.
15:25:29 <witek> <= not >
15:26:06 <witek> in some deployments monasca-agent is installed natively, not in virtualenv
15:26:17 <witek> and psutil has to be in older version
15:26:58 <rhochmuth> so, if you want complete compatibility, then we need to keep both metrics
15:26:59 <witek> rbak: we could add checks on psutil.version_info
15:27:07 <rhochmuth> and we have to test the version of psutil
15:27:08 <rhochmuth> right?
15:27:56 <rbak> Sure, that would probably work.
15:28:09 <bklei> yup -- then metrics would retain their current meanings
15:28:20 <rhochmuth> well, maybe we should jsut do that
15:28:28 <rhochmuth> i love removing unused metrics
15:28:29 <rbak> If e'retrying to keep metric behavior consistent though that will mean adding buffers and cache back into mem.used for the latest psutil versions
15:28:32 <rhochmuth> and i don't think we are using it
15:28:41 <rhochmuth> but, i don't know what everyone else is doing
15:29:32 <rhochmuth> rbak: i think that is the only way, if the answer is complete compaibility
15:29:39 <rhochmuth> unfortunately
15:29:40 <qwebirc11986> The other problem I see here, just a general problem, is that we're adding in things that depend on newer versions of psutil in some of these patch sets.  Do we have any idea what versions of psutil we should be testing against?
15:30:14 <bklei> since we have metrics for buffers and cache -- i think i'd vote to remove mem.used_mb and fix mem.used_real_mb and publish fewer redundant metrics
15:30:45 <bklei> then we're BW compat -- we've just stopped publishing a redundant metric
15:30:57 <rbak> Well if we're adding features that depend on newer psutil versions it sounds like we're already not backwards compatible.
15:31:36 <rhochmuth> rbak: i think that would be considered a bug
15:31:36 <qwebirc11986> Luckily the new features don't break anything yet, they just silently don't work on older versions.  Not necessarily awesome behaviour.
15:32:06 <rhochmuth> qwebirc11986: agree, a silent bug
15:32:19 <rhochmuth> witek: Do you want more time to consider?
15:32:48 <witek> I'll comment in review
15:33:16 <rhochmuth> witek: thx
15:33:25 <witek> but bklei's proposal sounds fine
15:34:08 <rhochmuth> so, keep the "real" metric, but fix it?
15:34:15 <witek> right
15:34:18 <bklei> yup
15:34:43 <rhochmuth> ok, how about we take a vote
15:34:49 <rhochmuth> is there a vot in IRC?
15:34:55 <rhochmuth> i don't know how to do that
15:35:28 <rhochmuth> how about all in favor of keep the real metric, and remove the non-real one, and fix up real, say awe
15:35:43 <rhochmuth> i feel like a pirate
15:36:19 <bklei> aye
15:36:34 <rbak> aye
15:36:38 <mhoppal> aye
15:36:42 <Kamil__> aye
15:36:46 <rhochmuth> witek?
15:36:49 <witek> aye :)
15:37:01 <rhochmuth> need some pirate emoji
15:37:08 <witek> #startvote aye
15:37:10 <openstack> Only the meeting chair may start a vote.
15:37:21 <rhochmuth> #startvote aya
15:37:22 <openstack> Unable to parse vote topic and options.
15:37:31 <sc> IIRC to record you agree on something you need to write "#agreed"
15:37:43 <rhochmuth> #agreed
15:37:49 <witek> #agreed
15:37:54 <rhochmuth> #agreed aya
15:37:58 <rhochmuth> #agreed aye
15:38:11 <rhochmuth> i need to take a class on irc
15:38:12 <Kamil__> #agreed b)
15:38:22 <bklei> #agreed
15:38:30 <rhochmuth> are there any dissenters?
15:38:32 <timothyb89> for future reference, https://wiki.evergreen-ils.org/doku.php?id=community:using-meetbot :)
15:38:48 <rhochmuth> ok, the aye's have it i think
15:39:29 <rhochmuth> #topic Instrumenting Monasca with Prometheus
15:39:47 <rhochmuth> timothyb89: you have the floor
15:40:09 <timothyb89> right, so I've written up the rough idea in a wiki page: https://wiki.openstack.org/wiki/Monasca/Instrumentation
15:40:38 <timothyb89> essentially the goal is to instrument monasca in a way we can consume ourselves, with one possibility being the prometheus client
15:40:55 <timothyb89> (now that we can consume prometheus metrics due to mhoppal's new plugin)
15:42:17 <timothyb89> but for discussion purposes right now, I'm mainly looking for some general feedback on the idea and trying to start up some discussion
15:43:09 <rhochmuth> so, a lot of this was motivated by issues with using statsd in a Kubernetes environment. is that correct?
15:43:36 <timothyb89> yes, one of the driving factors in the PoCs was trying to remove any need for configuration on the users' end
15:43:51 <mhoppal> and statsd brings a lot of problems to a kubernetes env
15:44:18 <timothyb89> right, I tried to sum up the issues we ran into with statsd on the wiki page
15:44:46 <timothyb89> mainly it comes down to language support (due to the dialect differences) and configuration challenges
15:45:45 <rhochmuth> so, besides hpe, interested in thoughts on this topic
15:45:55 <bklei> i'd love to see a demo of this during mid-cycle if possible, might help me wrap my head around it
15:45:58 <rhochmuth> do we want more time to review over the next week or two
15:46:17 <rhochmuth> bklei: sounds good
15:46:21 <timothyb89> a demo shouldn't be a problem, we've had the PoC running on one of our testing clusters for a while now
15:46:45 <rhochmuth> we can also have an on-line demo via collaboration tools simetime in the near future
15:46:51 <rhochmuth> nearer future
15:46:51 <bklei> sweet -- i wouldn't hold moving forward for that though, just want to understand it better
15:46:56 <rhochmuth> would folks be interested in that
15:47:34 <bklei> non-terminal interactions?  bite your tongue
15:47:42 <witek> is it planned to replace statsd?
15:48:07 <timothyb89> not really intended to replace, just solving a different problem
15:48:09 <mhoppal> potentially
15:48:20 <mhoppal> in a container/kubernetes world
15:49:04 <rhochmuth> so, questions are a little light
15:49:11 <rhochmuth> i think folks need some more time to think about it
15:49:29 <rhochmuth> in the man time, how about a collaboration session in the near future
15:49:33 <rhochmuth> mean time
15:50:40 <witek> sounds good
15:51:23 <rhochmuth> timothyb89: sounds like we have some next steps and then we can have a more indepth discussion
15:51:38 <timothyb89> sure, sounds good to me :)
15:52:00 <rhochmuth> timothyb89: ok, great.
15:52:23 <rhochmuth> thanks for all the work in this area an the thorough blueprint and wiki
15:52:40 <rhochmuth> looks like a good start
15:53:16 <timothyb89> for sure, and feel free to hit me up with any questions
15:53:35 <rhochmuth> #topic open floor
15:53:46 <bklei> did we skip the reviews?
15:53:57 <rhochmuth> ooops
15:53:59 <rhochmuth> we did
15:54:03 <bklei> Reviews:
15:54:03 <bklei> https://review.openstack.org/#/c/418509/
15:54:04 <bklei> https://review.openstack.org/#/c/422278/
15:54:05 <bklei> https://review.openstack.org/#/c/419581/
15:54:08 <rhochmuth> #topic reviews
15:54:28 <rbak> That first one is mine.
15:54:46 <rbak> It's been up for a couple weeks now.  Just waiting for merge or feedback.
15:55:30 <rhochmuth> ok, i'll review it more closely
15:55:40 <rhochmuth> but, there is a backlog of review a mile long right now
15:57:35 <bklei> well - latter two are mine, we can add them to the mile-long list :)
15:57:50 <rhochmuth> https://review.openstack.org/#/c/422278/
15:57:52 <Kamil__> :)
15:58:17 <rhochmuth> i don't have any issues, but i was waiting for something a little more definitive from sap
15:58:32 <bklei> ^^ is me -- i know sap folks have a jinja template solution coming, but i don't think that should exclude this change
15:58:44 <rhochmuth> ok, i'll take a closer look
15:58:49 <bklei> gracias
15:58:55 <rhochmuth> it sounds like the sap one is further out in time
15:58:59 <rhochmuth> and more for future
15:59:02 <bklei> yup
15:59:08 <rhochmuth> and we can address your review right now
15:59:31 <bklei> i think the change makes sense -- all messages green in hipchat get ignored here :)
16:00:14 <rhochmuth> i need to end the meeting i just realized
16:00:33 <Kamil__> bye
16:00:36 <rhochmuth> i'll look at the other review too
16:00:43 <rhochmuth> i think we are saiting on sonu,
16:00:51 <rhochmuth> bye everyone
16:00:56 <bklei_> thx roland
16:01:05 <rhochmuth> #endmeeting