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