18:14:43 <stickster> #startmeeting Atomic/Infrastructure 18:14:43 <zodbot> Meeting started Tue Sep 30 18:14:43 2014 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:14:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:14:43 <centbot> Meeting started Tue Sep 30 18:14:43 2014 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:14:43 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 18:14:50 <dgilmore> the tree will live 18:14:52 <stickster> #chair walters dgilmore oddshocks 18:14:52 <zodbot> Current chairs: dgilmore oddshocks stickster walters 18:14:52 <centbot> Current chairs: dgilmore oddshocks stickster walters 18:15:00 <stickster> #topic Roll call! 18:15:06 <dgilmore> walters: I have a ticket filed to get write access to where the tree will live 18:15:07 * oddshocks here 18:15:08 * jbrooks here 18:15:11 * dustymabe here 18:15:12 * dgilmore 18:15:19 <stickster> #chair jbrooks dustymabe 18:15:19 <zodbot> Current chairs: dgilmore dustymabe jbrooks oddshocks stickster walters 18:15:19 <centbot> Current chairs: dgilmore dustymabe jbrooks oddshocks stickster walters 18:15:22 <nirik> morning 18:15:26 <stickster> #chair nirik 18:15:26 <zodbot> Current chairs: dgilmore dustymabe jbrooks nirik oddshocks stickster walters 18:15:26 <centbot> Current chairs: dgilmore dustymabe jbrooks nirik oddshocks stickster walters 18:15:27 <stickster> Hi nirik ! 18:15:28 * imcleod here 18:15:35 <stickster> #chair imcleod 18:15:35 <zodbot> Current chairs: dgilmore dustymabe imcleod jbrooks nirik oddshocks stickster walters 18:15:35 <centbot> Current chairs: dgilmore dustymabe imcleod jbrooks nirik oddshocks stickster walters 18:15:40 <stickster> Maybe I should just wait to do that next time ;-) 18:15:48 <dgilmore> :P 18:15:53 <stickster> #topic ostree/update status 18:15:58 <walters> right now "atomic upgrade" tries to contact http://compose-x86-02.phx.fedoraproject.org which is obviously not what we want 18:16:23 <nirik> yeah, thats... not going to work. ;) 18:16:24 <stickster> Also from earlier: '<walters> so my high level understanding of the current state is we have a cloud image, but no tree configuration for online updates' 18:17:08 <stickster> dgilmore: I know you were on well-needed vacation end of last week, what's the plan ahead for having tree available for updates? 18:17:12 <walters> and the goal is to have ostree set up to use metalink=, right? Which needs the XML generated and pointing to content 18:17:13 <jzb> hi all 18:17:16 <jzb> argh, sorry 18:17:19 <stickster> #chair jzb 18:17:19 <zodbot> Current chairs: dgilmore dustymabe imcleod jbrooks jzb nirik oddshocks stickster walters 18:17:19 <centbot> Current chairs: dgilmore dustymabe imcleod jbrooks jzb nirik oddshocks stickster walters 18:17:51 <dgilmore> .fire jzb 18:17:51 <zodbot> adamw fires jzb 18:17:57 <stickster> heh 18:18:07 <oddshocks> yeah, so with regard to this metalink stuff I was asked to look into last week, I have a few notes/questions (mostly questions). they don't have to be answered here I suppose, I could email them if you want: http://ur1.ca/i9r40 18:18:59 <oddshocks> trying to solidify my understanding of how this all fits together 18:19:01 <walters> oddshocks, the summary file serves the same purpose as yum repomd.xml basically 18:20:19 <oddshocks> walters: OK, so are you saying that MM should *skip* any code that generates a repomd.xml if the repo will have a summary file? or does it need both? 18:20:55 <walters> doesn't createrepo generate repomd.xml? why would MM do that? 18:21:09 <nirik> mm crawls the directories looking for things that are repos (that have a repomd.xml), it uses that information to create/build the metalinks 18:21:23 <oddshocks> ahhh OK! cool. understood 18:21:34 <walters> ok right, in this case it's just "look for ostree repo with summary file instead of yum repo with repomd.xml" 18:21:41 <nirik> so, in the atomic case I suspect we don't care about repomd.xml at all, just want whatever info atomic can provide thats similar 18:22:24 <walters> (in the eventual future i'd like to get to, atomic will do both, but that's not for this release) 18:22:25 <oddshocks> walters: nirik: thank you that really clears that one up for me :) 18:23:39 <stickster> Do we want to delve into other questions too, oddshocks? 18:23:47 * stickster thinks if people that can answer are here, would save some time 18:24:18 <oddshocks> stickster: the more people can clear stuff up for me in that file i listed, the faster i can figure things out, whether here or via email :) 18:24:36 <jzb> #info http://ur1.ca/i9r40 18:24:38 * oddshocks is taking lots of notes :P 18:24:47 <stickster> oddshocks: (2) seems like a question for dgilmore since I don't know the interior source paths being used 18:25:04 <jzb> oddshocks: did you send that to the list as well? 18:25:24 <oddshocks> jzb: No, I wrote it over the past couple days just to have some things for this meeting 18:25:40 <oddshocks> jzb: I can send another to the list that has any q's not answered here, if that would help 18:25:40 <walters> do we know the final URL that will be used for the metalink? In that case I think we can move forward with changing the images to hardcode it 18:26:11 <jzb> oddshocks: if we get all the Qs answered here, it might be good to document that on the wiki 18:26:37 <oddshocks> jzb: I can tackle that for sure. on the Atomic page, or which page? 18:26:51 <dgilmore> oddshocks: we may need to do some mm work to detect ostree repos propperly 18:27:01 <oddshocks> hopefully if I can write the answers to my questions there, it'll help with anyone else coming on board 18:27:15 <oddshocks> dgilmore: something beyond looking for a valid summary file? 18:27:46 <dgilmore> oddshocks: I do not know the mm code well enough to know what it will do 18:28:09 <oddshocks> dgilmore: I am 99% sure I found the spot we're concerned with. 18:28:13 <dgilmore> oddshocks: at the least I know we will need to setup repo maps so it gets the prefixes right 18:28:16 * oddshocks gets link 18:28:56 <oddshocks> it all starts here: https://git.fedorahosted.org/cgit/mirrormanager/tree/mirrorlist-server/mirrorlist_server.py#n123 18:29:46 <dgilmore> https://git.fedorahosted.org/cgit/mirrormanager/tree/server/mirrormanager/repomap.py 18:29:52 <dgilmore> oddshocks: that will need some work 18:30:03 <jzb> oddshocks: how about here? https://fedoraproject.org/wiki/Cloud/Atomic_Runbooks 18:31:09 <oddshocks> dgilmore: right, so that file will need a part added that will identify if it's an atomic repo with an ostree summary file, I assume? 18:31:24 <dgilmore> oddshocks: something like that yes 18:31:50 <oddshocks> #action oddshocks add some info to https://fedoraproject.org/wiki/Cloud/Atomic_Runbooks 18:35:06 <jzb> are we set on Mirror Manager work for now? 18:35:07 <jzb> oddshocks: ^^ 18:35:08 <jzb> ? 18:36:45 <jzb> OK... 18:36:47 <oddshocks> I guess to summarize other q's: (1) do any of run-pungi, buildbranched, or buildrawhide need to run `ostree summary -u` (2) where is the actual location that the link to the summary file goes inside of the xml 18:36:49 <oddshocks> and 18:37:15 <dgilmore> I guess i missed the memo on ostree summary 18:37:20 <oddshocks> (3) are there any other repos we need to have summary files generated for besides pub/alt/fedora-atomic/repo/summary 18:37:33 <walters> yeah, the summary command needs to be rerun after rpm-ostree compose tree commands 18:37:40 <dgilmore> oddshocks: pub/alt/fedora-atomic/repo/summary is not offical and needs to be ignore 18:37:43 <dgilmore> ignored 18:37:50 <walters> the benefit of the separation is that one can atomically update multiple branches 18:37:59 <oddshocks> walters: and we need to add rpm-ostree commands to buildbranched and buildrawhide, like exist in run-pungi? 18:38:02 <oddshocks> dgilmore: noted 18:38:13 <walters> oddshocks, given my understanding of the compose scripts, yes 18:38:41 <dgilmore> oddshocks: yes. I think the nightly composes will always be done from a empty repo 18:39:00 <dgilmore> which I guess means no ever going back 18:39:21 <oddshocks> OK I think I'm good for now on major questions... thanks :) 18:39:59 <imcleod> So, I suppose now might be a time to briefly ask if anyone has begun to tease apart how we'll do these same compose tasks for CentOS. 18:40:05 <imcleod> Or, it might not.... 18:40:29 <dgilmore> imcleod: pretty much the same way 18:40:40 <dgilmore> imcleod: I do not know how they do their composes 18:40:41 <walters> i've been working on centralizing some scripts in https://github.com/projectatomic/rpm-ostree-toolbox 18:40:48 <dgilmore> so its impossible to say 18:41:02 <walters> these are just wrappers for well-known tools like lorax and imagefactory 18:41:15 <jzb> #info walters has been working on centralizing compose scripts in https://github.com/projectatomic/rpm-ostree-toolbox 18:41:25 <imcleod> dgilmore: Yeah. I'm still learning about that myself, but I gather it differs somewhat from Fedora and internal RHEL. 18:41:51 <dgilmore> imcleod: afaik its something custom they did 18:41:58 <imcleod> oddshocks: Permission to lean on some of what you are learning as I try to sort through the CentOS side of things? 18:42:31 <oddshocks> imcleod: permission granted 18:42:47 <jzb> imcleod: does this help at all? 18:42:49 <jzb> http://wiki.centos.org/HowTos/CommunityBuildSystem 18:43:54 <imcleod> jzb: A bit. From what I've learned so far, the core of CentOS is not built with koji or in the CBS. The CBS may well be the right location to source the compose from though, possibly with some external repos defined that point back into the core CentOS install media. 18:44:34 <imcleod> jzb: I'll keep digging. 18:45:37 <jzb> imcleod: thanks 18:45:39 * imcleod yields the floor 18:46:00 <jzb> ok 18:46:13 <jzb> walters: do you have any topics this week? 18:46:38 * jzb has a question on updates for Atomic, but wants to make sure other things are dealt with first. 18:46:55 <walters> i can't think of anything else for infra 18:47:09 <jzb> walters: OK 18:47:24 <jzb> dgilmore: do you have any items this week or issues blocking your work? 18:47:31 <dgilmore> jzb: we still are not setup to make updated images or trees, we need to figure that all out yet 18:47:32 <jzb> (that we haven't already dealt with, I mean) 18:47:43 <dgilmore> jzb: no. 18:48:03 <jzb> dgilmore: any action items we haven't captured yet? 18:48:14 <dgilmore> jzb: I do not think so 18:48:47 <dgilmore> jzb: the updates etc are not really atomic specifc either, its something that needs sorted for all cloud images 18:49:49 <walters> well 18:50:04 <walters> in the current atomic tooling, users are unable to update e.g. bash manually 18:50:12 <walters> without composing their own tree 18:50:17 <jzb> right 18:50:43 <dgilmore> walters: right, we need to figure out when and how tio make updated trees along with when an how to make updated images 18:51:04 <dgilmore> walters: for the most part its not an atomic only problem to solve 18:51:07 <jzb> dgilmore: so this is policy, not techically how to 18:51:11 <dgilmore> other than the atomic tree bit 18:51:22 <walters> right, agree image side is shared 18:51:24 <dgilmore> jzb: bit of both 18:51:45 <jzb> dgilmore: We can get policy sorted relatively quickly, I think? 18:51:59 <dgilmore> realisticly we should make updated trees in bodhi when packages in the tree get updated 18:52:11 <jzb> dgilmore: this is up to Cloud WG to define and make sure it's sane with rel-eng & QA, yes? 18:52:18 <dgilmore> jzb: well policy is the smallest bit of it all 18:52:47 <dgilmore> the largest bit is the releng side followed by QA 18:52:49 <jbrooks> users will expect tree updates to be timed w/ pkg updates 18:53:11 <dgilmore> jbrooks: right which is why i said we need to really get it done by bodhi 18:54:13 <stickster> dgilmore: Have you talked to lmacken about that? 18:54:47 * jbrooks wonders about an updates-testing tree, as well 18:55:16 <dgilmore> stickster: no, i just now thought of it 18:55:44 <dgilmore> jbrooks: I really do not know how well we will be able to do updates-testing trees 18:55:49 <stickster> No worries -- let's make sure to get him into discussion though 18:56:02 <jzb> who's taking that action? 18:56:04 <stickster> I don't want to see him have to scramble last minute to add features on release day minus two or something 18:56:32 <walters> note of course that having rollback built in means one can upgrade and try things with a lot less fear 18:56:38 <dgilmore> stickster: likely we will need to do it by hand for a bit 18:56:59 <jzb> speaking of doing it by hand... 18:57:01 <walters> it's part of the foundation of moving away from the waterfall model towards continuous delivery 18:57:03 <jzb> https://fedorahosted.org/rel-eng/ticket/6004 18:57:17 <jbrooks> Couldn't the tree-composer watch for new pkgs, and compose when they appear? 18:57:23 <jzb> dgilmore: any additional action/info/whatever I should add there? 18:57:44 <walters> jbrooks, it's been effectively a cron job for quite a while, but yes, push notification would be nice 18:58:04 <walters> (note rpm-ostree will not make a new tree if the package set is unchanged) 18:58:10 <dgilmore> is you speak of 18:58:15 <dgilmore> jbrooks: no idea what the tree-composer is you speak of 18:58:31 <jbrooks> dgilmore, just whatever it is that composes the tree 18:59:07 <jbrooks> for me, that's been the always-soon-to-be-deprecated rpm-ostree-toolbox scripts 18:59:15 <jzb> walters: does that include new versions of the same package set? 18:59:31 <dgilmore> jbrooks: a releng person 19:00:10 <dgilmore> jbrooks: there is a lot of room for automation and tooling here 19:00:23 <dgilmore> and it needs to tie into existing processes 19:00:24 <jbrooks> dgilmore, got it 19:01:19 <jzb> stickster: should you or dgilmore take the action to get lmacken into this discussion about bodhi? 19:01:30 <jzb> or is that too far in the future to worry about right now? 19:01:40 <dgilmore> jzb: we should get it on the roadmap 19:01:49 <dgilmore> I am happy to take that action 19:01:54 <jzb> dgilmore: groovy, thanks! 19:02:22 <jzb> #action dgilmore to bring lmacken into discussion about Atomic/Bodhi/updates. 19:02:34 <dgilmore> jzb: bodhi currently is stuck on RHEL6 19:02:43 <jzb> dgilmore: did you see the question about the ticket for the current Atomic image (F21 alpha)? 19:02:45 <dgilmore> not sure if that will cause us problems 19:03:03 <jzb> dgilmore: here's hoping not. 19:03:13 <dgilmore> jzb: yeah there is nothing really to do. I will be working on Beta_TC1 tonight 19:03:26 <jzb> dgilmore: so ... there won't be an update for the Alpha? 19:03:56 <jzb> or will we be able to point Atomic users to beta_TC1? 19:04:08 <dgilmore> jzb: nope 19:04:29 <dgilmore> jzb: if we publish the tree they should be able to update to Beta_TC1 19:04:51 <jzb> dgilmore: OK. I'm good with that if we can publish the tree 19:04:56 <jzb> anybody object to that? 19:05:15 <jzb> as walters points out, that's sort of the point of rpm-ostree to be able to easily go backwards if an update borks anyway 19:06:03 <dgilmore> jzb: ideally we sort out the permission issues and will get teh tree out 19:07:16 <jzb> OK 19:07:24 <jzb> Any other issues this week, folks? 19:08:03 <dgilmore> I don't think I have any 19:08:07 * jzb gives it 60 seconds to account for typing... 19:08:40 * nirik has nothing 19:09:16 <jzb> ok 19:09:27 <jzb> thanks all - sorry for my tardiness today! 19:09:30 <jzb> #endmeeting