15:34:25 #startmeeting Atomic SIG meeting 15:34:25 Meeting started Tue Nov 18 15:34:25 2014 UTC. The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:34:25 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:34:35 hello from Budapest! 15:34:41 (Won't get to say that often.) 15:34:53 hello! 15:34:54 #chair imcleod jbrooks kbsingh Evolution walters 15:34:54 Current chairs: Evolution imcleod jbrooks jzb kbsingh walters 15:35:03 I see. We deploy our own cloud-init we created. Maybe that should be mentioned as a caveat for CentOS 5 images: no cloud-init, do your own (just an idea) 15:36:06 So - here's minutes from last meeting 15:36:45 http://centos.org/minutes/2014/november/centos-devel.2014-11-11-15.35.html 15:36:52 two action items 15:37:01 jzb invite Stef and/or other Cockpit folks to next week's SIG meeting 15:37:11 ^^ I did that, but he was unavailable this week 15:37:17 so hoping Stef can join next week 15:37:28 imcleod carry discussion about Koji builds to centos-devel 15:37:35 imcleod: ^^ I believe you did that, yes? 15:37:50 i believe so 15:37:51 jzb: Yes. And it carried over to #centos-devel on Friday. 15:38:13 imcleod: ah, OK - anything to add to what's on the list then? 15:38:49 imcleod: i thought those were 2 differnet things (1) koji can now build images! yay! (2) we need external content for koji to build atomic content via anaconda, not so much yay 15:39:17 kbsingh: I would say we need _additional_ content, which is itself generated from CBS content. 15:39:30 kbsingh: I believe the definition of "external" and who gets to produce it is the crux of the issue. 15:39:33 I agree 15:40:12 kbsingh: I have gotten strong pushback several times when I've tried to gain access to an infra machine to use to generate content. The approach I have settled on, for now, is to whip up scripts that I can share as candidates for someone else to run within the infra. 15:40:13 so in the mean time, so as to move thing forward, I've got a seperate builder thread watching the git repo via https://github.com/CentOS/sig-atomic-buildscripts 15:40:20 ( as we discussed last friday ) 15:40:35 kbsingh: To generate the needed Anaconda install trees and rpm-ostree composes to allow the now-active Image building features in CBS to be used for Atomic. 15:41:18 kbsingh: Yup. AFAIK, that generates trees but not the Anaconda install tree. 15:41:31 and koji is unable to do the anaconda install tree's ? 15:41:35 i thouht that is the work that you were oing 15:42:10 kbsingh: To be clear on definitions here: Anaconda install tree = Output of running lorax. 15:42:17 kbsingh: koji cannot do this, no 15:42:33 right, 15:42:34 kbsingh: And we need this output, for now, to use Anaconda to generate Atomic disk images using Colin's latest bits. 15:42:44 but its this tree that would be used by anaconda to build an image. 15:42:57 kbsingh: In combination with an rpm-ostree "tree", yes. 15:43:05 kbsingh: Far to many trees. Easy to get them mixed up. 15:43:14 kbsingh: We should push for clearer nomenclature. 15:43:17 but this isnt a tree at all in that case, lorax does not generate a tree 15:43:22 it only gives you the installer images 15:43:43 kbsingh: The unpacked, HTTP accessible output of lorax is often called an install tree. 15:44:00 even though it has no packages ? 15:44:06 kbsingh: At least, in my experience. 15:44:13 ok, :) 15:44:13 kbsingh: I will call it whatever is helpful. 15:44:28 lets call it installer images, since thts what it is 15:44:48 kbsingh: My fear with that is simply that "install image" is often taken to mean an ISO. 15:45:06 kbsingh: And our tooling can use both an ISO or the unpacked tree. 15:45:10 that way we have : cbs generated repos of just-build packages, -> need to be merged into an ostree, and had installer images generated for anaconda to then consume to output qcow2 files ( and well, baremetal at soe point ) 15:45:16 does that look like the entire chain? 15:45:24 * imcleod unpacks that line 15:45:36 just-build = just-built, yes? 15:45:59 So, yes, I believe that is correct. koji can generate the packages and can build the images. 15:46:07 But.... it needs the install tree and the composed rpm-ostrees 15:46:22 And those two things cannot be done in koji but must be available to koji for anything else to work. 15:46:51 kbsingh: Are you now generating nightly rpm-ostree composes? 15:46:57 kbsingh: And/or images? 15:47:12 imcleod: thats what i mentioned above, the scripts are able to do this - but no new target has arrived in the github repo 15:47:26 I've actually made it so it does a 'for f in *.json' 15:47:41 kbsingh: but json doesn't have any fs 15:47:53 kbsingh, Not all changes accompany a changein the jsons 15:47:54 add as many targets as you like, each shows up in its own filesystem path ( so we'd need to rsync out the entire topdir, which is ok ) 15:47:58 Like updates 15:48:13 jbrooks: right, so the script will run nightly 15:48:27 ack 15:48:46 the main portion of tht is what maps to the released atomic-image tree on buildlogs.c.o- for folks to keep their machines updated. the additional tree's can then be used to do dev work / testing / wahtever 15:49:16 at some point in the very near future, when we do an announce for RHSA/EA/BA, we will respin the ostree under the released image 15:49:23 but it needs a bit of figuring out 15:49:29 kbsingh: OK. So if I need a distinct type of tree compose, I will PR a new json file in the SIG repo. 15:49:55 kbsingh: And I also need to provide you with a script to do nightly lorax runs to pull in any potentially needed changes to the Anaconda "install image". 15:50:06 kbsingh: Which I will also PR in the SIG repo. 15:50:08 coming back to imcleod's 2 things, 1 of those is largely solved ( it needs the json and a run, then adding to cron, but otherwise done ) - the second bit is the lorax run which I've done nothing about as yet 15:50:23 kbsingh: Right. See above. We are thinking in the same direction. 15:50:35 there is one bit we need to figure out 15:50:46 the glue metadata needs someway of being passed around. 15:50:49 kbsingh: Once there is a regular assembly line of rpm-ostree composes _and_ lorax runs then I can build qcow2 images at will in the CBS. 15:51:00 kbsingh: Define "glue metadata" please. 15:51:05 i need to tell your scrpts where to get the ostree from ( as an example ) and maybe where to rsync the resulting output from 15:51:45 kbsingh: OK. Let's unpack that. The json defines repos, but the repo files themselves are distinct files. That's one bit of it. 15:51:56 the where-to-get-from will be a http url, and where to rsync to will be a rsync target ( i guess, still need to sync with alphacc and Arrfab on howto make that result visible to koji ) 15:52:01 kbsingh: The lorax runs embed the details of where packages come from in the command line, so there's that. 15:52:13 kbsingh: And the Anaconda image builds in CBS embed the ostree source in the kickstart file, so there's that. 15:52:17 ah 15:52:28 so you dont need the ostree repo for lorax to consume 15:52:43 kbsingh: The rpm-ostree composed repo? No. 15:52:56 kbsingh: I need it for the _resulting Anaconda install image_ to consume. 15:52:58 ok, so no glue needed. makes life easier 15:53:03 kbsingh: But not to generate the install image itself. 15:53:44 ok 15:55:08 if that loop is closed off, i have another quesion 15:55:54 kbsingh: I have a clear idea of what I am going to deliver to the SIG repo. Ask away. 15:56:14 at the moment all builds in cbs are going into the -testing tag. 15:56:31 which means the ostree repo that were shipping for folks using the released image is also consuming all the same content 15:56:50 at some point were going to want to split that out to a stable or released tag to allow for acrobatics in -testing 15:57:03 kbsingh: Yes. I like that model. 15:57:12 one major issue for that is signing the rpms in cbs. and were about 2 weeks away from delivering that to the SIGs 15:57:40 kbsingh: point of order or something 15:57:48 kbsingh: could you do a #topic when you introduce a new one, pls? 15:57:51 is there anything else that needs to happen before stuff can move away from -testing 15:58:03 #topic release tags versus testing tags 15:58:11 ta 15:58:35 kbsingh: I am going to assume we can create the tag right now, just to have the placeholder, true or false? 15:58:39 We should be able to point to the git source of the pkgs in CBS -- we don't have an official place for that yet, do we? 15:59:46 jbrooks: The implication being that building from git is a pre-req for signing, yes? 16:00:28 imcleod, or at least for being official -- if people want to see the source, or contribute to it 16:00:39 jbrooks: Yup. Sounds reasonable to me. 16:00:51 kbsingh: Current release is pulling content from -testing, yes? 16:01:04 yeah, its the only pace there is content 16:01:08 kbsingh: Are you wanting to establish -stable as a new release criteria _right now_? 16:01:17 kbsingh: Or just want to get it on our radar. 16:01:18 https://github.com/CentOS/sig-atomic-buildscripts/blob/master/virt7-testing.repo 16:01:39 kbsingh: I don't know that we're going to be in a position to attach the word "stable" to this work in the next few weeks..... 16:01:45 imcleod: i am concerned about keeping the user experience on the released image as close to usable-always 16:02:01 kbsingh: Absolutely. A testing image can be usable. A stable image must be. 16:02:21 imcleod: ie. really would like to have a -stable'ish thing that does not get experimental builds from 5 min ago from walters ( not that i dont like walters.. ) 16:02:35 I mean like this: http://pkgs.fedoraproject.org/cgit/kubernetes.git/ 16:02:44 but walters likely needs a place to do his 5 min old builds too 16:03:03 kbsingh: I usually give walters 10 minutes before I figure his stuff is stable. 16:03:34 jbrooks: the git impor for sources is coming fairly soon, its a pre-condition to the sig signing thing which is ETD's 2 buildsys meetings away 16:04:01 kbsingh, OK, cool 16:04:18 kbsingh: I agree entirely with the sentiment, and also think we're not quite at that point. I'd suggest we make the action be "generate location for -stable releases and begin to establish criteria" 16:05:10 ok, works for me 16:05:18 Another thing, do we want/need more control over the docker pkg than we have now? Like, the kubernetes pkgs expect docker.socket, but our docker doesn't come w/ that 16:05:23 so are we now discussing what is the criteria for a stable release? 16:05:40 Some key pkgs come from virt-sig 16:05:59 jbrooks: i think we should be able to liase with lsm5 and get this sorted out as needed. As long as things done break someone else's usecase, its likely something that can happen fairly quickly as well 16:06:25 jbrooks: anything aside from Docker? 16:06:38 at this point we've got 2 dockers. the one indistro, and one in virt-sig 16:06:48 jzb, a couple, looking 16:06:57 kbsingh: right, I was just wondering what other packages jbrooks was referencing 16:07:04 it might be that we want to rename the virt-sig hosted docker into a docker-upstream ( or something else that indicates this isnt the rhel docker ) 16:07:25 jzb: i thikn kubernetes comes from there as well 16:07:30 might be wrong 16:07:31 * kbsingh checks 16:08:03 jzb, etcd kubernetes cockpiit cadvisor, bunch of deps 16:08:09 there is a kubernetes there, are we using 0.4-0.3 ? 16:08:12 http://cbs.centos.org/koji/packageinfo?packageID=105 - Correct - virt-testing 16:08:13 jbrooks: the socket activation thing would need a systemd upgrade on centos 16:08:13 Basically, like, all of atomic is in the virt sig 16:08:29 jbrooks: excepting rpm-ostree 16:08:43 jbrooks: And the Anaconda update packages 16:08:45 lsm5, ah, ok, now, we do have a new one in the atomic tag that we're using 16:09:00 we had to do a bit of a backport for cockpit as well.. its not using the distro glib2 16:09:02 jbrooks: And 25 other packages - http://cbs.centos.org/koji/taginfo?tagID=40 16:09:03 jbrooks: ahh cool, i'll update the docker package soon 16:09:16 kbsingh: we actually need to roll Cockpit back a bit 16:09:34 kbsingh: upstream has stabilized on something like 0.26 but they're at 0.31 right now 16:09:49 jzb: we have 0.24 iirc 16:10:01 kbsingh: weird, I thought we were ahead 16:10:04 lemme go look again 16:10:07 It sort of ties into my q's about git -- it's not clear to me now how we collaborate on the packages that make up this sig 16:10:19 lsm5: does providing the .socket cause issues on the existing systemd ? if not, roll it into the package for those systems that can consume it 16:10:54 kbsingh: the .socket file has SocketUser and SocketGroup which weren't supported in the systemd that I last saw on centos7 16:11:02 jbrooks: if you want to change something, I would think step1 would be to reach out to the person managing it, if they cnat do the change, then you can fork it and setup your own branch in git 16:11:31 jbrooks: the way thngs are setup, everyone with commit rights into a sig, will be able to create and commit into a git branch that maps to their signame, in all of /rpms/ 16:11:36 kbsingh, In fedora, I know where to fork from -- but, like you said, that's coming 16:12:02 lsm5: would adding this cause issues on a machine that didnt support it 16:12:38 also, reminder that i need to head off in a few min. 16:12:49 kbsingh: yup ... there was a CVE ...don't quite remember the number offhand 16:13:02 2014-7189 i think 16:13:15 jbrooks, lsm5: When/where does the virt SIG meet? I could being lurking there if you think that would help. 16:13:37 Today at 2 gmt 16:13:43 every alternate week, alternativing between phone and irc, on Tuesdays, we had an irc one today 16:13:52 kbsingh: CVE-2014-3499 16:13:55 14:00 UTC 16:14:22 jbrooks, kbsingh: OK. Darn. 16:14:24 lsm5: perhaps send an invite to imcleod ? 16:14:35 gwd: ^ 16:14:55 what other issues do we need to get to while kbsingh is still here? 16:14:56 i can dig out the conf call info 16:15:09 lsm5: ok, will dig that CVE stuff. 16:16:18 imcleod: if its not done before, then lets do the lorax plumbing on friday afternoon UTC 16:16:27 * kbsingh off. will read backlog in a bit 16:16:28 kbsingh: Roger. 16:17:28 OK - any other topics this week? 16:17:33 #topic open floor 16:19:03 16:19:12 jbrooks, imcleod all good, I guess? 16:19:46 jzb, Yeah, I think so 16:19:59 I believe so. 16:20:01 Still trying to get kubernetes working 16:20:43 jbrooks, imcleod - any opinion on whether we should do a SIG meeting next week? 16:20:51 since it's the week of Thanksgiving 16:20:58 I figure a lot of folks will be scarce 16:21:00 jzb, I'm planning to be on the road 16:21:00 jzb: An American holiday, yes? 16:21:15 imcleod: yep 16:21:17 :-) 16:21:23 jbrooks: so you're out? 16:21:42 jzb, I may not have left yet by the time of this mtg -- 7:30 am 16:22:02 imcleod: ? 16:22:04 jzb, I guess, maybe? :) 16:22:13 Can skip, yes. 16:22:33 #info no meeting week of 25 November 16:22:39 thanks all 16:22:41 #endmeeting