serversig
LOGS
19:59:39 <sgallagh> #startmeeting Fedora Server SIG Weekly Meeting (2018-05-15)
19:59:39 <zodbot> Meeting started Tue May 15 19:59:39 2018 UTC.
19:59:39 <zodbot> This meeting is logged and archived in a public location.
19:59:39 <zodbot> The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:59:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:59:39 <zodbot> The meeting name has been set to 'fedora_server_sig_weekly_meeting_(2018-05-15)'
19:59:39 <sgallagh> #meetingname serversig
19:59:39 <sgallagh> #topic Roll Call
19:59:39 <zodbot> The meeting name has been set to 'serversig'
19:59:50 <sgallagh> .hello2
19:59:51 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
19:59:57 <smooge> .hello666
20:00:00 * nirik is here, but going to grab some more coffee...
20:00:07 <smooge> hello
20:00:46 <mjwolf> .hello2
20:00:47 <zodbot> mjwolf: mjwolf 'Michael Wolf' <mjw@linux.vnet.ibm.com>
20:02:44 <sgallagh> Just trying to summon a few other participants
20:03:06 <sgallagh> pbrobinson: I'm guessing you're asleep, but in case you're here, we plan to discuss the snaps question
20:05:24 <sgallagh> OK, I guess we'll get started
20:05:33 <sgallagh> #topic Agenda
20:05:33 <sgallagh> #info Agenda Item: Fedora Base Snap
20:05:40 <sgallagh> Anyone have other agenda items for this week?
20:05:54 <mjwolf> no
20:06:38 <sgallagh> #topic Fedora Base Snap
20:06:53 <nirik> can someone summarize what this is? something needed for other snaps to build on? or ? what would be in it?
20:07:23 <sgallagh> nirik: It's roughly comparable to creating a container base image, yes
20:07:44 <sgallagh> The idea would be that other snaps could be produced that would rely upon it and thus be built on a Fedora foundation instead of an Ubuntu one
20:07:44 <nirik> ok, and how is it built/distributed?
20:07:53 <langdon> .hello2
20:07:54 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
20:08:01 <sgallagh> nirik: Today, manually.
20:08:21 <sgallagh> Neal and Zygmunt plan to add a plugin/extension for ImageFactory to generate it as part of this effort.
20:08:21 <nirik> releng isn't going to like that. :)
20:08:28 <nirik> ah, ok. I missed that
20:08:59 <sgallagh> Right now it's a proof-of-concept that they've gotten along far enough that they know the bits can be made.
20:09:11 <nirik> the package set would be something like container base image?
20:09:13 <sgallagh> The remaining work would be making it automatable
20:09:23 <sgallagh> Similar but IIUC not exactly the same
20:09:55 <sgallagh> I was hoping Neal or Zygmunt could answer some of these questions, but they didn't reply to my pings
20:10:08 <sgallagh> I'm mostly just rehashing the two conversations I had with them
20:10:52 <sgallagh> pbrobinson raised a valid objection to splitting the focus of the Server SIG that I think warrants some discussion.
20:11:01 <nirik> ok. I'm fine with producing and distributing it, but it would need releng ack to make sure they have the cycles...
20:11:19 <sgallagh> Right now, we've got good momentum on the Modularity work and Peter's concern would be that this would split our efforts.
20:11:22 <langdon> re:splitting focus.. aren't snaps primarily focused on desktop apps?
20:11:50 <sgallagh> langdon: According to Neal, it's the opposite. Flatpaks are more desktop focused, while snaps are focusing on services
20:12:11 <langdon> weird.. certainly not in their hype /me should go investigate
20:12:14 <sgallagh> Likely both can be used for either, but I gathered that snaps are designed more around the latter.
20:12:50 <sgallagh> nirik: I already put them in touch with mboddu to investigate the necessary work.
20:13:51 <sgallagh> My understanding from Neal and Zygmunt is this: they plan to do this work regardless, but they really want to be able to do it with the Fedora name, rather than creating a Remix or derivative.
20:14:11 <sgallagh> They are unlikely to get permission to use the branding without it being built in our build-system.
20:14:25 <langdon> sgallagh: so... is the proposal to support them? or to actually encourage their use? and/or has anyone investigated generating them from modules like the flatpak folks are?
20:14:50 <sgallagh> langdon: I haven't made the proposal yet, I'm establishing the problem space :)
20:15:34 <mboddu> sgallagh: If its about snaps, I talked to Neal about it and informed him what tools require updates to support snaps, thats all I got
20:15:50 <langdon> well.. the answer speaks a lot to the "splitting focus" .. if the server sig is just enabling it, i don't see a focus split.. if encouraging it, then i would be concerned as well
20:16:10 <sgallagh> No one has asked for us to make a *recommendation* about the relative value of snaps. We've basically just been asked to assert whether we think the project deserves exploration in Fedora (under the Server banner) and if it's okay for them to do the work and use the Fedora name.
20:16:38 <sgallagh> langdon: Sure, I'm getting there. I was just trying to make sure that my proposal was framed with sufficient information
20:16:49 <langdon> sgallagh: cool...
20:17:37 <nirik> definitely would want this to be non blocking/best effort... but as long as they do most of the work, I think it's fine to do it and see if it gets used any. ;)
20:17:50 <sgallagh> Proposal: The Server SIG will welcome the efforts of anyone who wants to contribute to getting a Fedora Server base snap created. We will assist where feasible, but we don't commit to any specific deliverable timeframe or resource allocation.
20:17:54 <langdon> nirik: im with you
20:18:52 <langdon> sgallagh: would it be worth adding some "review" to the proposal (me typing more)
20:19:03 <sgallagh> Maybe I should make it clearer that we are setting the priority at "nice to have" (meaning if it would interfere with other efforts, it's the first to be bumped)
20:19:41 <langdon> in the <somewhere> thread you were asking about selinux for example.. like should we ask that "xyz people do some due diligence on security/fit/etc" as part of the proposal?
20:19:52 <sgallagh> BRB, just started raining and I need to drag in a bunch of cardboard that the recycling truck refused to pick up :-/
20:20:20 <langdon> sgallagh: you don't want to just recycle it via rain in your yard?!?
20:22:58 <sgallagh> Please continue, monitoring on my phone while I do this.
20:23:09 <sgallagh> Please suggest improvements.
20:24:10 <langdon> well.. i don't want to be a nudge.. but i wonder if an unbiased review of snaps (i know my info is pretty dated) would/should be a requirement..
20:24:43 <langdon> so your proposal is "fine" but perhaps adding "subject to a review by a fesco member" or infra member or something
20:25:21 <langdon> sgallagh: ^^
20:27:57 <smooge> so I don't see it as a problem as long as the rule is "you stop helping or cant find someone to take it over we rip it out"
20:28:11 <sgallagh> smooge: +1
20:28:28 <sgallagh> I kind of see this as being adjacent to a Spin
20:28:58 <sgallagh> But as the stated focus is on services, I think it fits under our umbrella
20:29:08 <sgallagh> (rain metaphors, yay!)
20:29:22 <smooge> keep them pouring in
20:29:47 <sgallagh> Lightning quick!
20:30:49 <sgallagh> langdon: Well, FESCo delegates Server SIG decisions to us.
20:30:58 <sgallagh> So if we say "go for it", that's acceptable
20:31:24 <langdon> ok.. so.. is someone volunterring to do a review from server-sig? :)
20:31:41 <zyga> Hi
20:31:44 <smooge> what kind of review?
20:31:47 <sgallagh> Ah, hello zyga
20:31:51 <sgallagh> You can answer all the questions :)
20:32:04 <sgallagh> langdon: You had several Q's, please ask them :)
20:32:32 * zyga will do his best to help
20:32:42 <langdon> a) is the goal with snaps that server-sig supports them? or encourages them?
20:33:00 <langdon> b) has anyone investigated generating snaps from modules like flatpak folks are doing?
20:33:23 <zyga> I think neither at this point. We (Neal and I) just wanted to continue the experiment under the Fedora umbrella.
20:33:43 <langdon> c) should someone from the server-sig who is not making the proposal review current state of snaps?
20:34:05 <langdon> zyga: is that to "a"? i should probably have just paced them out ;)
20:34:21 <zyga> Yes, that was to a)
20:35:04 <langdon> zyga: ok... so, would you expect them to be built in anything beside rawhide?
20:35:08 <zyga> B) modules? I’m not familiar with them yet. Our goal now is to use f29 rpms (binary) to generate our snaps
20:35:31 <zyga> C) is interesting but should not affect this in my eyes
20:36:13 <zyga> I would expect that snaps will be built from whatever release that is desired, including stable releases
20:36:23 <sgallagh> zyga: Well, C) is very interesting to *us*
20:36:39 <zyga> As any snap can be used on any system (eg f27 system can run a snap that uses f29 base)
20:36:39 <sgallagh> Because it helps us decide if it's a sensible use of Fedora resources
20:36:49 <sgallagh> (builders, composies, etc)
20:36:54 <sgallagh> *composes
20:37:59 <langdon> sgallagh: could we write a f29-change to go from composes->composies? i think it sounds much more friendly
20:38:08 <zyga> I think the cost would be tiny, it is just a script that churns a file out of some rpms from the archive. It is mainly an enabling step to allow developers to use Fedora as a base of their projects
20:38:35 <zyga> One we make the changes to tools that do composes it will mainly run itself
20:38:47 <smooge> so from what I can tell.. snap needs a bas 'container OS' to work... modules are stuff which would be put on top after they have made the base snap to stand up in a 'container'
20:38:52 <langdon> zyga: so no need to rebuild teh rpms?
20:39:02 <zyga> langdon: correct
20:39:05 <sgallagh> zyga: And to confirm, you plan to do that yourselves (sending PRs as appropriate) with minimal aid from releng, right?
20:39:12 <langdon> smooge: yeah.. flatpak does the same..
20:39:16 <sgallagh> that == changes to compose tools
20:39:17 <zyga> sgallagh: yes
20:40:03 <zyga> smooge: the base container you speak of is exactly what we want to build now
20:40:14 <langdon> zyga: what describes what is in the "base"? kickstart?
20:40:18 <zyga> It ships no “apps” (nothing for end users to run)
20:40:36 <sgallagh> langdon: I think it's a manifest file
20:40:59 <zyga> Snap authors explicitly pick the base they want to use, that serves as the rootfs of said application snap
20:41:20 <langdon> sgallagh: so.. i would assume, that would need to be "maintained" to change the content over time? unless it can be gen'd from comps or something
20:41:43 <zyga> langdon: this is open to debate. We want to use a minimal set of rpms and post process them
20:41:52 <zyga> (To add snap mount points mainly)
20:42:12 <langdon> zyga: yeah.. but the "minimal set" is (likely) not static, right?
20:42:15 <zyga> I think today we just use @core but this is really something we need to experiment with
20:42:48 <sgallagh> zyga: I think he means "can the base snap be updated"?
20:42:54 <zyga> But the resulting snap is pretty big so we will probably reduce it much more
20:42:56 <zyga> Yes
20:43:01 <zyga> Snaps can be updated
20:43:14 <zyga> Bases are special as they should not break on update
20:43:20 <zyga> As that breaks other snaps
20:43:42 <zyga> So bases need careful update process that ensures abi is unchanged
20:44:10 <langdon> not quite what i meant.. but that is also interesting .. two qs: do you expect the base snap to be updated more often than every fedora release? 2nd, i meant, between f29 & f30, the manifest describing what is in the base snap will likely change, how does that get managed?
20:44:23 <zyga> Our current experiment will likely not break the abi over time but we will experiment with the set of files to ship or remove
20:44:45 <zyga> Yes, whenever security updates warrant that for instance
20:44:59 <langdon> if you need updates more often than every fedora release, like base containers do, they you need integration with OSBS as well (i think)
20:45:04 <sgallagh> Alternately, can the snaps update in-place or does a base snap have to be replaced in totality?
20:45:10 <zyga> In Ubuntu the 16.04 base snap is updated about once a month on average
20:45:12 <langdon> s/they/then
20:45:34 <sgallagh> So it requires a full rebuild, rather than running e.g. `dnf update` inside
20:45:42 <zyga> Snaps are mounted, we just mount another revision and transition apps over to new one
20:45:43 <sgallagh> Yeah, that gets more complicated
20:45:52 <zyga> Ah sorry
20:46:03 <zyga> I will thought you meant at runtime
20:46:27 <zyga> At build time we would just unpack the set of latest rpm’s and run the post processing again
20:46:41 <langdon> zyga: yeah.. this is more like ostree or base docker containers.. not "undoable" .. but if you need to ship a whole new base image, our existing update process doesn't do that, however, osbs does
20:46:55 * zyga nods
20:47:25 <zyga> Each built snap can be uploaded to the store and can be published separately, after any QA
20:47:27 <nirik> are base snaps signed ?
20:47:43 <zyga> All snaps have assertions that are effectively signatures, yes
20:47:54 <sgallagh> Right, and we're rapidly getting into "Designing this properly is going to require more involvement than I had hoped for" territory :(
20:48:00 <zyga> Assertion system is sophisticated. It is more than just a signature
20:48:01 <langdon> and, i may be mistaken, but .. fedora never ships a new base container, mid-cycle, but we change what is available in the docker repos by layering it on in osbs?
20:48:18 <nirik> but they don't need to be signed by releng as being 'fedora signed' ?
20:48:57 <zyga> What happens when a Fedora docker image needs a security update? I largely think snaps have similar life cycle
20:49:28 <langdon> nirik, sgallagh, smooge i was kinda guessing 2 lines up
20:49:38 <langdon> to answer that q for zyga
20:49:44 <zyga> nirik: no, the signature is generated by the store and describes the blob and the uploader
20:49:49 * Pharaoh_Atem waves
20:49:54 <nirik> ok
20:50:01 <zyga> (So Fedora infra would have an account that can upload snaps)
20:50:03 <Pharaoh_Atem> .hello ngompa
20:50:04 <zodbot> Pharaoh_Atem: ngompa 'Neal Gompa' <ngompa13@gmail.com>
20:50:08 <Pharaoh_Atem> sorry, I'm super late
20:50:31 <zyga> Hey Neal
20:50:36 <Pharaoh_Atem> what'd I miss?
20:50:49 <zyga> Lots of questions about snaps
20:50:59 * langdon needs to catch a bus soon.. will remain.. but slower typing from mobile
20:51:47 <sgallagh> So, I think I remain of the opinion that there's no reason for us NOT to accept any work that Pharaoh_Atem and zyga want to do, but we aren't going to treat it as something we're *investing* in.
20:52:16 <smooge> agreed
20:52:31 <zyga> This makes sense. It is very early and our goal is to enable app developers
20:52:34 <nirik> yep. Will be interesting to see what uptake it gets. ;)
20:52:35 <langdon> well. i agree.. but i think it is important that zyga and Pharaoh_Atem investigate the "we only build once per cycle" unless you use osbs
20:52:39 <smooge> I am glad and happy you people are doing this..
20:52:47 <zyga> To release apps using Fedora as the foundation
20:53:10 <smooge> then we can go for fedora atomic snaps to be built every 2 weeks
20:53:17 <Pharaoh_Atem> yes, which would be super-cool
20:53:28 <zyga> I largely expect next 6 months will be spent on the tooling (snapcraft) and experiments
20:53:29 <Pharaoh_Atem> we could build more frequently even, but following atomic's cadence would work fine
20:53:35 <Pharaoh_Atem> yeah
20:53:49 <Pharaoh_Atem> once we have a base snap, it unbreaks a big catch-22 to actually start fixing snapcraft to do the right thing
20:53:52 <zyga> And convincing people to try making Fedora snaps
20:54:07 <zyga> Pharaoh_Atem: I agree
20:54:16 <smooge> well I think convincing people to do anything container-ish is still out there
20:54:29 <Pharaoh_Atem> yeah, containers are a hard sell no matter what
20:54:30 <smooge> don't they magically grow on trees
20:54:31 <zyga> We are also lucky that snapcraft is getting simplified and decoupled from Ubuntu
20:54:40 <Pharaoh_Atem> ooh
20:54:52 <zyga> Snaps are not like typical containers, they don’t feel that way
20:54:53 <Pharaoh_Atem> dare I say it, is it becoming.... modular? :D
20:54:54 <sgallagh> smooge: I thought containers arrived on barges...
20:55:16 <sgallagh> I have a hard-stop in five minutes, so is there anything we want to add here?
20:55:22 <smooge> same here
20:55:25 <zyga> Pharaoh_Atem: yes, with declarative base logic (proposal is on the forum)
20:56:42 <Pharaoh_Atem> sweet
20:56:49 * Pharaoh_Atem makes a note to look that up later
20:56:58 <zyga> I can share quickly
20:57:08 <Pharaoh_Atem> cool
20:57:40 <Pharaoh_Atem> sgallagh: so are we given the okay to work on this? My expectation is that aside from a small piece of wire-up work, it's almost entirely going to be zyga and myself working on this
20:58:25 <Pharaoh_Atem> and if mattdm's proposal of adding a variant ID to everything goes through, we'd probably need to make up something for that...
20:58:30 <sgallagh> I need to get a vote on a formal proposal:
20:58:32 <zyga> https://forum.snapcraft.io/t/draft-consistent-build-environments-build-vms/5374
20:59:19 <sgallagh> Proposal: Server SIG will welcome any work done by the community to advance snaps in Fedora, but will not treat it as a priority if it comes in conflict with other initiatives.
20:59:58 <smooge> +1
21:00:08 <langdon> +1
21:00:13 <nirik> sure, +1
21:00:16 <mjwolf> +1
21:00:46 <sgallagh> #agreed Server SIG will welcome any work done by the community to advance snaps in Fedora, but will not treat it as a priority if it comes in conflict with other initiatives. (+5, 0, -0)
21:00:49 <zyga> Thank you. We will do our best to help :-)
21:01:01 <sgallagh> OK, it's the top of the hour and I need to run. Happy coding :)
21:01:06 <smooge> nifht
21:01:10 <sgallagh> Thank you everyone for participating
21:01:11 <smooge> thank you sgallagh
21:01:15 <sgallagh> #endmeeting