14:00:23 <witek> #startmeeting monasca
14:00:24 <openstack> Meeting started Wed Oct  4 14:00:23 2017 UTC and is due to finish in 60 minutes.  The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:28 <openstack> The meeting name has been set to 'monasca'
14:00:52 <witek> Hello everyone
14:00:56 <koji> o/
14:00:57 <haruki> hi
14:00:58 <sc> hi
14:00:58 <cbellucci> o/
14:01:18 <witek> Link to agenda: https://etherpad.openstack.org/p/monasca-team-meeting-agenda
14:01:37 <witek> #topic monasca-agent python3 compatible
14:01:37 <sc> may we switch discussion topics, I'm busy reading a document but I'll need to have your opionon on the agent
14:01:53 <witek> ok
14:02:19 <witek> so you want to move the first point to later?
14:03:43 <witek> #topic remove monasca-api Java implementation
14:04:22 <witek> we have discussed during our meet-up deprecation of Java in monasca-api
14:04:43 <witek> I would like to go further and completely remove the code
14:05:03 <witek> wanted to ask you, if there are any objections to that?
14:05:15 <jgu_> witek: it occurred to me that essentially deprecates Vertica
14:05:53 <witek> jgu_: yes, Vertica is only in Java
14:06:00 <sc> jgu_: that is going to be deprecated any way
14:06:00 <jgu_> we are not ready for deprecating Vertica yet
14:06:37 <jgu_> our current release is still in Vertica until Cassandra is merged in
14:07:00 <sc> jgu_: this is what I was about to say
14:07:09 <witek> OK, that's important reason
14:07:22 <sc> we still need the java, so I thing that a deprecation period is needed
14:07:37 <jgu_> sc: agreed
14:08:08 <sc> jgu_: there is a good reason I'm looking closer to your work ;-)
14:08:16 <witek> good, we'll mark it deprecated then and leave in the repo for one more release
14:08:48 <sc> this is OK for me
14:08:50 <jgu_> one more release after queens?
14:09:22 <witek> as soon as we have Cassandra
14:09:42 <jgu_> that sounds good :-)
14:10:47 <witek> #topic Remove keystone auth cache dir
14:11:07 <witek> https://review.openstack.org/#/c/509311/
14:11:59 <witek> after upstream changes in devstack it doesn't seem a blocker anymore
14:12:05 <witek> but a good change anyway
14:12:39 <jgu_> it was still broken yesterday evening. which upstream change from devstack?
14:13:20 <witek> Kien has cited in review
14:13:22 <witek> https://review.openstack.org/#/c/509307/
14:14:31 <jgu_> they reverted the devstack change :-)
14:14:38 <jgu_> cool
14:15:42 <witek> but they'll remove it anyway so your change can be merged as soon as the gates are functional again
14:16:11 <witek> #topic Zuul v3 migration
14:16:33 <witek> https://docs.openstack.org/infra/manual/zuulv3.html
14:16:57 <witek> OpenStack infra has upgraded Zuul
14:17:19 <witek> unfortunately it impacts our CI jobs as you can see
14:18:08 <witek> we have 2 engineers working on migrating the configuration
14:19:13 <witek> they have also switched on the old Zuul v2 jobs today again, so perhaps we could have some temporary solution in short term
14:20:50 <witek> sc: can we now move to Python 3 topic?
14:22:24 <sc> yes
14:22:37 <witek> #topic monasca-agent python3 compatible
14:22:46 <sc> there are two options
14:23:18 <sc> 1) use a fork of supervisor that is python 3 compatible but not python 2 compatible
14:23:44 <sc> 2) get rid of supervisor and add a contrib directory to the project with the suggested systemd configurations
14:24:05 <sc> which aproach do you prefer?
14:24:26 <akiraY> 2)
14:24:28 <jgr> Much as it pains me (I'm generally not fond of things depending on systemd), I vote for (2).
14:24:36 <witek> could you give the reference to the fork?
14:24:58 <jgr> (I'm even less fond of supervisor)
14:25:12 <sc> just a second
14:25:18 <sc> I the link
14:25:47 <witek> supervisor is not in global requirements
14:26:00 <witek> and I guess it could be difficult to get it in
14:26:06 <sc> no
14:27:14 <sc> orgsea/supervisor-py3k
14:27:34 <sc> https://github.com/orgsea/supervisor-py3k
14:27:38 <witek> thanks
14:28:03 <sc> if I understood correctly this is not py2 compatible
14:29:12 <witek> for option 2) isn't monasca_setup taking care of generating systemd config?
14:30:30 <sc> witek: I don't remember if so we need to change the generated systemd configurations in a way that collected and forwarder are started in the right order and the restarted if broken
14:31:04 <witek> yes, I think it's also my preference
14:31:10 <sc> the devstack plugin has systemd configuration
14:31:11 <jgr> witek: optionally, yes. But that creates a service file that assumes supervisor is used.
14:31:44 <witek> jgr: sure, we'd have to update it
14:31:48 <sc> witek: are you proposing to patch monasca_setup?
14:31:54 <jgr> So monasca_setup would need to be changed to create 3 units instead of one.
14:32:12 <witek> correct
14:32:24 <sc> my idea is to get systemd configuration out
14:32:26 <akiraY> is supervisor-py3k under development?
14:32:36 <sc> explicitly available in the repo
14:33:08 <jgr> akiraY: it looks like it's under development for now...
14:33:17 <akiraY> https://github.com/orgsea/supervisor-py3k/blob/master/setup.py
14:33:34 <sc> something like our friends in cloudkitty are doing:
14:33:40 <sc> https://github.com/openstack/cloudkitty/blob/master/contrib/init/cloudkitty-processor.service
14:33:48 <jgr> akiraY: and I'm a bit worried that "for now" may turn into "freshly abandoned" at some stage (it looks like a one man project).
14:34:06 <akiraY> me, too.
14:35:07 <sc> I'm for solution 2), too but now the question is: monasca_setup or external config files?
14:35:50 <jgr> monasca_setup is fine by me as long as it remains optional (the way it is right now).
14:35:55 <witek> I like the monasca_setup approach, where you can set an option if you want to generate service files or not
14:36:21 <witek> explicit files can be added to the repo anyway
14:36:42 <sc> OK, so now I know where to break things :-)
14:37:05 <jgr> I.e. we'll provide our own unit files in our monasca-agent package and are not overly keen on monasca-setup messing with these :-)
14:37:44 <witek> :)
14:37:59 <witek> sc: do you want to work on this?
14:38:30 <sc> I'm adding to my personal backlog
14:38:44 <witek> great, thanks
14:39:19 <witek> anything else to this topic?
14:40:02 <witek> do we have other topics?
14:40:12 <jgr> Yes https://governance.openstack.org/tc/goals/queens/policy-in-code.html
14:40:28 <witek> #topic policy in code
14:40:43 <witek> I haven't looked to it yet
14:40:43 <jgr> I'm currently working on a spec for this, but I'm also trolling for volunteers... :-)
14:41:18 <witek> I'll check with our team
14:41:28 <jgr> I.e. I'm happy to do a writeup of what needs doing in the spec, but I don't think I'll have the capacity to do the implementation as well (the agent domain thing is more than enough, I think...)
14:42:30 <witek> your help with writing things up would be great
14:42:47 <jgr> No worries, I'll do it :-)
14:42:58 <witek> btw. your first spec is in good shape, I guess
14:43:13 <witek> https://review.openstack.org/#/c/507110/
14:43:52 <witek> please, have a look, would be great to have that merged soon
14:44:42 <jgr> And I still need to check how this impacts the events API...
14:44:53 <jgr> (or how the events API affects it)
14:45:05 <jgr> I'll try to make some time for that tomorrow.
14:45:39 <witek> should be similar to logs
14:46:13 <jgr> Ok. That sounds like it definitely has an impact.
14:47:44 <witek> is there anyone else, who wants to work on "policy in code" community goal?
14:48:48 <witek> some other topics?
14:48:57 <akiraY> https://review.openstack.org/#/c/501601/
14:49:45 <akiraY> I'll put 'recheck' after ci will work well.
14:50:33 <witek> has added myself to review
14:50:42 <akiraY> thank you.
14:51:59 <witek> ok, if there are no more topics, we may be closing
14:52:41 <witek> thanks you
14:52:47 <haruki> thank you
14:52:54 <akiraY> thanks
14:52:55 <jgr> Thank you!
14:52:57 <witek> have a nice rest of the week
14:53:02 <witek> and see you
14:53:17 <witek> #endmeeting