15:00:52 <imcsk8> #startmeeting RDO meeting (2016-03-30)
15:00:52 <zodbot> Meeting started Wed Mar 30 15:00:52 2016 UTC.  The chair is imcsk8. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:52 <zodbot> The meeting name has been set to 'rdo_meeting_(2016-03-30)'
15:01:29 <apevec> meeting on time!
15:01:44 <apevec> imcsk8, set topic, add chairs :)
15:01:53 <imcsk8> #chair number80 apevec
15:01:53 <zodbot> Current chairs: apevec imcsk8 number80
15:01:58 <trown> o/
15:02:10 <imcsk8> first topic: Bugzilla Component for newly added packages in RDO ecosystem
15:02:17 <apevec> no :)
15:02:19 <imcsk8> #chair trown
15:02:19 <zodbot> Current chairs: apevec imcsk8 number80 trown
15:02:25 <apevec> #topic roll call!
15:02:26 <number80> o/
15:02:30 <apevec> o/
15:02:30 <dmsimard> o/
15:02:31 <jpena> o/
15:02:48 <imcsk8> #chair dmsimard jpena
15:02:48 <zodbot> Current chairs: apevec dmsimard imcsk8 jpena number80 trown
15:02:55 <chandankumar> o/
15:02:56 <jruzicka> o/
15:03:00 <imcsk8> #topic Bugzilla Component for newly added packages in RDO ecosystem
15:03:11 * tristanC sit in the back
15:03:11 <imcsk8> #chair chandankumar jruzicka
15:03:11 <zodbot> Current chairs: apevec chandankumar dmsimard imcsk8 jpena jruzicka number80 trown
15:03:27 <apevec> I'll take that one, I'm comparing list of BZ components in product=RDO
15:03:40 <apevec> and will send update to request to rhbz RT
15:03:47 <tosky> o/ (late, sorry)
15:03:48 <chandankumar> apevec, Thanks :-)
15:03:48 <apevec> incl. adding new releases
15:03:55 <imcsk8> #chair tosky
15:03:55 <zodbot> Current chairs: apevec chandankumar dmsimard imcsk8 jpena jruzicka number80 tosky trown
15:04:07 <apevec> #action apevec send rhbz RT to update product=RDO in Bugzilla
15:04:35 <apevec> I'll also sync default assignee w/ rdoinfo
15:04:36 <imcsk8> anything else on this topic?
15:04:49 <chandankumar> nope from myside
15:04:51 <apevec> and QE contacts
15:05:06 <apevec> (that's not in rdoinfo, figuring it out case-by-case)
15:05:21 <chandankumar> apevec, just like maintainers, do we need to define qe contacts in rdoinfo?
15:05:31 <apevec> I don't think so
15:05:47 <apevec> until we have large QE subcommunity  in RDO
15:06:03 <apevec> even in Fedora, dedicated QE is small
15:06:03 <number80> apevec: we need to document it btw
15:06:26 <apevec> number80, it will be in BZ, for now
15:06:53 <number80> I mean creating bz component after we add new package in the workflow doc
15:07:03 <number80> or we'll keep forgetting about it
15:07:03 <apevec> number80, ah ok, true that
15:07:21 <apevec> #action apevec to update packaing docs to include defining QE contact
15:07:29 <apevec> #undo
15:07:29 <zodbot> Removing item from minutes: ACTION by apevec at 15:07:21 : apevec to update packaing docs to include defining QE contact
15:07:34 <apevec> #action apevec to update packaging docs to include defining QE contact
15:07:57 <apevec> number80, btw where is that kept in Fedora, it is not in pkgdb?
15:08:08 <apevec> so it's also in rhbz only?
15:08:15 <number80> it's an alias to QA
15:08:26 <apevec> for all pacakges?
15:08:31 <number80> yes
15:08:37 <apevec> ok, we might consider that
15:08:39 <number80> we could create one or a list
15:08:41 <apevec> tosky, ^ wdyt ?
15:09:19 <tosky> apevec: well, I'm just one of the QEs :)
15:09:38 <apevec> currently we have QA Contact: assigned to folks which left RHT and are not active anymore
15:10:02 <apevec> tosky, yeah, we could have a list of QE folks interested in RDO
15:10:18 <apevec> or just create a mailing list and have them subscribe
15:10:24 <apevec> you can then filter your components
15:10:33 <trown> I like ML idea
15:10:45 <tosky> I'm already the QE contact for Trove and Sahara, and I would be happy to continue to handle them, but I'd fine also with a mailing list
15:11:12 <tosky> I guess that macro-lists for "similar" components would be too complicated
15:11:12 <apevec> we should first migrate rdo-list to @rdoproject.org
15:11:14 <trown> ML is simple for a new component that may not have dedicated QE
15:11:35 <apevec> misc, ^ do we have infra for listman hosted by osas ?
15:12:44 <apevec> ok, I think we covered the main topic, I'll followup re. QE contacts
15:12:48 <apevec> next topic
15:12:50 <imcsk8> is there anything else on this topic? should be proceed with next one?
15:12:57 <imcsk8> #topic DLRN instance status
15:13:20 <apevec> tl;dr it's back
15:13:22 <trown> seems like we have moved back to the present
15:13:26 <pkovar> \query trigert
15:13:34 <jpena> that's mine :). Initially I was going to ask for some downtime to reboot the instance and check the file system, but...
15:13:35 <apevec> we had outage earlier today
15:13:49 <apevec> jpena, and you got it :)
15:14:05 <trown> nice work on the quick restore
15:14:12 <jpena> on the good side, now the instance root disk is backed by a Cinder volume, so we'll get better availabiliry
15:14:18 <trown> I was expecting to lose today
15:14:22 <jpena> s/availabiliry/availability/
15:14:30 <chandankumar> jpena++
15:14:30 <zodbot> chandankumar: Karma for jpena changed to 8 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:14:43 <jpena> I'm still making sure all workers are ok, so shout if you find anything strange
15:15:02 <apevec> if you see Mar 23 latest in https://trunk.rdoproject.org/centos7-master/report.html do shift-Reload in your browser
15:15:47 <apevec> backup was week behind w/o us noticing that, there will be monitoring check now
15:17:01 <imcsk8> ok, i guess we can continue to the next topic
15:17:23 <jpena> yes, pls go ahead
15:17:26 <imcsk8> #topic RDO Mitaka RC1 status
15:17:49 <misc> apevec: we don't
15:17:51 <number80> we have all core services (except cloudkitty which is FTBFS)
15:17:55 <misc> (also in a meeting)
15:18:00 <number80> now, rebuilding tripleo
15:18:14 <number80> some issues w/ packstack
15:18:19 <apevec> link?
15:18:22 <number80> https://etherpad.openstack.org/p/rdo-mitaka-stable-prep
15:18:43 <apevec> few are mariadb10 related
15:18:47 <number80> yes
15:18:53 <jpena> dmsimard: do you have a link to the port 5000 issue? I can't reproduce it
15:19:01 <apevec> one is packaging diff which should be solved by packstack patch
15:19:20 <apevec> and trove should have a patch by vkmc ready today
15:19:37 <dmsimard> jpena: I'm not the one who reported it, despite it being my color
15:19:47 <trown> hmm so we are switching to mariadb10 for mitaka release?
15:19:49 <tosky> number80, apevec: shouldn't the list include the missing dashboards?
15:19:49 <dmsimard> jpena: it's probably my color because I shifted some text around at some point
15:19:55 <jpena> dmsimard: ohh ok
15:20:01 <social> apevec: are we supposed to branch opm mitaka now?
15:20:34 <dmsimard> jpena: btw backup instance is older than 24h :P
15:20:36 <dmsimard> [sensu] NEW: master.monitoring.rdoproject.org - check-delorean-update-backup @ http://uchiwa.monitoring.rdoproject.org/#/client/rdo-monitoring/master.monitoring.rdoproject.org?check=check-delorean-update-backup |#| CRITICAL: File at http://trunk-backup.rdoproject.org/centos7-master/current/build.log is older than 86400 seconds: Wed, 23 Mar 2016 05:56:52 GMT
15:20:44 <apevec> social, upstream openstack-puppet did branch afaik
15:21:31 <dmsimard> apevec: they didn't just branch, they also released
15:21:32 <number80> social: opm is tagged but not branched yet
15:22:18 <apevec> tosky, please add !
15:22:53 <apevec> trown, is THT patch for mariadb10 not going to be ready?
15:23:07 <trown> apevec: I dont think it is on anyones radar
15:23:18 <apevec> number80, ^ heh, so planB ?
15:23:26 <apevec> trown, that's unfortunate
15:23:31 <imcsk8> apevec: the one for packstack?
15:23:33 <apevec> mariadb5.5 is rather old
15:23:36 <dmsimard> the mariadb10 bump was way too last minute, we should have tested that WAY before.. but I'm repeating myself
15:23:49 <apevec> imcsk8,  packstack patch should be good to go
15:24:01 <apevec> dmsimard, as number80 said, it's not under our control
15:24:10 <apevec> so there's planB but that sucks
15:24:12 <trown> ya, I think we could try to switch early in newton, but mariadb10 was not on the blocker list for tripleo
15:24:24 <jpena> apevec: is this the patch for tht? -> https://review.openstack.org/299352
15:24:27 <dmsimard> the mariadb10 impact is just trove or is there something else ?
15:24:38 <imcsk8> apevec: i see there was an update, i'll check it later
15:24:39 <apevec> so far only trove afaik
15:25:00 <apevec> jpena, yeah, that one
15:25:39 <apevec> number80, ok, let's revert to mariadb5.5 then ?
15:25:45 <trown> apevec: did the clustercheck binary get added?
15:25:59 <apevec> yes, that was the packaging fix we were waiting for
15:26:08 <apevec> https://bugzilla.redhat.com/show_bug.cgi?id=1310622
15:26:18 <dmsimard> apevec: Are they mutually exclusive ? Can we include them both in the repos ?
15:26:25 <trown> hmm, well if the ha job fail on that patch is spurious (it usually is) we could try to get that in
15:26:31 <dmsimard> Otherwise, does that mean we'd be "stuck" with 5.5 for the Mitaka release ?
15:27:06 <apevec> dmsimard, we could upgrade if patches are done right
15:27:12 <apevec> packstack should work w/ both
15:27:26 <apevec> and THT also afaict, jpena you reviewed it?
15:27:37 <apevec> dmsimard, and yes, we can't keep both
15:28:10 <apevec> they're not parallel installable
15:28:16 <jpena> apevec: I had a look at the THT patch, yes. Waiting for some answers from Damien
15:28:41 <trown> hmm, that HA failure is in the post deploy validation, I will recheck that
15:28:43 <apevec> unless we go SCL (no thanks for now)
15:28:47 <number80> apevec: we'll have to remove it before buildlogs is created for mitaka
15:29:12 <jpena> apevec: about mariadb 10, I assume this will be based on the same spec as f24, correct? I checked that one to get the correct subpackage name (mariadb-server-galera)
15:29:15 <apevec> number80, I think kbsingh has removal fixed for buildlogs sync ?
15:29:42 <apevec> jpena, it's the f24 spec + fixup by number80
15:29:51 <jpena> apevec: ack
15:29:51 <number80> apevec: it is now? i must have missed, last time, it has to be manually fixed
15:29:59 <number80> *something
15:30:04 <apevec> https://github.com/hguemar/mariadb-rdo-package/commits/rdo-common
15:30:53 <apevec> number80, 	Re: [CentOS-devel] cbs -.> buldlogs push is paused
15:30:59 <number80> ok
15:31:15 <apevec> > The scripts will now auto trim old / stale repodata content
15:31:28 <number80> excellent
15:31:51 <apevec> but maybe I mis-read that
15:31:58 <apevec> let's confirm w/ KB later
15:32:10 <number80> *nods*
15:32:40 <imcsk8> anything else on this topic?
15:33:08 <apevec> focus is to get this done
15:33:18 <apevec> today/tomorrow
15:33:27 <apevec> so we're ready to just rebuild GA next week
15:33:37 <tristanC> misc: this issue describes what rcip-dev experienced this morning: http://tracker.ceph.com/issues/14242
15:33:47 <apevec> #action everybody work on Mitaka RC issues in etherpad
15:34:20 <number80> I'll be focusing on rebuilding 3o RC1 so that we can also test it too
15:34:27 <number80> likely to be done by tomorrow
15:34:39 <trown> #action trown babysit tripleo mariadb10 patch
15:34:49 <dmsimard> trown: do we have a way to test quickstart with arbitrary repos ?
15:35:04 <apevec> trown, number80 - let's sync tomorrow about reverting to mariadb5.5
15:35:16 <number80> ack
15:35:30 <trown> dmsimard: there is not a parameterized job, but we could create a one off easily
15:35:56 <dmsimard> being able to fire the quickstart jobs on the testing stable repos would be nice
15:36:33 <ibravo> shall I add there issues with baremetal servers as well?
15:37:05 <dmsimard> ibravo: tripleo isn't quite ready to test just yet as I understand it
15:37:34 <trown> well it should be
15:37:50 <apevec> ibravo, you can file upstream bug if you're using latest current-passed-ci
15:37:50 <dmsimard> number80 said he would have the rebuild out for tomorrow
15:37:55 <trown> we are importing pretty close if not exactly what is in centos7-mitaka delorean repo
15:38:14 <dmsimard> trown: well, yes, okay. current-passed-ci != testing stable repos
15:38:27 <dmsimard> I meant the stable repos might not be ready for testing yet for tripleo
15:38:29 <trown> I dont think there have been any backports to mitaka yet in tripleo
15:38:59 <trown> ya, I think ibravo hit issues with centos7-mitaka/current-passed-ci
15:39:27 <ibravo> indeed
15:40:26 <imcsk8> anything else for this topic?
15:40:31 <dmsimard> brb
15:40:34 <trown> ibravo: I would say go ahead an capture them in that etherpad... worst case they are not relevant come release rebuild, but I doubt that
15:40:58 <number80> it's close to current-passed-ci but not necessarily exactly the same content
15:41:44 <apevec> trown, ibravo - ok, let's open separate section for tripleo in https://etherpad.openstack.org/p/rdo-mitaka-stable-prep
15:42:30 <apevec> added to the bottom
15:43:27 <imcsk8> next topic...
15:43:57 <imcsk8> #topic Chair for Next meeting?
15:44:18 <number80> I think chandankumar took it last week
15:44:25 <imcsk8> i can do it again...
15:44:32 <jpena> I can do it, it's been a while
15:44:42 <apevec> grabs! :)
15:44:45 <chandankumar> jruzicka, can you chair next week meeting?
15:46:12 <chandankumar> i think he is not around. imcsk8 you can go ahead.
15:46:36 <imcsk8> ok i'll chair the next meeting
15:46:42 * number80 happy to see new chairs :)
15:46:50 <chandankumar> #action imcsk8 to chair for next meeting
15:46:59 <vkmc> apevec, with which version of mariadb are you reproducing the migrations bug?
15:47:04 <jruzicka> chandankumar, sure
15:47:09 <number80> vkmc: 10.1.12
15:47:23 <imcsk8> we have 13 minutes left
15:47:29 <jruzicka> I have something little
15:47:31 <number80> http://cbs.centos.org/koji/buildinfo?buildID=10246
15:47:32 <imcsk8> que can finis or discuss misc stuff
15:47:42 <vkmc> thx
15:47:47 <number80> imcsk8: you can end the meeting :)
15:47:53 <imcsk8> ok
15:48:03 <imcsk8> #endmeeting