14:03:26 <bstinson> #startmeeting CBS/Infra
14:03:26 <centbot> Meeting started Mon Jun 12 14:03:26 2017 UTC.  The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:26 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:03:41 <bstinson> #topic Agenda/Greetings
14:03:50 <bstinson> #info Topic: Status Updates
14:03:58 <bstinson> #info Topic: Account Requests
14:05:32 <bstinson> #info Topic: Open Floor
14:05:37 <bstinson> #topic Status Updates
14:05:41 <bstinson> anyone here today?
14:05:45 <Arrfab> bstinson: me :-
14:06:04 <bstinson> Arrfab: \o
14:06:26 <sbonazzo> o/
14:08:43 <bstinson> anything going on this week?
14:09:35 <sbonazzo> bstinson: on my side, still fighting to get packages built in cbs landing correctly on buildlogs and on mirrors
14:09:54 <sbonazzo> bstinson: and built / published for altarchs
14:10:56 <Arrfab> sbonazzo: kbsingh said that there are no pkgs waiting for signatures, so the question is : what are those pkgs ?
14:11:01 <Arrfab> kbsingh:  ^
14:11:14 <Arrfab> or is the script not altarch aware ? (so not even checking for altarch pkgs)
14:11:23 <sbonazzo> Arrfab: kbsingh: example: http://cbs.centos.org/koji/buildinfo?buildID=17353
14:11:43 <kbsingh> there are 5 different things here
14:11:55 <sbonazzo> not landing in https://buildlogs.centos.org/centos/7/opstools/x86_64/logging/
14:12:11 <kbsingh> do you have the bug no where this was requested ?
14:12:23 <sbonazzo> kbsingh: let me fetch it
14:13:04 <sbonazzo> kbsingh: https://bugs.centos.org/view.php?id=13332
14:13:33 <kbsingh> ": Please remove opstools7-elastic-* tags"
14:13:52 <kbsingh> is that the right bug id :)
14:14:00 <sbonazzo> kbsingh: read description :-)
14:14:14 <kbsingh> you need to file a report, specifically, to add a target to be moved.
14:14:18 <kbsingh> use the format mentioned in the sig guide
14:14:23 <kbsingh> i am sure you have done this in the past...
14:14:41 <kbsingh> anyway, i think the one liner in there was entirely lost in the msg there, bstinson can you add/mod content-control as needed ?
14:14:59 <sbonazzo> kbsingh: not 100% sure. But I can file yet another bz if needed
14:15:30 <bstinson> sure
14:15:34 <kbsingh> upto bstinson here... now that its been highlighted
14:15:45 <sbonazzo> kbsingh: bstinson: thanks
14:15:51 <kbsingh> but i suspect it got lost in the middle there
14:16:16 <sbonazzo> kbsingh: next: https://bugs.centos.org/view.php?id=13283
14:16:34 <kbsingh> sbonazzo: also, make sure that the relevant people +1 etc
14:16:37 <kbsingh> ink so, asked mrunge to review and said it looks good.
14:16:47 <kbsingh> erm
14:17:04 <sbonazzo> kbsingh: any other people to ask other than mrunge ?
14:17:23 <kbsingh> sbonazzo: whoever owns the code :) - but ask them to +1 or say something on the bug report itself please
14:17:32 <mrunge> kbsingh, looks good to me
14:17:36 <sbonazzo> mrunge: can you please ack on the bz?
14:17:42 <kbsingh> ink so, asked mrunge to review and said it looks good.
14:17:57 <mrunge> sbonazzo, what bz?
14:18:04 <mrunge> you mean the centos bug?
14:18:06 <sbonazzo> mrunge: https://bugs.centos.org/view.php?id=13332
14:18:24 <mrunge> oh, that?
14:18:27 <sbonazzo> mrunge: and https://bugs.centos.org/view.php?id=13283
14:18:39 <mrunge> looks good as well
14:19:55 <alphacc> sbonazzo: opstools7-sensu* are not yet rebuilt ppc64le
14:20:45 <kbsingh> added a note to the 13283 report as well - basically, the scripts are not finding content at the same place
14:21:35 <mrunge> it looks like the packages tagged to opstools7-fluent-012-release are not copied over to mirror.c.o
14:21:46 <mrunge> or was that fixed recently?
14:22:13 <kbsingh> mrunge: they are not on buildlogs, cant promote to mirror till they are on buildlogs
14:22:29 <bstinson> mrunge: this will all get sorted out now that we have a recorded +1 from you
14:22:42 <kbsingh> mrunge: so the way to fix this is to make sure that all the content, is built with the same srpm, and pushed to the same tag ( ie, the repo path on the cbs nfs needs to be identical ) and it will just-work for buildlogs
14:22:54 <kbsingh> if we can get to that point, lets then look at where and how the content is going to land on mirror.c.o
14:22:55 <mrunge> where do you need a recorded +1 bstinson ?
14:23:57 <bstinson> mrunge: comments in the bugs would be best
14:24:06 <mrunge> bstinson, already done
14:24:09 <alphacc> mrunge: https://buildlogs.centos.org/centos/7/opstools/x86_64/logging/ contains fluent, no ?
14:24:25 <mrunge> it does
14:24:39 <mrunge> but we have a newer build, alphacc
14:24:45 <bstinson> alphacc: the tags were moved
14:25:25 <sbonazzo> alphacc: what's missing for rebuilding?
14:25:28 <mrunge> alphacc, https://cbs.centos.org/koji/buildinfo?buildID=16789
14:25:44 <mrunge> that build is tagged, but didn't land somewhere, for example
14:25:53 <alphacc> sbonazzo: all the rubygems that are arch specific and the rest
14:26:21 <alphacc> sbonazzo: I dont think we looked at sensu tags yet
14:26:38 <sbonazzo> alphacc: can I help with it?
14:27:58 <alphacc> sbonazzo: Let me send the build and see if we have things to fix
14:28:09 <sbonazzo> alphacc: thanks
14:29:53 <bstinson> anything else for status updates?
14:32:05 <bstinson> cool
14:32:09 <bstinson> #topic Account Requests
14:32:29 <alphacc> sbonazzo: I remember now the problem is some package have been cross tagged, no need to rebuild in original buildroot and so enable ppc64le for those buildroot
14:32:54 <alphacc> s/no/so we/
14:32:58 <kbsingh> i have an apology for amoralej - when you requested the account, i had spoken with apevec as i usually do - and i *thought* the account was ack'd, but it wasent.
14:33:12 <kbsingh> thanks Arrfab and rbowen working through that and gettting it sorted out while i was away
14:33:32 <amoralej> no problem kbsingh, and thanks Arrfab for helping me!
14:33:50 <Arrfab> amoralej: you're welcome, especially after the help you gave me for rdo ;-)
14:35:06 <kbsingh> otherwise no pending accounts other than spammers, or ones that are requested and not -1'd
14:35:09 <kbsingh> so were good for now
14:35:36 <bstinson> i believe everything should be caught up in CI. i'm waiting on a couple of folks to create bugs. will handle those then
14:36:17 <bstinson> #topic Open Floor
14:36:25 <bstinson> what else do we have for today?
14:36:40 <Arrfab> #info as discussed with bstinson we plan on moving jenkins master to a more powerful node. Details will land on the ci list when plan is ready
14:36:46 <kbsingh> did we ever get to workout a delete/arch/de-activcate unused accounts ?
14:37:04 <kbsingh> Arrfab: wrong meeting ? :)
14:37:32 <kbsingh> ah, i missed the open floor
14:37:38 <Arrfab> kbsingh: hmm, I thought that cbs/infra meeting was also about CI, but happy to shut my mouth if not the correct one :-)
14:37:51 <kbsingh> Arrfab: no, my bad, i thought we were still talking accounts
14:37:52 <bstinson> CI stuff is certainly welcome here :)
14:38:01 <kbsingh> yea
14:38:09 <Arrfab> kbsingh: you can't delete accounts (per design)
14:38:22 <Arrfab> but you can remove them from groups or disable those accounts
14:38:24 <kbsingh> the question was more about at what time do we deactivate them
14:38:33 <kbsingh> we have some accounts that are unused now for almost 2 years
14:38:53 <Arrfab> kbsingh: that's a good question as we'd have then first to quantify "active or inactive"
14:38:56 <kbsingh> its safe to say that user is unlikely to come back, if they do - requesting re-enabling should be acceptable
14:39:03 <Arrfab> yes
14:39:16 <bstinson> this is just from memory so i may be wrong, but we agreed on marking them inactive 6 months after the certificate expires?
14:39:31 <kbsingh> 6 months get my vote
14:39:41 <Arrfab> wfm
14:39:48 <kbsingh> what is the term of the cert we issue at the moment ?
14:39:51 <Arrfab> so that can be up to one year
14:40:06 <Arrfab> kbsingh: 6 months is the default validity
14:40:09 <bstinson> +1 from me
14:40:09 <kbsingh> we might need to link the cert to account enabled status (?)
14:40:29 <bstinson> link the cert in what way?
14:40:33 <kbsingh> so if that is 6 months, then someone who does not renew for say 4 weeks after expiry of cert can be marked as 'disabled' ?
14:40:58 <Arrfab> kbsingh: so 1 month instead of 6 as proposed earlier. That also works for me
14:41:14 <kbsingh> ah i see
14:41:27 <Arrfab> as soon as we disable a user in ACO, it revokes the user's cert and put it in the CRL that is also used by cbs
14:41:28 <kbsingh> were you saying/assuming that someone who does not renew their cert for 6 months ? that seems a bit long
14:41:49 <Arrfab> kbsingh: yeah, also reason why I said then "up to one year" :-)
14:42:14 <kbsingh> we should certainly disable someone who's not renewed cert in 6 months from expiry
14:42:18 <kbsingh> but do we need to wait that long ?
14:42:20 <Arrfab> so 4 weeks after cert expired is good from me
14:42:51 <Arrfab> and still not tracking the activity itself within CBS ?
14:43:33 <kbsingh> do we need that ? as in, we already track cert expiry - tracking usage in cbs might add another layer of complexity
14:44:01 <kbsingh> would this also include users who do things like blog's or use any other service connected to aco ?
14:44:13 <Arrfab> kbsingh: true, reason why I asked. We can have "inactive" users who just renew their certs though, but if they don't use it, why caring ?
14:44:16 <kbsingh> i guess people on seven.centos.org dont get a cert at all ( unless they also do cbs )
14:44:28 <Arrfab> kbsingh: yes
14:44:35 <bstinson> i think the lifecycle of accounts on the other services is another question
14:44:35 <kbsingh> how would we cover those users ?
14:45:10 <Arrfab> kbsingh: back to the "how do we quantify" inactive vs active outside of CBS
14:45:26 <kbsingh> might be good to have just one policy, implemented in only one place, if possible, for all the centos services
14:45:29 <kbsingh> but only if we can
14:46:09 <kbsingh> do we want to takeaway an action to 'implement expiry for cbs now, and explore options for other services'
14:46:24 <bstinson> i think one-size-fits-all would be difficult to do since there's no central mechanism for tracking login activity
14:46:32 <bstinson> not impossible, but difficult
14:47:41 <Arrfab> kbsingh: +1
14:47:58 <kbsingh> bstinson: would the auth landing page not log this
14:48:19 <kbsingh> but, I'm ok to get this done for cbs, so i can stop chasing people who are clearly not interested/busy elsewhere/moved on
14:48:32 <kbsingh> and let Arrfab find a way to implement for everything else ( or propose a plan )
14:48:52 <Arrfab> wfm
14:48:59 <bstinson> kbsingh: not necessarily, because we sync user accounts for some services
14:49:14 <kbsingh> bstinson: ah, i had forgotten that
14:49:28 <kbsingh> ok, needs more thought
14:49:47 <bstinson> i'm good with doing CBS, 4 weeks after the user certificate expires
14:49:51 <bstinson> Arrfab is +1
14:50:43 <bstinson> looks like kbsingh is +1
14:51:19 <Arrfab> +1
14:51:58 <bstinson> #agreed CBS accounts will be deactivated 4 weeks after the user certificate expires
14:52:40 <bstinson> Arrfab: if you want a hand let me know, we'll probably do this in the same script that sends out the emails?
14:53:18 <Arrfab> bstinson: yes, that was my thought : if already expired for >= 28 days, send another mail to $admins to expire the account
14:53:55 <bstinson> cool
14:54:05 <bstinson> other items for open floor?
14:55:37 <Arrfab> bstinson: not on my side
14:55:55 <kbsingh> one thing from my side
14:56:05 <kbsingh> there was some issues around signing and how content is pushed around in the automation
14:56:33 <kbsingh> I've got a todo to look at the logs to find out why everything was running with a 24hr delay
14:57:11 <kbsingh> only briefly looked at the logs, and there is nothing apparent as to why this might be, the sign queue will literally copy things, sign and return - and as far as i can tell, it has been signing when it saw stuff
14:57:20 <kbsingh> but will post details to the centos-devel list
14:57:48 <Arrfab> kbsingh: cool. What I saw (for Altarch) is that you push back pkgs that were removed from signing queue
14:57:51 <kbsingh> the one thing that did happen in the last few weeks is that i was not doing manual runs on demand ( which i have done in the past when people pinged me ) - so perhaps part of this is expectation as well
14:58:18 <kbsingh> Arrfab: there is no --delete option for the sign queue - not for the cbs ones or the altarch ones
14:58:45 <kbsingh> so removing stale bits is a manual process. you did email me a list of these .part files, i will go look soon
14:58:47 <Arrfab> so how can we remove pkgs from mirror.centos.org ?
14:59:01 <kbsingh> how do you mean ?
14:59:02 <Arrfab> not only partial rsync files, but older files too
14:59:10 <kbsingh> the sign process does not push to mirror.centos.org for altarch
14:59:32 <kbsingh> for the cbs process, each package is verified before a push, so only files that meet the spec will be put in ( they are done one at a time )
14:59:37 <Arrfab> kbsingh: I know but if I delete at the signing queue level, those deleted pkgs are back there
14:59:41 <kbsingh> and we typically dont remove from mirror.centos.org
15:00:12 <kbsingh> that would be something you need to fix and remove at the stage where you push from altarch signed bits into the mirror.centos.org place
15:00:23 <kbsingh> this is just a one off, isnt it ?
15:00:32 <Arrfab> that's what I have to do : new clean up, new repodata, each time
15:00:37 <kbsingh> also, you are talking specifically about the altarch sign queue
15:00:48 <Arrfab> true
15:00:58 <kbsingh> Arrfab: ok, but a validation stage is good to have there anyway
15:01:08 <kbsingh> atleast a rpm -K
15:01:36 <Arrfab> which I do for each altarch before pushing , including specific key check for $arch
15:01:42 <kbsingh> cool
15:02:06 <kbsingh> so we just need to move those 4 or 5 part files
15:02:22 <Arrfab> kbsingh: yes .. let me give you a full list offline
15:02:44 <kbsingh> thanks
15:03:15 <bstinson> ok, going to close the meeting in 1 minute unless there are any last items
15:04:45 <bstinson> thanks all!
15:04:47 <bstinson> #endmeeting