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