 So, hey everyone, welcome to second year of talking about Snaps of the Dora. This time it's Snaps Love the Dora. So it's an ecosystem progress update by myself, Neil, and this is Masiek, who is, you know, from Canonical. I'll let him talk about himself. Come on. Hi, Masiek. Hi. I'm from Canonical. Yeah, basically the upstream of SnapD, basically inside the SnapD core team, so like a couple of guys working exclusively on SnapD, it's a thing that runs, installs, manages Snaps and stuff. So, actually, I have a fast account, which I created years ago, but I never got into like packaging anything, so that's kind of crazy situation. Well, you know, before joining Canonical, I worked in embedded for like lots of years and contributing to the options as we have to open embedded Zephyr OS, like doing the first board of Zephyr to STM32 chips, and then Canonical started working on that piece. So, by the way, I use Arch, so it's like, I'm one of those guys who actually, you know, not only use Snaps in Ubuntu because that's like most majority of Canonical plays do, but I also use most of the distribution of my home, actually my work laptop is still running out. Do you run Arch on your cover since you're four? Oh, no, no, but by the way, the 64 stands for 64 bits, right? Sure. So, and of course, y'all kind of know me, but like for just to reiterate, I'm, you know, been around doing this for a little over a decade as a contributor and a package in Fedora. I've been involved in other distributions like Magia and open SUSE for the past four or so years. I am involved largely in the software management stack, RPM, DNF, OBS, Koji. My day job, I'm a DevOps engineer at Datto, it's a backup disaster recovery company. There's my Twitter and my email, but yeah, not quite as interesting, as exciting as Magia care. So, what are Snaps? Yeah, so what are Snaps? Actually, because there seems to be like a lot of myths about what Snaps are basically just a squash of this image, which contains your application and all the dependencies. And supposedly it's a way to deliver applications into environment, which doesn't really carry all the dependencies inside your native host distribution. And so also it's a way to provide like kind of like modules and streams, like we can provide a number of channels, which carry either like the latest, greatest version of application or the stable version application or the beta version application you can distinguish between the stability levels. It's also not just the application, we can deliver services, so it's like you can dump a Snap, which contains services, which are then integrated with SystemD. There's a SnapsTor page, which is a bunch of applications, there's a bunch of Snaps already available, a quick list of some of the featured Snaps, as you can basically also see that we were also kind of dog-fooding, because LSD is part of, it's actually delivered as a Snap mostly, and it's also a bunch of canonical projects as well. Yeah, but we are trying to be close with the upstream and trying to accommodate all the needs, because people have different needs, people have different problems, and trying to just find a way in this maze. So Snaps can also deliver, there's second mode of Snaps, which is kind of not confined applications, and this is mostly used for development stacks, so some very special applications that have to work in this kind of a classic distro mode, in which they're not really confined, they have access to the host system, yeah, and those are mostly used for delivering, as I said, development stacks, like Go, Node, RAS, and stuff. So last flock I came and talked about how we were starting to roll this out, and we had just gotten the integrations in place, and things like that, and there were some plans to evolve the SCLinux support, and along those lines. And now we have SnapD and SnapDGlib in Apple 7, that actually happened at the end of last year, which was when I got to the point where I was comfortable enough with my own SCLinux policy for SnapD being good enough to make me not scared of it running on EL7. For the Fedora 30 development cycle, I started sketching out the work for the eventual Fedora-based snap, and we got the snappy variant added to Fedora release for Fedora 30. This was more in line to be part of the better counting thing that Matt was trying to pull out somehow. The idea is that when people are building software with Fedora stacks, we will have an idea because that will ping us with SnapCraft and DNF and things like that. The SCLinux back can actually now exist. It doesn't do a lot yet. It is really new, but it is written and it's in Snap Confined, and it's in development. That landed in March. For SnapD, what was it, 236, I think, was when that landed? 238 might be when I turned it on. We now have the SnapD SCLinux policy and Snap Confined are now generating context for all of the snaps that are being executed on the system. There's not too much happening yet because there's still a lot of work to go about plugging in dynamic policy loading into the kernel, which it doesn't really support doing right now, but that's the thing. We've also added more tests to the upstream CI to cover SCLinux-based behaviors as well as adding sentos to the test suite in addition to supporting the latest Fedora. We actually test the latest stable and raw hide, and so that is continuously tested for every commit that goes into SnapD upstream. We did make the Fedora 29 base snap demo for last flock. Zygmunt, who was here last year, did that. That tooling, I have kind of been working on revamping the, and we've been working upstream to try to figure out a definition for what a base snap's supposed to look like, and then we can kind of bring that together with what we consider the minimal environment that should be included for application delivery runtimes, like what is similar to flatback runtimes for the Snap world. And yes, they are still fun, and we do have cookies. Hopefully you're not allergic to chocolate. So what's kind of going on right now? The ongoing maintenance of SnapD releases, again, is still a thing. SnapD releases on a monthly cadence, more or less. And a big part of this is we're still doing refinements and improvements to the policy, and building up the backend as things keep changing. We're actually now closely tracking changes in Fedora C linux. So as the SELinx policy evolves, we are adapting to it as well. And because of our test suite, we're actually validating as SELinx policy changes land and rawhide and whether they still stay compatible with EL7, which is, as it turns out, slightly complicated because the SELinx policy tends to grow new forms of confinement that don't exist in EL7. And handling both of those is an interesting challenge. Groups and namespaces or SELinx? So the basic confinement currently is seccomp, C groups, namespaces, and other types of Mac and DAC filtering that are applied at mount time. So it is still reduced compared to how it is on Ubuntu because the app armor one does the debus mediation. And so that's since, for example, in Flatpak, you have the portal mechanism. But the portal mechanism essentially is an unfiltered debus call. And in SNAPs, there's actually a way to granularly filter what they call mediate, debus and other types of IPC type actions, which is a glorious hack in app armor that's not upstream. But that is something that SNAPD relies on. SELinx actually has equivalent functionality, but it is really tricky to support because SELinx does not support. As far as I'm aware, somebody who knows better can tell me otherwise, directly, dynamically loading policy instructions through the SELinx at runtime. That's the part that is making this difficult to enhance the back end because for app armor, what they do is SNAP Confine generates the policy as the applications being loaded and then just shunts it into the kernel and then unloads it by poking the kernel until the profiles go away. And so it's kind of scary and glorious at the same time. Last part. So that part is where we're trying to abstract those differences and try to provide a framework for us to fill in SELinx back end stuff as we keep going on. That's largely what Masiek has been doing for the past few months. And I've been kind of helping him a little bit here and there with trying to fill in some of the roles and features and things like that and making sure that that stuff is working. And then improving the integration in the desktop UI experiences, Nome Software and Plasmin Discover have gotten a fair bit of work in the ArabStream projects. The KDE guys have actually done a lot of it by themselves because KDE Neon has been exploring this for a while. For Nome, Canonical has been doing it upstream principally to benefit us and other distributions that prefer the Nome Software experience as well as because in the current Ubuntu LTSs they are shipping it as well. I realize that there's been a little bit of a kerfuffle related to this in the Nome community but as far as basically everyone I talk to, Canonical is at this point saying that the Nome Software experience is something that they want to preserve and enhance out as they can. Provided upstream is okay with it. So we'll see how that goes. So here's kind of where we are now. SnapB has been in the Fedora repository since Fedora 26. I am actually fairly aggressive about updating things as they go as long as things still compile, they get updated, they get tested and updated. One of the things I'd like to do in the near future is if when Fedora CI becomes like not broken for me I'd like to actually add some smoke tests and basic tests for the entire SnapD stack to execute for package builds and updates. Don't know how that's going to happen anytime soon because of some of the other bits related to that. SnapD and Nome Software integration, the Snap Store is an extra source. It works the same way you do when you're working with flat packs. Some Snap specific features, channels and interfaces and things like that. It has been available also since Fedora 26, but except with Fedora 31, things are in a wobbly state of affairs right now depending on how things kind of shake out over the next week or so. It will show up, it'll return, whether it's part of the Nome Software source package or I wind up being forced to do the terrible deed of building Nome Software all over again and shipping only parts of it, it will still be there. So at this point I can say it will be there, I don't know how right now. You can ask for it now if you want, but I'd also like to finish, let's, Plasma Discover integration has actually drastically improved since it was introduced in Fedora 28. It actually works kind of well. It's similar to Nome Software and I think the maturity level is about the same at this point. There's just a little bit of weirdness because it is younger and people aren't paying as much attention to KDE as they are Nome, which is sad because that's what I use. But Snapcraft is still the problem and we still don't have it as it turns out it is really hard to add new backends to Snapcraft. It is a massively complicated piece of software that does really crazy things to make it possible for you to not have to rebuild everything in order to make working snaps out of stuff that wasn't snapped in the first place. It's something that we will kind of get to but I don't have the bandwidth right now to do it and Masiek did some work actually in the past couple of weeks to try to get at least it working sort of in the copper for raw hide. Do you want to talk a little bit about that? Yeah, so this basically started us be trying to run Snapcraft in large natively without installing Snapcraft as a snap which turned into a larger crusade to get it working for Dora because why not, right? Yeah, it's kind of hackish. The checks are disabled. They managed to make all the unit tests working so there's that but it allows you to log in and push the snaps and basically just do some basic operations. Still if you build it's not really running the build natively it's trying to launch a multi-pass or an XD under the hood so that's still a problem, right? But yeah, we can try it and see how far we can get to that. I really don't know too much about this beyond like the, I decided to kind of give up trying to make the Snapcraft thing work now and I wanted to try to find a different path to getting Fidora application shipped as snaps for the benefit of the Snap using community which is increasing quite a bit. So the modularity tooling for all of its warts is actually pretty good at producing non-RPM artifacts that are usable by humans because they are doing this right now for flat packs and it works kind of okay, modular bugs with the runtime and extending this to produce snaps and allowing Fidora to publish them that way. I don't think it'd be that difficult to add and it would actually allow for a familiarish pipeline to releasing maybe simultaneously from the same based runtime kind of environment software in both formats for people to leverage because in the Ubuntu world you'll get snaps by default on your system and seeing Fidora produce content or Fidora deliver content for them to benefit from I think would be hugely valuable and raise the profile of what we're doing as a community. And our tooling is already optimizing itself around producing modules and so it will make it a lot easier to scale out building out snaps in the same way that we're trying to scale out building flat packs. So this is again, like I said this last year as well but a little bit tweaked with new information. Building, we want Fidora to be the best source for developers to build software for and that means that allows them to even if they're trapped in this Ubuntu world they can actually use the best source of software which I think is Fidora and be able to create applications with that and support them effectively and that starts with the base snap and actually Masiya had just told me a few days ago that we have now finally kind of got a definition of what is the expectation of what a base snap is supposed to include so I'm gonna try to see if we can harmonize that with what we expect in a Fidora base runtime and produce something that we can have either at the near the end of the Fidora 31 development cycle or at the beginning of the Fidora 32 one to have that rolled out and in place. The handoff to the infrastructure team for publishing and releasing does not mean that I'm going to go away as the maintainer of that particular piece of software that does that bit. I'm actually in the process of writing the tool and I intend to maintain it as part of working with RelEng and other infrastructurey people so it's not like I'm gonna throw it over the wall and then it's all your fault if it breaks. I'll still be around to help of course and of course this is all about producing snaps as an artifact for modules and then another bit is we want to also still get the snap craft bit there because it does provide certain things for people that are unique to the developer experience and one of the things that I have when I've been playing with the snap tooling snap craft I think is a major plus point despite how scary it is under the hood. It is supremely easy to put together a piece of software as a well-crafted snap and ship that for people with the snap craft tooling. I'm not saying we can't do that also with the Fidora tooling but it is the native tooling and I'd like to also see that work well for producing software based on Fidora and then of course C Groups V2 which is now a thing that we're gonna deal with. Actually I should thank the container team for this because we have known about this for about two years and the change proposal actually made it was the final hurdle to push it to get work done on it. So when everyone was complaining during the discussion on devil about how snapd would be broken by this I had talked to the core team for the snapd core team and we basically got it prioritized so that this is going to be fixed. The expectation right now when I was talking to one of the members of the team was that we should actually have it working by the end of the Fidora 31 development cycle. Probably before beta freeze, we'll have basic support in place and then by the end of after RC freeze we will probably have complete support as long as things don't go horribly wrong. Yeah, yeah and so right now the testing apparatus in upstream is being adjusted so that we produce a second raw hide in Fidora 30 variant that has C Groups V2 switched on and so that will be used to add to the testing of it as soon as the initial patches that add support for this land. So maybe I could jump in because I'm kind of sorry. Because you know that part. Yeah because I can start to work again on this bit as well. So we started with raw hide and then we moved to Fidora 30 because of different mount problems with 5.3 kernels in raw hide. So it's kind of like juggling. Well the loop stuff got broken again in the kernel. Yeah so it's because we're kind of like trying to exploit the kernel at least the mount API is a bit. We tend to hit different behavior scenarios where it's not really possible to fix that in an easy way so we have to kind of accommodate and find this stable kernel. So but also the switching to raw hide to unify C Groups help identify some problems with these snaps so that's all tracked and actually topic trackers which is discourse. Yeah that's being actually worked on. This is... Yeah also this experimentation with packet because kind of like the idea that we could bring because SnapDspec actually which is upstream is really close to the one that's used by Neil for packaging. There are slightly slight differences like one outstanding patch I guess. We have one outstanding patch and there's a couple of conditionals you have upstream that I don't want to have. Right. And we're going to try to see if we can get rid of those. Is this packet to snap or is this packet for the snap software? The packet for the snap software to the audience. So I started with packet, got some initial success got a kind of building and we'll see where we can move that further maybe provide like from get releases at least in some copper repo just know for... Yeah. And we testing. I used to provide in the early days of the integration I used to provide a SnapD get copper where I would just take snapshots and push them but it's a pain in the butt to do that by hand and so this might actually make it so we can bring that back. Yeah, so as well about Fedora Bay Snap so as Neil mentioned last week basically kind of the we have some decisions about what would Bay Snap should actually do this. This was also triggered by a request from community to create a Bay Snap as based on free desktop runtime which kind of know start post some questions about whether Bay Snap should provide some apartment profiles and how about confinement? What are the limits on what should be inside the Bay Snap? So we were less of integration points which is basically just multiple locations and we'll see how far we can get from that because... Right, yeah. Because we don't know yet. I mean, although our Fedora Bay Snap will not be the first Bay Snap that uses Fedora bits so did you get any info from Sigmund about that? No. No. Well, the only thing I could say is that the Godot Snap that are in the Snap store are actually all using Fedora libraries and tools because that's the stuff that they wanted to use. Godot. Godot. The game engine. Yeah, of course. Although as far as I know they use some really wacky build process to... Well, I mean Sigmund wrote it by hand so we already know it's weird. We already know it's weird. But it also shows that the Fedora stuff isn't incompatible with being in that kind of a confinement environment. So we already know that this is possible and workable. It's just that producing a standardized environment for everyone to consume is something that we need to sketch out and actually define. Yeah, so we're actually running out of time so maybe I'll just skip the demo. Yeah, this was just basically... I have a question. Well, you can ask your question. All right, that's my question. So is there going to be an open source? Like can we push these to a Fedora run snap store or to a distro neutral snap store that is not known by conical and proprietary software and will be monetized? So I'm probably the worst person to ask this question. Yeah, I'm the conical person. So my response would be, I will get back to you. Yeah, because honestly, it is a little long, but the slide with the halo is interesting to me for the same reason that Fedora and WSL is interesting to me, we can get back to work. More Fedora everywhere is good, but this is basically, we're putting Fedora into a new space for the good of users who are stuck on a new type of situation, right? And if we wanted to get something more than that, we needed neutral or Fedora-owned place to get it. And we're looking at putting flat facts into Quay as a bit random, but distro neutral source. So we're gonna ask you, and that could be the generic registrations required. Sure. So one of the things that I had previously talked to phenomenon people about, and I think you're kind of aware of it because you weren't there for a few of them, is that at least for development staging and all those kinds of things, it'd be nice to have a way to put it all there somewhere and then yes, publishing for lots of other people to consume, like how we do with the Dockerhubs thing, same thing for this, but it would be nice to... Docker providing registry, which is basically a way to upload something, make it available, but doesn't really mean that it has the same functionality as the full Dockerhub, right? Right. Firstly, I don't really see a reason for this not happening because it seems like an easy way out to solve this controversy, but hopefully we can make it work. I think the real problem at this point is that still the store APIs are unstable and so re-implementing it or splitting it out is still difficult and it is something that I do push for as I keep working with them and it is a concern that they do keep in the back of their minds about it. It's definitely something I want to see happen before we get to the Snappy Fedora edition or something like that, where everything can be booted out of the Snap similar in a similar fashion to how Ubuntu Core works because if I want to get to that world, I also want to be able to provide that kind of an experience for people. I already know if I needed to, how to change SnapD to allow us to do that. It's just a matter of having an implementation to use. So it's more of a function of time and effort and getting somebody to say this is what it's supposed to look like more than anything else because it totally can happen. Everything is, all the bits are in place from the Snappy side to make that kind of thing happen right now. It's just that we don't, the store is still churning API-wise and that makes it very difficult for me to be able to pin down or anyone else to pin down an open source implementation. There was one and the reason is there's a model for development or something like that. Yeah, I know it's like some kind of thing with a namespace and a number. Well, that or developing it in the open and then productizing it as downstream just like a recommendation for one way to do these things. I mean, you know, blast stones. But there's a seriousness that's really a showstopper for full support. I mean, what you're doing is cool and I'm not going to block it or anything but it's hard to get, certainly nobody at Red Hat in an official, wearing a Red Hat capacity is going to be interested in this at all in that state and as a community project with Fedora's interests in mind it is only mildly interesting to me when it is basically a defeat stuff into the conical universe and put conical at the center of a key bit for applications. That's not a future that I want and it's not a future that's great for Fedora. So. I mean, I personally would like to see something more neutral happening to even the existing snapshot implementation. But I can't do anything about it. We're only hope. I know what I'm talking about. That's a nice stage of my diversity for the last, you know? Yeah. Just speaking of flatbacks. All right. Let's wrap it up. Yep. See you guys. Thanks.