15:00:29 <witek> #startmeeting monasca
15:00:30 <openstack> Meeting started Wed Jan 17 15:00:29 2018 UTC and is due to finish in 60 minutes.  The chair is witek. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:34 <openstack> The meeting name has been set to 'monasca'
15:00:44 <witek> Hello everyone!
15:00:49 <fouadben> Hi
15:00:50 <cbellucci> Hi!
15:01:10 <haruki> hello
15:01:18 <jgu_> Hi
15:01:20 <jgr> Hello
15:01:23 <witek> #topin mailing list
15:01:27 <witek> #topic mailing list
15:01:29 <witek> :)
15:02:13 <witek> I realized that we have two independent mailing lists referenced at wiki
15:02:40 <witek> I actually though that mails from launchpad are forwarded to openstack-dev, but that's not the case
15:03:29 <witek> wanted to ask what do you think about dropping the launchpad mailing list and using only openstack-dev
15:03:43 <sgrasley1> +1
15:04:04 <jgr> +1 (I only learned that this other list even exists just now...)
15:04:18 <jgu_> +1
15:04:26 <fouadben> good idea
15:04:36 <witek> jgr: yes, that's the main issue with having two lists
15:05:52 <witek> OK, if nobody complains, I will disable the launchpad list then
15:06:03 <witek> and update the wiki
15:06:28 <witek> I think launchpad and wiki are the only places where it's referenced
15:06:32 <joadavis> I assume you will also send out a final 'closing this list' email to the launchpad list.
15:06:47 <witek> yes, good point
15:07:55 <witek> #topic DCO for monasca-docker
15:08:05 <witek> timothyb89: are you around?
15:08:42 <witek> we have started discussing it last week
15:09:04 <witek> I have suggested moving monasca-docker to openstack namespace
15:09:21 <witek> but it doesn't seem feasible in the short term
15:09:32 <witek> or eaven mid term
15:10:23 <witek> timothyb89: has prepared the document describing the new contribution workflow for monasca-docker repo
15:10:58 <witek> https://github.com/monasca/monasca-docker/pull/397
15:12:05 <witek> everyone commiting to the repository would have to sign his commits
15:12:48 <witek> if you're interested in contributing, please review the PR
15:14:04 <witek> I think using DCO is a pragmatic approach to fulfil legal requirements
15:14:09 <joadavis> Kind of a bummer, but I'm happy we are getting more docker functionality.  Will the steps be added to the monasca wiki or somewhere else to point to this external repo?
15:15:11 <witek> we don't have many references to monasca-docker at that time
15:16:37 <witek> Monasca Contributor Guide could be a good place
15:17:41 <witek> anyway, we have also discussed how we can improve the process of building and publishing the docker images for Monasca
15:18:22 <witek> and agreed we could move the Dockerfiles of Monasca components to upstream repos
15:18:32 <witek> to better couple it with OpenStack CI
15:18:56 <witek> we'll prepare a user story about it
15:20:25 <witek> #topic Rocky Community Goals
15:21:18 <witek> TC discusses which topics should be tackled as community wide goals for the next release
15:21:25 <witek> http://lists.openstack.org/pipermail/openstack-dev/2018-January/126266.html
15:21:56 <witek> if we want to influence it in any way, that's probably the right moment
15:22:29 <witek> * Remove mox is a good candidate
15:22:46 <witek> only monasca-ui is affected as far as I know
15:23:24 <witek> * Ensure pagination links
15:23:52 <witek> the goal is more about auditing current implementations
15:24:15 <witek> and checking if tempest test are implemented
15:24:25 <witek> if I understand correctly
15:25:03 <witek> should be fine in our case I guess
15:26:06 <witek> the last two candidates seem to be more complex
15:26:50 <witek> although I did not investigated the details
15:28:39 <witek> SUSE folks, how relevant are they from your perspective?
15:28:44 <witek> * Enable mutable configuration
15:28:49 <witek> * Cold upgrades capabilities
15:28:51 <jgu> sounds more interesting too. did monasca already migrate to storyboard (#1)
15:29:27 <witek> yes, we did, but it won't be the goal for the next release
15:29:34 <jgu> I understand
15:31:14 <jgr> There's very little in the way of information on both cold upgrades and mutable configuration - what are they about?
15:31:20 <joadavis> Not sure what 'mutable configuration' implies.  We have managed configurations through the installer, like crowbar or ansible, that allow refreshing changes
15:31:42 <jgr> One can guess from the title, but that's not a good basis for a judgement call...
15:31:46 <jgu> is there link to "enable mutable configuration" and "cold upgrade capabilities" definition?
15:32:19 <jgu> here is for the upgrade: https://review.openstack.org/#/c/533544/
15:32:32 <jgr> And https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html
15:32:34 <witek> mutable configuration - https://review.openstack.org/534605
15:32:53 <jgr> Cold upgrades have implications...
15:33:18 <jgr> Serious implications: "Database schema updates are stable and ordered such that moving a database (with actual data in it) from release N-1 to N is possible without data loss."
15:33:29 <jgr> We still do not use Alembic, do we?
15:33:40 <witek> no
15:35:27 <witek> yes, cold upgrades would be probably be the most expensive
15:35:57 <witek> but they write in the spec they would expect it only from 'main OpenStack bucket' services
15:36:31 <witek> anyway, it wouldn't be a bad idea to start with some small steps towards it
15:36:46 <jgr> Mutable configuration probably wouldn't be too bad. While I haven't read the proposal that would be fairly easy to pull off as long as oslo.config provides a hook for a signal handler to force a reload the next time the config object is accessed.
15:37:06 <jgr> I agree.
15:37:28 <jgr> We could at least lay the groundwork for Alembic based database setup.
15:37:50 <jgr> That'll get us most of the way to fulfilling that goal anyway :-)
15:37:57 <witek> :)
15:38:31 <jgr> And it meshes nicely with the service domain thing, for that will require schema changes among other things.
15:39:23 <joadavis> ah, so mutable configuration doesn't have to be all the configuration options.  not as bad as I'd feared
15:39:55 <jgu> for the mutable configuratons,  I imagine not all properties will be mutable w/o service restart. It'd be a good to come up with a list of conf properties as the goal for the mutable conf story.
15:40:22 <jgu> jodavis: crossed msgs
15:41:11 <jgr> I for one would put the mutable config story off until later - solid database schema handling is more important in my book
15:41:41 <jgr> At least if it's an either-or choice :-)
15:42:30 <witek> jgr: I think it's a good point for the PTG
15:42:50 <witek> btw, thanks for your entries in the etherpad
15:43:09 <witek> also 1-2 devs from OP5 will participate
15:44:06 <jgu> are you planning Wed-Thur for the Monasca PTG?
15:44:12 <witek> yes
15:44:39 <witek> don't have any confirmation from organizers though
15:45:12 <joadavis> Is there a schedule posted yet?  Wondering what to do with Mon-Tues
15:45:37 <joadavis> and if we are done Thurs, I'll probably try to leave Fri
15:46:01 <witek> the wiki page is here: https://wiki.openstack.org/wiki/PTG/Rocky/Etherpads
15:46:13 <witek> started filling in
15:46:31 <witek> created today
15:47:22 <witek> "NB: We are still working on the room / day / track assignment based on
15:47:22 <witek> each team's requirements and hope to be able to publish a strawman
15:47:22 <witek> proposal by the end of the week."
15:48:30 <witek> any other topics?
15:48:52 <jgr> https://review.openstack.org/#/c/532486/ is officially driving me crazy - upon the last run monasca-tempest-java-mysql failed; in the recheck that worked but monasca-tempest-ython-mysql failed. No changes of course, just rechecks...
15:48:56 <jgr> Just venting :-)
15:49:54 <jgr> If I had to guess, my money would be on oomkiller randomly offing services or something along these lines
15:50:20 <witek> for this fail I have reported the bug today
15:50:42 <jgr> Oh, interesting - what is the underlying issue?
15:50:51 <witek> https://storyboard.openstack.org/#!/story/2001482
15:51:36 <jgu> is it timing issue in checking results? a wild guess
15:51:44 <witek> the metric is persisted without dimensions
15:51:59 <witek> but I didn't investigate
15:53:14 <witek> jgr: I have rechecked your change again
15:53:38 <jgr> witek: ah, thanks, was just about to do that myself :-)
15:53:41 <jgu> a random question -- the postgresql jobs always fail. do we still need them in the newer releases?
15:54:26 <witek> you mean, disabling the tests?
15:54:40 <jgu> right
15:55:16 <witek> yes, it's probably a good idea
15:55:34 <witek> I'll ask dougs if they use posrgres
15:56:13 <jgu> good idea. I am just bugged that the two postgresql jobs always fail :-)
15:56:29 <witek> not maintained for some time now
15:57:02 <witek> ok, I'll be wrapping up
15:57:17 <witek> thank you everyone for joining
15:57:37 <witek> bye bye
15:57:44 <joadavis> bye
15:57:46 <fouadben> bye
15:58:04 <haruki> bye
15:58:07 <witek> #endmeeting