15:03:43 <amoralej> #startmeeting RDO meeting - 2018-03-21
15:03:43 <zodbot> Meeting started Wed Mar 21 15:03:43 2018 UTC.  The chair is amoralej. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:43 <zodbot> The meeting name has been set to 'rdo_meeting_-_2018-03-21'
15:03:43 <openstack> Meeting started Wed Mar 21 15:03:43 2018 UTC and is due to finish in 60 minutes.  The chair is amoralej. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:43 <number80> people can be lazy to add agenda items
15:03:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:47 <openstack> The meeting name has been set to 'rdo_meeting___2018_03_21'
15:03:53 <amoralej> #topic roll call
15:04:10 <amoralej> #chair number80 jruzicka mjturek ykarel
15:04:10 <zodbot> Current chairs: amoralej jruzicka mjturek number80 ykarel
15:04:11 <openstack> Current chairs: amoralej jruzicka mjturek number80 ykarel
15:04:13 <number80> o/
15:04:22 <jpena> o/
15:04:22 * jruzicka adding agenda
15:04:23 <tosky> o/
15:04:23 <baha> o/
15:05:02 <amoralej> #chair tosky baha
15:05:02 <zodbot> Current chairs: amoralej baha jruzicka mjturek number80 tosky ykarel
15:05:02 <openstack> Current chairs: amoralej baha jruzicka mjturek number80 tosky ykarel
15:05:09 <amoralej> #chair jpena
15:05:09 <zodbot> Current chairs: amoralej baha jpena jruzicka mjturek number80 tosky ykarel
15:05:10 <openstack> Current chairs: amoralej baha jpena jruzicka mjturek number80 tosky ykarel
15:07:10 <amoralej> if anyone has a topic for the meeting, please add it to https://etherpad.openstack.org/p/RDO-Meeting
15:09:52 <rdogerrit> Jakub Ruzicka created rdoinfo master: distroinfo: add `more-info` section to allow modularity  https://review.rdoproject.org/r/13016
15:10:19 <jruzicka> #topic distroinfo modularity
15:10:53 <jruzicka> #link https://review.rdoproject.org/r/#/c/13016/
15:11:42 <jruzicka> please turn your attention to that review, especially the commit message which is a proposition for solutions of current problems with rdoinfo
15:12:14 <amoralej> jruzicka, we currently have some reference to deps.yml in rdoinfo
15:12:34 <amoralej> and iirc including deps.yml is optional
15:12:36 <amoralej> in some
15:13:25 <amoralej> your proposal is to replace that or using more-info ?
15:13:47 <jruzicka> my proposal basically unifies the two files
15:14:23 <elmiko> number80: if only i was as popular as a remote session package ;)
15:14:30 <jruzicka> I wanted to avoid listing all the files in every client querying the database
15:14:51 <amoralej> ack
15:14:54 <amoralej> sounds ok to me
15:15:09 <jruzicka> so the question is if there is a reason to have them optional
15:15:17 <amoralej> I'd say so
15:15:25 <amoralej> but i need to double check
15:15:27 <jschlueter> amoralej: ack and thanks
15:16:30 <amoralej> jruzicka, but anyway sounds good that clients doesn't need to know the files in the database
15:16:45 <jruzicka> disadvantages:
15:17:48 <jruzicka> - instead of one database, there are now as many of them as there are combination of the different info files... scalar becomes vector, guaranteed to increase copmlexity
15:18:23 <jruzicka> - instead of a single URL to a file, vase URL and a list of files needs to be passed
15:18:32 <jruzicka> *base, heh
15:20:08 <dmsimard> I'm here, kinda
15:20:19 <amoralej> #chair dmsimard
15:20:19 <zodbot> Current chairs: amoralej baha dmsimard jpena jruzicka mjturek number80 tosky ykarel
15:20:19 <openstack> Current chairs: amoralej baha dmsimard jpena jruzicka mjturek number80 tosky ykarel
15:20:33 <jruzicka> amoralej, actually, if you want to have a lightweight info and full info, there can be base info file for each, and both would #include-info: the base file, but only would include the deps
15:21:52 <jruzicka> number80, dmsimard, jpena, mhu, apevec, no opinions on this?
15:22:12 <dmsimard> jruzicka: I'm multithreaded right now and in a meeting ;(
15:22:31 <jruzicka> dmsimard, how can you do that to RDO meeing?! you monster...
15:22:35 <amoralej> jruzicka, yes, we can keep that list in the base and make it optional
15:22:36 <amoralej> so good
15:22:52 <dmsimard> jruzicka: people not in the RDO meeting sending meeting invites? :)
15:22:55 <jpena> I like the  idea of having separate "master" files for lightweight and full info. What I don't get is the differences/advantages of more-info: vs include-info
15:24:31 <jpena> actually, we would use that lightweight master file in dlrn
15:24:41 <jruzicka> jpena, I provide both just in case to cover all future desires, both can be used to achieve this with more-info being preferred ;)
15:25:01 * jpena prefers a single implementation
15:26:43 <amoralej> ok, i think we can keep the discussion in the review
15:26:49 <jruzicka> yes
15:26:59 <jruzicka> I just wanted to get it some attention.
15:27:00 <amoralej> just note that data distribution among files has some limitations
15:27:11 <jruzicka> which partially succeeded :-p
15:27:23 <amoralej> iirc a package can only exist in a file
15:27:41 * number80 multithreading and can only type using left hand
15:28:00 <jruzicka> ¯\_(ツ)_/¯
15:28:02 <number80> use #info command
15:28:27 <number80> raise visibility of ythat in the meeting minutes
15:28:27 <amoralej> there are no more topics
15:29:04 <jruzicka> #info please review and discuss rdoinfo/distroinfo modularity: https://review.rdoproject.org/r/#/c/13016/
15:29:14 <amoralej> ok
15:29:28 <amoralej> no more topics in the agenda
15:29:44 <amoralej> any volunteer to chair next week?
15:29:57 <amoralej> next week some people may be in pto
15:29:59 <jpena> I'll be on PTO next Wednesday
15:30:02 <amoralej> me too
15:30:49 <ykarel> i can take it
15:31:16 <amoralej> #action ykarel will chair next meeting
15:31:54 <amoralej> #topic open floor
15:32:04 <amoralej> any other topic that you'd like to share?
15:32:38 <dmsimard> amoralej: I have something
15:32:43 <dmsimard> amoralej: re: https://lists.rdoproject.org/pipermail/dev/2018-March/008638.html
15:32:55 <amoralej> yeah
15:33:02 <dmsimard> amoralej: so it's a one time trigger and if there's an issue, there's nothing that will pick up that one of our packages isn't up to date ?
15:33:09 <amoralej> yeah
15:33:22 <amoralej> as any job in post pipeline
15:33:33 <amoralej> we are notified if the jobs fail
15:33:54 <amoralej> in fact, i did remember an issue we had in ci tooling
15:34:00 <dmsimard> amoralej: could we have a periodic job that checks openstack/requirements or openstack/releases and matches that against what we have ? I'm concerned about the update gaps we might have especially considering how unstable the different environments have been recently
15:34:01 <amoralej> that i think was the root cause for that
15:35:01 <amoralej> yes, we could have a "reconciliation" job
15:35:06 <amoralej> to find out issues
15:35:26 <amoralej> between what is released and what is in -testing
15:36:04 <dmsimard> I remember a trello card I created shortly after joining Red Hat that was meant to do something similar but for reqs.txt of each project
15:36:21 <amoralej> the job has been quite stable but the last update of rdopkg broke it for some hours
15:36:21 <amoralej> https://review.rdoproject.org/r/#/c/12311/
15:36:27 <dmsimard> roughly equivalent to rdopkg reqcheck I think
15:36:30 <amoralej> that's why that job failed
15:36:56 <amoralej> i missed that build when i review the builds we lost
15:37:16 <dmsimard> amoralej: you shouldn't need to catch failures, it's a machine's job :D
15:37:21 <amoralej> yeah
15:37:22 <dmsimard> amoralej: if you want we can even monitor it through sensu
15:37:38 <amoralej> the point is that we run job for all reviews in rdoinfo
15:37:45 <amoralej> and openstack/releases
15:37:55 <amoralej> and got notifications about failures
15:38:06 <amoralej> but we need to check which ones were relevant to re-run it
15:39:08 <amoralej> so, yes, some check on missing releases would be good
15:39:17 <dmsimard> amoralej: we have different ways of attacking the problem
15:39:56 <dmsimard> amoralej: we can have a job that periodically checks that what we have matches what is in requirements/releases (and I think this would be good regardless of whether or not we want to use this to catch this problem, I could see this catch inconsistencies)
15:40:16 <dmsimard> and when I say a job, this could be a monitoring thing instead (i.e, sensu)
15:40:31 <dmsimard> and we can also monitor specific jobs in sensu, we used to do it for ci.centos.org
15:41:08 <amoralej> and alert in #rdo-dev?
15:41:12 <amoralej> or #rdo?
15:41:26 <dmsimard> amoralej: https://github.com/rdo-infra/ansible-role-rdomonitoring/commit/8f84fb223b2e00c460cce3f761efb10a1497c56e#diff-1240a240a51d3e45b83afc603d88dd68
15:41:40 <dmsimard> amoralej: we can do whatever we want
15:41:44 <dmsimard> I'm just saying the possibility is there :)
15:42:01 <dmsimard> It's probably more relevant to run this through monitoring rather than a job
15:42:31 <amoralej> i'll think about it
15:42:54 <dmsimard> amoralej++
15:42:54 <zodbot> dmsimard: Karma for amoralej changed to 5 (for the f27 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:43:58 <amoralej> any other topic?
15:46:43 <amoralej> ok
15:46:47 <amoralej> i'll close the meeting
15:46:59 <amoralej> #endmeeting