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