13:01:13 <bstinson> #startmeeting cbs/infra 13:01:13 <centbot> Meeting started Mon Sep 29 13:01:13 2014 UTC. The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:13 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:01:22 <bstinson> #topic Agenda 13:01:24 <bstinson> #info Greetings 13:01:26 <bstinson> #info Status Updates 13:01:28 <bstinson> #info Auth for git.c.o 13:01:30 <bstinson> #info SIG branch/build-target naming 13:01:32 <bstinson> #info Building embargoed content 13:01:34 <bstinson> #info Open Floor 13:01:36 <bstinson> #topic Greetings 13:01:38 <bstinson> #chair alphacc, arrfab, Evolution, kbsingh, MerlinTHP, quaid 13:01:38 <centbot> Current chairs: Evolution MerlinTHP alphacc arrfab bstinson kbsingh quaid 13:02:20 <bstinson> Looks like Arrfab alphacc MerlinTHP and Evolution are already here 13:02:26 <Arrfab> yes 13:02:33 <MerlinTHP> Afternoon all 13:02:37 <alphacc> hi 13:02:41 <Evolution> morning 13:02:51 <bstinson> mmmm coffee 13:02:58 <MerlinTHP> bstinson: give ;) 13:03:11 * bstinson DCC's MerlinTHP some coffee 13:03:16 * MerlinTHP finishes off his cold tea 13:03:40 <bstinson> #topic Status Updates 13:03:42 <MerlinTHP> First day back at work after a few days holiday, already missing my home espresso machine. 13:04:36 <bstinson> if i could fit an espresso machine in my office, i'd never get anything done 13:05:08 <MerlinTHP> I said I was going to sort out the test IPA instance. I've been slack and not done a lot on it (holiday / bash hilarity), so I need to get that sorted in the next few days. 13:05:49 <Arrfab> MerlinTHP: cool .. I don't know if quaid made progress on the FAS side either (quaid doesn't seem to be online) 13:06:10 <Evolution> MerlinTHP: there will only be another dozen or so iterations of the bash fix. 13:06:17 <Evolution> so should be good by the end of the week 13:06:49 <bstinson> Centpkg is pretty much where I left it last week 13:06:50 <TrevorH> which year? 13:06:50 <alphacc> I said I was gonna release Koji RPMs packages but then shellshock... It will be done before end of the day (I rebased on master branch as all patches we need are in) 13:07:14 <MerlinTHP> I think shellshock has uniformly caused chaos 13:07:46 <Arrfab> #info ShellShock got in the way, explaining status on various things 13:07:50 * kbsingh is here, but will be in meeting in 10 min, need to close off one critical thing 13:09:15 <Arrfab> FAS/IPA are things in parallel that will influence cbs, but what about other blockers on the cbs front ? 13:10:09 <bstinson> remind me what is blocking koji builds from git? 13:10:27 <alphacc> I think it's a matter of giving access to git.c.o to sig users 13:11:07 <Arrfab> alphacc: and kbsingh said that gitblit can support any auth we want (in the meantime, will be "unified" later) 13:11:40 <alphacc> Also, from last week there is a cron that generate the test repositories automagically. We may want to discuss that 13:12:01 <alphacc> Arrfab: I think the plan was to give them l/p 13:13:20 <Arrfab> alphacc: and you'd do a matching based on the CN in the cert you'll generate ? 13:14:32 <bstinson> #topic Blockers: Test repositories 13:14:48 <alphacc> Arrfab: koji will build from a public branch so it doesn't matter for the interaction even if they differ. 13:15:08 <kbsingh> for git.c.o access - my understanding is that we need a way to communicate branch name right ? 13:15:16 <kbsingh> if we dont need that, we can do login/pass right away 13:16:05 <kbsingh> alphacc: ah ok, so if the koji cert is limited to a target, the user can build whatever from git.centos.org's content, but only to that target 13:16:09 <kbsingh> if so, that is perfect. 13:16:25 <kbsingh> lots of cases, where people want to build content to their targets that is maintained by a different SIG 13:16:54 <alphacc> kbsingh: no, he can build anything from git.c.o but can tag it to his destination tags. 13:17:01 <alphacc> +only 13:17:08 <kbsingh> ok,that works too 13:18:10 <alphacc> kbsingh: while all branches we use are accessible through http, it should work. 13:18:15 <kbsingh> whats involved in testing this ? is it just a case of import some content into git.c.o and setup a few usernames ? 13:18:53 <kbsingh> we are going to import the xen content in tomorrow morning, so we can use that as a test 13:19:09 <alphacc> kbsingh: good cause srpm already built fine 13:19:27 <kbsingh> cool 13:19:49 <Arrfab> #action kbsingh to create usernames/pass on git.centos.org to test the git -> koji interaction 13:20:22 <bstinson> can they be both passworded and tied to a client cert? 13:20:26 <kbsingh> some folks already have user/pass 13:20:40 <kbsingh> bstinson: no, if we start moving to certs, the login/pass will need to go 13:20:48 <alphacc> Arrfab: cbs.c.o/repos contain all testing / release repositories that are generated every 10 minutes. Do we have concern about that ? 13:21:05 <kbsingh> alphacc: the repos are good 13:21:30 <kbsingh> if we start running out of resources, we might need to mirror those somewhere else i guess , but the mchine should have lots of space cpu / ram/ disk /net at this point 13:21:40 <alphacc> kbsingh: I found a bug, for 7 it generates i386 as well, I'll push a fix soon. 13:22:06 <kbsingh> is the bug i386 ( vs/ i686 ) or that it generates it at all 13:22:09 <alphacc> kbsingh, Arrfab : it would be great to have a git repo to push all koji stuff 13:22:18 <kbsingh> if it generates the 32bit target, we should maybe leave that in and import the tree's from buildlogs 13:22:35 <alphacc> (so you can see I do some work ;) 13:22:44 <kbsingh> what would this stuff be ? 13:23:04 <Arrfab> alphacc: define "git repo" : to store some scripts around koji ? 13:23:12 <kbsingh> if its rpms like layout then we just need the git repos under rpms/ for that, if its config and notes etc - then we can create a git repo under sig-core 13:23:13 <alphacc> all admins script and if we use git-crypt maybe the CA stuff 13:24:03 <Arrfab> kbsingh: ^ do you see an issue with that ? 13:24:30 <kbsingh> how much do we trust git-crypt 13:25:09 <Arrfab> kbsingh: so what would be your recommandation ? 13:25:30 <kbsingh> maybe put the ca stuff in a priv repo for now, and let the other stuff be public 13:25:37 <kbsingh> we can host a priv repo in the same place as well 13:27:00 <bstinson> +1 13:27:41 <kbsingh> 100% of survey responders agree... 13:27:44 <Arrfab> kbsingh: the idea was to have a priv repo for that anyway .. but didn't know you wanted a public one too .. so let's divide that into two parts 13:28:15 <kbsingh> oh; i thought alphacc was saying a public git repo -and that makes sense, why would we want to have the scripts etc be private ? 13:29:15 <Arrfab> kbsingh: well, he never mentioned "public" but it's also the reason why we're discussing it here and now 13:29:41 <Arrfab> if we all agree, I can create two repositories for that (I normally can do that on git.centos.org) 13:30:07 <Arrfab> #action Arrfab to create two git repositories for cbs usage to hold scripts/automation and everything around cbs 13:30:22 <bstinson> great 13:30:29 <kbsingh> works for me 13:30:29 <alphacc> both are ok with me. it's more to track my work in a better way and delegate actions soon 13:31:53 <bstinson> while we are talking about git, is there any chance i could get added to the centpkg repo and have another under /rpms created? 13:32:24 <kbsingh> bstinson: sure, can you file a request at bugs.centos.org and we can take it from there 13:32:30 <bstinson> will do 13:32:46 <bstinson> anything else before we move on? 13:32:50 <kbsingh> lets try and drive bugs.centos.org as an audit trail for who has access to what/where ( till we have a better system ) 13:33:11 <alphacc> +1 13:33:57 <Arrfab> do we have something else for today ? 13:34:09 <kbsingh> bstinson: yes, lets move along 13:34:14 <bstinson> #topic Building embargoed content 13:34:17 <Arrfab> and no, I don't want people to say "yes, new bash packages please" :p 13:34:23 <MerlinTHP> Awww ;( 13:34:33 <MerlinTHP> Maybe some c4 ones? 13:34:35 * MerlinTHP runs 13:34:43 <kbsingh> there will almost certainly be more packages for the bash issue in the coming days / weeks 13:34:49 * Arrfab slaps MerlinTHP with a bash function 13:34:56 <kbsingh> but so far the packages out there resolve all the major / known cases 13:35:06 <bstinson> heh 13:35:38 <alphacc> (I think next one is Xen be ready on 1st ;) 13:36:35 <alphacc> Embargoed content will need some work on Koji 13:37:07 <kbsingh> is there someway we can come up with a process flow that achieves something similar 13:37:08 <bstinson> kbsingh: is the idea to have the builds ready to go far in advance? 13:37:29 <kbsingh> ok, so 2 things 1) we need a place for people to be able to test build embargo content 13:37:36 <Arrfab> alphacc: is there a possibility to have a specific tag/target only visible to authorized people ? and also not producing repodata/repositories visibile under /kojifiles ? 13:37:44 <kbsingh> and secondly we need a place to stage content 13:37:50 <kbsingh> (1) is more important than (2) 13:37:59 <MerlinTHP> kbsingh: me query is... do we? Fedora doesn't, for example. 13:38:22 <MerlinTHP> Are we likely to start getting embargoed notifications? 13:38:22 <alphacc> Arrfab: the is no acl at all in koji for content. 13:38:41 <kbsingh> for (1) we can likely do scratch builds, since that also means we dont need to hit git.centos.org 13:38:47 <TrevorH> CentOS is on the list of interested parties notified in advance for XSA-108 I think 13:38:54 <MerlinTHP> scratch builds are still visible 13:39:02 <kbsingh> for (2) we can always go with 'submit to git and push to build once issue is public' - and even for longer running jobs, we should be mostly OK 13:39:09 <MerlinTHP> You have to dig for them, but you can still see them 13:39:24 <kbsingh> MerlinTHP: we get lots of embargo content, and its only growing 13:39:52 <MerlinTHP> Right-o. 13:39:53 <bstinson> one option is to build locally, commit to git, and then push after the embargo is lifted 13:40:03 <MerlinTHP> Basically, if you build it in cbs, someone can see it. 13:40:05 <kbsingh> MerlinTHP: right, so for scratch builds, can we have them end up in a place where they are not ( ie. no logs either ) 13:40:11 <MerlinTHP> kbsingh: nope 13:40:14 <kbsingh> humm 13:40:38 <Arrfab> bstinson: or have another koji setup for that specific task/purpose but it's becoming hard 13:40:44 <kbsingh> the problem i am mostly trying to solve is : to not haveto fix builds and work code in build process / deps once a known exploit is public 13:40:52 <MerlinTHP> The best you can do really (that I can think of) is a local mock build using the koji repo (which you can do with centpkg) 13:41:05 <kbsingh> humm 13:41:28 <MerlinTHP> The alternative is what I suspect is some deep surgery to koji 13:42:02 <Arrfab> MerlinTHP: not sure we want to dive into that :-) 13:42:04 <kbsingh> mikem: do you have an opinion on this ? embargo content thing 13:42:06 <MerlinTHP> If we wanted to go that route, Mike McLean's already chimed in on the c-d mail thread, and I think he's most familiar with the code. 13:42:14 <kbsingh> yea 13:42:15 <MerlinTHP> ... or ask him here :) 13:42:47 <MerlinTHP> Arrfab: well, koji's codebase isn't bad, it's just that that sort of access control just wasn't designed in at any point 13:42:55 <MerlinTHP> Not sure how hard it'd be to graft in 13:43:35 <mikem> kbsingh, MerlinTHP is right about the difficulty of adding read access acls to koji. 13:44:14 <mikem> Not to say it can't happen, but it is not likely to happen quickly 13:44:17 <kbsingh> since git is public, we cant push to that ahead of time anyway - so we can easily say that neither git nor koji should be used for this, and bake in some process for centpkg that hits the same repos etc as koji would... 13:44:28 <MerlinTHP> FWIW, the main difference between a koji scratch build and {cent,fed}pkg's mockbuild command (which does a local mock build using koji's mock config) is generally number of CPUs, amount of RAM, disk speed. 13:44:34 <kbsingh> overall, that should mean the build gets run in a fairly similar way as it will on koji 13:44:47 <bstinson> kbsingh: rpkg already pulls in the mock configs from koji 13:45:07 <MerlinTHP> So a centpkg mockbuild _should_ basically be the same as a koji build, modulo breakage from make -j issues. 13:45:13 <kbsingh> MerlinTHP: and the challenge that centpkg is being run on the same machine type arch etc 13:45:15 <mikem> and we'd want to also have similar read acls in git 13:45:32 <bstinson> and some tweakery around _not_ uploading sources to the lookaside yet 13:45:51 <MerlinTHP> bstinson: centpkg mockbuild works on uncommitted local changes 13:45:54 <bstinson> if you want stage the commits 13:46:05 <MerlinTHP> I use it a _lot_ before pushing stuff into git and doing a koji build 13:46:11 <kbsingh> mikem: gitblit can make branches readonly.. we'd just need to agree to a pattern 13:46:20 <MerlinTHP> ( cos I like the git commit logs to look like I know what I'm doing ;) 13:46:58 <kbsingh> mikem: but, it would be readonly to people who cant commit to that branch name, if we say give Group X access to branch names el7_blah_*; then any branch name starting with el7_blah_* will NOT be private to that entire group 13:47:15 <MerlinTHP> Basically, AFAICT Fedora "solves" this issue by people doing their own local builds, and only pushing to fedora git and doing a koji build when the embargo ends. 13:47:39 <MerlinTHP> I suspect if it was that much of an issue for them, they'd have solved it themselves by now. 13:47:48 <kbsingh> MerlinTHP: so that works 'doing their own thing' - but we need try and come up with a process that anyone / everyone can follow - and then socialise it 13:47:59 <alphacc> kbsingh, mikem : passing authenticated git url to koji will need some work. 13:48:00 <mikem> kbsingh, did you really mean readonly? or did you mean private? 13:48:06 <kbsingh> if this becomes a huge thing, ie. we need to do more than 1 or 2 a month, then we can even find some hardware that has reasonable perf 13:48:21 <mikem> alphacc, yes, that too 13:48:58 <kbsingh> mikem: so, that branch would be private ( so noone other than the group can see it ) - but everyone within the group will see it readonly, except the author who gets read+write 13:49:21 <kbsingh> erm, i see what you mean mikem - yes, i meant private there. 13:49:23 <MerlinTHP> kbsingh: I'd assume embargoed content would be fairly restricted circulation anyway, so how many people are we talking about educating here? 13:49:30 <mikem> short term, the simple answer is local mock build using the same repos that koji does. The koji cli will even generate a mock config for you. 13:49:44 <kbsingh> MerlinTHP: potentially every sig 13:49:45 <mikem> Also, there the the pyrpkg feature for local builds 13:49:51 <MerlinTHP> kbsingh: ... ouch. 13:51:14 <Arrfab> mikem: do you mean a local mock config file pointing to the same repositories used at the koji builders level ? 13:51:22 <mikem> yes 13:51:25 * MerlinTHP nods. 13:51:26 <kbsingh> so, who is going to write up the wiki page on 'handling embargo content' 13:51:49 <kbsingh> also, are all the koji repo's publicly visible ? 13:52:25 <Arrfab> mikem: well, it would be "interesting" as those nodes are using specific internal repositories, not available outside (for base/updates) 13:52:40 <mikem> kbsingh, in most setups yes. You could block them if desired 13:52:45 <Arrfab> kbsingh: yes, they are 13:53:45 <alphacc> kbsingh Arrfab : it will return the repo as declared in koji. 13:54:26 <MerlinTHP> In this case, the repos are either public (koji repos) or contain public content (the local external centos mirror), so I don't really see an issue. 13:55:09 <bstinson> ok, so did we settle on having embargoed content being built locally (koji&mock and/or centpkg mockbuild) for now? 13:55:10 <kbsingh> ok 13:55:23 <Arrfab> bstinson: yes 13:55:31 <kbsingh> bstinson: yeah, we should document it through specicially as 'this is how we do embargod content' 13:55:47 <MerlinTHP> *nod* 13:55:54 <mikem> if we want it /now/ then local mock builds are really the only available option 13:56:05 <alphacc> yes 13:56:08 <bstinson> #info Embargoed content will be built locally for testing, and pushed/built in CBS once the embargo expires 13:56:17 <MerlinTHP> We could look at providing access to specific build hosts 13:56:31 <MerlinTHP> Not everyone can sensibly do local mock builds. 13:56:32 <bstinson> let's do a vanilla wiki page (with the koji cli and mock) and i'll add a section to the centpkg page 13:57:18 <mikem> for sanity of documenting, centpkg mockbuild is probably the easiest way to go 13:57:32 * MerlinTHP nods 13:57:33 <alphacc> +1 13:57:35 <Arrfab> MerlinTHP: that's a good idea 13:57:55 <bstinson> #action bstinson will write up an "Embargoed Content" section for using centpkg mockbuild 13:58:12 <mikem> (vs koji mock-config -o foo.cfg ; mock -r foo.cfg) 13:58:33 <MerlinTHP> I'd recommend tuning the mock config on the box(es) a bit, turning off buildroot caching, maybe enable tmpfs build if the box has enough ram, etc. 13:58:42 <Arrfab> MerlinTHP: let me sync with kbsingh to see if we can't even host that machine (a VM would suffice I guess) for those embargo'ed builds 13:58:54 * MerlinTHP nod 13:59:15 <Arrfab> kbsingh: ^ 13:59:41 <bstinson> great, let's talk about the status of that next meeting 14:00:55 <bstinson> one more thing before we go, let's discuss the SIG branch naming scheme on the list 14:01:24 <bstinson> <signame><centos_version_number> seems to be the natural choice 14:01:53 <kbsingh> works for me 14:01:54 <alphacc> +1 (as it is closed to what we agreed for cbs) 14:02:16 <Arrfab> #action: arrfab to discuss a plan with kbsingh to provide access to a VM for those embargo'ed builds with centpkg 14:02:32 <kbsingh> Arrfab: i think lets do that VM thing etc if/when this becomes a bigger deal 14:02:39 <bstinson> do we have "distribution" build targets? 14:02:56 <kbsingh> at the moment, people with the embargo content typically represent or already work inside the project being affected 14:02:57 <alphacc> #action validate and communicate (update wiki) on available testing repositories. 14:03:04 <MerlinTHP> bstinson: what would that be for? 14:03:36 <bstinson> i'm just working out what to map the c5/c6/c7 dist-git branches to 14:03:49 <MerlinTHP> centos base doesn't build in koji 14:04:19 <MerlinTHP> Is this for centos-extras type stuff? 14:04:49 <kbsingh> the only case we have for that is cloud-init 14:04:56 <kbsingh> where I used c7-extras as the branch name 14:05:08 <bstinson> no, if we want to leave those alone (and not map those to a target at all) that's fine too 14:05:26 <MerlinTHP> If we made those targets people would just try and use them... 14:05:27 <MerlinTHP> ;) 14:05:38 <kbsingh> ok 14:05:52 <bstinson> let's wrap this up 14:06:07 <MerlinTHP> kk 14:06:10 <bstinson> #topic Open Floor 14:06:26 <MerlinTHP> I've got a (hopefully) quick one 14:06:33 <MerlinTHP> koji builder internet access. 14:06:38 <MerlinTHP> Looks like the current box does. 14:06:42 <MerlinTHP> It shouldn't ;) 14:07:02 <alphacc> +1 14:07:07 <MerlinTHP> The builder(s) should only have access to the hub, lookaside, and git 14:07:32 <kbsingh> +1 14:07:39 <MerlinTHP> If they have internet access, an rpm build could e.g. wget random crap from the internet and stick it into the build 14:07:41 <Arrfab> MerlinTHP: git machine is somewhere else, so easy fix is to delete default route and add a specific one to git 14:07:51 <MerlinTHP> Arrfab: that sounds like a plan 14:08:02 <MerlinTHP> Or make the default router a firewall or something 14:08:10 <MerlinTHP> Anything that has that effect 14:08:12 <Arrfab> MerlinTHP: that too 14:08:40 <Arrfab> #action arrfab to fix default route on koji builder to remove internet access 14:08:55 <bstinson> awesome 14:09:00 <MerlinTHP> Cheers :) 14:09:10 <MerlinTHP> That's all I've got 14:09:22 <kbsingh> cool, thanks 14:09:39 <bstinson> #info Congrats to the CentOS Core Sig for the 5.11 release 14:10:12 <Arrfab> bstinson: do you close meeting ? I'll fetch/upload minutes to centos.org/minutes in the following .. <drum roll> minutes !</drum roll> :D 14:10:29 <bstinson> #endmeeting