15:33:07 #startmeeting CentOS Atomic SIG 15:33:07 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:33:07 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:33:43 #chair walters Evolution imcleod_ jbrooks 15:33:43 Current chairs: Evolution imcleod_ jbrooks jzb walters 15:33:43 Current chairs: Evolution imcleod_ jbrooks jzb walters 15:34:00 OK, quick rundown from last week's meeting 15:34:13 #topic ACTION: jzb get info on SRPM collaboration 15:34:31 this is still pending. I bumped the discussion on the CentOS list - there's been no activity since last Monday. 15:34:36 (aside from my bump...) 15:34:47 Evolution: any way to move that to completion? 15:34:57 * jbrooks here 15:35:01 bstinson: ^^ if you're around, I know you started the discussion 15:36:01 jzb: dunno what you're after here. for srpm collaboration 15:36:33 Evolution: the "Policy for Ad-Hoc Upstreams" discussion 15:36:50 I think we're still in limbo deciding how we collaborate on sources that aren't part of CentOS proper. 15:37:33 i think we could probably move atomic forward with just keeping specs in a github repo 15:37:46 what does GlusterFS do? 15:37:51 * walters looks 15:40:54 answer appears to be https://forge.gluster.org/glusterfs-core/glusterfs/blobs/master/extras/LinuxRPM/Makefile.am 15:41:22 jzb: well, to some extent atomic is a bit of a snowflake case. 15:41:38 Evolution: sadly, true. 15:41:41 most projects have outside source repos already and we don't want to interfere there. 15:42:08 Evolution: if it's not going to get us blocked anywhere, I think the SIG is happy to use GitHub 15:42:10 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 github's fine by me. 15:43:02 i guess with centos for the most part the only intersection between SIGs is the common core 15:43:21 The SIG materials on the centos site talk about code needing to be in git.centos.org, but github is fine 15:43:26 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 OK, so - are we all good with GitHub then? 15:44:45 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 #chair kbsingh 15:45:16 Current chairs: Evolution imcleod_ jbrooks jzb kbsingh walters 15:45:17 Current chairs: Evolution imcleod_ jbrooks jzb kbsingh walters 15:45:40 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 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 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 the dist-git repos can only push into the branch that matches the users sig tag 15:47:08 and the upstream git repos end up in /signame/, rather than /rpms/ ( but i guess that bit is already clear ) 15:47:14 the docker dist-git is not in git.centos.org currently, is it? 15:47:45 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 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 kbsingh: is the process for this on the wiki somewheres? 15:48:27 signing of the rpms or of the git commits? 15:48:35 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 walters: technically, moving out of -testing targets, so signing the rpms 15:48:48 ok 15:51:03 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 hence the build srpms, as an interim boostrap process. 15:52:33 kbsingh: OK. Roger. Is there help to be offered there or should we simply track the progress? 15:53:18 i am sure they can use a hand - bstinson and MerlinTHP are the people to ping about that 15:53:25 kbsingh: Cheers. 15:54:00 and I am sure the koji side of things can use a hand or a dozen as well 15:54:33 imcleod_: sounds like there's an #action there 15:55:09 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 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 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 kbsingh: OK. Yes. I can attempt to help untangle that as well. 15:56:03 imcleod_: none of the cern linux folks working on koji for centos are there ( in Paris ) 15:56:12 kbsingh: Correct. 15:56:16 But many other folk are. 15:56:22 They are the user start of the show. 15:56:37 start = star 15:56:37 "Star User" 15:56:49 ok, I will be around in paris as well tomorrow. 15:57:14 kbsingh: Wonderful. Let's deep dive on build system stuff in person. 15:57:20 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 kbsingh: can you clarify the question there? 15:58:11 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 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 kbsingh, can you link to those build routines? 16:00:20 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 https://github.com/CentOS/sig-atomic-buildscripts 16:00:56 imcleod_: http://buildlogs.centos.org/monthly/7/ has an Atomic image, can you give that a shot ? 16:01:08 also, that url is not for public announcement yet :) 16:01:13 the buildlogs one 16:01:36 kbsingh: Sure. How was this generated? 16:02:23 the old toolbox thing 16:02:52 it uses contet from the virt7-testingf and atomic7-testing repos on cbs.centos.org 16:03:11 kbsingh: This is the non-Anaconda offline disk image generation. 16:03:39 kbsingh: these are not all Atomic images, correct? 16:03:44 kbsingh: just the qcow2 16:04:45 I tested that image yesterday and the docker service wouldn't start 16:05:55 jbrooks: i wodner what causes that, a minimal c7 install, with that docker installed works fine out of the box 16:06:08 jbrooks: you got the 1.3.1 docker right ? 16:06:14 kbsingh, right 16:06:23 the local jenkins setup here seems to have last run with 1.3.0 16:06:32 and my c7 min + docker build is also 1.3.0 16:06:36 so its worth poking 16:06:41 lsm5: did you break docker ? 16:06:55 kbsingh: ? 16:07:08 kbsingh, the image has 1.3.1-1 16:07:20 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 kbsingh: jbrooks works for me on centos7 16:09:10 what's the error you see jbrooks ? 16:11:11 lsm5, Couldn't create Tag store 16:11:21 hmm 16:11:40 maybe we should take this offline and get through the rest of the items for the meeting? 16:12:11 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 #topic Update on storage 16:15:46 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 jzb: Nicely implied..... 16:16:09 I need to know how much space the images/trees will take up 16:16:19 Evolution: let me check what they are right now. 16:16:22 imcleod_: do you have a guess? 16:16:22 On my test environment 16:16:58 [root@oslab-nib-vm2 centos-atomic]# du -sh repo/ 16:16:58 438M repo/ 16:16:58 [root@oslab-nib-vm2 centos-atomic]# 16:17:25 The respun Anaconda install tree is 803 MB 16:17:40 Follow on repo updates should be smaller than 438 MB, but I don't know by how much. 16:17:52 so... 2PB should do it? 16:17:52 A hyper-conservative estimate would be 500 MB per updated tree. 16:18:01 2 PB should hold us for a few weeks yeah. 16:18:16 imcleod_: we're only keeping 2 trees, or...? 16:18:20 how many trees do you envision needing? 16:19:33 I have not determined. 16:19:43 Open to suggestions. 16:20:00 Let's assume at least 3 16:20:05 old, newer, latest 16:20:34 imcleod_: so, realistically, 1.5 - 2GB? 16:21:40 jzb: Yes. 16:22:17 Evolution: so around 2GB is doable? 16:22:36 jzb: 4 GB would be better. Is that a stretch? 16:22:54 true, that way we can preload 1GB of cat pictures on each image. 16:23:02 go for the competitive advantage. 16:24:41 OK. Formal request for 4 GB please. 16:25:43 #agreed Atomic SIG needs ~4GB of space for images/trees. 16:26:15 OK, any other topics this week? 16:26:18 walters: ^^? 16:26:22 imcleod_: ? 16:26:25 #topic open floor 16:26:27 mirroring 16:27:10 this discussion mirrors[1] https://lists.fedoraproject.org/pipermail/cloud/2014-November/004503.html 16:27:12 [1] hehe 16:27:46 walters: I think we're going mirrorless for now. 16:27:50 were we thinking of going with the centos-release-atomic rpm that would point to a static url? 16:28:04 walters: and the final URL will be pending Evolution when we get space. 16:28:08 ok 16:28:26 walters: question 16:28:40 walters: can we point to a static URL for now, and then an Atomic update would point to a different URL? 16:28:50 well 16:28:54 is that something that can be updated easily or does it have to be done manually? 16:29:12 is there an ability to insert a HTTP redirect at the former location? 16:29:20 let's say there isn't 16:29:28 ostree has no %post equivalent 16:29:47 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 er actually, if the url is in a package in the tree, then it would switch on updates 16:30:45 walters: OK, then we should probably go with URL in package 16:30:51 yeah 16:30:59 Sorry, had to move locations. 16:31:21 #agreed include atomic update URL in RPM that can be updated with new URL at a later date. 16:31:40 imcleod_: do we have said RPM already or we need to create that? 16:31:51 jzb: We do not. 16:32:13 walters: this would literally just be a single file RPM, right? 16:32:20 yep 16:32:28 #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 hey, I bet even I can do that. 16:33:16 OK, any other topics this week? 16:33:34 pretty sure we've lost Evolution and kbsingh to other meetings. 16:34:06 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 I can add the bug number to the meeting notes if that would be helpful. 16:34:27 imcleod_: please 16:35:17 https://bugs.centos.org/view.php?id=7686 16:35:33 OK 16:35:46 #action jzb follow up on bug 7686 16:35:51 with that, let's go and do stuff 16:36:10 #endmeeting