14:02:33 <tflink> #startmeeting fedora-qadevel
14:02:33 <zodbot> Meeting started Mon Jul 31 14:02:33 2017 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:33 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:02:37 <tflink> #topic roll call
14:02:43 <roshi> .hello roshi
14:02:44 <zodbot> roshi: roshi 'Mike Ruckman' <roshi@mykolab.com>
14:02:54 <tflink> sorry for the late start
14:03:25 * kparal is here
14:03:35 * lbrabec is here
14:03:38 * jskladan lurks
14:04:01 <tflink> ok, let's get this thing started
14:04:12 <tflink> #topic Announcements and Information
14:04:41 * tflink didn't send out a wiki page ahead of time, so feel free to update here
14:04:50 <tflink> #chair jskladan kparal roshi lbrabec
14:04:50 <zodbot> Current chairs: jskladan kparal lbrabec roshi tflink
14:04:55 <kparal> nothing from my part for the last week
14:05:35 <kparal> but I fixed taskotron-dev today by rebooting it :)
14:05:43 <kparal> it was rejecting all jobs for the past few days
14:05:51 <tflink> any idea why?
14:06:02 <kparal> I think it was related to qemu update a few days back
14:06:12 <jskladan> #info started working on Phab to Pagure migration - Diffs and Tickets now can be exported to html/json 'snapshots' - jskladan
14:06:14 <kparal> but I couldn't fix it by restarting services
14:06:34 <lbrabec> I pushed small fix to feature/ansiblize branch of libtaskotron (artifacts dir creation) and played with ansible in general for a while
14:07:21 * tflink has been working on a service for the atomic host CI stuff that listens for results and populates a resultsdb instance
14:07:57 <tflink> any comments/questions or other updates?
14:08:25 <jskladan> I have some WRT the phab/pagure transition
14:08:32 <jskladan> if this is the time and place
14:08:40 <kparal> let's do a specific #topic for that
14:08:49 <tflink> I was going to have separate topics for the migration and ansibleize
14:08:56 <jskladan> ook
14:09:10 <jskladan> nothing for  announcements, then, from my side of the interwebz
14:10:00 <tflink> ok, moving on
14:10:06 <tflink> #topic phabricator migration
14:10:21 <kparal> I started moving all the repos to pagure
14:10:23 <jskladan> OK, so Kamil started moving the repos
14:10:35 <tflink> what namespace are you using for the tasks?
14:10:39 <kparal> taskotron
14:10:53 <kparal> I'd need to create a new user group in order to be able to use a different namespace
14:11:16 <tflink> do we want to create a new namespace?
14:11:40 <kparal> no strong opinion
14:11:54 <kparal> I used the existing namespace because it was easier
14:12:14 <tflink> have you already moved most of the repos?
14:12:45 <kparal> many of them, probably not most. it depends if we want to move everything or delete/ignore some old ones
14:13:05 <kparal> about half of the task repos
14:13:32 <tflink> does it make sense to move them again?
14:13:48 <tflink> how are you handling the mirroring changes?
14:13:51 <kparal> why? do you really with for a separate namespace?
14:14:00 <kparal> *wish
14:14:30 <kparal> I'm keeping the old repos working still, we'll adjust the mirrors on taskotron-dev, then production, then kill the bitbucket repos
14:14:51 <tflink> sounds good, just double checking
14:14:55 <kparal> ok
14:15:10 * tflink doesn't really care about moving the repos, just asking questions
14:15:22 <tflink> er, having a separete namespace
14:16:00 <jskladan> About the ticket move:
14:16:00 <jskladan> To move the tickets, we will need to do manual changes in each repository - enable issue tracker, set the Priorities, Close states, and tags - this can not be done via any kind of API/automation.
14:16:00 <jskladan> Tickets themselves can be moved by using the /tickets git of each project. I have been messing around with it this afternoon, and have a pretty good idea on doing that. So technically we "only" need to do the manual parts, and possibly create exceptions for when the ticket trackers already exist and have some Priorities/Close states
14:16:00 <jskladan> We should also probably go through tickets in phab, and close those we don't care for any more...
14:16:55 <tflink> yeah, that makes sense
14:17:11 <tflink> how close are you to being ready to do the migration?
14:17:18 <kparal> I'll wade through the existing tickets and try to close everything outdated or very improbably to implement in the future. any help is welcome
14:17:41 <jskladan> tflink: a day or two, but then at least a day going through the repos one by one, and doing the manual work
14:17:55 <jskladan> + implementing the special cases
14:18:20 <jskladan> we could schedule the migration for early next week, I think
14:18:44 <jskladan> and by "migration" I mean "start disregarding any changes in phab"
14:19:07 <tflink> yeah, I was wondering how we would handle that
14:19:16 <kparal> is it possible to set it to read-only mode?
14:19:21 * tflink wonders if there is a read-only switch somehere in phab
14:19:29 <jskladan> tflink: kparal: would be nice :)
14:20:11 * tflink doesn't see anything obvious, will look more
14:20:22 <jskladan> https://secure.phabricator.com/T4571
14:22:38 <tflink> a quick read seems like "kind of"
14:22:42 <jskladan> yup
14:23:02 <roshi> chmod :p
14:23:37 * tflink will look into it later this week
14:23:43 <jskladan> on a more general note - if  you haven't already, please try to read the email I sent to qe-fedora-list (From Phabricator to Pagure, and beyond...)
14:23:48 <tflink> #action tflink to look into a read-only mode for phabricator
14:23:50 <jskladan> and ideally also respond :)
14:24:16 <jskladan> roshi: could you move the testcloud repo from github to Pagure, if you have not already?
14:24:32 <kparal> I'll do it as well, when I'm at it
14:24:49 <jskladan> kparal: OK, thx
14:25:10 <kparal> roshi: any objections?
14:25:37 <roshi> I can move it - but will keep the GH one there, becuase plenty of things link to it
14:25:52 <roshi> it gets use outside of Fedora QA
14:26:03 <kparal> the readme can be replaced with a "moved to" link
14:26:07 <kparal> is that sufficient?
14:26:12 <tflink> or maybe change it to a mirror?
14:26:32 <kparal> it makes no sense to have it in two places. if you really want to keep the github one, let's keep it there
14:26:50 <jskladan> I'm not moving any tickets to github, though :)
14:26:55 <kparal> however, on pagure, it would be easier to maintain people access (adding the whole taskotron group, for example)
14:27:15 <jskladan> if the goal is to unify on pagure, I'd rather see it moved, but honestly, I could not care less
14:27:30 <kparal> there are about 15 tickets against testcloud in phab
14:27:51 <kparal> 11
14:27:59 <roshi> yeah, we can move it
14:28:59 <roshi> I don't really care that much, just want to make sure people reading an old link can still get there
14:29:16 <jskladan> roshi: kparal: I'd vote for the "moved" description in Readme
14:29:17 <kparal> that's the same thing I do for bitbucket repos
14:29:22 <jskladan> the same way we do on BB
14:30:02 <roshi> sure
14:31:04 <tflink> anything else on this?
14:31:07 <jskladan> nope
14:32:33 <tflink> ok, moving on
14:32:49 <tflink> #topic libtaskotron's ansiblize branch
14:33:36 <kparal> any objections to deploying the code to taskotron-stg?
14:33:44 <kparal> for testing purposes
14:33:45 <tflink> any updates on this?
14:33:55 <tflink> is it already in dev?
14:34:15 <jskladan> kparal: other than "I don't understand a bit of what it does, and what changes are necessary to make it work", no :D
14:34:15 <kparal> nope, I'd use stg for this and keep dev and prod running the old code
14:34:37 <kparal> stg is not working atm anyway
14:34:39 <lbrabec> as far as I can tell from my testing, the martin's change to code does the work, but there are lot of small issues that needs to be solved... should I create a ticket for each issue I find or fix it and push it?
14:34:54 <kparal> lbrabec: fix it and push it!
14:35:39 <tflink> lbrabec: any idea how many issues we're talking about?
14:36:30 <kparal> I'm not clear on one thing - how exactly are we notified that a standard-test-interface (STI) task should be scheduled and where do we pull it from? it is expected to be tied to distgit execution right now?
14:37:15 <tflink> for the most part, yes
14:37:33 <tflink> the tests will live in dist-git
14:37:53 <tflink> the triggering that isn't handled by the atomic host ci folks will be process related
14:37:53 <lbrabec> that is hard to tell, I don't see anything big atm, but the current state is "works on my machine in some particular way", I think we will find more as we deploy it to stg/dev
14:39:06 <kparal> when we deploy this to stg, should we react to stg or prod dist-git messages?
14:39:12 <tflink> prod
14:39:16 <kparal> ok
14:39:19 <tflink> there aren't that many things built in stg
14:39:39 <tflink> unless there are module builds or somerhing that are only in stg
14:39:54 <kparal> so, we'll need some skilled sysadmin to do this...
14:40:04 <kparal> jskladan: hi!
14:40:12 <kparal> :)
14:40:18 <jskladan> kparal: you solved some serious issues kparal
14:40:23 <jskladan> you are far better at it!
14:40:27 <kparal> I can only reboot
14:40:47 <lbrabec> rebooting until ansiblized?
14:40:50 <jskladan> well, maybe we could encode something in the reboot-cycle.. :D
14:41:04 <tflink> lbrabec: that sounds like a good idea to me :)
14:41:09 <roshi> kparal: reboots as a service :p
14:41:15 <kparal> :D
14:41:23 <jskladan> roshi: sounds like something Lennart would do...
14:41:30 <roshi> hahaha
14:41:33 <tflink> the other option would be to move a new dev-ish instance to the cloud
14:41:54 <tflink> with the aim of deprecating the current dev instance
14:42:03 <jskladan> tflink: I'm not even sure whether we're still in the middle of buzz-word-off, or not :)
14:42:37 <tflink> I was being serious - it would free up a worker box
14:42:54 <tflink> regardless of what form this thing takes
14:43:09 <kparal> so why do this on dev when stg is now standing idle?
14:43:50 <tflink> doesn't matter much to me
14:44:19 <kparal> ok
14:44:37 <tflink> I forget, are we still running 24 on our deployments or did we upgrade to 25?
14:44:47 <jskladan> 25 IMO
14:45:05 <jskladan> but I'm not sure, honestly
14:45:41 <tflink> prod is 24
14:45:48 <tflink> so is stg
14:45:50 <kparal> qa12 is 25
14:45:57 <kparal> which is prod
14:46:07 <kparal> so mixed it seems
14:46:07 <tflink> dev is 25
14:46:22 <tflink> the client-hosts are a different story
14:46:40 <tflink> I couldn't get 24 to install on the client hosts
14:46:52 <tflink> and only got 25 to work after much gnashing of teeth
14:47:51 <kparal> I'd like to deploy ansiblize as easy as possible. if we include moving to cloud and upgrading, it might take much longer
14:47:59 <kparal> but it's true that F24 is eol soon
14:48:03 <tflink> 24 goes eol soon
14:48:10 <tflink> so we don't have a whole lot of choice
14:48:17 <roshi> everything takes much longer kparal :)
14:48:48 <kparal> tflink: so, what's your suggested battle plan?
14:49:11 <tflink> when does 24 go eol?
14:49:28 <tflink> in about a week
14:49:55 <tflink> I'd say that upgrading stg/prod is more important than getting ansiblize deployed
14:50:20 <tflink> so, start upgrading stg/prod
14:51:00 * tflink doesn't much care if we move to ansiblize at the same time or wait until after the upgrades are done
14:51:12 <jskladan> I'd rather do one thing at a time
14:51:30 <kparal> and we have a volunteer!
14:51:31 <jskladan> I suspect the upgrade will be quite a pita, anyway
14:51:34 <kparal> thanks jskladan
14:51:48 <tflink> jskladan: they consume time but they're not usually too bad
14:51:50 <jskladan> noprob, I'm willing to nominate you any day of the year :)
14:52:40 <tflink> especialy when dev has already been done
14:52:53 <tflink> and all the non-dev client-host boxes are f25 already
14:53:31 <tflink> the question remains - when to do the upgrades?
14:53:34 <jskladan> btw: why don't we upgrade to 26?
14:53:45 <tflink> because 25 has already been figured out
14:53:53 <tflink> and that was before 26 had been released
14:54:07 <jskladan> tflink: what does 'figured out' mean in this context?
14:54:07 <tflink> if you want to do the upgrade to 26 on dev, that'd be fine by me
14:54:18 * jskladan has not figured out anything yet :D
14:54:21 <tflink> jskladan: iron out any kinks that come out of the upgrade
14:54:45 <tflink> sometimes it's painless, sometimes there are configuration changes that need to be worked out
14:55:18 * tflink points out that we only have 5 minutes left
14:55:26 <jskladan> so upgrading to 25 will be seamless, now? /me is not ironic, really asking
14:55:34 <tflink> I think so
14:55:53 <tflink> there will be some changes in ansible but IIRC, mkrizek got the upgrade ironed out a while back
14:56:48 <jskladan> well, we'll see. I have not seen any "this is what I encountered, be aware" document. I'm not sure whether it means the playbooks are just fixed, or not
14:57:05 <tflink> dev is 25, dev works
14:57:33 <tflink> therefore, I assume that the playbooks are fixed outside of any version-specific conditionals
14:57:49 <tflink> but it sounds like stg should be upgraded this week, at least
14:57:56 <tflink> maybe do prod a week from today?
14:58:02 <jskladan> OK, the upgrade to 25 was also done manualy by somebody else - is that the same for these machines?
14:58:20 <tflink> somebody else?
14:58:29 <tflink> it's usually me and martin
14:58:33 <tflink> is/was
14:58:36 <jskladan> IIRC, Martin did not do the reinstall
14:58:42 <jskladan> he was just running the playbooks
14:58:50 <jskladan> but was not installing the actual Fedora
14:58:54 <tflink> the reinstall is part of the playbook
14:59:14 <tflink> only the machine deletion is something that requires more privs
14:59:59 <tflink> as we're running out of time, I propose this:
15:00:05 <jskladan> whatever - there was some task he could not do, I don't know what it was - is it the same here, or not?  For the lack of information, I can't really ask about specifics, I just remember hearing "somebody else will need to do it" from him
15:00:07 <tflink> upgrade stg to 25 on wed or thurs
15:00:19 <tflink> upgrade prod to 25 on a week from today
15:00:26 <tflink> jskladan: deleting the old vms
15:00:35 <tflink> which is usually something I take care of
15:00:51 <tflink> jskladan, kparal: who's going to help do the upgrade?
15:01:18 <jskladan> I choose, kparal!
15:01:30 <tflink> this feels like pokemon
15:01:37 <tflink> "kparal, I choose you!"
15:01:51 <lbrabec> "it's super effective"
15:02:02 <tflink> kparal uses "upgrade" on the servers
15:02:12 <kparal> sure. but wednesday can't do
15:02:17 <tflink> thursday?
15:02:21 <kparal> yep
15:02:40 <tflink> ok, we can follow up in #fedora-qa on the time of day
15:02:50 <tflink> anything else for this?
15:02:55 <tflink> we're already over time for today
15:03:14 <jskladan> let's follow up elsewhere then
15:03:23 <jskladan> kparal and I will get the upgrade sorted out, hopefully
15:04:05 <tflink> #info taskotron-stg upgrade to f25 will happen this thursday
15:04:15 <tflink> #info taskotron-prod upgrade to f25 will happen next monday
15:04:39 <tflink> #info changeover of dev or stg to ansiblize will be soon, date TBD
15:05:24 <tflink> anything else on this?
15:05:32 <tflink> other than not answering the original question?
15:05:45 <kparal> what's the original question?
15:05:57 <tflink> upgrading something to ansiblize
15:06:33 <kparal> let's do that after f25 is working
15:06:50 <tflink> fair enough
15:07:13 <tflink> which, I think brings us to a very short ...
15:07:18 <tflink> #topic Open Floor
15:07:26 <tflink> anything else to bring up, even though we're out of time?
15:07:30 <lbrabec> nothing here
15:07:38 * tflink lights the short, non-deterministic fuse
15:07:45 <jskladan> http://kittenrescue.org/wp-content/uploads/2017/03/KittenRescue_KittenCareHandbook.jpg
15:08:05 <jskladan> http://www.warrenphotographic.co.uk/photography/bigs/03003-Ginger-cat-with-grey-foster-kittens-white-background.jpg
15:09:06 <tflink> jskladan: is the ginger cat supposed to be you?
15:09:15 <tflink> ok everyone, thanks for coming
15:09:20 * tflink will send out minutes shortly
15:09:22 <tflink> #endmeeting