 Okay, cool. So the next session is building Debbie and Jesse for Microsoft Public Cloud by Martin Zobel-Ellis and Steven Zarkis. Hi, everyone. As you might have followed during the last year's Debcon, there were questions on the Debbie and Devel mailing list asking about support for Microsoft, Debbie and images for Microsoft Azure Cloud. During last year's Debcon, I gave a short introduction on what we plan to do and this is more or less a talk on what we did the last year. So, it's loud. Is anyone not familiar with what Azure is? I know we're running low on time, so if there's no hands, here's a slide on that. Basically, Azure is a fast-growing cloud, so if you haven't used it, you know, it's actually pretty neat. It's one of the big three with 26 regions and three of those regions are local regions like Azure China and Germany and one for US Gov. We support all the major Linux distros, including Debian 7 and 8 and we started supporting Debian late last year and it quickly rose to one of the top Linux distributions, top three in Azure. Obviously, there was a lot of latent interest in Debian, people waiting for it for quite a while. We now can say that we have a third of the VMs in Azure running Linux. I like to say that a few years ago when we started, it was 0%. Now we have a third. Maybe next Debcon, we'll have a bigger number for you. It's definitely a popular project for us. We can probably move along and if there's any questions about Azure, I'm happy to take them afterward. So who is involved within the project? From within the project, I'm from Microsoft. From the project, this is Bastian Blank, Alexander Wirt and me and it's from the Microsoft site, it's Steve, it's Josh Paulson who had been in Heidelberg last year and Daniel Sohl, lately doing the work on the Azure Linux agent. So what have you done in the last year? We effectively started first doing a build host for building the images and upon request from Microsoft, we set up an internal mirror network inside Microsoft Azure using Azure part that's called Traffic Manager. It's some sort of load balancer. So we are having two mirrors per region behind a load balancer and from wherever you connect within the region, you will be directed to your closest mirror. So we have one URL in all the images that pointing to Debian Archive Traffic Manager.net and this mirror also got recently added to the Debian Mirror's list as it's also reachable from outside Azure. And we set up quite a bit of monitoring infrastructure. So we see if the build pipeline is broken or if the mirrors are broken and so on. So we set up that infrastructure. The build host currently is doing daily builds of VZ, Jessie and Stretch and we are doing daily uploads into public Azure. Why are we doing the daily builds? Because we want the latest security packages or package from security Debian Arch installed into the images that persons boot up. There is a possibility to boot up older images if you are interested in that. Speak with me or speak with Steve. We can explain you how you can boot up older images from a few days before that. Then there is a release process for uploads to those three, VZ, Jessie and Stretch and Steve yesterday worked on also getting the K3BSD images not yet working but we are working on getting K3BSD images as well. And for the build process we are using Jenkins as job builder and make all the log files for the build process we are doing publicly available through this Jenkins job scheduler. This was one of the requests that we had from the trademark team last year. As I said, Microsoft wants routine update traffic restricted to Azure regions. So persons having an app source to Debian traffic manager dot net, Debian Archive traffic manager dot net get those traffic into their own regions. You have two mirrors in each public Azure region. Why are we doing that? We are first taking, so if a mirror push occurs, we are first taking out the first mirror, doing the full mirror run, then switching the mirrors in the load balances, doing the second mirror run from one internal master mirror and then we have both mirrors in the Azure region public on the new mirror pulls. We are currently getting pushed from the Debian sync proxies, so we are usually quite up to date. We are doing that for the main archive and for the security archive. Currently, we only have AMD 64, 32-bit and the source. Why are we doing the 32-bit? Because sometimes persons want to run multi-arc with 30-bit closed source software on their images, so we thought that is a good idea to also add the I386 and as said, 26 regions plus the master mirror is about roughly 25 terabyte and we are, as I said, we are running those mirrors with a slightly adapted version, so how we are pushing the mirrors. There was a lot of internal discussion when we started about which process to use for building the images. There was either the possibility to use OpenStack Debian images versus the Bootstrap Reset. We ended up, because we wanted images quite fast, being available to the community, so we took OpenStack Debian images because I was personally already doing building images using that tool for the OpenStack setup. I tried to do it in the past year as a DSA member, so it was used to that script. Then Bastian did a lot of work on the packaging on the Azure Linux agent and uploaded new versions of that into the archive. We are currently still with 2.0.3, is that correct? 2.0, well, yeah, so we just upgraded 2.1.3 and the other ones were running 2.0.16. We have a couple branches. We also currently work on getting the main provisioning done by CloudInnit, so we will hopefully in future switch from currently we are provisioning the images using the Azure Linux agent and hopefully for a seeable future CloudInnit will take over that part and we only do the scripting part using the Azure Linux agent. The software, as I already said, we are using Jenkins for building the images. There were some problems with defining more or less static IPs in the ISC DHCP client package, which where patches were available, even in the BTS, and we were able to convince the release team to get this patch accepted for Debian 8.2. Thomas was recently so kind to merge most of our patches we did for OpenStack Debian images back into his script and we probably will, we already discussed that I think two days ago, that we probably will extend that script a bit so we can actually define whether we want to bootstrap OpenStack image or if we want to bootstrap Azure image. And also as an additional result, when we started the mirror network was the persons behind doing all the mirroring work were mostly missing in action and as one result, Bastian is nowadays working on the Debian mirror network during his paid work time, so he invests one to two hours a week into adding new mirrors, having the mirror list up to date and so on. Besides Donald Norwood, I think, who is also the other person on the behind the Debian mirrors list. Yeah, we had quite a lot of discussion after we were more or less ready to publish the images with the Debian trademark team because Microsoft asked us if we could please speak to the Debian trademark team that we are officially may use the Debian trademark for the images and that was sort of a longish discussion which resulted in me publishing, me and Bastian publishing what we have done so far on the Debian cloud mailing list. And then one of the outcomes of that discussion is that we want the images being built on the Debian CD, Debian images, however it will be called in future team and I spoke with Steve McIntyre recently and we will move to the Debian CD image master machine to build our images. So yeah, bullet number two, along with cloud and support which is mostly there and system out of integrated with Debian, we have we've pretty much completely rewritten the Azure Linux agent which does a whole bunch of other plumbing, we can go to that whole another talk I think but that is another component that Microsoft supports, it's up on GitHub. And then the last item is this new thing called Azure Stack which is currently in technical preview and you can think of Azure Stack as your own personal Azure region. It's an on-prem version of Azure running on top of Microsoft Windows, they're using server 2016 for that and it'll be released later when it's ready. But it is, in other words, you know, we have 26 Azure regions and you can create your own Azure region in your own office or your basements or whatever you want using the same protocols and APIs that you would provision VM onto Azure with, you can provision onto Azure Stack on the on-prem. So look for that later this year. And Thread images are newly built now with cloud in it doing the provisioning and just Linux Azure agent doing the scripting behind that. You should also mention on the Azure Stack side, you can use the same image as well, so it's compatible internally and externally. In terms of protocols, as long as you're using the right version of the agent, you can basically move your VMs back and forth. Yeah, contact all of us, the guys working at Creditive and the persons at Microsoft behind the whole Debian Azure images are reading the Debian cloud list and following that. So if any questions occur, just speak up on the Debian cloud list and we are happy to help you with the technical answers. If those images are, if those questions are more in, well, I have problems with in Azure, you should probably just use the Azure support portal and speak there. Yeah, that's mostly. Thank you. Is there any questions? Good talk. Hello, it's really good to see this work. I used to be in doing similar stuff at Google and it's great to see that it says sort of spreading to Azure as well. And I'm wondering, did you, when you were comparing open stack Debian images in Booster App VZ, which both Azure and Google currently use, sorry, Amazon and Google currently use, I totally understand why you went with the one you were more familiar with. It's definitely a good way to get it done faster. That makes complete sense. Did you find any other differences that are worth noting between the two, like in terms of one being better for certain purposes or the other being better for certain purposes? We were internally discussing that and I think Steve is even still taking care of the Booster App VZ patches for Microsoft Azure, Debian images for Azure. We could probably also switch to that script. It needs a little bit of work, but I was actually written for Booster App VZ, but I was overruled. Because I'm the author of the script. I wrote it in only shell script to make it easy for everyone to understand. So the thing I did is like 600 lines. It goes from the top of the source to the bottom. And so I think that's the main reason why they use it because it's probably easier to hack. And then in terms of features, I don't know the other one well enough. Any other questions? Okay, then let's thank the speakers. Thank you. I would like to also encourage everyone here to also participate in the Debian Cloud BoF, which is taking place at Menzies 12, around 4 p.m. to this afternoon. Then we're off for lunch. See you later, everybody.