15:03:29 <number80> #startmeeting RDO meeting - 2018-11-14
15:03:29 <zodbot> Meeting started Wed Nov 14 15:03:29 2018 UTC.
15:03:29 <zodbot> This meeting is logged and archived in a public location.
15:03:29 <zodbot> The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:29 <zodbot> The meeting name has been set to 'rdo_meeting_-_2018-11-14'
15:03:30 <openstack> Meeting started Wed Nov 14 15:03:29 2018 UTC and is due to finish in 60 minutes.  The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:33 <openstack> The meeting name has been set to 'rdo_meeting___2018_11_14'
15:03:40 <number80> #topic roll call
15:03:50 <jpena> o/
15:04:08 <number80> Tengu: yes, for quick workarounds, but we still have to test against virt SIG packages as it's very close to what RHEL will have in the future
15:04:10 <dciabrin> o/
15:04:16 <number80> #chair jpena dciabrin
15:04:16 <zodbot> Current chairs: dciabrin jpena number80
15:04:18 <openstack> Current chairs: dciabrin jpena number80
15:05:10 <Tengu> "quick workarounds"? well, I don't see that as a workaround, but more in a way to validate new podman version while sticking with a stable/valide one in a mirror.
15:06:35 <openstackgerrit> Javier Peña proposed openstack/packstack master: Fix virtualization detection for Fedora jobs  https://review.openstack.org/617969
15:06:57 <number80> Tengu: hence EmilienM is right by having automated jobs to gate updates in virt SIG
15:07:13 <number80> But we'll discuss that when it'll come to that point
15:07:19 <Tengu> ok
15:07:27 <number80> #topic  heads up on pcmk2 rpms for OOOCI consumption?
15:08:18 <number80> dciabrin: https://trello.com/c/qm6LiTCV/682-stein-pacemaker
15:08:19 <dciabrin> number80, want to do a quick heads up on rpms rebuild?
15:08:29 <dciabrin> number80, faster than me :)
15:08:51 <number80> well, pacemaker is ready, pcs and resource-agents have many dependencies to rebuild first (perl and rubygems)
15:08:59 <dciabrin> ack
15:09:14 <dciabrin> so we had a quick chat with bandini about that
15:09:22 <number80> I need to check what EL has for perl (could be shipped in a different repo), but rubygems will be rebuilt
15:09:29 * number80 listens
15:09:52 <dciabrin> the pcs package that Emilien uses for testing podman under centos just has a oneline patch added to stock pcs in centos
15:10:22 <dciabrin> if pcs is too much of a burden, we may want to rely on a patched pcs until the next centos verison is available upstream
15:10:49 <dciabrin> bandini-built pcmk  version is more involved so it still makes sense to build pcmk2.0 for centos
15:10:51 <dciabrin> _but_
15:10:52 <number80> one patch?
15:11:41 <number80> I see many dependencies lacking in buildroot, so maybe they came from another repo, so we might have to build them though
15:11:43 <dciabrin> (yes pcs with podman support == current pcs in centos 7.0 plus a one line)
15:12:29 <dciabrin> that's because last week we settle on the fact taht we could rebuild the next pcs for centos. that one relies on a truckload of rubygems dependencies and whatnot
15:12:40 <dciabrin> does that makes sense?
15:14:15 <dciabrin> basically, if porting the new pcs takes too much effort on centos, I think we could just provide a custom specfile like we do for mariadb, and add podman support to current centos-7 pcs
15:14:24 <number80> I'll give it a look then
15:14:45 <dciabrin> number80, thx AI on me to forward you bandini's patch
15:15:12 <dciabrin> bandini, you want to discuss pcmk version on the host vs in containers?
15:15:15 <number80> but keep in mind, that we cannot ship in repositories bundled code
15:16:02 <bandini> right. so this 'new-pcmk' repo will be only used for one podman job and we must have the same version on host and containers
15:16:11 <number80> ack
15:16:13 <EmilienM> one podman job?
15:16:17 <bandini> likely for containers we will inject these newfangled pcmk rpms at every run
15:16:26 <EmilienM> we plan to switch all CI on podman before end of stein milestone3
15:16:32 <EmilienM> and you guys know why
15:16:34 <number80> ack
15:16:45 <number80> I don't know anyone named why
15:16:54 <number80> :)
15:17:00 <number80> joke aside
15:17:13 <bandini> hohum
15:17:19 <number80> #action number80 look at bandini's patch for pcs
15:17:40 <bandini> we spoke about a special repo that will be used for podman testing
15:17:49 <number80> #info TripleO considering to have all CI running against podman
15:18:01 <bandini> we also mentioned that we don't really want these packages injected in containers just yet
15:18:02 <number80> specific repo?
15:18:09 <number80> right
15:18:21 <dciabrin> EmilienM, how many CI jobs require HA + podman?
15:19:02 <dciabrin> EmilienM, this special packaging only applies to jobs where pacemaker is used
15:20:15 <EmilienM> dciabrin: all multinode with pacemaker
15:20:24 <EmilienM> scenarios, container-multinode, OVB
15:20:24 <number80> ok
15:20:40 <EmilienM> I can list at least 10 jobs
15:20:43 <EmilienM> so yeah
15:20:55 <dciabrin> ok
15:21:26 <number80> ok
15:21:39 <number80> next topic?
15:22:05 <dciabrin> EmilienM, let's discuss the details with bandini after the rdomeeting?
15:23:27 <number80> next topic then
15:23:41 <number80> #topic mariadb specfile PR to fix mariadb 10.3.10 rpms
15:23:50 <EmilienM> dciabrin: cool
15:23:56 <number80> I reviewed change and it is approved
15:24:09 <dciabrin> number80, just spotted that thx very much
15:24:29 <number80> #action number80 build newer mariadb in CBS
15:24:39 <number80> so I guess this is ok
15:24:39 <dciabrin> I'll use the new rpm in a DNR review upstream to test deployment in CI
15:24:42 <dciabrin> yep
15:24:52 <number80> #topic Automate podman/virt SIG updates testin
15:24:55 <number80> #undo
15:24:55 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fe508d4b110>
15:24:57 <openstack> Removing item from minutes: #topic Automate podman/virt SIG updates testin
15:24:59 <number80> #topic Automate podman/virt SIG updates testing
15:25:12 <number80> So let's continue the discussion we had before the meeting
15:25:19 <Tengu> :)
15:25:21 <number80> So what's the context
15:26:13 <Tengu> EmilienM: you go? I have CIX in 4
15:26:46 <EmilienM> hey
15:26:59 <EmilienM> we would like to test every time we update podman
15:27:02 <EmilienM> and its deps
15:27:22 <EmilienM> so i've proposed https://review.rdoproject.org/r/#/q/topic:podman+status:open
15:28:01 <number80> since we don't own this repo, we have to check if virt SIG has automated testing and if they'd like us to add jobs
15:28:03 <EmilienM> the idea is to 1) pin podman in tripleoclient-distgit and 2) run a tripleo job in this distgit
15:28:15 <EmilienM> I'm pretty sure they don't have anything automated
15:28:28 <EmilienM> everytime I have to ping a guy and he's building an rpm by hand and pushing it
15:28:31 <EmilienM> then we all pray very hard
15:28:37 <EmilienM> and usually end up crying
15:28:59 * jpena sees a potential use case for CI in the Virt SIG
15:29:00 <number80> EmilienM: then, we should try harder at getting them in the Software Factory :)
15:29:22 <number80> apevec: I know you're busy ^
15:29:32 <EmilienM> good luck with that
15:29:44 <number80> Yeah
15:29:54 <number80> Meanwhile, we need a contigency plan
15:30:22 <number80> so maybe adding a buffer repo between virt SIG and trunk.rdoproject.org
15:31:19 <jpena> number80: maybe something like deps.yml but for external deps? We could gate there, but it would make it complicated to consume SIG repos directly
15:32:00 <number80> jpena: yeah, but I have no proper solution unless virt SIG do accept our help to automate their update pipeline
15:32:48 <number80> pinning version in spec file is ok for workaround but not sustainable long term
15:33:47 <EmilienM> btw I need help from CI team for https://review.rdoproject.org/r/#/c/17351/
15:33:52 <EmilienM> weshay, panda|rover ^ see my comment
15:35:06 <number80> Let's move that discussion to the list then
15:37:26 <number80> #action number80 move discussion to the list
15:37:34 <number80> #topic open floor
15:37:45 <number80> Who wants to chair next week?
15:38:49 <jpena> I can chair
15:38:58 <number80> #info jpena to chair next weej
15:39:02 <number80> #undo
15:39:02 <zodbot> Removing item from minutes: INFO by number80 at 15:38:58 : jpena to chair next weej
15:39:03 <openstack> Removing item from minutes: #info jpena to chair next weej
15:39:07 <number80> #info jpena to chair next week
15:39:09 <number80> Thanks :)
15:39:22 <number80> Any other topic you want to bring before we close the meeting?
15:40:57 <number80> Ok, thanks for attending!
15:41:11 <number80> And productive summit to the people in Berlin!
15:41:13 <panda|rover> EmilienM: me and amoralej were looking at the same exact job, we are looking at the error now.
15:41:16 <number80> #endmeeting