 Okay. There's a count-up time. So my name is Brian Axelbeer, and I'm responsible for the bad parts of this presentation. And this is, I'm Dusty Maeve, I'll be pushing buttons today. So this talk is bringing developers into the flock. And it is online and available, and there might get hub-account in this project space. There's a directory called flock2016developers and the URL, which we'll live on through right all of that up. So we kind of have two items on our agenda today. We want to introduce people to the atomic developer bundle, the ADB. And then secondly, we want to talk about why that is actually important to the federal project. So to get started with the ADB, well, what is the ADB not? So let's just address this up front. It is not the ancient development bank, and it is not the Android debug bridge. Names are really, really hard, and we have an open issue if you would like to have a conversation about the ADB name. But my one request is just move forward with us, run with it. We are not competing with Android. It's a very small project to Android. We're going to overpower them anyway, so it's not important. We're starting to step up. So what is the ADB actually? The project itself has given us this project definition, and I will read one slide to you, and it's this one. The atomic developer bundle ADB is a pre-packaged development environment filled with production-grade pre-configured tools that makes container developers' lives easier. The ADB supports the development of multi-container applications and it's different technologies and orchestrators while providing a path that promotes best practices. This is a mouthful. We also take PRs against this. But this is kind of the project statement and goal, and we come a long way. So Project Atomic is responsible for the ADB, and we thought about this and we were like, why are people actually going to do this? We started with this, why? And this is the stuff we came up with. We're targeting developers. Not all developers are like our Fedora contributors. They don't all necessarily want to run their own computers. They don't all want to have to think about how to do the system setup and configuration. They are using various operating systems. Not all of them are using a Linux or a Fedora. They're using complex tools as a part of the DevOps container environment. Setting up some of these orchestrators like Kubernetes or OpenShift is not trivial. And you don't want your developers spending a lot of time thinking about how to get the environment right before they can even do their job. The second piece is that it's removed into containers. The actual environment on a developer's PC has become significantly more important down the line. So if there's a mismatch there, it's harder to fix it when you get to production because we're passing entire blogs of data and bits down the line. So our goals are to give it easy multi-environment support, whether that's OS or language or orchestrator and container development environment, whether that's development model, whether you use a GUI IDE, whether you use CLIs, whether you use SSH into a box. And we want it to be production-grade, self-contained, and open-sourced. So what is all of that that I've just said actually mean? It means that we're providing a pre-configured virtual machine. We are leveraging a bunch of different virtualization providers so that it's easy to run. And we're highly integrating it into the host environment. We are using a project called Vagrant SSHFS, we're written mostly by this man, to do file sharing so that it's very cross-platform and zero-configured. We're doing a lot of environment variables in configuration for the developers. And then we've wrapped everything into an easy-to-use package that we call Vagrant Service Manager. So it's easier to show than tell, so we'll do a little show and tell. And I've lost my piece of paper that tells me what I'm supposed to show you. Okay, so the first thing is everyone can hopefully see and read my screen. It is a Vagrant box. So first I'm going to show you I don't have Docker and I happen to be running Linux, so Linux is Fedora is smart enough to go, would you like Docker? This isn't true for all developers. So I am going to first Vagrant up a box. And we're only going to boot, we're going to show you two environments, but I'm only going to boot one of them just because it takes a non-trivial amount of time and it makes me nervous to be staring at a screen. Just for the record, if you're not familiar with Vagrant, I'm doing a talk on Vagrant right after lunch. So if you're interested in more about that tool, come to my talk. Strongly encouraged. Lots of Vagrant is extraordinarily chatty. You kind of get used to that. So I have also downloaded a plugin called Vagrant Service Manager. And we have built into Vagrant Service Manager a lot of helper things like an end command to give you all of your environmental setup. So this is just providing us with our Docker environment variables. We have set this up so that it's trivial to eval. And now I've got a Docker environment. The problem is I still can't run Docker because I don't have Docker. So the answer for a lot of people would be use your package manager. If you're on a Linux, go hunting around in the various Docker repos. If you're not on Linux, what we've said instead is let's just make it easy for developers. So we have given them an install CLI command for our environments so they can install Docker in this case. They could install OpenShift. There's not a marathon as far as I know CLI, so they can't install that. But when there is, they will be able to. And it's just putting it in the path for us. Again, it's an evalable command, but it's just one line, so. And now I can run Docker. Thrill it. I have no Docker images. Let's pull one. I think by law I'm required to show you the minimal Docker example, which you'll see as soon as this is finished pulling. It would have been really embarrassing if I didn't have any. So, shockingly, I have now pulled Fedora. We can all do the standard run-up container, get a bash prompt, cat, etc. Fedora release, Fedora 24. So that's not terribly interesting. Slightly more interesting is this. I've written a small Docker file. This Docker file literally just tries to LS a directory. And that directory is SlashWorkder. So I'm going to build this right quick. I'm going to call it BexTest, which is extraordinarily creative. It runs in relatively trivial time. My laptop's a little slow. And so now let's run it. As expected, it fails. Because SlashWorkder is not a standard directory in Fedora, so there's nothing you can LS. Where it gets a little more interesting for the ADB, and we can do this on Mac, we can do this on Windows, but we're at block, is that I'm going to just map in my current working directory to be SlashWorkder in the container. Those are the files that it sees. Those are the files that I have. They are the same files. To continue to prove that point, I'll touch foo and run the container again. And you see foo. Why is this interesting? This is interesting because you are seeing me map a directory into a Docker container running on a Docker daemon that's inside of a virtual machine on my box. So what is it going on behind the scenes? If we go into the box itself, there's a lot of things mounted, but the most important ones are these here at the bottom. We're using a vagrant. We should probably do that. We're using vagrant SSH to do a fuse mount of the home directory off of my box, my actual Linux box, which is home Vexelby, and it's being mounted into the same place inside of the virtual machine. If I was on a Mac, it would be mounting users Vexelby into Slash users Vexelby. This way, I don't have to think about the fact that this is a daemon running inside of a virtual machine, potentially somewhere else, you know, in terms of on my computer. It's going to create the exact same pattern for me. As a developer, I now have no friction. This is not necessarily new, but it's now being done completely open source. It's being done with things that are within the possible control of Fedora, and we'll talk about that at a later time. The other thing that I'll show you before I let Dusty do a demo right quick is the service manager command, service manager, and I can't spell something, vagrant service manager dash home. Oh, I'm inside the box. Vagrant service manager, Kelly. We've added some other features to it. Easy ways to get to the IP address, version information of what's going on to control services like Docker or other orchestrators, restarting stocking status, to install all of these CLIs. This is an area where we're continuing to grow the project so that we can continue to remove friction for our developer audience of choice. And I think I will turn it over to you. Cool. We'll do a little laptop switch here. So, Brian just showed you, I guess, the CDK or the ADB. The CDK is the downstream name of the project. The ADB is the upstream name of the project. We just showed you running just the plain Docker provider within the ADB. I'm going to show you actually running the OpenShift provider. So let me see if I can get my screen set up. And we will zoom in on this to see if we can get you to see these things. So let me go here. So I brought up a machine earlier that is using or bringing up the OpenShift provider within the ADB. I'm just going to run through and show you the output of that real quick. I didn't want to run it live because it actually does go and download upstream OpenShift directly from OpenShift and run it. So from the vagrant up at the very top, here's the output that comes out. And if we scroll down here just a little bit, you can see where it actually pulls the Docker images for OpenShift directly from upstream. And in this case, we're downloading version 1.2.0. That's configurable. So like if a newer version comes out and the ADB hasn't been updated, you can actually configure it to go test out an alpha version if you wanted to or whatever else. So that's kind of neat. But it also prints out some useful information for you right here at the bottom. So it tells you the OpenShift console is at this location and it also tells you the username and password for a normal user. It also tells you the username and password for the equivalent of a root user in OpenShift LAN. And it also tells you how to use the OC command line tools to do the same thing. So let's check out and look at what the OpenShift console looks like. So this is what it looks like when you first approach it. And I will type in OpenShift dev and valve and now we actually have a web console into the OpenShift instance. And so with the ADB you can either choose to use like CLI tools or you could choose to use like the web console if you want to. So let me just run through the web console real quick and create a new project called Flock. So we'll create Flock and we'll also step through adding something to this project. Nothing too interesting, just an example of Node.js application. So I'll click on that. It actually has a get repo that it uses as a source for this example. So you could actually edit the get repo and modify the source if you wanted to. So it's pulling it directly from get. So I'll go ahead and do create. And it says application created. And so we'll just continue to the overview screen where it shows basically what applications you have that are running or configured to be running. And you can also click view log for this build that's going on in the background. So this is kind of the stuff that's going on that will create a container image that you will then run. So that's the web console part of it. Let me show you how to actually do it if you wanted to do it all via the command line. So Brian talked a little bit about the bigger service manager and the EMD command to actually set up your bigger environment. So I'll just run that here. Oops. I'm in the wrong place. Let's see if this works. So basically here are all those same variables that he showed you a minute ago. It shows us how to connect a doctor directly. It tells us how to connect to OpenShift if we want to do that. And it also tells us exactly how to populate our environment for configuring and connecting to that. So let's just run this eval command which will just set all this stuff up for us. And now let's run I don't know if I have okay all right cool. So let's do oc login and we'll basically yeah. So you see right here it actually tells you when you run bigger service manager EMD exactly what command you need to run to login and we had it told us that the username and password were OpenShift Dev and develop. So here I am, I'm logged in and you can just run oc UMI I think and it tells you who you are. And now we can actually switch project to the flock project that we just created so now I'm using the flock project on the local server or the server running on the ADP and now let me just look at the pods that are running. And you can see from that example application that we created there was a build that was started which is this pod down here and then there was another pod that was created and after that build completed. And so if we just do oc logs on the build you can actually see all those same logs that you were looking at in the web console over here. So this is pretty much the same thing. So as a developer you would have a choice between using the web console or the command line client it doesn't matter whichever one works. You know just another example of that is you can run oc and then you get routes and that will show you how you can actually connect to the service that's up and running. So I'll just open that I'll copy it and paste that into a terminal and you can hit enter. And now that Node.js application that we just started from the example get repo is up. The other way to do that is to go into the web console and click on overview and you can click directly on that link there and it does the same thing. So console you know CLI or web console you can do either one that's kind of the idea and you know one thing that we're doing with the ADB now is we're pulling those images from Docker with Fedora we could actually use the packaged version of OpenShift if we wanted to or whatever we wanted to do. So it could be an opportunity for us to test those bits that are in Fedora as well and send talks with the ADB project. So want to talk some more? Do you want to bring up the demo? Yes. So this is the demo slide. Sweet. So one last bit about the project itself. What is the future hold? One of the things that we're working on right now is a persistent storage. There's a lot of opportunities for contribution here. We are moving to Landbrush which is a private DNS system that exists on the box as opposed to using an external service like Ship.io which you saw in the URL. We love documentation and we are continuing to innovate in that area and strongly encourage people to help us there. We are doing tests and test-rode development. Every project meets tests and if you haven't done a lot of TVD this is an opportunity to join a project where that's being very heavily pushed. And of course the future service manager is going to continue to get a lot of extension. Actually we want to extend that further. We want to add more pieces. There's an embarrassing open bug right now that involves Florida for redirects. I think it's almost fixed but if not yeah, there's that. We're also working on things like Windows PowerShell detection so that environment variables especially under Windows can come out correctly. It's kind of random what you need for big style environment variables or set X style environment variables and the detection of that environment is rather challenging at times. And then we've got some Fedora client side dependency issues that we need some help sorting out as well so that's a huge opportunity for contributors to Fedora. So that kind of concludes the AEB talk. We didn't extend this to the full 15 minutes because we didn't want to just do a project presentation. That's terribly interesting but it's not why we're here at FLOP. So are there questions about AEB? For those watching the recording, this is a 300 seat theater with all seats taken. And no questions. Okay. So why should we do this in Fedora? It is kind of the big question. Like why do we care? It's a great project but there's a lot of great projects. So we feel like the AEB project really speaks to the four foundations of Fedora. Freedom Freedom Friends features in First because I'm talking and I'm not allowed to say them without looking. And so I wanted to kind of unpack each of the foundations of Fedora and why I think the AEB project makes sense for Fedora to consider doing. So the first one first of all, Frank is an extra slide that I should have related. Next one, Frank. Yes. Okay. Freedom. It's free software. That's an easy one. We already said it was open source. So next. Friends today Fedora is trying to attract more users. Specifically one of the focuses Matt mentioned yesterday was developer users. One of the challenges I think that Fedora has in this is that, A, we have two stories. Story number one is install our desktop. It's fantastic. And Fedora desktop is fantastic. But for some developers it's not an option today for them to run a Fedora desktop. They may be in an environment where they are required to run an alternative operating system. They may not be comfortable enough yet to make the move away from the environment that can be productive in with full-blown access time. That may not need to be the piece of friction between us and that user. So we offer option B which is download our virtual machine and then use it as your desktop place. So basically download Fedora VM SSH into it and now you're running Fedora but without having to reinstall your computer. That's not necessarily a whole lot less friction for a lot of the developer community. There's a lot of the developer community that these are fine options but we're missing a huge share of the market with some of this friction. So we looked at some other things. We have the developer of Fedora Project Power website which is a fantastic website. If you haven't gone there go there. If your language or stack or testing tool or whatever is not properly documented pull the repo and submit the patch and do it before flood is over. This is an important website that is critical that we provide the information that will help developers get started. The challenge though is that this website still presumes that you are sitting at a Fedora prompt at a machine and that you're willing to take ownership of package management and other challenges on your machine. We all know these things aren't hard but it's still friction between us and our potential developer user and developer member of our community. Fedora lost pipeline. Huge initiative got mentioned yesterday by Matt as well. Again, we are tools for our pipeline. We have lots of modules of pipeline. If you attended Miroslav Sufi's talk yesterday, you know that the COCO project is doing automated rebuild of every pipeline module and every Ruby gem like we're very serious about this we're very serious about making this work. But again, these things are predicated on the idea that you are sitting at a Fedora prompt which should be all of these that are using Fedora. And I have this vision where we can draw developers in a slightly less friction way. So features. We want to be first. We want to not be bleeding edge, but we want to be bleeding edge. We want to show best practices. Those are goals of Fedora that the project could align with the goals of the ADA. And I think there's a lot of opportunity here. The other thing is and I apologize to Langgood the idea is basically we can deliver a Fedora that's useful regardless of whatever that developer's email layer is. One of the challenges that a lot of people are looking for modularity to solve or virtual machines to solve is I want to be able to do something but there may be a library conflict or something else that's going to destroy my ability to browse the web. I can't have that happen. So how do I deal with that? ADB is one answer to that for some developers. Remember that developer Fedora project that Orga mentioned. This is what we talked about to like a Node.js developer. We say, look, first you need to get our desktop. Okay, that's some level of we've got to do a conversion. Then we want you to install NPM from our packaging. That's actually pretty easy. That is not a hard request when you've got somebody on your desktop. Then we want you to install all of your Node modules using NPM. Okay, fine. I've gone to a Fedora desktop and I've come from a Windows world. If I've gone to a Fedora desktop, I'm willing to buy it. I'm invested at this point. I'm cool. On developers, we then give a small sermon about why using NPM install is a bad idea. And maybe as a Node developer from another platform at this point I'm starting to kind of annoyed because I wasn't expecting that. But okay, you've got your reasons. They're good reasons because they really are very good reasons. I'll keep buying into that. At that point we then tell you, by the way in order to actually use these modules you've just installed, you need to reconfigure your environment a little bit. You've either got to add an environment variable or you've got to call things in the Node code slightly differently. You need to do more configuration. So like, we're adding teeny tiny layers of friction at every point here. And then at the end we go, oh yeah, not all the modules that you may be looking for there. So here's like more repositories and all of COPER where you can go start hunting for things that are going to be in line with what we've told you to do. But at the end you may have to bail and do a local and solve it right again anyway. And like, at that point I'm worried that there's a community of developers who can ultimately become great users and potentially great contributors that we've lost with just this pile of paper-cut friction. And maybe we can think about ways to solve that. ADB itself doesn't solve that but it may provide us with a model that we in a Fedora project can grow larger to solve that. This is what the Fedora Atlas page looks like. This is the Vagrant virtual machine download page. What I'm saying is today we can add one to this which is the ADB. And that gets us towards container developers. Tomorrow we can keep adding to this so that we can say, oh, you're a node developer. There's I hope that slides there. Yes it is. There's a Fedora node JS that you can use. Here's why you need to think about our node JS environment and what it's going to do for you and how it's going to translate into production and why it's better tested and better integrated and going to work better for you today. And so we turn those five friction commands we hope into something that's what a virtual machine provider that you used to is a lot of developers do use Vagrant and it just works. There is no step forward. Like the friction becomes a whole lot less. We can pre-configure the environment we set up. Eventually we will have a node model but until then even then we don't have to give the sermon because if they want to do a conflict it's in a VM that's just being used for node. At that point we're not destroying somebody's virtual, you know, their email there. Can you step back for one second because we've marched over something that we said earlier. I want to emphasize this. You can still use your Vagrant host after Vagrant. Neither of us happen to use a project called Eclipse which is a fantastic graphical user interface IDE development environment but Eclipse also works with all of the ADB and it can be, what you were saying here, we can build these boxes, we can help you continue to use the tools you're used to while we're trying to show you options that are available in your future. So first, support advancement. There are things that Fedora does really really well. There are a lot of other projects benefit from. There's a reason it's not just the Fedora operating system it's the Fedora platform. It's a way to do it that accomplishes. One of our challenges, for example with ADB is right now the self contained box is very large. Today we're building on a CentOS platform. CentOS gives us a lot of ability to build things. They have a SIG system that's similar to our SIG system in Fedora. It gives us a lot of opportunity to put in the code that we need but something as simple as solving our size problem that's going to require us to go through and basically start repackaging the core of CentOS to reduce its size down. This is an exercise Fedora has already done a lot of as part of the atomic post project. So, Fedora bringing this in is actually going to be able to contribute back to this upstream by going, look, we've kind of already started to solve their size problem for you because we have innovated one thing that we find ourselves doing a lot in the ADB is, oh we need apps it's not in CentOS ok, well our SIG lets us package it ourselves and get it and use it. So then we have to go through a packaging exercise. Fedora probably packaged it last week. Like we can rely on Fedora and Fedora can contribute back in this way and everything moves forward in a very nice cycle. And ultimately we want to drive people back into Fedora. Packaging of ideas as was mentioned Fedora moves fast, the ADB moves fast moves synergies. This is the last slide. So, this is like the discussion part. Does this make any sense? Am I crazy? Is this a good idea? Don't answer both of these questions. Yes. Please don't answer them all yes either. But this is the part where you have to talk about Fedora's work. So, what's the next step then? Since you're all in agreement I will put all of you down to help us build this. I'll get you all enrolled into the Fedora Clouds working group. But no, in all seriousness the next step is to kind of take this to Fedora Cloud because that seems to be the appropriate working group. It seems to have passed the sanity test. So to have a conversation in cloud cloud is working on some related initiatives. They're looking at something called Project FAO Fedora Atomic Post Fedora Atomic I think I have a few to drop for those of you that is Atomic Post and OpenShift. This is kind of related to some of those things. So, we'll talk to cloud. Hopefully some of you will be encouraged by this talk to want to be part of this. You can even join the upstream project or I encourage you to become part of the Fedora Cloud Conversation around this who will be starting. There's some links here. There's the slides again. But the ADB project can be done on GitHub as well under the project Atomic Namespace. It's the ADB Atomic Developer Bundle and yes, names are even hard with GitHub projects. So, please consider that. And then lastly, you can look at our homepage projectatomic.io So, let's open there even more questions. At least there's a lot of smartness. That does that take a lot of time. Did we talk for more than 20 minutes? Yes. That should accomplish. Bye.