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