15:00:45 #startmeeting RDO meeting (2016-07-06) 15:00:45 Meeting started Wed Jul 6 15:00:45 2016 UTC. The chair is amoralej. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:45 The meeting name has been set to 'rdo_meeting_(2016-07-06)' 15:00:46 Meeting started Wed Jul 6 15:00:45 2016 UTC and is due to finish in 60 minutes. The chair is amoralej. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:49 The meeting name has been set to 'rdo_meeting__2016_07_06_' 15:01:03 dmsimard, we need to disable one of the bots 15:01:11 yep 15:01:37 rhallisey: https://bugzilla.redhat.com/show_bug.cgi?id=1353227 15:01:53 amoralej: we are good to go now 15:01:53 here we go 15:02:02 #topic roll call 15:02:05 o/ 15:02:06 thanks rbowen 15:02:06 o/ 15:02:06 Yo 15:02:08 o/ 15:02:09 o/ 15:02:12 \i 15:02:15 o/ 15:02:26 #chair trown number80 jschlueter rbowen number80 eggmaster dmsimard jpena 15:02:26 Current chairs: amoralej dmsimard eggmaster jpena jschlueter number80 rbowen trown 15:02:38 o/ 15:02:49 o/ 15:02:50 please add your name in the sidepane so that we know who wrote what 15:02:54 #chair flepied jjoyce 15:02:54 Current chairs: amoralej dmsimard eggmaster flepied jjoyce jpena jschlueter number80 rbowen trown 15:03:21 apevec, are you around, first topics are yours 15:03:39 yeah, lemme reboot 15:04:08 and o/ 15:04:23 #chair apevec 15:04:23 Current chairs: amoralej apevec dmsimard eggmaster flepied jjoyce jpena jschlueter number80 rbowen trown 15:04:29 o/ 15:04:36 #chair imcsk8 15:04:36 Current chairs: amoralej apevec dmsimard eggmaster flepied imcsk8 jjoyce jpena jschlueter number80 rbowen trown 15:04:46 so, let's go with the first topic 15:04:49 #topic move all openstack-* logging to systemd journal only (apevec) 15:05:22 tl;dr let's drop logging to /var/log/PROJECT/... 15:05:40 and configure by default oslo.log to use stderr 15:05:48 why?, just saving space of there is any other reason? 15:05:52 apevec: why that? 15:05:55 that is then captured by systemd and put in journal 15:06:08 better integration with baseOS 15:06:17 this is going to break a lot of user implementations 15:06:20 there's also bug with logrotate 15:06:20 probably 15:06:34 I'm fine with it but I'm curious about operators feedback on that topic 15:06:35 dmsimard, where? 15:06:37 is there good writeup on how to pull content from systemd/journal ? 15:06:48 journalctl 15:06:51 apevec: people expecting stuff to be in /var/log/ 15:06:52 I always have trouble trying to filter content in journald, but that's probably me 15:06:58 dmsimard, they can still configure it 15:07:01 logstash, etc 15:07:01 my main concern is that many people will be using /var/log/ for monitoring and logs collection 15:07:02 this is about package default 15:07:11 e.g. puppet-* would still do whatever they do now 15:07:21 apevec: how does an upgrade from mitaka to newton will work ? will it override anything ? 15:07:34 rpm upgrades do not touch config files 15:07:49 I'm curious if UCA will do something similar 15:07:57 amoralej: good point, we need to coordinate with optools folks 15:08:00 but yeah, this topic was mainly to get it out and collect pushbacks :) 15:08:03 I guess I'll ask zigo and jamespage, just curious 15:08:06 i'd think the oposite, let's leave rpms are they are and use puppet-* to modify it 15:08:07 UCA ? 15:08:13 Ubuntu Cloud Archive 15:08:21 they will probably not 15:08:38 I'll ask :p 15:08:50 I'm pretty sure they don;t like Lennart ;) 15:09:07 well, systemd is default on both debian and ubuntu :) 15:09:26 CI will need to be updated to collect logs from there instead of /var/log/XXX 15:09:30 number80, yeah, resistence is futile 15:09:31 but changing to journald do impact operators 15:09:44 operators and CI 15:09:50 number80, again, they'll use their installer and configure loggin as they like 15:09:57 ack 15:10:05 serious operators do not rely on package defaults do they? 15:10:25 ok, so action, thread on rdo-list? 15:10:41 proposal: migrate packages to journald but give a deadline so that we can review/fix upstream/downstream CI 15:10:44 #action apevec start thread about logging defaults in openstack RPMS 15:10:52 wfm 15:10:58 apevec: do you want to finish this by the end of N ? 15:11:14 ok, let's move on to the next one 15:11:17 ok, but my answer will be "let's wait a bit more until everyone is more comfortable with journald" :) 15:11:17 we have time to do that in time for Newton 15:11:17 Milestone 3 or push to next cycle 15:11:20 let's first see how discussion goes 15:11:30 ack 15:11:42 jpena, it's been few years already :) 15:11:45 but yeah 15:11:55 #topic packaging exception request: bundling JARs in sahara-tests https://bugzilla.redhat.com/show_bug.cgi?id=1318765#c13 (apevec) 15:12:07 oh yes, fedora-review FTW 15:12:12 it's pure RDO package btw 15:12:19 (not in Fedora) 15:12:30 licensing-wise, it's ok 15:12:42 yeah, but still RDO does follow fed pkg guidelines 15:13:01 I'm fine w/ giving this package an exception 15:13:02 we can grant exception after discussion in this forum 15:13:23 ok, I need still to confirm there are sources for all JARs included 15:13:48 at least one is just JAR copied from apache 15:13:58 ouch 15:14:30 we could also say these are just test fixtures 15:14:33 ick, are the jar's used for tests or just an example? 15:14:36 but that would be going to far 15:14:41 jschlueter: for testing 15:14:42 tests 15:14:51 actually used in testing... 15:14:52 other option is to drop that 15:15:05 I'll check w/ tosky about that 15:15:24 apevec: should we add a follow-up topic for next week? 15:15:34 or the one after? 15:15:35 #action apevec to check with tosky about jar files in sahara-tests 15:15:51 let's keep it for next week 15:16:00 ack 15:16:35 ok, let's move on to the next topic 15:16:41 #topic puppet packaging status (hguemar) 15:17:01 ok 15:17:03 two changes 15:17:17 #info puppet 3.x packages in RDO enable allow_virtual by default 15:17:33 this should prevent any python2 side-effects in puppet modules 15:17:42 #info puppet 3.8.7 is in common-ending 15:17:53 EmilienM: ^ 15:18:06 I'd like people to test the latter more extensively so that we can release newton with it 15:18:26 #undo 15:18:26 Removing item from minutes: INFO by number80 at 15:17:42 : puppet 3.8.7 is in common-ending 15:18:28 #info puppet 3.8.7 is in common-pending 15:18:35 AFAIK, weirdo-generic jobs passed with puppet-3.8.7 15:18:35 but this would only "fix" it for TripleO/Packstack, Puppet CI uses the puppetlabs rpm 15:18:53 jpena, puppet CI has fix in their manifests 15:18:55 right but we can change it 15:19:03 we could use RDO rpms 15:19:10 jpena: well, we don't test against puppetlabs rpm 15:19:13 I actually would prefer using your packages 15:19:25 forget about puppetlabs rpm now, we can change it :) 15:19:31 if upstream CI uses our puppet packages, this would allow us to upgrade it more aggressively 15:19:34 what about puppet4 ? 15:19:41 next iteration? 15:19:41 I'm ok with having allow_virtual=true by default (I think that's the way it should be), but we need to be aware that this is a deviation from the expected puppet behaviour 15:19:49 do we want to plan upgrade that in Newton or later? 15:20:05 puppet4 will require more work than you expect 15:20:05 jpena: I'll document it then 15:20:21 I expect more work 15:20:27 tripleo won't work with puppet4 I think, we'll have to adjust some code 15:20:37 #action hguemar document RDO puppet 3.x package deviation from standard 15:20:42 that's why I'd like we start planning that for Ocata 15:20:50 let's switch upstream CI to use your puppet rpm 15:21:15 EmilienM, but openstack-puppet CI has puppet4 jobs already? 15:21:16 EmilienM: wait that we push it in -testing though 15:21:24 yes but we use puppetlabs also 15:21:36 so let's first iterate by using RDO for puppet3 15:21:41 ack 15:21:43 and then we'll see for puppet4 15:22:00 we need extensive testing around puppetCI/packstack/tripleo first 15:22:08 #info postpone puppet-4.x to Ocata release 15:22:16 it's a good choice ^ 15:22:16 Fabien Boucher created rdo_gating_scripts: Adapt gerritbot instructions for the new SF 2.2.2 http://review.rdoproject.org/r/1593 15:22:39 after my composable roles work in tripleo, I'll focus on puppet4 migration 15:22:48 I'm happy that we're moving forward in that area 15:22:59 me too, puppet4 is really cool 15:23:04 if nobody has anything else, I'm fine w/ next :) 15:23:25 ok, 15:23:30 #topic stable branch maintenance upcoming changes (hguemar) 15:23:43 #link https://trello.com/c/URAtrhLU/86-automate-stable-packages-releases 15:23:54 ok, we brainstormed w/ apevec, flepied a plan to automate stable packages releases 15:24:05 plan is in the link on the trello card sent by amoralej 15:24:13 s/on/to/ 15:24:29 the plan is to empower anyone to do stable releases in RDO 15:24:39 albeit with a reviewing process :) 15:24:48 number80, apevec: please ping me when I can download puppet3.x in RDO buildlogs or somewhere else 15:24:53 EmilienM: ack 15:24:55 number80, apevec: I'll work on the transition. 15:25:04 any comments? 15:25:22 let's just put tl;dr for meeting minutes: 15:25:30 rpm-STABLE will be gone 15:25:42 DLRN will build from STABLE-rdo branches 15:25:51 both DLRN and CBS actually 15:26:05 #info DLRN will be building from STABLE-rdo branches (rpm-STABLE branches will be removed) 15:26:54 and will we automate reviews to STABLE-rdo when new point releases are tagged? 15:27:03 that's next step 15:27:11 ok 15:27:40 currently we force STABLE-rdo branches for each release, right? 15:27:52 has someone done audit for whats different between rpm-STABLE and STABLE-XXX branches to see where they have drifted apart? 15:27:52 yes, we fork them 15:27:59 yes, those are regular "distgit" branches 15:28:08 jschlueter: that's what I'll be doing after I finish py3 migration 15:28:11 i.e. each CBS build has corresponding commit on *-rdo 15:28:12 that means when a new version is released, we'll create NEXT-rdo for every project 15:28:31 * jschlueter nods to number80 15:28:51 amoralej: branch creation is still to be defined, but it will likely be semi-automated 15:28:55 jschlueter, yes, branch sync is the first task in the checklist 15:28:55 s/be/remain 15:29:02 Would there still be a master? 15:29:08 jjoyce: always 15:29:12 rpm-master stays 15:29:16 rpm-master will be untouched 15:29:18 this is for stable branches/DLRN only 15:29:46 one side-effect is that there will be no more "lazy" rpm-RELEASE branching 15:30:00 i.e. reusing rpm-master for stable releases where it still works 15:30:06 well, I think that people were a bit confused about it 15:30:08 so we would not have a branch for each of the releaes? I am trying to get a picture in my mind. 15:30:17 that means more backports to do but that can be automated 15:30:32 and yes, it removes source of confusion 15:30:46 jjoyce, we would 15:30:50 end result: 15:31:01 rpm-master => RDO Trunk master 15:31:15 STABLE-rdo => RDO Trunk STABLE and CBS builds 15:31:34 #info rpm-master branch stays for DLRN only master packages (RDO Trunk master) 15:32:12 apevec: Is there a sample package that has been changed to get a better view? 15:32:25 jjoyce: not yet 15:32:42 but you can just look at existing STABLE-rdo branches 15:32:45 jjoyce, DLRN can work with *-rdo as is 15:32:58 it replaces Version: Release: Source0: anyway 15:32:59 number80: ack 15:33:00 thanks to jpena 15:33:12 apevec: OK, I think I see it 15:33:26 there was change in DLRN to drop %changelog 15:33:39 b/c those entries do not make sense for trunk builds 15:34:08 so we just need to sync branches and change rdoinfo 15:34:22 #info no changes are expected in DLRN to support new model 15:35:02 we want to do it asap or wait until newton GA? 15:35:18 asap 15:35:42 ok, so actions 15:35:43 it's already in progress 15:35:43 yes, just finished current migration 15:36:02 #action hguemar review, sync, fix rpm-STABLE/STABLE-rdo branches 15:36:05 implement some package as pilot? 15:36:28 or test DLRN instance? 15:36:35 with modified rdoinfo 15:36:53 jpena, do we have resources ^ 15:37:15 we still have the old dlrn server, it may be useful for tests 15:37:17 right now we have available space, thanks to removing the kilo instance and cleaning fedora-master 15:37:30 ah yes, could be on old server 15:37:32 we could also use the old instance 15:37:45 yes, let's make that staging playground 15:37:47 yep, that sounds like a good solution 15:37:47 could you share here direct url ? 15:38:11 it's http://trunk-primary-old.rdoproject.org 15:38:16 let's not share it until old content is removed 15:38:17 ack 15:38:25 it would be confusing 15:38:26 but we should change the forced redirection to https :) 15:38:35 right 15:38:47 #info old dlrn server will be used for tests (http://trunk-primary-old.rdoproject.org) 15:38:48 well, I have IP for many previous incarnations of the server so I wanted to check the right one 15:39:15 jpena, amoralej please also mv old content so it is not served 15:39:24 #action amoralej remove https redirection from old server 15:39:26 let's keep it around for a while before removing 15:39:37 just removing the symlinks will do 15:39:50 #action amoralej remove symlinks from old dlrn server 15:40:34 ok, so i think we have the first list of tasks 15:41:00 anything else about this topic? 15:41:16 rest of tasks are in the trello card 15:41:35 ok 15:41:42 so, move on to the next topic 15:41:49 #topic review.rdoproject.org platform upgrade 15:42:01 not sure who added this 15:42:03 #info upgrade is DONE 15:42:09 <- guilty 15:42:10 nice! 15:42:22 good job! 15:42:23 cool! 15:42:24 #action hguemar and fbo will migrate project replications to new method 15:42:49 #info thanks to Software Factory folks for helping us in the migration 15:42:57 create project script will be adjusted? 15:42:58 they did a great job :) 15:43:02 yeah!! number80 15:43:06 apevec: yes, that's follow-up 15:43:27 [sensu] NEW: master.monitoring.rdoproject.org - check-delorean-newton-current @ http://uchiwa.monitoring.rdoproject.org/#/client/rdo-monitoring/master.monitoring.rdoproject.org?check=check-delorean-newton-current |#| Build failure on centos7-master/current: sahara: http://trunk.rdoproject.org/centos7-master/report.html 15:43:37 ok, so this was short 15:43:39 tristanC++ 15:43:41 let's name those great folks :) fbo++ tristanC++ cschwede++ 15:43:41 apevec: Karma for fbo changed to 1 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:43:42 fbo++ 15:43:44 number80: Karma for fbo changed to 2 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:43:45 mhu++ 15:43:49 mhu++ 15:43:57 not in FAS? :) 15:44:14 yes, sadly but well intentions matters :) 15:44:28 :) 15:44:29 Clearly we need another bot to track karma. 15:44:52 let's move on or we'll get out of time 15:44:56 #topic ODL packages in RDO? 15:45:05 This is more a quick question than something that's happening. 15:45:15 The OpenDaylight folks are considering putting ODL packages in RDO. 15:45:20 The question is, are we ok with that kind of thing happening 15:45:21 #info pending MEAD in CBS discussion on centos-devel (for opstools SIG) 15:45:30 Something *outside* of OpenStack being packaged for RDO. 15:45:37 And having those packages live in our repos. 15:46:04 rbowen, isn't there centos NFV SIG where this would fit? 15:46:12 Yes. That's the other option. 15:46:19 on technical side, it's what I mentioned: 15:46:41 it's Java monster, so let's first wait for discussion about MEAD in CBS 15:46:50 so we can build it properly 15:46:54 are those packages only intended to be used with OpenStack? or can they be used standalone or with other tools? 15:46:54 So, it sounds like the conversation is already happening somewhere that I wasn't tracking it. 15:47:00 I'm -1 to just wrap binaries from upstream in RPM 15:47:05 No, they are not intended only for use with OpenStack 15:47:18 But, then, they're also not only intended for OPNFV, apparently. 15:47:26 there's already OPNFV build in CBS but like apevec said -1 to warp upstream binaries in RPM 15:47:39 So wherever they go, it's not 100% the right place. 15:47:56 rbowen: alternative is to incubate it within Cloud SIG under a separate repo 15:47:56 we had opstools incubating in our CBS tags 15:48:02 but they'll move to their SIG 15:48:16 ok, so consensus seems to be that we're not keen on having these in the RDO repos. Thanks. That's what I wanted to know. 15:48:16 and nfv already has CBS tags afaict 15:48:34 we're keen to reusing other SIGs repos 15:48:42 like we do with qemu-kvm-ev and ceph 15:48:48 and there's discussion to merge NFV/Cloud SIG 15:49:17 number80, that's fine, but still separate tags/repos right? 15:49:20 yes 15:49:21 Well, sure, but it seems we've been discussing that for a year. 15:49:44 rbowen: I plan to submit a proposal but needs to free some time 15:50:15 openstack team is the only active team within Cloud SIG, and NFV is looking for partnering with us 15:50:42 so let's reduce administrative churn and share a common SIG 15:50:50 with separate repo off course 15:50:55 Thanks. I will pass on this feedback in the conversation I've been copied on. That's all I had on this point. 15:51:22 #info RDO proposal is to share a SIG (Cloud SIG) but with different repos and tags for OpenStack and ODL 15:51:26 ^ is this ok? 15:51:31 yes 15:51:33 That sounds ideal to me. Yes. 15:51:44 sounds reasonable, yes 15:51:52 ok, so next topic 15:52:03 #topic Upcoming dates 15:52:05 Upcoming dates: 15:52:05 OpenStack Summit CFP closes July 15th 15:52:05 Newton M2 July 11-15 15:52:05 Newton M2 test day July 21-22 - https://www.rdoproject.org/testday/newton/milestone2 15:52:13 That's all. :-) 15:52:20 #info OpenStack Summit CFP closes July 15th 15:52:31 #info Newton M2 July 11-15 15:52:43 we should get a promote of Newton today, so looking good for M2 15:52:46 #info Newton M2 test day July 21-22 - https://www.rdoproject.org/testday/newton/milestone2 15:52:51 excellent 15:52:57 w00t w00t 15:53:14 ok, so all proposed topics are done 15:53:23 #topic open floor 15:53:34 #action hguemar add test case to enable people testing puppet 3.8.7 for M2 test days 15:53:57 #undo 15:53:57 Removing item from minutes: ACTION by number80 at 15:53:34 : hguemar add test case to enable people testing puppet 3.8.7 for M2 test days 15:53:59 #undo 15:53:59 Removing item from minutes: 15:54:07 #action hguemar add test case to enable people testing puppet 3.8.7 for M2 test days 15:54:16 now, you can re-roll new topic :) 15:54:29 thanks :) 15:54:29 #topic open floor 15:54:49 it's the time to arise any other topic... 15:54:53 I'm good, a lot of work piling up for me but no specific impediment 15:55:24 #topic chair for next meeting 15:55:27 * chandankumar is up for chairing for next meeting. 15:55:46 grab the chair! 15:55:48 #info chandankumar to chair next meeting 15:55:57 thanks chandankumar!! 15:56:04 so i guess we can close 15:56:18 thx amoralej ! 15:56:19 #endmeeting