14:02:29 <tflink> #startmeeting fedoraqa-devel 14:02:29 <zodbot> Meeting started Mon Oct 2 14:02:29 2017 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:02:29 <zodbot> The meeting name has been set to 'fedoraqa-devel' 14:02:44 <kparal> and jskladan has a sick day 14:02:55 <tflink> ok, should we just wait for him? I don't think we have a full hour of stuff today 14:03:40 <kparal> sure, let's wait for lbrabec 14:03:58 <kparal> we can discuss something first, though 14:04:38 <kparal> mprahl pinged us once again about new release of python-resultsdb_api 14:04:40 <kparal> https://bugzilla.redhat.com/show_bug.cgi?id=1496476 14:04:47 <kparal> so I wonder if we could make him a co-maintainer 14:05:07 <kparal> we can still tag the release in git, but he'd be able to build and push the updates himself 14:05:36 <kparal> because we seem to be too overloaded to respond quickly 14:11:23 <tflink> actually, I was wondering the same thing 14:11:31 <tflink> I have no objection to doing that 14:12:21 <tflink> otherwise, I can get to it today. the end of last week got really crazy for me 14:12:38 <tflink> or we could do both, honestly :) 14:12:57 <kparal> so, this would mean adding mprahl to resultsdb package in pkgdb-replacement (somewhere in pagure I guess) 14:13:08 <tflink> I think so, yes 14:13:12 <kparal> let's get jskladan's ack tomorrow and do it 14:13:26 <kparal> of course, you can still do it if you have time 14:13:34 <kparal> at least tag it in git 14:14:02 <tflink> I thought it was just updating the EPEL7 branch 14:14:52 <kparal> ok, I don't know, I thought it needs a new release 14:14:58 * lbrabec is here 14:15:08 <kparal> lbrabec: welcome 14:15:25 <kparal> tflink: you seem to be right 14:15:44 <kparal> tflink: if you have some time, try to figure out how to give somebody the rights now that pkgdb is obsolete 14:15:57 <kparal> I saw some email to devel describing the process in pagure 14:16:03 <kparal> I can dig it out if needed 14:16:57 <tflink> yeah, I remember seeing some emails about that as well 14:17:59 <kparal> ok, a different topic now 14:18:18 <kparal> login on taskotron-stg01 doesn't work right now 14:18:39 <kparal> actually root privs, not login 14:18:44 <kparal> for anything in .qa in stg 14:19:12 <kparal> puiterwijk said RHIT needs to make firewall changes to fix that. hopefully could be fixed later today 14:19:16 <kparal> so just FYI 14:19:54 <tflink> fun 14:20:07 <kparal> and while we're at it, buildmaster.service no longer starts on production 14:20:15 <puiterwijk> proxy01.stg moved IP last week, and the firewall from QA -> Fedora wasn't changed with 14:20:20 <kparal> I had to make a workaround which I described in https://pagure.io/taskotron/issue/236 14:20:40 <kparal> puiterwijk: thanks 14:21:02 <kparal> so, that's just a recap of everything that broke (that I know of) in the last few days :) 14:21:48 <tflink> fun times 14:22:36 <kparal> that's all from me, I don't have anything for the past week 14:22:39 <tflink> ah, lbrabec is back and just being quiet :) 14:22:57 <kparal> tflink: he announced himself though 14:23:06 <tflink> did I really miss that 14:23:07 <tflink> oh 14:23:14 * tflink drinks more coffee 14:24:00 <tflink> ok, let's continue this disorganized and apparently caffeine-lacking party :) 14:24:35 <kparal> lbrabec might be increasing the caffeine average here, if I know him :) 14:24:57 <tflink> isn't it a bit late in the day for lots of caffeine for you all? 14:26:05 <tflink> #topic deploying ansiblize 14:26:29 <tflink> this was the big thing that I wanted to talk about today - see if we're all on at least similar pages :) 14:26:49 <kparal> do we already know where to deploy it? 14:26:57 <kparal> after our recent discussion about stg? 14:27:25 <tflink> IIRC, the longer term plan is to remove most of our stg deployment from stg and keep a resultsdb instance there for other folks to test against 14:28:05 <kparal> yes, but what to do right now? 14:28:08 <tflink> probably add some scripts and/or docs on how to poke at the resultsdb instance as well 14:28:17 <tflink> that's what I wanted to discuss :) 14:28:21 <kparal> ok 14:28:52 <tflink> I'm still of the mind to start modifying dev 14:29:08 <kparal> wfm 14:29:10 <tflink> and make the current stg deployment more of a prod-staging for our testing 14:29:41 <tflink> we'll have to be more careful about task changes until the "new" stg deployment is working 14:30:33 <tflink> I still want to move dev to the cloud but that's not going to happen today 14:30:35 <kparal> or test in production if there's no other way :) 14:30:48 <tflink> returning to our roots! 14:31:01 <tflink> do you still have that picture up in the new office? 14:31:20 <kparal> nope, we should 14:31:50 <kparal> will you be managing dev manually or will it be in the standard playbook? 14:32:04 <kparal> just want to know if replaying the playbook will break things 14:32:25 <tflink> I see no reason to do things manually 14:32:52 <tflink> if I do hack stuff in and don't put it in the playbook or at least tell you all, that sounds like my problem :) 14:32:54 <kparal> ok. can we use the copr builds on dev, or is that a problem? 14:33:06 <tflink> I think that it's OK for dev since it's not critical 14:33:19 <kparal> good. it'll be easier to update regularly 14:33:29 <kparal> just submit a build and dnf update 14:33:34 * tflink will double-check to see if we need to rebuild the copr rpms 14:33:54 <tflink> but I suspect not 14:34:35 <tflink> one question that is only tangentially related - do we want to start looking into making our current image building system go away? 14:35:05 <tflink> I'm thinking not immediately but maybe once we get the ansiblize stuff at least into dev or maybe prod 14:35:06 <kparal> do we have human resources for that? and what we would replace it with? 14:35:51 <tflink> DIB is in the back of my head: https://github.com/openstack/diskimage-builder 14:36:07 <tflink> but the image making stuff that we use for openqa would be another option 14:36:41 <kparal> ok, add mkosi to the list of candidates 14:36:42 * tflink was reminded of that when thinking about re-imaging the client-host for dev 14:36:51 <tflink> mkosi? 14:36:56 <kparal> since it's lennart's project and that guarantees it's awesome ;) 14:37:19 <kparal> tflink: http://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html 14:37:28 <lbrabec> I suspect it will be included in systemd pretty soon :) 14:37:33 <tflink> oh yeah, I remember seeing that now 14:38:11 <tflink> I still have a slight preference for DIB because it's designed to use the images produced by releng instead of building stuff from scratch or using non-releng-produced bits 14:38:25 <tflink> but that doesn't mean the process would be sane :) 14:38:50 <kparal> isn't this a similar argument you had for imagefactory? :) 14:39:37 <tflink> how many other options did we have at the time? 14:39:42 <kparal> anyway, sure we can look into replacing it. but I think it should be substantially better in order to invest time into it. imagefactory is pita but lately mostly worked 14:39:53 * Southern_Gentlem waiting for pungi to be updated to use dnf instead of yum) 14:39:53 <tflink> the argument is still quite valid, I think 14:40:06 <kparal> tflink: the other option at that time was taskotron-vmbuilder built on top of virt-builder 14:42:29 <tflink> eh, we can continue the conversation if/when we can justify working on something new/different 14:42:47 <kparal> sure 14:43:15 <tflink> to summarize what I think we're talking about: 14:43:27 <tflink> 1. start re-working dev to use ansiblize 14:43:55 <tflink> 2. eventually get the current stg instance to be out of the infra stg network 14:44:14 <tflink> 3. create a new resultsdb-stg for the purposes of integration testing in stg 14:44:35 <kparal> ack 14:44:58 <tflink> which means that it's almost time to fight with anaconda again :( 14:45:14 <kparal> f25 eol you mean? 14:45:50 <tflink> it seems silly to rebuild stuff without upgrading fedora at the same time 14:46:10 <kparal> so let's use f27 right away 14:46:18 <kparal> and upgrade just once a year 14:46:19 <tflink> yeah, I was thinking the same thing 14:46:21 <kparal> ok 14:46:38 <tflink> even if that means using beta in the short term 14:47:09 * tflink wonders what kind of fun he's signed himself up for 14:47:10 <tflink> :) 14:47:49 <tflink> it might be worth just changing the kickstart for the client-host machines to play nice with anaconda 14:47:54 <kparal> it's rock stable, right, lbrabec? 14:48:02 <kparal> even with selinux on! (he says) 14:48:14 <lbrabec> yea, sure sure 14:48:23 <tflink> the way you state that does not fill me with confidence 14:48:58 <tflink> anyhow, are there other topics to bring up today? 14:49:07 <tflink> or things I missed on this one? 14:49:35 <kparal> I think that's all 14:49:44 <kparal> when you do expect to switch dev to ansiblize? 14:49:50 <kparal> *do you 14:50:25 <tflink> dunno, depends on how much fun the client-host box is to install 14:50:52 <kparal> tflink: a few minor playbook changes for making ansiblize work are mentioned in https://pagure.io/taskotron/libtaskotron/issue/380#comment-464408 14:50:55 * tflink realizes that he could probalby just run system-upgrade and save much pain 14:51:48 <tflink> I suspect that we'll need to address that buildmaster.service startup issue as well 14:52:35 <kparal> I wasn't happy to be experimenting on prod today :) not sure why it works on dev 14:52:41 <kparal> maybe amount of data and timing 14:53:35 <tflink> possible 14:54:09 <tflink> bah, I need to upgrade the upstreamfirst pagure instance as well. I keep forgetting about that 14:56:04 <tflink> #topic open floor 14:56:14 <tflink> any thing else to bring up today? 14:56:22 <kparal> not here 14:56:30 <lbrabec> nope 14:58:00 <tflink> alrighty, thanks for coming 14:58:07 * tflink will send out minutes shortly 14:58:10 <tflink> #endmeeting