15:33:07 <jzb> #startmeeting CentOS Atomic SIG
15:33:07 <zodbot> Meeting started Tue Nov  4 15:33:07 2014 UTC.  The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:33:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:33:07 <centbot> Meeting started Tue Nov  4 15:32:45 2014 UTC.  The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:33:07 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:33:43 <jzb> #chair walters Evolution imcleod_ jbrooks
15:33:43 <zodbot> Current chairs: Evolution imcleod_ jbrooks jzb walters
15:33:43 <centbot> Current chairs: Evolution imcleod_ jbrooks jzb walters
15:34:00 <jzb> OK, quick rundown from last week's meeting
15:34:13 <jzb> #topic ACTION: jzb get info on SRPM collaboration
15:34:31 <jzb> this is still pending. I bumped the discussion on the CentOS list - there's been no activity since last Monday.
15:34:36 <jzb> (aside from my bump...)
15:34:47 <jzb> Evolution: any way to move that to completion?
15:34:57 * jbrooks here
15:35:01 <jzb> bstinson: ^^ if you're around, I know you started the discussion
15:36:01 <Evolution> jzb: dunno what you're after here. for srpm collaboration
15:36:33 <jzb> Evolution: the "Policy for Ad-Hoc Upstreams" discussion
15:36:50 <jzb> I think we're still in limbo deciding how we collaborate on sources that aren't part of CentOS proper.
15:37:33 <walters> i think we could probably move atomic forward with just keeping specs in a github repo
15:37:46 <walters> what does GlusterFS do?
15:37:51 * walters looks
15:40:54 <walters> answer appears to be https://forge.gluster.org/glusterfs-core/glusterfs/blobs/master/extras/LinuxRPM/Makefile.am
15:41:22 <Evolution> jzb: well, to some extent atomic is a bit of a snowflake case.
15:41:38 <jzb> Evolution: sadly, true.
15:41:41 <Evolution> most projects have outside source repos already and we don't want to interfere there.
15:42:08 <jzb> Evolution: if it's not going to get us blocked anywhere, I think the SIG is happy to use GitHub
15:42:10 <Evolution> but at the same time, we're looking to be the source repo for SCL, and likely atomic as well unless you stay with github
15:42:20 <Evolution> github's fine by me.
15:43:02 <walters> i guess with centos for the most part the only intersection between SIGs is the common core
15:43:21 <jbrooks> The SIG materials on the centos site talk about code needing to be in git.centos.org, but github is fine
15:43:26 <walters> you don't have the fedora concerns where someone may want to update some e.g. python library and have to reverse map to what products it affects
15:43:45 <jzb> OK, so - are we all good with GitHub then?
15:44:45 <kbsingh> the dist-git stuff needs to be in git.centos.org; but if the upstream code is elsewhere, thats fine - thats mostly how almost everything is setup right now. the SCL setup might be the first lot to have their upstream inside git.centos.org as well
15:45:16 <jzb> #chair kbsingh
15:45:16 <zodbot> Current chairs: Evolution imcleod_ jbrooks jzb kbsingh walters
15:45:17 <centbot> Current chairs: Evolution imcleod_ jbrooks jzb kbsingh walters
15:45:40 <imcleod_> kbsingh: OK.  So those of us who want to be building this need to add g.c.o access on top of our CBS access, yeah?
15:46:07 <kbsingh> imcleod_: technically, it should be the same thing, most people would only need to ask for git.c.o access, and that gets them access to cbs for their sig branch names as well
15:46:26 <kbsingh> imcleod_: the big diff in an upstream git repo and a dist-git repo on git.centos.org is that the upstream repos can have arbitary branch names
15:46:37 <kbsingh> the dist-git repos can only push into the branch that matches the users sig tag
15:47:08 <kbsingh> and the upstream git repos end up in /signame/<name>, rather than /rpms/<name> ( but i guess that bit is already clear )
15:47:14 <walters> the docker dist-git is not in git.centos.org currently, is it?
15:47:45 <kbsingh> walters: no, for the -testing repos, you can send up srpms as scratch or whatever; but all this will need to be in git.centos.org before they are signed.
15:48:06 <kbsingh> at this point, i dont think anything other than xen is in git.centos.org properly ( maybe a couple of xen deps )
15:48:25 <jzb> kbsingh: is the process for this on the wiki somewheres?
15:48:27 <walters> signing of the rpms or of the git commits?
15:48:35 <imcleod_> kbsingh: This is all for the not-yet-completed dist-git setup for the CBS, correct?  My current understanding of CBS (and the builds I've been doing) is that it is SRPM build only.
15:48:44 <kbsingh> walters: technically, moving out of -testing targets, so signing the rpms
15:48:48 <walters> ok
15:51:03 <kbsingh> we also dont, at this point, have the cgi uploader worked out - so there is no way to push non-text sources into git.centos.org; i believe that in turn is blocked on central auth
15:51:31 <kbsingh> hence the build srpms, as an interim boostrap process.
15:52:33 <imcleod_> kbsingh: OK.  Roger.  Is there help to be offered there or should we simply track the progress?
15:53:18 <kbsingh> i am sure they can use a hand - bstinson and MerlinTHP are the people to ping about that
15:53:25 <imcleod_> kbsingh: Cheers.
15:54:00 <kbsingh> and I am sure the koji side of things can use a hand or a dozen as well
15:54:33 <jzb> imcleod_: sounds like there's an #action there
15:55:09 <imcleod_> kbsingh: Yes.  I'm ready to engage on koji, having dipped my toes into the code recently.  I need to circle back with alphacc on an open request to activate some of the image building features.
15:55:38 <imcleod_> kbsingh: Am going to bring this up, tangentially, in a meeting with the CERN folk tomorrow.  Mainly just a "thank you for supporting the koji manager resource".
15:55:40 <kbsingh> imcleod_: i think the issues are a bit more fundamental at this point, eg changing the way koji handles ( or does not handle ) tagging for srpms and how that maps to dist tags
15:55:59 <imcleod_> kbsingh: OK.  Yes.  I can attempt to help untangle that as well.
15:56:03 <kbsingh> imcleod_: none of the cern linux folks working on koji for centos are there ( in Paris )
15:56:12 <imcleod_> kbsingh: Correct.
15:56:16 <imcleod_> But many other folk are.
15:56:22 <imcleod_> They are the user start of the show.
15:56:37 <imcleod_> start = star
15:56:37 <imcleod_> "Star User"
15:56:49 <kbsingh> ok, I will be around in paris as well tomorrow.
15:57:14 <imcleod_> kbsingh: Wonderful.  Let's deep dive on build system stuff in person.
15:57:20 <kbsingh> i need to head out into another meeting in 4 min, but before i go - I wanted to confirm that the atomic images are now in the build routines for all centos images.
15:57:39 <imcleod_> kbsingh: can you clarify the question there?
15:58:11 <kbsingh> were starting to do monthly images for everything, atomic host is included in there, based on the repos and scripts jbrooks has done.
15:58:48 <kbsingh> the 29th Oct 2014 one does not have an upstream repo since the old repo: thing didnt work, so for the next one we just need a centos-release-atomic rpm file that sets up the repo and that bit should work too
15:59:09 <walters> kbsingh, can you link to those build routines?
16:00:20 <imcleod_> kbsingh: I have just now gotten alpha images built from the CBS-sourced RPM content.  This should be significantly more up to date than the stand alone repo jbrooks was building from IIRC.
16:00:27 <kbsingh> https://github.com/CentOS/sig-atomic-buildscripts
16:00:56 <kbsingh> imcleod_: http://buildlogs.centos.org/monthly/7/ has an Atomic image, can you give that a shot ?
16:01:08 <kbsingh> also, that url is not for public announcement yet :)
16:01:13 <kbsingh> the buildlogs one
16:01:36 <imcleod_> kbsingh: Sure.  How was this generated?
16:02:23 <kbsingh> the old toolbox thing
16:02:52 <kbsingh> it uses contet from the virt7-testingf and atomic7-testing repos on cbs.centos.org
16:03:11 <imcleod_> kbsingh: This is the non-Anaconda offline disk image generation.
16:03:39 <jzb> kbsingh: these are not all Atomic images, correct?
16:03:44 <jzb> kbsingh: just the qcow2
16:04:45 <jbrooks> I tested that image yesterday and the docker service wouldn't start
16:05:55 <kbsingh> jbrooks: i wodner what causes that, a minimal c7 install, with that docker installed works fine out of the box
16:06:08 <kbsingh> jbrooks: you got the 1.3.1 docker right ?
16:06:14 <jbrooks> kbsingh, right
16:06:23 <kbsingh> the local jenkins setup here seems to have last run with 1.3.0
16:06:32 <kbsingh> and my c7 min + docker build is also 1.3.0
16:06:36 <kbsingh> so its worth poking
16:06:41 <kbsingh> lsm5: did you break docker ?
16:06:55 <lsm5> kbsingh: ?
16:07:08 <jbrooks> kbsingh, the image has 1.3.1-1
16:07:20 <kbsingh> lsm5: jbrooks tried to run with the docker 1.3.1 on centos-7-atomic-host and docker didnt start
16:07:35 * lsm5 takes a look
16:08:50 <lsm5> kbsingh: jbrooks works for me on centos7
16:09:10 <lsm5> what's the error you see jbrooks ?
16:11:11 <jbrooks> lsm5, Couldn't create Tag store
16:11:21 <jzb> hmm
16:11:40 <jzb> maybe we should take this offline and get through the rest of the items for the meeting?
16:12:11 <jbrooks> lsm5, actually, weirdly, I have one host that started as the alpha and I rpm-ostree upgraded w/ a tree I build, and docker is running there. But it isn't running on the img kbsingh built
16:15:26 <jzb> #topic Update on storage
16:15:46 <jzb> Evolution: last week you had the item on storage - any updates there? When imcleod_ has images later this week, where shall we put them? :-)
16:16:08 <imcleod_> jzb: Nicely implied.....
16:16:09 <Evolution> I need to know how much space the images/trees will take up
16:16:19 <imcleod_> Evolution: let me check what they are right now.
16:16:22 <jzb> imcleod_: do you have a guess?
16:16:22 <imcleod_> On my test environment
16:16:58 <imcleod_> [root@oslab-nib-vm2 centos-atomic]# du -sh repo/
16:16:58 <imcleod_> 438M	repo/
16:16:58 <imcleod_> [root@oslab-nib-vm2 centos-atomic]#
16:17:25 <imcleod_> The respun Anaconda install tree is 803 MB
16:17:40 <imcleod_> Follow on repo updates should be smaller than 438 MB, but I don't know by how much.
16:17:52 <jzb> so... 2PB should do it?
16:17:52 <imcleod_> A hyper-conservative estimate would be 500 MB per updated tree.
16:18:01 <imcleod_> 2 PB should hold us for a few weeks yeah.
16:18:16 <jzb> imcleod_: we're only keeping 2 trees, or...?
16:18:20 <Evolution> how many trees do you envision needing?
16:19:33 <imcleod_> I have not determined.
16:19:43 <imcleod_> Open to suggestions.
16:20:00 <imcleod_> Let's assume at least 3
16:20:05 <imcleod_> old, newer, latest
16:20:34 <jzb> imcleod_: so, realistically, 1.5 - 2GB?
16:21:40 <imcleod_> jzb: Yes.
16:22:17 <jzb> Evolution: so around 2GB is doable?
16:22:36 <imcleod_> jzb: 4 GB would be better.  Is that a stretch?
16:22:54 <jzb> true, that way we can preload 1GB of cat pictures on each image.
16:23:02 <jzb> go for the competitive advantage.
16:24:41 <imcleod_> OK.  Formal request for 4 GB please.
16:25:43 <jzb> #agreed Atomic SIG needs ~4GB of space for images/trees.
16:26:15 <jzb> OK, any other topics this week?
16:26:18 <jzb> walters: ^^?
16:26:22 <jzb> imcleod_: ?
16:26:25 <jzb> #topic open floor
16:26:27 <walters> mirroring
16:27:10 <walters> this discussion mirrors[1]  https://lists.fedoraproject.org/pipermail/cloud/2014-November/004503.html
16:27:12 <walters> [1] hehe
16:27:46 <jzb> walters: I think we're going mirrorless for now.
16:27:50 <walters> were we thinking of going with the centos-release-atomic rpm that would point to a static url?
16:28:04 <jzb> walters: and the final URL will be pending Evolution when we get space.
16:28:08 <walters> ok
16:28:26 <jzb> walters: question
16:28:40 <jzb> walters: can we point to a static URL for now, and then an Atomic update would point to a different URL?
16:28:50 <walters> well
16:28:54 <jzb> is that something that can be updated easily or does it have to be done manually?
16:29:12 <walters> is there an ability to insert a HTTP redirect at the former location?
16:29:20 <walters> let's say there isn't
16:29:28 <walters> ostree has no %post equivalent
16:29:47 <walters> but one could write a systemd service which started in the new tree and checked whether the origin was the old location, and if so updated it to new
16:30:18 <walters> er actually, if the url is in a package in the tree, then it would switch on updates
16:30:45 <jzb> walters: OK, then we should probably go with URL in package
16:30:51 <walters> yeah
16:30:59 <imcleod_> Sorry, had to move locations.
16:31:21 <jzb> #agreed include atomic update URL in RPM that can be updated with new URL at a later date.
16:31:40 <jzb> imcleod_: do we have said RPM already or we need to create that?
16:31:51 <imcleod_> jzb: We do not.
16:32:13 <jzb> walters: this would literally just be a single file RPM, right?
16:32:20 <walters> yep
16:32:28 <imcleod_> #action imcleod Figure out with walters how to have a sane strategy for migrating from a single static non-mirrored URL to something else.
16:32:29 <jzb> hey, I bet even I can do that.
16:33:16 <jzb> OK, any other topics this week?
16:33:34 <jzb> pretty sure we've lost Evolution and kbsingh to other meetings.
16:34:06 <imcleod_> I'll just note that I'm pretty sure I am still waiting on some Infra server space to actually do the image builds and composes in some official future process.
16:34:18 <imcleod_> I can add the bug number to the meeting notes if that would be helpful.
16:34:27 <jzb> imcleod_: please
16:35:17 <imcleod_> https://bugs.centos.org/view.php?id=7686
16:35:33 <jzb> OK
16:35:46 <jzb> #action jzb follow up on bug 7686
16:35:51 <jzb> with that, let's go and do stuff
16:36:10 <jzb> #endmeeting