17:00:09 <dustymabe> #startmeeting fedora_atomic_wg
17:00:09 <zodbot> Meeting started Wed Aug 16 17:00:09 2017 UTC.  The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:09 <zodbot> The meeting name has been set to 'fedora_atomic_wg'
17:00:13 <dustymabe> #topic roll call
17:00:16 <contyk> .hello psabata
17:00:17 <dustymabe> .hello dustymabe
17:00:17 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
17:00:24 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dustymabe@redhat.com>
17:00:28 <yzhang> .hello yzhang
17:00:29 <zodbot> yzhang: yzhang 'Yu Qi Zhang' <jzehrarnyg@gmail.com>
17:00:36 <strigazi> .hello strigazi
17:00:37 <zodbot> strigazi: strigazi 'Spyros Trigazis' <strigazi@gmail.com>
17:00:42 <dustymabe> yzhang strigazi \o/
17:00:46 <miabbott> .hello miabbott
17:00:46 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
17:00:47 <jberkus> .hello jberkus
17:00:47 <jbrooks> .hello jasonbrooks
17:00:49 <zodbot> jberkus: jberkus 'Josh Berkus' <josh@agliodbs.com>
17:00:49 <yzhang> dustymabe \o/
17:00:52 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <JBROOKS@REDHAT.COM>
17:01:33 <dustymabe> looks like maxamillion isn't around today
17:01:37 <jlebon> .hello jlebon
17:01:38 <zodbot> jlebon: jlebon 'None' <jlebon@redhat.com>
17:02:01 <miabbott> good ol' 'None Lebon'
17:02:02 <dustymabe> jlebon: looks like your first name is jlebon and last name None
17:02:05 <dustymabe> :)
17:02:13 <ksinny> .hello sinnykumari
17:02:14 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
17:02:19 <dustymabe> hi ksinny !
17:02:25 <ksinny> dustymabe: Hey!
17:02:44 <dustymabe> ok we'll quickly run through action items from last meeting
17:02:50 <dustymabe> #topic action items from last meeting
17:03:00 <dustymabe> * jberkus strigazi to continue moving kube issues to new kube-sig
17:03:02 <dustymabe> tracker
17:03:04 <dustymabe> * jbrooks to look at building a module himself, this will help us come
17:03:06 <dustymabe> up with even more questions before our meeting next week
17:03:08 <dustymabe> * dustymabe to invite petr sabata to the atomic host meeting next week
17:03:10 <dustymabe> to answer questions and to present a POC atomic host from a module
17:03:12 <dustymabe> * jbrooks to go through 'remove-kube' tickets and update them
17:03:14 <dustymabe> * kushal to create ticket for planning our activities around FLOCK
17:03:15 <jberkus> dustymabe: first issue is ongoing
17:03:16 * dustymabe did invite petr
17:03:23 <jberkus> jbrooks: just found a couple more issues this AM
17:03:26 <dustymabe> he is here today - we'll use a sepearate #topic for that
17:03:41 <kushal> https://pagure.io/fedora-atomic/issue/72
17:03:42 <jzb> .hellomynameis jzb
17:03:43 <zodbot> jzb: jzb 'Joe Brockmeier' <jzb@redhat.com>
17:03:43 <dustymabe> #info jberkus still working on moving kube issues to new kube-sig tracker
17:03:49 <jbrooks> dustymabe, I updated the issues on the atomic-wg tracker, and then moved them to the kube-sig tracker
17:04:10 <dustymabe> #info jbrooks updated 'remove-kube' issues and also moved them to the kube-sig tracker
17:04:11 <jbrooks> dustymabe, I started looking at my own module, but haven't made one yet
17:04:15 <kushal> .hellomynameis kushal
17:04:16 <zodbot> kushal: kushal 'Kushal Das' <mail@kushaldas.in>
17:04:28 * roshi_ lurks
17:04:39 <contyk> jbrooks: happy to help with that :)
17:04:42 <dustymabe> #info jbrooks started investigating atomic host module (as a learning excercise). has made some progress, but no real results
17:04:58 <walters> i played with building locally, hit https://github.com/cockpit-project/cockpit/issues/7510 at least
17:05:30 <dustymabe> #info kushal created https://pagure.io/fedora-atomic/issue/72 for us to plan our activities around flock
17:05:55 <dustymabe> walters: you looked at creating your own module?
17:06:09 <walters> no, running `mbs-build local` against the one contyk set up
17:06:13 <dustymabe> ahh ok
17:06:19 <walters> https://src.fedoraproject.org/modules/atomic
17:06:20 <dustymabe> ok let's move on to topics for today
17:06:40 <dustymabe> #topic contyk to present his POC so far for atomic host module
17:06:44 <dustymabe> contyk: take it away
17:07:05 <contyk> alright; unforuntately I don't have any binaries or images to show as I hit numerous issues trying to build the PoC module
17:07:18 <contyk> the cockpit spec file bug walters was referencing was one of them
17:07:40 <contyk> another problem was our main repodata we use for depsolving and generating modules was sort of borked for the past week
17:07:43 <contyk> however
17:08:04 <walters> another I hit is apparently coreutils %check blows up when mock is run inside a container
17:08:25 <contyk> I used a json file provided by walters to compose a list of packages that feed to our depsolver; this can be found here -- https://github.com/fedora-modularity/hp#atomic
17:08:26 <walters> but I think RPM %check is a bad idea, so retrying today with --skiptests anyways
17:08:34 <contyk> walters: +1 on that
17:08:54 <contyk> I limited some packages to certain architectures because they either weren't available on all of them
17:09:05 <contyk> or some of their [build] dependencies anywhere in the chain weren't
17:09:29 <contyk> using this list and the scripts in this repo as well as in this one -- https://github.com/fedora-modularity/baseruntime-package-lists
17:09:51 <contyk> ...I put together a PoC modulemd file, which is available here:
17:10:04 <contyk> https://github.com/fedora-modularity/baseruntime-package-lists/blob/master/data/Fedora/devel/atomic/atomic.yaml
17:10:09 <contyk> and in dist-git under modules/atomic
17:10:17 <walters> one thing related to this that's clear is that rpm-ostree should probably learn how to parse the module list...maintaining things twice will be painful otherwise
17:10:27 <walters> #link https://github.com/projectatomic/rpm-ostree/issues/744
17:10:41 <contyk> now if we lived in a perfect world, we could just "mbs-build submit" this and MBS would build all of the components and tag them into a unique tag we could then compose and generate an ostree image from
17:10:45 <dustymabe> contyk: so what is the link walters provided earlier?
17:10:50 <contyk> but alas, many of the packages FTBFS
17:10:54 <dustymabe> https://src.fedoraproject.org/modules/atomic ?
17:11:07 <contyk> dustymabe: yes, that's the place
17:11:10 <dustymabe> FYI all: FTBFS == failed to build from source
17:11:40 <contyk> I haven't had the time to investigate these failures; any help is appreciated
17:11:53 <dustymabe> #info contyk has a module definition for an atomic host module at https://src.fedoraproject.org/modules/atomic but many packages currently aren't building for various reasons in the module build system
17:12:05 <contyk> note the atomic module shares its buildroot with the host & platform modules so any build failures will or do affect host & platform as well
17:12:20 <dustymabe> contyk: so what are the other links you gave us
17:12:30 <dustymabe> and how do they compare to https://src.fedoraproject.org/modules/atomic ?
17:13:16 <contyk> we use fedora-modularity/hp as input -- a README file with components we definitely want in the modules; this is meant to be human readable but is also consumed by our depsolver (depchase)
17:14:10 <contyk> the fedora-modularity/baseruntime-package-lists is more technical; it consumes the content definition from the "hp" repo and creates complete, per-architecture package lists using fedora repodata (we have a development snapshot with our own updates on top)
17:14:40 <contyk> the package lists are then parsed and modulemd files are generated; these modulemd files are also included in that repo and they can be pulled into dist-git and built
17:14:48 <dustymabe> contyk: can you update the readme of https://src.fedoraproject.org/modules/atomic to add this detail?
17:15:11 <contyk> that's a good point, yes; we need more documentation... like everywhere
17:15:14 * contyk makes a note
17:15:41 <dustymabe> #action contyk to update the readme in https://src.fedoraproject.org/modules/atomic to point to other places where things are defined and explain why things are the way they are
17:15:55 * contyk nods
17:16:17 <dustymabe> contyk: yeah - right now it seems like we are pulling in pieces from a few different places. is it the plan for it to be that way always or will it get simpler over time?
17:16:39 <contyk> so, once cockpit is fixed, we will include the fix in our special updates repo, regenerate the lists and modulemd files and see if it fixed the module build problems
17:16:50 <dustymabe> ok
17:16:54 <contyk> of course it's not just cockpit, more packages failed to built, unfortunately
17:17:11 <walters> i have to admit i am really confused by the role of the bootstrap.txt files, the platform.csv files, and the different types in the modulemd in addition to all of our existing "lists of packages" formats like comps, rpm-ostree, dockerfiles et
17:17:23 <contyk> at this point I don't dare to promise you any specific date when I could show an image but I still hope it will be within two or three weeks
17:17:28 <jbrooks> So do modules always begin from source, or do they begin w/ the existing rpms
17:17:41 <dustymabe> #topic open questions for the modularity team
17:17:53 <dustymabe> ok i switched topics since it looks like we are going into that territory
17:18:00 <contyk> walters: they are mostly part of our workflow and aren't really meant to be consumed by anyone
17:18:02 <dustymabe> walters: jbrooks: feel free to ask those questions
17:18:28 <contyk> jbrooks: they always build from source, but the very first module was created by cherry picking rpms from the traditional tags
17:18:55 <walters> s/build from source/are self hosted/ right?
17:19:03 <walters> https://blog.verbum.org/2012/10/13/building-everything-from-source-vs-self-hosting/
17:19:39 <contyk> yes, the ultimate plan is to be self-hosted but we're not there yet
17:20:06 <contyk> the reason is the self-hosting set is ~3600 packages at this point and roughly 150 of them FTBFS
17:20:23 <contyk> so the self-hosting set cannot really rebuild itself and we still have to manually update it
17:20:40 <contyk> by tagging builds from rawhide once they include the fixes we need
17:20:44 <contyk> it's a pain
17:21:10 <contyk> for reference, bootstrap.yaml (modules/bootstrap) is the self-hosting set
17:21:18 <contyk> besides being the buildroot for host, platform, shim and atomic
17:21:44 <dustymabe> ok jbrooks I think you have a few questions as well from the ticket (some of them are already answered in the ticket but would be good to recount them here)
17:21:59 <dustymabe> #link https://pagure.io/atomic-wg/issue/313
17:22:04 * contyk clicks
17:22:22 <dustymabe> contyk: might be best if he copy/pastes them here
17:22:28 <dustymabe> and we can have a discussion
17:22:36 <contyk> yep
17:22:59 <jbrooks> Well, the first two were more or less answered in irc / in the ticket
17:23:41 <jbrooks> I asked how an ostree tree would be composed, and it would, initially, be composed the same way it is now, but from a repo based on a module
17:23:45 <jbrooks> I think I have that right?
17:23:54 <contyk> yep
17:24:01 <dustymabe> jbrooks: that is my understanding
17:24:08 <jbrooks> I also asked how package layering would work, and Colin answered, pretty much the same
17:24:11 <walters> yeah, don't see a different way to do it
17:24:12 <jbrooks> As now
17:24:20 <contyk> I can explain how MBS builds stuff and where the resulting RPMs are if you like
17:24:26 <jbrooks> Sure
17:24:28 <contyk> but that might be too detailed for this meeting
17:24:31 <jbrooks> OK
17:24:34 <contyk> up to you :)
17:24:43 <dustymabe> contyk: maybe a 5-10 minute summary?
17:24:49 <dustymabe> we have time
17:24:51 <walters> although related to this topic i learned that modularity today doesn't split the buildroot off so we'd still have all the -devel packages in the repo unfortunately
17:25:10 <walters> and there's a whole other topic here around what packages aren't in AH that people might want to layer
17:25:14 <contyk> walters: unless you filter them out, which you totally can do
17:25:53 * jwf peeks in
17:25:53 <contyk> ok, so for the build -- when you submit a modulemd, MBS creates a new pair of tags -- the resulting module tag and its build tag
17:26:07 <contyk> it then sets up tag inheritence based on the module's build dependencies
17:26:28 <dustymabe> tag == koji tag?
17:26:36 <contyk> so if you module buildrequires platform:master, for instance, MBS finds the latest version of platform:master in PDC, finds its koji tag and sets your build tag so that it inherits from that tag
17:26:42 <contyk> yes, koji tag, sorry
17:26:48 <dustymabe> just making sure
17:27:27 <contyk> it then builds the source packages listed in your modulemd data.components.rpms section, using the specific refs you have there -- these might be any git refs: commit hashes, tags, or branches
17:28:08 <contyk> branches are especially useful with the arbitrary branching change where we hope maintainers will create upstream-versioned branches in dist-git so that we could then say "I want the 5.26 branch of perl" instead of a specific commit
17:28:37 <contyk> every time you build your modulemd, even without changes, the ref is translated to a specific commit and that commit is built in koji, in your build tag
17:28:59 <jbrooks> And so it's not really tied to a specific version of fedora, just a specific version of perl
17:29:00 <contyk> you can even build components in a specific order or define extra RPM macros for your buildroot, MBS sets it up for you... with magic
17:29:08 <contyk> (okay, it injects a special macros package in there)
17:29:13 <contyk> yep
17:29:52 <contyk> so, as it builds you packages, it tags them into the resulting module tag; once the module is built, you can find all your RPMs in your own private tag which defines your module/stream/version/other bits
17:29:58 <contyk> this is where the build ends
17:30:01 <contyk> but then you compose it
17:30:04 <walters> who has the access to submit module builds today?  and that's manual (requires krb auth?), can't be triggered by e.g. a push to git?
17:30:47 <contyk> we tell pungi what modules+streams we want, it looks up the latest versions and their tags and creates a repository with RPMs in those tags; it then drops binary packages listed in the filters of those module builds and optionally even adds multilib magic (not yet implemented)
17:31:22 <contyk> walters: MBS access is limited to modularity-wg members until we have module packaging guidelines
17:31:26 <walters> definitely don't care about multilib =)
17:31:30 <contyk> walters: should open up next week
17:31:37 <contyk> ;)
17:32:03 <contyk> so, once the pungi repo compose is done, it proceeds with the usual stuff -- it runs buildinstall to create a boot.iso and processes any configured kickstarts to create images
17:32:06 <contyk> nothing special there
17:32:23 <contyk> so for atomic...
17:32:38 <jbrooks> In fedora's package git, the branches are associated with fedora versions, would there be new branches for the modules?
17:32:52 <jbrooks> or would they all look to the master
17:32:55 <contyk> once there's at least one stable build, I would change the extremely specific refs in the modulemd to "master" or something else you want to use -- per package, I guess
17:33:08 <contyk> jbrooks: let me find a link for you
17:33:25 <contyk> jbrooks: https://fedoraproject.org/wiki/Changes/ArbitraryBranching
17:33:33 <dustymabe> yeah we would have to figure out what we wanted our git branches to be named and what to use
17:33:40 <walters> we don't have to do this in this meeting but i'd definitely like to understand the over-time maintenance
17:33:43 <contyk> jbrooks: with this change (should be available next week?) packagers can create any* branches they like
17:33:49 <dustymabe> walters: me too
17:34:17 <jberkus> are we discussing anything else this meeting?
17:34:26 <walters> e.g. NetworkManager upstream changes, NM pkg maintainer goes and does all the current manual spec file editing/fedpkg/koji crud, then at some point we...notice this somehow?
17:34:27 <contyk> jbrooks: *fc\d+, el\d+ and epel\d+ will be reserved branch names people cannot use and f27 and possibly even f28 will still be created by the system
17:34:31 <dustymabe> jberkus: i have a few more things
17:34:54 <jberkus> can we, then? modules discussion seems like a VFAD at this point
17:35:01 <dustymabe> do we really want specific packages to have a branch for our atomic module?
17:35:10 <contyk> jberkus: the general expectation is people will have upstream-version-driven branches and pull into f27/f28 from there
17:35:13 <dustymabe> i.e. the kernel, systemd, anaconda, etc
17:35:40 <jbrooks> Yes, I like the upstream-driven scheme
17:35:42 <dustymabe> jberkus: agreed - we need a more focused discussion on this
17:36:00 <dustymabe> walters: jbrooks contyk - can we set up some time to chat soon on this topic
17:36:07 <dustymabe> sounds like there are more questions than anticipated
17:36:09 <contyk> works for me
17:36:12 <jbrooks> sure
17:36:25 <dustymabe> also i wish we didn't have a bunch of build failures when contyk first did the POC
17:36:34 <dustymabe> that makes me a little less optimistic
17:36:42 <dustymabe> but we'll see
17:36:49 <contyk> :)
17:36:56 <dustymabe> #action dustymabe walters jbrooks contyk to havea separate breakout on this topic
17:37:10 <contyk> well, thanks for having me and feel free to ask on #fedora-modularity anytime, too
17:37:17 <dustymabe> contyk: thanks for coming
17:37:21 <jbrooks> Thanks
17:37:24 <dustymabe> and hopefully we can find you in #atomic too
17:37:27 <walters> thanks for staying online late!
17:37:31 <dustymabe> ok, next topic
17:37:33 <contyk> I wasn't sure which channel to join
17:37:38 <contyk> #atomic it is then
17:37:42 <dustymabe> #topic adding tuned to atomic host and btrfs-progs to atomic workstation
17:37:47 <langdon> dustymabe, et al) you could also bring this to the modularity-wg office hours or the meeting
17:37:52 <langdon> both on fedocal
17:38:05 <dustymabe> we have had a few requests for adding things to atomic host and atomic workstation
17:38:08 <dustymabe> tuned for atomic host
17:38:19 <dustymabe> #link https://pagure.io/atomic-wg/issue/315
17:38:24 <dustymabe> and btrfs-progs for workstation
17:38:33 <dustymabe> #link https://pagure.io/atomic-wg/issue/319
17:38:45 <dustymabe> although we could argue that it should maybe go in both workstation and host
17:38:54 <jbrooks> Those both sound like worthy adds to me
17:39:08 <dustymabe> i think tuned was a nobrainer as the openshift-ansible guys would like to depend on it for the installer
17:39:33 <dustymabe> i think btrfs-progs makes sense too, especially if we are serious about https://pagure.io/atomic-wg/issue/306
17:39:44 <jbrooks> the initramfs thing
17:39:55 <dustymabe> jbrooks: ?
17:40:26 <jbrooks> Just from the summary on the btrfs-progs one, it's a reason not just to layer it on optionally
17:40:37 <dustymabe> ahh ok
17:40:49 <dustymabe> any opinions on thse packages and including them in atomic host?
17:41:02 <jbrooks> I'm +1 to both
17:41:42 <jberkus> seems fine
17:42:02 <dustymabe> walters: jlebon: any objections?
17:42:10 <walters> i just commented
17:42:15 <walters> https://pagure.io/atomic-wg/issue/319#comment-458232
17:42:17 <dustymabe> ok cool
17:42:24 <dustymabe> moving on to next topic
17:43:04 <dustymabe> #topic  Flock 2017 list of events from Atomic WG
17:43:13 <dustymabe> kushal: you made the ticket against the wrong pagure repo
17:43:28 <kushal> blah
17:43:29 <dustymabe> this: https://pagure.io/fedora-atomic/issue/72
17:43:29 <walters> can someone close https://pagure.io/atomic-wg/issue/319 ?  I don't have privs
17:43:34 <kushal> I blame my fever
17:44:06 <dustymabe> so for this topic, jberkus is there any thing you'd like to schedule?
17:44:18 <dustymabe> or maybe we can even plan to have a dinner or something
17:44:23 <dustymabe> to get the group together
17:44:35 <kushal> Will do the right one tomorrow morning.
17:44:37 <jberkus> dustymabe: can you file that on the right repo?  I can add stuff in the comments
17:44:57 <jberkus> I would like to do an Atomic social thing, except that I don' tknow enough about the social schedule at Flock
17:44:59 <jberkus> does anyuone?
17:45:03 <dustymabe> jberkus: sure
17:45:08 <dustymabe> i'll open a ticket against the right repo
17:45:16 <dustymabe> jberkus: i think maybe ask bexelbie
17:45:48 <jzb> walters: I added you as an admin + closed that issue. Somebody yell at me if I was overzealous.
17:46:10 <jzb> jberkus: as long as you're not booking mariachis again. ;-)
17:46:22 <dustymabe> jzb: i was just in the process of doing the same thing
17:46:29 <dustymabe> was about to tell walters he already had privs :)
17:46:45 <jberkus> jzb: nope,too hard to find in cape cod.  was planning to find an acapella sea shanty group instead
17:46:51 <jbrooks> dustymabe, are you also booking  mariachis
17:46:54 <dustymabe> #action jberkus to get with bexelbie to organize an atomic social for Flock
17:47:06 <jzb> jberkus: ಠ_ಠ
17:47:16 <jberkus> dustymabe: do we have any idea how many people on our team will be there?
17:47:48 <dustymabe> jberkus: not exactly. maybe we can start an etherpad and send it to the list to ask people to add their name
17:47:49 <kushal> :)
17:48:17 <dustymabe> ok moving to open floor
17:48:20 <dustymabe> #topic open floor
17:48:28 <dustymabe> anyone with anything for open floor?
17:48:54 <jberkus> I'll just note that we have several new contributors on the new docs repo
17:49:06 <dustymabe> jberkus: sweet!
17:49:23 <jberkus> and: OpenShift Online Pro is now available, so I will be geting a paid account for Atomic until we can get a comp'd one
17:49:28 * dustymabe needs to fill out the issues on the docs repo from our VFAD
17:49:34 <jberkus> dustymabe: yes, you do
17:49:44 <strigazi> can we have the link to the repo?
17:49:49 <jberkus> I still need to fix up the toc/chapter structure
17:50:05 <jberkus> strigazi: https://github.com/projectatomic/atomic-host-docs
17:50:15 <strigazi> jberkus thanks
17:51:03 <dustymabe> anyone else with anything for open floor?
17:51:07 <dustymabe> ksinny: ?
17:51:50 <dustymabe> ok will wait a few minutes and then close the meeting
17:51:51 <ksinny> I had a question for walters related to issue https://pagure.io/atomic-wg/issue/299#comment-448609
17:52:30 <ksinny> walters: I see that https://github.com/projectatomic/rpm-ostree/pull/877  has been fixed, so is there any timeline to get a new relaese for rpm-ostree?
17:52:31 <walters> ah yeah it requires an anaconda patch and then after that's done changing the kickstarts
17:52:59 <walters> ksinny, i think "soon" like less than a week
17:53:10 <ksinny> walters: Thanks, that will be geart!
17:53:35 <dustymabe> k
17:53:41 <ksinny> Once changes are made in anconda, FAH cloudImage should build and run on aarch64 and ppc64le
17:53:45 <dustymabe> anything else for open floor?
17:54:26 <dustymabe> #endmeeting