On Fri, Jul 18, 2014 at 04:48:50PM -0400, Matthew Miller wrote: > On Fri, Jul 18, 2014 at 09:40:59AM -0400, Colin Walters wrote: > > Let's look at blocking issues for Atomic in Fedora: > > - Having rpm-ostree be run as part of nightly compose > > As I understand it, Dennis is working on this. Dennis, anyone -- let me know > where particular help is needed. David Gay (oddshocks) is also available to > help (pretty much full time for a little while once fedimg is in production > in the next few days, as I understand it). That's correct, and David, Dennis, Matt, and I talked about that as well. Before I left for vacation I believe David, Colin, Dennis, and some others met to discuss about how to approach the ostree work, but no tasks came out of it for David yet (at least then). > > - Content mirroring > > * Server with SSL, some level of redundancy > > * Open question around how often/when composes are done, and how much > > history is retained > > From when we last talked, I thought you were going to bring up this last one > as a policy question on the Fedora Cloud list? But also from our discussion, > it doesn't look like keeping even full history would be hugely significant > -- 1.6GB over the lifetime, _worst case_. I also don't think that we need to > have this answered urgently... it's something we need to know by October, > right? > > > - GPG signing > > Can you elaborate here? If I remember right we had discussed this as a > release blocker but not necessarily an immediate blocker (for example, not > all RPMs in F21 branch are currently signed.) > > > - Method of having Koji/ImageFactory pull mirrored OSTree repository > > content to compose ISOs > > I think this is just making the above mirror available to ImageFactory > during install. > > > > - MirrorManager integration (no code written on ostree side yet) > > To the best of my knowledge, code exists for all of the above except the > > last, and the last bit is hard to write without having a deployment of > > MirrorManager using it, which depends > > Again, let me know if it would help to have someone focused on this and I'll > see if I can find the right help. > > > I see two solution paths: > > - Double down and fix the above, continue trying to sync Atomic with > > Fedora > > Based on our conversations last week and earlier this week, I don't think > it's really so dire that it comes to "double down", but this is the > direction I'd like to continue in. It's important to Fedora Cloud, and it's > important to F21 messaging overall. > > > Would more regular meetings help? > > If it would, let's do it. :) +1. Given the speed and priority of Atomic, I think I'd benefit from a regular checkpoint to see where things are blocked and making sure specific tasks get assigned to someone to do, especially where it hits my team. I feel like we have a sort of split -- some tasks for which we have resources for (like coding that David can help with), but not sure of direction; and some tasks for which we have a better idea of direction (the infra related stuff, to some extent), but not sure about resources. The resource problem we can probably solve, and we have alternatives other than doubling down, or overloading everyone already doing lots of stuff. But we need to be able to quantify exactly what's not getting done and why first, so I'd love to hash that out. Is Fedocal what we'd use to set something up for early next week? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
