14:00:54 #startmeeting fedora-qadevel 14:00:54 Meeting started Mon Mar 13 14:00:54 2017 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:54 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:54 The meeting name has been set to 'fedora-qadevel' 14:01:03 #topic roll call 14:01:08 * mkrizek 14:01:23 * tflink was following UTC thinking he sent out the wrong meeting time and is a little unprepared 14:01:32 * roshi 14:01:37 cursing DST for the next couple minutes is encouraged 14:01:39 * jskladan joins for the fun parts 14:02:14 all hail UTC! 14:02:41 (also the DST change for us back in Brno is in two weeks... 14:02:52 I thought it was 3 weeks 14:03:00 either way, all hail UTC! 14:03:38 * roshi is on the UTC bandwagon 14:03:45 #topic Announcements and Information 14:04:13 this isn't in a wiki page this week, so please list the things that you would have normally put there 14:04:33 #info taskotron-dev works again - mkrizek 14:05:07 #info deployment of atomic/cloud checks is in progress - mkrizek, roshi 14:05:14 ^^ 14:05:52 #info we have nested virt on dev \o/ 14:06:16 cool, qa11 has been rebooted now? 14:06:21 yep 14:06:42 * kparal is late 14:06:47 #info working on overview documentation for how data flows through taskotron - roshi 14:06:49 do we have the change ready for the other qa boxen? 14:06:54 * tenk is late 14:07:26 for all client-hosts yes, just run the playbook and reboot 14:07:42 cool 14:08:14 anything else? 14:08:24 nothing else here 14:08:35 * tflink was in meetings pretty much all of last week, didn't get much of anything productive done 14:08:47 #info phab updated to a version with working search 14:08:52 other than that, forgot about that 14:08:58 tflink++ 14:09:06 but moving on 14:09:08 also mkrizek++ 14:09:08 kparal: Karma for mkrizek changed to 1 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:09:33 #topic Deploying New Features 14:09:50 specifically, I'm thinking of two: dist-git tasks and the atomic/cloud stuff 14:10:02 I'd like to get those into prod by the end of the week 14:10:23 atomic/cloud stuff seems doable 14:10:42 do you have concerns about the dist-git stuff? 14:10:43 there are couple issues but nothing major I'd say 14:10:58 * roshi is working on a patch for atomic/cloud stuff right now 14:10:59 that dist-git stuff that runs in stg? 14:11:08 yeah 14:11:21 * roshi guesses he'll do the image finding the correct way (that we talked about in #D1157) 14:11:24 haven't really checked the results yet 14:11:29 potentially for modules and layered images as well 14:11:40 since those are in prod koji now 14:11:43 but if that works well in stg, no objections 14:12:23 as far as I know, it works well in stg other than me adding an 's' to the documentation (tests directory instead of test) 14:13:37 is everything needed in develop? 14:13:54 as far as I know, yes 14:14:13 cool 14:14:15 I'm pretty sure that all the required patches landed last week and they may already be released 14:14:54 we'll need a new trigger for atomic/cloud stuff though 14:15:17 for the issue we discovered today 14:15:23 ah 14:15:40 I was going to ask how that wasn't covered by roshi's patch 14:17:04 any more questions/concerns/comments about this? 14:17:28 none here 14:17:59 * tflink moves to the next topic 14:18:11 #topic Documentation, Guides and Examples 14:18:34 I expect a lot of new people to start writing tasks once we get the dist-git stuff deployed 14:19:25 I don't recall exactly who it was right now (I blame still being a bit sick) but I have some notes on issues that folks had in our documentation 14:19:37 they were brought up last week 14:19:56 maxamillion 14:20:01 iirc 14:20:05 oh yeah, thanks 14:20:38 are we going to go with full formula etc needed, or are we going to try to have some simplified wrapper asap (only requiring folks to write a bash script, we do everything else)? 14:21:00 if we want the dist-git stuff to be successful, our docs need to be easy to follow and we need to have some more examples 14:22:15 I'm not sure how realistic it is to have that wrapper ready asap 14:22:22 s/asap/this week 14:22:27 yeah, I talked to adam (maxamillion) a bit about it 14:22:53 and I'm writing a high-level overview that shows how data moves from fedmsg through taskotron ending in a resultsdb submission 14:23:07 * tflink thinks that the stuff roshi's working on will help 14:23:19 so if you're looking at any part of the system, you can have a better grasp of what bits have what inputs and what outputs 14:23:57 that does seem to be a thing that folks get hung up on - where the vars come from, what they're named and what's in them 14:25:22 it threw me for a bit 14:25:33 I know I've had this as a meeting item for the last several meetings but if you get the chance, please go through our docs and see if there's anything that's out of date 14:25:40 which also makes the "install libtaskotron locally and run these args 14:25:47 " seem kinda arcane 14:26:12 roshi: not sure I follow 14:26:58 not knowing where the vars come from 14:27:21 when I was writing a task for the first time, the -i -t flags for runtask were really unclear to me 14:27:28 ah 14:27:29 and how I get info into my task 14:27:39 because I had no idea of the bigger whole of the system 14:27:39 the doc you're working on should help clarify that, right? 14:27:44 that's the goal 14:27:56 I'll have maxamillion take a look when it's closer to being done 14:28:06 sounds good 14:28:11 thoughts on ETA? 14:28:11 see if it does what I hope it should 14:28:27 as soon as we get this trigger update in 14:28:35 ok 14:28:48 I'll have a patch in for that today, and I'll be actually parsing the metadata from a compose instead of hardcoding the value 14:29:09 it'll be published by the end of the week 14:29:27 roshi: thanks 14:29:29 roshi++ 14:29:29 tflink: Karma for roshi changed to 7 (for the f25 release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:29:43 anything else on this? 14:29:58 nope 14:31:19 so, moving on to everyone's favorite topic ... 14:31:25 #topic Phabricator 14:31:57 I'd like to make a decision on what we're going to be doing long term 14:32:29 there has been yet another php package added which will need to be shepherded if we want to have real packages 14:33:22 https://bugzilla.redhat.com/show_bug.cgi?id=1418940 14:33:34 how hard would it be to just be really lazy and run it in docker? 14:33:41 in infra? 14:33:49 I don't think that'll fly 14:33:51 yeah, can we do that? 14:34:03 if there's no one else who'd be interested in having it packaged, I think we should stop spending time on packaging and deploy it per upstream instructions somewhere privately (fedora cloud?), provided we're allowed to do so 14:34:11 * roshi has been wondering if we dogfood atomic/docker in any of our infra 14:34:26 we just got the first containers earlier this year 14:35:17 kparal: from what I've been told, they don't care as much if it's not production but stuff that doesn't go through koji should be outside infra 14:35:20 just a thought, I don't know how tenable it would be 14:35:21 infra hates docker, with grave passion, AFAIK 14:35:45 does that mean outside of fedora cloud as well? 14:35:48 nope 14:36:10 is there any disadvantage in using fedora cloud for phab? 14:36:20 except we might need to change the url again? 14:36:22 we'd have to change domain names again 14:36:39 that would be still worth it I think 14:36:39 we'd be 100% responsible for maintaining the instance 14:37:02 how many percent responsible were we before? 14:37:04 what's the recommended way upstream phab recommends? docker? 14:37:06 er, now 14:37:16 another issue is that I'm not sure that relying solely on me to keep that instance running is wise long term 14:37:20 kparal: via git 14:37:39 roshi: ~80% 14:37:40 and then what, make install into the system? 14:37:56 kparal: no, just run the php application from those checkouts 14:38:19 all binaries are run with commands like ./bin/storage 14:38:38 ok, so we can run it on a standard fedora, or atomic host 14:38:51 standard fedora will likely be easier 14:39:14 using kanarip's packages in copr is a pretty easy process 14:39:56 I see one major disadvantage here. if we abort our packaging efforts, it will get harder to get involved in developed, due to arcanist 14:40:04 another question is if phab is really enough better than pagure to justify this effort going forward 14:40:07 not being in fedora proper 14:40:22 *development 14:40:31 especially when it will likely cause problems with dogfooding 14:41:37 kparal: development of the packages or upstream? 14:42:15 contributing to taskotron 14:42:34 true 14:42:35 * roshi already wrote a container and some bash to let you run arcanist from a container and not have to have arcanist installed locally 14:42:45 because while it is possible to upload a diff from the website, using arcanist is far superior 14:42:52 but I think that not using a PR based workflow does most of that damage 14:43:21 roshi: does it properly integrate with running the test suite of the project, using its virtualenv etc? 14:43:36 doesn't run a virtualenv, but it does run the tests and linter 14:43:51 since a container kinda is a virtualenv, I didn't see the point in that 14:44:03 all my deps are in virtualenv, usually 14:44:10 so without it i can't run the test suite 14:44:24 for this, all the deps are in your container 14:44:29 ah 14:44:37 I can do a writeup if people are interested 14:44:49 I just did it because I didn't want PHP installed on my machines :p 14:44:51 let's see if we keep phab first 14:45:03 I think this comes down to a couple of questions 14:45:20 1. Do we want to continue paying the cost of maintaining our own bug tracker and review system? 14:45:28 honestly pagure is quite bad atm I think. github is much better. but we can hope for fast improvements in pagure 14:45:44 2. Can we justify being different from everyone else in terms of barriers to new contributors? 14:46:23 3. Who's going to be maintaining our phabricator instance if we get through 1 and 2? 14:46:53 do you already know you won't be able or willing to do that in the future, if we keep it in some form? 14:47:13 even if he can, we should spread it around 14:47:19 busfactor-- 14:47:40 kparal: maintaining the phab instance? I just have suspicions that make it more risky to rely on me for that going forward 14:47:56 particularly only on me 14:48:22 do you have some estimate how time consuming it would be if we relied to git checkout deployment? 14:48:30 *on 14:49:47 in theory, it should be pretty painless outside of keeping the machine updated and updating to the latest stable branch on a regular basis 14:50:22 I like the idea of a container model for a one-off like this because it's easy to rollback 14:50:37 but I suppose it's easy enough to roll back to a prior commit too 14:51:05 the only thing that could be a problem is rolling back the git checkout after running db migrations 14:51:12 * tflink isn't sure how well phabricator would tolerate that 14:51:28 yeah 14:51:32 * roshi doesn't know 14:52:03 * roshi doesn't have a real solid preference to one system over the other 14:52:16 we only have 9 minutes left so I think this will become a mailing list discussion 14:52:24 if we did move to pagure, at least it's python and we could send patches 14:52:33 unless folks are ready to take a vote on the various questions 14:53:14 I don't know, honestly. all the choices are bad 14:53:19 agreed 14:53:36 mailing list it is, then :) 14:53:40 moving on to ... 14:54:06 #action tflink to move the conversation around phab and pagure to qadevel@ 14:54:10 #topic open floor 14:54:22 anything else that folks want to bring up? 14:54:41 nothing here 14:54:49 nothing here 14:55:03 * roshi has nothing 14:55:34 then I'll end the meeting and we can reconvene in about 5 minutes for the qa meeting 14:55:39 * tflink will send out minutes shortly 14:55:46 thanks for coming, everyone! 14:55:49 #endmeeting