 Yeah, James Bromberger who already yesterday talked about how AWS can help Debian will now talk about Debian on AWS And yeah, thank you. Cool. So firstly, this is the both session So that's why I said everyone come forward and we'll try and just discuss because basically so far I've obviously grabbed Ingers as script and we've been generating AMIs and we've been keeping it as base But there's been a couple of ideas that have come up a few of these we've discussed on the mailing list on the Debian cloud list But it'd be great to get some feedback in the room and some ideas back in the room because We don't have an official cloud team on Debian. It's kind of this. We are the cloud team. Thank you. You've come along You're in the group. So I had a bit of an agenda that I wanted to go through a quick Sorry the current status of the AMIs on on AWS and obviously my talk now I'm actually talking as a Debian developer not as a native rest person. I'm completely above the hypervisor here Lifecycle management of those AMIs I deprecated a couple of the old dumb squeeze or this old squeeze release six oh six about two three weeks ago The additions that we've got on there, obviously, there's a base image right now security and then any other items that come up sound cool General nodding cool So current status we have base Debian AMIs in all regions and including gov cloud So I've managed to find someone who was good enough and kind enough to sponsor us taking that image into the Ita restricted gov cloud environment. Obviously, I can't push that there myself I don't have access not being a US citizen and and I guess Jimmy would you like to push the A mind? Yeah, yeah, yeah, yeah as a politics It only contains Debian main packages plus the SS SSH root resize user data Execute scripts in the root file system. Well, yeah, I said that but no cloud need so we all know this issue right now And we have that question around whether cloud and it should be pulled in from back ports And if we do that whether or not that means we should have back ports in app sources or app sources list D by default We configured for HP dot debbing net. We're not doing a full back to a cloud front of debbing dot net But HP dot debbing net for most regions is actually pointing at cloud front So it's a zero-sum game. And if we as Debbie and want to ever not use cloud front for The CD enter to access packages, then we obviously can change that outside of AWS We also don't have any of the software development kits. So the libraries the boat with it Although Boto is in there. It's an odd. Well, actually it's reasonably up-to-date. I think it's somebody look today We've now also got SDKs for Node.js for Java for Ruby, I think it's about six or seven SDKs that are available. I think Boto may be one of the few ones that are on there There's some older pearl libraries on there some older client tools in fact S3 CMD, I think might have a bug in it that I was Persisting to the maintainer saying we need this sort of three-line patch applied because it's gonna be an issue And so we've got a bunch of questions as to what should actually be in them So let's go through that What do you guys think about Cloud knit how are we gonna handle that? Microphone not working. I think you should I think you should install it But if we install it then we obviously need to maintain it and we need to make sure that it's correct for any security problems that happen As long as it's in backports in backports. Yes So should we package pin it to backports? So it's the only to pin it you just need to install it and as long as it's installed It's going to be upgraded automatically if it's if you have the app source list What if there's anything else in backports that supersedes what's in main? It's not a problem. I don't think it's not a problem. No only upgrade packages that are already installed Okay So if from backports from backports specifically Cool, so what do we need to that just an app sources line and then in the Install script. We just installed back cloud knit. Do we still consider that to be a Debbie an image? Backpots is official now. Yeah, does everyone else agree with that? Yes. Yeah Cool, so we could do that for the next build that we do of the images That actually solves a whole bunch of things and brings us a little bit more uniform And would you guys do the same thing? Maybe if I put it Yeah, okay What? Why do you could you guys switch to cloud in it at some point? What's the what's the blockers for good compute? Right now there are Right now Google computers not willing or Google is not willing to sign the License agreement that you need to sign to submit code to a canonical to include in cloud in it so we would have to have a special we would either have to change that agreement that we have to sign or submit the code in some other way or Or for for Debian So yeah, we're working on getting code out there whether or not canonical takes it though And I think the main question is whether Debian would be okay with having a cloud in it that has code in it That's not in the upstream cloud in it and that might be okay. I should also clarify We'd be very happy for them to take the code, but I mean the default license would of course be their default license of GPL V3 We're happy to take the packages and obviously take patches and be applied to the patch on on package create So that's one option. This is you know, maybe the right right next step for us is to take our Get some changes out for cloud in it to make it support Google compute put it into Debian and then worry about the canonical problem later Yeah, yeah Okay SDKs client tools, etc. Now this becomes an interesting one that obviously the SDKs from all cloud providers Updated pretty regularly new features happen and a lot of users want those features And I think we were talking earlier about things like being able to write to object storage and stuff like that We have a lot of Amazon tools already available. So I mentioned s3 cmd boat. I was already there But do we want to be adding in additional stuff from a vendor repository into the Debian cloud images? My thoughts are potential But then it would be significantly different from Debian Because it's got vendor PPA for one of a better expression of in that base image Not all obviously not all instances that start on the cloud need these tools But the fact that they're installed and not used might not be an issue. What do people here think? so the Personally, I'm happy with the images as they are but they are tools like for example Glacier SDKs to talk to Amazon some cold storage That's not available in in in any of our AMIs right now But do we want that and this is the same question you guys have got with just I would argue that your customers are probably crying for it Whether like whether they say so or not But there's there's two options though Do we put it into the base image or do we make it trivial for them to bootstrap to get to that point that it's available? Will you put that in Debian main? Yes these tools that would that I would like to then do it in main I'll put it to seed and then after 10 days I'll put it to backports and then problem solved. Yeah So we I like backpots. I did we channel everything through backpots yeah my understanding is that's the only way to get the The update rate which we yes, I don't know if everybody else Concurrs, but my impression from the process is that if you want to upgrade your tool upgrade your tools every couple months With new features and functionality you have to go to backports when I these tools I think we should have in main Standard anyway because I know these SDKs are very useful for me for my laptop. They would be old. Yes They would be old. I mean none of us are going to deprecate our API's at a rate that that the The tools that were packaged, you know three years ago I'm going to stop working and not be useful to some degree It might not have the latest greatest thing that the customers are going. Oh, nice shiny toy. We want that Okay, cool It's kind of set of AMI's so we currently have EBS AMI 64 bit and 32 bit power virtualization And we're going to add s3 AMI's as well I started working that about two weeks ago. I hit something and didn't manage to get back to it Couple of interesting questions here. Should we drop 32 bit? We have multi-arch. Yeah. Yeah, Dave. Can we go back just one second back one? That was one second I'll be here all week this I apologize because this sort of breaches into some of the stuff that we're talking about Earlier, which was like how can we copy thing like it was the gcu till problem Can we copy code from other packages and put it into our package? Is that more acceptable and back ports than it would be a main? No Yeah, but but newer versions of packages are by definition of back ports more acceptable Hmm as long as you make sure that when you have back ports included things are relatively coherent and Working if you include back ports and and you pay attention to security fixes. Yes, your team doesn't Yeah Okay So back to the 32 bit question. We have multi-arch support in wheezy Is that good enough that we don't need 32 bit? Images Someone has an opinion. Come on for many work load 64 bits is all right though if you run pearl or PHP the problem is that it takes twice the amount of memory. Yeah, so for some PHP users 32 bits may make sense though. We have also coming soon the X32 architecture which will be a partial architecture that might solve the problem So you we would run in 64 bits Together with some 32 bits user land. Yeah, which still has the eight registers and whatever in see in this So that's a Jesse here a problem. So it's going to happen But like when Jesse is going to be released not before perfect and in so what I would do if I were you would Be keeping 32 bits for Debian until we have Jesse and The X32 partial architecture sound sensible everyone agree There is no guarantee that there will be expert to ingest Yeah, if it happens. Yeah, okay Next one. So EBS HVM images so hardware virtualization Now if you saw my talk yesterday the API for registering images from a block device got updated so that now you can actually register HVM images No Yeah, not anymore Haha, there's a man who had an NDA So No, this is now going to be open and and available to be called from tools now eucalyptus obviously in the last 11 days hasn't implemented that yet Even the AWS EC2 tools haven't implemented that parameter yet as well. Obviously, they all of these will In the goodness of time But it does mean that we'll be able to actually get our WN AMIs up onto the larger instance sizes for example the cluster compute instances and the Graphics instances plus the graphics instances with the Nvidia Tesla cards and whatever else happens in the future with that family So I'm thinking that this is a yes But then the question also becomes should we do that for s3 backed HVM in 32 and 64 bit times 9 regions so I have a question if you do drop 32 bit and if you do Like if you don't keep everything go one of these other permutations Are they all going to be possible for a user who is so motivated to? Continue to create such an image with our method on and run it on your cloud because if so then if we handle most of the cases and make it clear how to do the official equivalent thing with Their use case in a different permutation that seems great for example in Google's cloud We only ship 64-bit images right now, but I believe build a beam cloud support I haven't tested it so much, but the support ought to work for 32 bit I'm not sure about kernel stuff, but we're going to allow arbitrary kernel soon anyway So yeah, I think the script should support it So like all of these things are going to be supported at the infrastructure level Yeah, somebody could still build it even if the community here drops it Yeah, absolutely. I think that the build script that Anders has got Should do all of the permutations that we want Please write patches put them in if there's if there's a permutation that you feel is that you're passionate about No, chat up on the mailing list and we'll talk about how we can do it. I Obviously have created an AWS account specifically for us as the Debian group to work in so I'll give you access to that You can test all of these images and and do anything you want So if you'd like to work on any of this, let me know Okay Life cycle management. I'm sorry. I should ask any other points of of the current images that we're generating I'd like to automate some of it because at the moment the way I'm doing it is I I Have a user data script which I've put into an instance and I put a spot bid in and an instance starts up and It installs The script from github it installs git obviously and then from github it gets the script runs the script and then it Terminates itself when it's so, you know, basically their spot bid is around for about five minutes And I do that times eight regions and they're all built independently locally and Yeah, that's what I need to sort of do that next step and automate that as well anything else we want to do with the The current permutations No, okay So life cycle management And and hopefully you guys will have something on this so I'm 606 I got rid of What two weeks ago or so I gave notice about the beginning of July, so I gave about three weeks notice I think I'd even spoken about it earlier in an earlier post in the Debian cloud mailing list Amis Generally from most vendors change over time A security roll-up means a new AMI which means a new AMI ID and the reason this is important is as we were talking earlier beforehand if it's embedded into an autoscale configuration or a cloud formation template And the AMI is no longer available Then obviously you need to do some maintenance to keep that going in the current way that the cloud formation works I Feel that we should keep 607. I don't think there's any reason to get rid of 607 because you never know in in three four five years time you might come back and say I need to go back to a squeeze image Does everyone feel the same that we should keep these old ones? Yeah So the then the initial next question becomes 7.0 to be other point release Typically at the end of the life cycle of an old stable The release team does a point release. Yes, so eventually your six zero dot seven will get deprecated Form security. Yes, but what if you wanted to start one up? You're desperate to find an AMI or an image to start up 607 in a couple years time given Yes, you know, you're not gonna get any security updates. Yes, but then why would you want 607 and not 609 nine? Yeah, so the lot the ultimate one whether it's eight nine ten whatever comes up We should keep updating to that at that point Yes You should move the sources to archive that the beyond org to be able to still keep updated Installing packages from the older readings, but yeah, you can keep it That's an interesting question though because obviously when the image is generated the sources list talks to the current Look, I guess maybe then does do we need to separate our archive from from the main distribution over time? We've done why have we done so up to now to conserve space to reduce mirror space for our kind mirrors that the take copies Yeah, if SSH key is enabled Here we go microphone coming Since SSHD is enabled by default on image, right? how Sensible is it to keep an image which is? Luckily to get insecure just a few months after it's deprecated by the beyond sorry could you say that once more time? How lucky is it? To have an image which is insecure a few months after the beyond stop providing security updates Well, it depends on how you launch it if you're launching it within a virtual private cloud Where there's no public access to that image then it's a resource for you to use Would you want a 607 publicly facing right now? Well right now it's probably okay, but in four years time You probably don't want to publicly facing but you do still want it launchable inside a virtual private cloud or with a security group That's completely closed because you've got something that you need to do to that image. So Do you have somebody to enforce that? No You you have complete control over whether you make it public-facing or not I think what we should do is we should advise, you know, yes big flashy lights This is an old release You should obviously, you know, launch this in a secure manner I would be against forcing some security Yes Or some security restrictions on all the unsupported images because I can perfectly imagine that Some security researcher for example wants to use this old image as a part of honeypot or yeah part of Even research how many attacks are there on absolutely just because we stop supporting You know squeeze from from security updates doesn't mean people to stop running on the internet So we keep them verbatim as they are good they can't hear you on the stream So Coming to the bottom 7.1 a so for those that didn't see obviously we noticed When just after a couple days after 7.1 came out that we hadn't Re-initialized the ecliptic curve cryptography host key, which is new in 7 With open ssh 6 was that or newer anyone? familiar And so we generated a whole heap of new AMIs and I just went for oh, it needs a new number. We need this out there quickly. Let's make it 7.1 a and obviously that'll become 7 2 when we do the next point release of of wheezy I got rid of the original 7.1 because the time frame between the two was three days four days I got obviously gave it at what two weeks or so. I've noticed before I did that But I haven't got rid of seven zero Should we now following following? Sorry Should web. Yes without the B. So let me let me take another that should we Now it's it's are we from the rule we had here where we said would keep the last point release of old stable Should we also keep the last point release of current stable with some window as we migrate through so it's seven zero now useless Yeah, general consensus Is it confusing to the customers it seems to me I would be if I were trying to figure out which Is I want I mean seven and six I can kind of wrap my absolutely but having both of these to be a Debian insider to figure out The difference between seven point one and seven point zero. I Think I know the biggest number wins But I think I think getting rid of seven zero would make it simpler because less choice is easier to make a choice Yeah, that's another data point from Google We haven't figured out like a proper deprecation lifecycle for prior point releases of six and seven But the I mean the API services, I think all of them right now and and the Web interface list you I think choose all of them But certainly defaults to the newest and the command line GCU till only by default Unless you use certain flags and shows you the newest six and the newest seven. Yeah, only yeah So the two ways that we're distributing these AMIs through marketplace and through our own Amazon web services account The marketplace has been updated to be this six or seven and seven one a That's all you can see you can't see seven zero anymore. However, we've still got seven zero in our own account So what I'm proposing is we we take that away from being marked as public Which is the same process I did for the others I I took away the public share so that nobody could actually launch them and I waited for someone to scream Nobody screamed so two weeks later three weeks later, whatever I removed those AMI so they know we're no longer there Because we will need to do management of this over time There's a large amount of storage being taken up by all of these times eight nine regions now And obviously more to come over time that we're gonna have to to be able to manage this in some some fashion especially if we do ever do some of the next points which are coming up such as Other flavors of Debian that we might want to do or blends potentially So general consensus was drop seven zero. Just just one more check on that. Yeah, cool I have a small comment now, please if you want to keep 60 Last yeah final just because somebody may want to have a honey, but they're why you don't want to have seven point Oh, just if somebody wants to play with it Good question. Ecliptic cups. Yeah. Yeah I think the likelihood is that most people are gonna be more interested in Getting the final version because honey pot isn't the only reason why you want to start up an old version It might be that you have some software that you've found that you need to restore from a backup and you need to take it back to 2010 So I think there's there's more value in in the ultimate old stable versus random other point releases Yeah, cool One of the back please specifically for seven point all yes So the same reason you want to keep to see six point all you may want to say we keep the seven point all forever forever, so some user can Get this one and maybe update update to seven point Let's say at some point with seven point five someone uses seven point zero Updated to seven point two. Yes again, also you mentioned that some people may want to use a backup and restore an application and They're probably not going to want to back up this two weeks after the distribution is deprecated It's probably going to be one year and then they said all dammit. We we don't have that server in house anymore. We want and AWS to restore data and I see where you're coming from but I also would counter that with The changes of from seven zero to seven one a being point releases The compatibility I think we generally keep there because as we said just in the pre discussion is The only changes that are going in there are security fixes and not major features So I don't want to litter us with 20,000 AMIs that we're trying to manage But I do think that that the most useful one is the Ultimate point release from every every release we had so if we could go back to five point What was our last five release anyone? Five ten five ten five oh ten So five oh ten might be useful. Obviously we need now support for the hypervisor in use here Which I don't know if we had a kernel then even that did it so there's interesting things if we wanted to do a Historical project and and if people want to do a historical project if someone here says they want to go and make a bow and a slink and a ham Back on here. Obviously you'd have to do some custom kernel stuff to try and get get support in there But that would be really interesting Maybe And in any case if you need software from an older point release you still have the snapshot that they can Yes, yes gives you every version of every package ever. Mm-hmm. So you can still install from that if you really need it 25 terabytes and growing Cool, okay editions So we've only got base images at the moment when we've put in a hundred percent DFSG compatible software Obviously, it's all done from the script. Everything is covered by the the licensing which we're happy with We said we should pull in cloud and it from back ports for base images. We've kind of agreed on that so far Should we have an image with boat or estuary tools another state of STK's that's kind of repeating what I was talking about before That's that is repeating what I said before isn't it? Yes, moving on security So here we talk about ecc Now when the ecc stuff came out I it was it was two o'clock in the morning for me I was a horizontal at the time and when I woke up at six I saw that somebody had mailed some the security team Which was great. Does anyone here who did that? No, it was great. The security team had been notified and I went right. Okay, so I'll wait for their response Okay, this is taking this I've had breakfast now Hmm, I'll go and start generating these images just in case somebody says yes do it And so I generated the images and they went it's getting up to sort of 11 a.m. Now I Might just start to roll this because we needed to get a fix out there So I don't know what our Relationship should be with security for Debian security whether we should just roll a new release And you're gonna have the same question that comes up as well because we have one or two little extensions like this Now we obviously want to keep these issues to a minimum We've said all along we want minimum changes from a base install What else should we do are we happy with the fact we went to 7.1 a we want some other process in future How are we gonna handle this and this is Jimmy I can see you searching for Mike Like although we didn't have that particular issue do some of the weird Right here right here type You saw that Yeah, right But like even even with Debian images we already had to do a kernel zero-day security fix release There's been a bulletin about this. It's not yeah Definitely You know and I think for things like kernels there are days Then we need to also push the security team And see if they're gonna release a new package of the kernel into the security updates and just pull that into a new Exceptions to a minimum I think right because yes, we should fix this once Anyone else got any other ideas or questions on security with regards to the images I also mentioned earlier about deny hosts or fail to ban since we've got open SSH installed by default And open by default Obviously, there's security groups around to restrict it at launch time Should we have something like Fouter ban or deny host or some other Before that just talking about the dates. Yeah when we have a Debian point release and then just right after we have Security problems that is getting fixed through the security repository then If you're going to release a new image That's not going to be the point release. Do you understand? Yes, it's going to be an intermediate. Yes, so in that case It will be point release plus that update so I think it's very important that we notify our users of that and That we make sure that we all do the same work on all clouds at the same time So that raises another thing is that when our images boot They do not do apt-get update They do not get apt-get upgrade minus dy for all pending security at the point of that launch And the reason for that is because the instance from my point of view is the instance may be launching inside a Network where it's got no access to any archives So a it can't update and be it might not be vulnerable to it because it's running inside a walled garden effectively um Also, we don't install unattended updates by default do we feel we should have unattended updates installed No, I'm getting an open there. Yeah, so our The Google security team is very upset with us in general whenever we don't run unattended updates and whenever we don't Do everything we can to lock down the machine Yeah, and sometimes we fought back when we went to Debian from our previous operating system We thought back a little bit and tried to say hey by the way, maybe Debian should be involved in figuring out what the default policy is but I More I hear you talk and the more I hear our security teams talk I have a feeling that really the cloud's requirements here are just it makes more sense to protect users from vulnerabilities and so forth then to Then it like it makes sense to do something that the rest of Debian is doing even if That makes sense, you know saying so yeah, I feel that the standard for cloud Debian should be definitely different Right, we should be locking it down. We should have the night house We had it in our previous image. We don't have it now in our Debian image We should be disabling root login by default let users override it I saw you had a comment. Can we get the other microphone over there? No, you're okay Someone else got an input on this So I see that there are three parties at play here. There's the cloud vendor There is Debian and there is the user Now the from amazon's point of view we say we operate a shared security environment that obviously everything that the Hypervisor in the physical environment is done is taken care of by by amazon operating system patches the responsibility of the end user I think what what david you were implying there is that how much does Debian want to do on behalf of the user To pre-secure that environment for them in that model um But then that's not just a question for For cloud that's also a question for Debian in general on every other piece of infrastructure we deploy on I just potentially we've just profiled the risk to be lower When it's running on a lab in your home behind your nat Thank you for the water whoever put there um So, uh Other feelings anything else we should do So we like to know our hosts No, I I don't like to discuss policies because we the cloud have a specific need I really think it should be more broad inside Debian So where should we take it to? The discussion tech committee That going too high too big a hammer if you're just installing a new package That's fine. If it's changing the behavior of a package or its default configuration Then I think you should deal with the current maintainer of the package As much as possible and I think it's just install a package. I think we're just saying which packages should be available there Then I'm fine with that. Yeah Okay cool Excellent, uh, yes, please good the contents of deny host who will Put it together But there is a deny host sorry the contents of deny hosts who will put it together the package maintainer It'll populate itself by by um, whatever happens with regards to to access it to the to the host So there's no customizations required that i'm aware of but that includes a fail-to-band construction Effectively that's what deny host does deny hosts and fail-to-band are very similar I'll come from the time that deny host was a static file Uh, it generates doesn't it deny host is generated on uh out logs from Basically, whatever is hitting ssh and you know, it's hitting too many times depending what configuration you've got for deny host If it's hitting, I don't know five times a second or whatever 20 times and it will fail 15 of those for a period of time It will put the ip into deny hosts and it will be banned from accessing it Or is this an overreaction given that we're only doing ssh authentication with keys only Thank you. So there's there's a trade-off there. Okay um Other ideas. Here's the general stuff. What else are we not currently doing for the amis on debian that we should do Yes Come on Thomas. Give it to us. We are only publishing it on amazon Right, we we need a place where we publish all our dbn clouds without Request the need of having a credit card registered on whatever provider I could not test the ami because I don't have an amazon cloud account, right? Um, you're welcome to have a login onto the amazon shared account. I don't want one. You don't want one Okay, well, I still thank you for coming I'm joking. I'm joking. I would like to test my image. So I would like an account But that's a different thing But I think everybody should be able to download it and I think that these cloud images should be On the dbn repository If we consider them official Yeah, so I did start with the first one. I very first started doing this I dumped and g zipped from the snapshot into an s3 bucket. So it was publicly downloadable But that was all manual steps and they didn't get scripted That may end up being More than you want the I mean, maybe you only want the latest version of any of these things, but like I don't know we keep the latest every single version we that's ever been published We have kind of available. We deprecate them and stuff, but they're still there Um It's gigabytes upon gigabytes upon gigabytes of images for sure I don't know if you want that on the public repository Well for the dbn images, by the way, I don't think we like we should actually publicize this via the dbn wiki but like all of the ones that since since the official launch that we have Officially published to the dbn cloud project. I've actually shared publicly in a google cloud storage bucket And what I mean publicly. I mean you could just browse to a vhtp With no Accounts of a is that not good enough and it could also be put in the debian Servers if they want, I mean, it's uh, there's there's they're all freely licensed. It's uh, it's um, they're just tar balls The the google i'm sorry, but the dbn the google infrastructure is not the dbn infrastructure It has to be on the dbn infrastructure to my point of view. I don't mind that but is it of any use there The our images are basically tar balls of raw disk images. So sure yeah So yeah, that's what they are The data. We currently upload all of our images to google cloud storage I don't know if it makes sense, but we can easily give you guys those URLs we can You want some hosted on debian infrastructure as well, but they can go to both places. That's absolutely What i'm saying is like, I don't know if I want to decide the policy of what gets stored on debian servers, but Yeah, they can copy we can make it so that they can copy whatever of those files that they want Or push them because I want I also would love to have Those images Created at the same time as the dbn cds Which is why I think it would be best to have everything built out of the dbn archive Without access to provider because that way we can give the scripts to let's say stave macintyre If he's still doing the cds and then he would create the cloud images And they will be released at the same second when we do a part release Yeah, the only the only concern There is nothing about doing it within debian doing it within debian is good and Our images do not have to be built on the cloud. We're not doing that even but We release more often than the corresponding debian stable release because of various fixes like we've been discussing So It's actually reasonable to release a new image when a debian point release goes out But it's not going to be only then but I think it's great I think it's a fine idea to uh When the when the build happens uploaded to both debian and google cloud stores The second one is required for the adding it but it can go to both places. Sure Okay But my point was not that you guys at google upload it my point is to automate it within the process It's just it's just not just a cd release. It's more frequent. That's all. Hmm. Yeah Cool, we have five minutes left any more questions Any more suggestions any anything at all No, okay I'll throw it open to any questions about amazon or anything at all as opposed to just the amis that we've been doing and the rest of Stuff anybody got any questions they want to ask? No cool Yes, are they are they in a package in main? So no, this this is actually a really good thing. Um the tools The tools I think are universally useful that they should be installable on on no matter which platform because Just because an instance is running on amazon It might want to talk to google storage and vice versa. Uh, one of your images running on google compute might want to talk to s3 Um specifically we might want to take the images and the amis that we've all generated and throw them onto the storage on Each other's clouds and that might alleviate the question of it's not on debian's infrastructure No, but it's on multiple cloud providers and we've we've covered the the infrastructure that way Yeah Yeah, see better thinking No Yes And so I've got the more general idea about generating those images regardless whether they are on debian infrastructure or Google or amazon infrastructure So are we intending to as soon as we have cds? We we want also to have images and yeah possibly many Many formats like am i row these Whatever as google accepts whatever else. I don't know Yeah, I think so if there's a release then we want to on on all of the platforms as quickly as possible Then one of the other questions is at the moment we haven't generated any jesse images Should we start doing that and at what frequency should we start doing that? Uh, and and I had um steve come and asked me uh yesterday. Um, how about getting a cloud image that uses um, uh, system d How about we test yeah, how about we yeah, how about we test both of them and have cloud images for both I mean do we want to use that as a platform? Yeah on on any of the vendors, but obviously we want to generate am is which do this that we can then open up for people to test You have nightly builds for For di why not have night? Yeah We could do You like that idea thomas? Yeah Should do that. Yeah Well, no, we just need to script it We script it it'll happen Yeah, yeah But obviously I would suggest we probably don't push nightly builds through the marketplace because that's going to confuse our New users quite a lot. Wow. I've got devian 7.1 2013. Oh wait 13 12 5206 point something um Cool, so yeah, I think we should start to get some jesse images happening around the place because obviously that's somewhere where we can Fight some bugs and and fix stuff up obviously for the next release Any other questions? No in which case, please do me a favor and take a t-shirt or more Um, there are two boxes here of t-shirts. There is another box of triple extra large in the next room Only because I couldn't carry in here in the time that I had beforehand. Um, I don't want to take them back to australia Thank you everyone for your input. Um, please subscribe to the debian club mailing list Your opinions are of a huge value to amazon to google to all of our us And obviously we want to make debian to be as successful as possible for all of our users no matter how we categorize them Thank you everyone