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