 BCF G2 in the house? CF engine? No? Okay. Cool. So hopefully we won't bore you too much with the intro stuff since everybody's fairly familiar. We're still going to run through it, but we'll make it quick and then we'll start talking about what Provizo is all about. But first, we'll introduce ourselves. So again, this is our sessions on Provizo, which is a goal to sort of standardize vagrant-based Drupal development. I'm Patrick Connolly. I work at MyPlanet Digital back in Toronto, Canada. I guess I'm not a DevOps team, but I work there and just try to help teams create tools to help them self-serve their own infrastructure internally for our projects. I am Howard Tyson, Tizzo on Drupal.org Twitter and anywhere else I can get it. I work at a company called ZivTech where I kind of do a lot of the tech direction and work on a lot of our stack tools and have kind of been really focused on building out our hosting infrastructure and our vagrant stuff and making that as slick as possible. And so I've been spending a lot of time on kind of that side of things. So we kind of wanted to frame this with a little bit of history. So in the beginning of website development, local development was hard because you probably had to kind of set up all the different pieces yourself for LAMP infrastructure. There were endless screencasts on it. Lots of people back then were still using Windows before this kind of Mac revolution where everybody has a glowing apple if they work in tech. So you're probably doing it on Windows, so you just didn't. And a lot of people just kind of went in and used FTP and just kind of said, this whole local thing is too hard. So that was Bill O'Reilly saying, screw it, we'll do it live. Really disappointed after all that. Anyway, so then we started to build tools. We were the monkeys with the bone and that's the sort of tool that we built. And we called it MAMP and WAMP and ZAMP and it worked on my machine. This is a vagrant talk, so we had to have the obligatory it works on my machine slide, right? And you had Drupal running locally, but was Solar running, was Memcache running, was Varnish running, Redis, SSL, Selenium. There were all these pieces that you really needed that you just didn't have. And so for those parts, a lot of people still ended up just developing on production or on something like it because those tools just weren't easy to set up. And then there was vagrant. Welcome to the future. And so that's where we stand today. vagrant creates virtual machines under the environment. Hopefully you guys all know you can kind of provision it with any of those provisioners we were talking about, which led us to this rise of all of these different vagrant projects and all of these different machines. We can just run vagrant up and all of the stuff was working perfectly in rehearsal. And vagrant bundle installs all of our plugins. Vagrant has a lot of awesome plugins. We're leveraging a lot of them in the Proviso project and it builds your system. But this kind of led to this proliferation of lots of different vagrant projects. Kind of an insurmountable and daunting set of overlapping tools and people working on the same stuff. Oh God, there are so many tools and so many machines rising up in this flow where we've got the Drupal Vagrant project, Oscar, Ariadne, Oscar again. Quick start. Drupal Pro, AgerUp, DevShop, Drupal Lamp, the Vagrant DevVM. We've all been reinventing the wheel and we've all been doing things slightly differently but mostly the same. And there hasn't been a place where people have been coming together to start sharing best practices and starting to assemble sort of how is it that this community should be doing this? And what are we sort of trying to replicate? And I think there's sort of an upside and a downside to that because part of the idea with Vagrant is you can use your real provisioners, your real source that's going to be running on production to build your dev infrastructure. If you build and maintain your own dev infrastructure, the thing is that a lot of companies don't. A lot of companies have some sites that run on Pantheon, some that run on Aquia, some that run on the clients hosting. And so there's an awful lot of kind of shared stuff. And there was no way to collaborate and no space for that until now. That's the baby from 2001. Just in case you didn't get that running. So proviso was born. So what happened was a whole bunch of us that have been working on this stuff got together at DrupalCon Portland and started saying, oh, you wrote a little SSH plugin to automatically add your SSH key to SS agent to do the thing. So git would work. I did that too. Oh, yours is kind of better. Oh, but mine does this thing. And we started realizing that there was a whole lot of kind of overlapping effort. And we should kind of pull together and start coming up with ways to collaborate. So what is proviso? It's a community project to assimilate them all. Resistance is futile. If you've got your own Vagrant project, just come on board. So first off, more than anything else, proviso aims to be a community. It aims to start conversations and get us working in a place where we can start to assemble best practices and look at each other's code and start contributing to a common thing. Don't we have a community? Yes, we do. We have especially folks that are working on this kind of stuff. A lot of people hang out on groups.drupal.org slash devapp slash high performance. Those conversations aren't as active as they probably could and should be based on how much time we're all spending on this. But most of the stuff that's happening there is conversing not converging. We talk about, hey, I have this bug on my server. But there's no easy way to sort of replicate that issue to be able to set up exactly what your server looks like and say, let's make a tweak and benchmark in a way that all of us can kind of reproduce. All of us can contribute to. All of us can start to figure out what should a secure server look like? What should a high performance server look like? What's the performance implication of terminating SSL with nginx versus apache versus whatever? And just as an example, if you look on securing your drupal site on drupal.org, there's a bunch of pages, a bunch of sub pages on how to secure a server. And it's all words. It's not executable. And everyone's doing this when they find it, hopefully they're doing this on their own. Yeah. So the idea is it's code is conversation. So let's see. Oh, right. So the idea is can we kind of follow some of the more recent DevOps best practices of can we have code over documentation? Instead of having a checklist, can we have a chef cookbook or a puppet module that just shows you what those steps should be so that you can look at a working machine? Because if you're building a chef cookbook, or sorry, yeah, chef cookbook or a puppet module, that has all of those steps captured in it in a way that's clearly understandable. Both of those tools have optimized for being able to read and understand what's being specified in there. So that's sort of the best form of documentation because it actually will then run. And it's not a checklist that needs to be maintained, needs to be updated. And you know, you're not missing a step if it works, right? So the idea is if we can pull all of this in, this is such a sales pitch most of this presentation, if we can get all of you guys to come to Proviso and start pulling some of the conversation there, we can start to turn more and more of our best practices into community modules that we can all use and share locally and on our remote servers potentially. So how? This is where we start to get into the technical implementation of how we're trying to tackle this project. So Proviso is an initiative in addition to being a community. It's not a finished product. It is a thing that we are trying to get more momentum on and trying to get more people contributing to. It's not that we don't have code, it's not that we don't have stuff running. It's just that like how we get together and talk about Drupal core initiatives where we think something's a good idea and a lot of people are pushing on it, that's where Proviso is especially right now. So we're trying to work to find the best ways to share because sharing is caring. It's also a vagrant project. So the idea is that teams that need a vagrant development environment can use ours and we can again start to reduce duplicate effort with all of those fricking projects that we listed before that mostly set up a lamp stack. And then another thing is to make it accessible. I don't know if any of you guys have been following the Calamuna guys. They're this dev company that's been working on this project called the Calabox. It's very cool. It is a wrapper around vagrant and virtual box that gives you a one click installer for OS 10. They hope to have one for Windows eventually and then they use Node.js and some desktop-y Node.js packaging to build a pretty slick GUI. So it's kind of modeled after the lamps and the lamps and the zamps out there where you have this like status page that says whether Calabox is running, whether it's got engine X up, my SQL up, whether the SSH keys are installed, whether Solar is installed and running, whether WebRoot is, rating of happiness, it's maximal, you'll be glad to hear. And the idea is that you've got a list of local sites, you've got a list of your sites on Pantheon, you've got a list of the different tools. These are like quick jumping points for things like PHP My Admin. You've got commands so they have some sort of nice wrappers to do things like pull down copies from Pantheon. Some of that stuff is a little still in progress, but a lot of it works pretty slickly. And then the plan is eventually there's going to be a deploy so that you can actually then deploy sites that you've built locally on to Pantheon. Just to add on to that, the idea is like if you're not using Pantheon, they each of these panes, I guess they're looking to make it extensible so that like if this, you need an aquia pane, you work with aquia or there's another tool that you'd like to resurface in there. Yeah, they want to make it so it's opinionated but you can always extend on those opinions or like remove ones that you don't agree with. So the next big component that we need to solve that we're working on hashing out and starting to write code around is exactly how to make this part possible. Because how do we pull a bunch of people together if they don't have quite the same needs? You say tomato, I say tomato, you say I run Apache, I say I run Nginx. How do we allow all of that to live under one roof in one project? And our idea is to make sure that there are sort of individual pieces that can be turned on and off and kind of assembled with some sensible defaults so that you can piece together the individual parts. So you can pick your provisioners and you can pick from service packages. We'll talk about a little bit more of what I mean by pick from provisioners in a second to be able to tack on your own pieces and leverage mostly what's already in the community. So you'll notice that Proviso has both Chef and Puppet. Yeah, sure. I guess the idea of making it multi-vendor was I think kind of the original catalyst and it was basically stemmed from all our frustration where we're in the same room of the fact that we're only talking now because we're talking about how we're complaining about how we're not talking and it seemed like one of the roots of why we weren't collaborating on these things and these ecosystems around whether it's like how we're using plugins or little helper scripts was because what we all thought of is the big component, the provisioner, we were speaking different languages. So the thought was that it's very common in enterprise to, as a security measure, to choose a multi-vendor approach. You don't lock into any one. It seems a little redundant but you cover, you use different products and then if you need to swap out that's actually safe for you and it makes it simple to, you know, if things don't go in one direction with a product you have this other one that's ready to go. So the thought was we could take that approach with with this project as well and get us all in the same room kind of thing and in the same issue queues. Also, I don't know if you guys have all seen the To Do MVC site. To Do MVC is this group of people that took the backbone.js, backbone, the front end JavaScript framework. They took the backbone.js example, which was this little simple to do list and they started porting it to every other sort of implementation. So what we're kind of hoping is that we can get some other people that are involved in some of those other projects, that's kind of partly other provisioners, sorry, people that are using other provisioners. So I'm a puppet guy. Pat's a chef guy. We're still friends and we're hoping that some of you are Ansible guys or salt girls and that you can come and join us and that maybe we can kind of be the To Do MVC of provisioners where we have one set of sort of acceptance criteria. We have one set of sort of feature requirements. We have implementations in puppet and chef and Ansible and that way it's an easy place to go and sort of compare and contrast how this tool sort of organizes and assembles the different things that need to be built. So sort of if you go to To Do MVC you can go and look at the same thing, the same feature set, the same kind of front end built with Angular and backbone and Batman and all the crazy JavaScript frameworks. So the goal is hopefully as we continue to build out this multi-vendor support right now we've got actually right now we've got pull requests pending that get us all the way to to a lamp stack and with chef and puppet but we'd like to get we'd like to get more so that we can kind of be this middle ground for comparing and contrasting projects. Yeah so it also lowers the barrier to jump ship because right now if you have started to build a tooling around one and you're building that tooling on your own then just say you know just say you look at this you know this analog of To Do MVC and you recognize wow like it seems really more straightforward how chef is building this exact same thing and you now if you're using the puppet tooling then you can kind of jump the other and try it for a while and you're in a bit of a safe a safe zone where you're not like starting from scratch and having to learn how to replicate your full you know whatever you had before. So maybe I'll take a second to just mention I think we get to this later too but so one of the things that when I say like we have you know feature parity between all these between the chef provisioner and puppet provisioner and whatever else we include the idea of a big part of this is to have a common set of of integration tests that are basically testing the built stack and ensuring and we're doing this using using combination of Travis CI a tool that Opsco who maintained chef have created called test kitchen which is for like basically spinning up a bunch of test suites a matrix of a bunch of test suites and a bunch of different platforms and running building running the running the puppet modules or running the chef the chef cookbooks and then running final integration tests and making sure that you know it's memcaches available and apaches or apaches responding in a certain place so yeah it's you got you know that you have a this feature parity in between stacks and the idea is that we're testing this on every commit using by spinning up on amazon basically every time. So I think that that was automated testing from day one is one of our goals so just to elaborate on what Pat said so here's an example from one of our pending pull requests that that we've got tests that can reach out and run from to have Travis CI spinning up the amazon instances and you can see these are each of the things reporting back is it running on sentos 64 or is that sentos 64 right sentos 63 sentos 64 precise 64 bit lucid 64 bit and getting back all like results on all of those in terms of the upstreams we just wanted to comment on the fact that we're big fans of librarian both librarian puppet and librarian chef we're using that to pin all of our dependencies and to kind of enforce best practices where we're pulling from community cookbooks and modules and trying to force ourselves to either produce a new community module or cookbook or find one that already does what we're looking to do how many people here are using community modules or cookbooks primarily rolling your own primarily most of you guys that raised your hand saying you're using puppet or chef aren't doing either creating your own or using puppet or using community stuff um fair enough i don't think puppets doing very much for you guys i've just got a quick question um i saw you're talking about different distributions there are you talking about using the same golden images are you building those from a set set of scripts i mean where are those images coming from because that's obviously an underlying piece here right so um so the yeah so it's kind of people are having to package up the base images like there are there's a base ones on amazon that are basically kind of the stock sent os 63 image the idea is we're going from the very the very basic install and now you know most most most os maintainers actually put those packages out on amazon and they're kind of getting the habit of actually creating vagrant base boxes and providing them so we're not in as a community rowing them all on our own and uh michael hashamoto the vagrant maintainer actually wrote this school project called packer that's helping everyone do this and there's yeah that's kind of where i was going was because you've got like vwe and things like that that basically are scripts to they take an iso and build an image out of it yeah and i'm just wondering if that's sort of on the horizon there to include that that basically you've got it okay we're gonna if you're building everything essentially from packages you really want that absolute minimal system and that's usually the biggest problem is you have to make sure that everybody's on that exact same minimal system and if you have the script you guarantee that we built it from an iso to this standard yeah yeah it's uh and just encouragement everyone like that that's awesome that you just got up and asked the question so anyone else who has a question in the middle that's great um so the uh the as pat said the tests that run on amazon aren't actually running through vagrant really they're um provisioning from amazon base images and while it is kind of a golden image in that it's cloning the existing kind of amazon image which allows us to do it fairly quickly um but not anything is not much as pre-installed on that um it's pretty much a clean install there's not like a golden image that has to have a patchy and other stuff on it at the moment we're relying on base boxes for vagrant that have puppet pre-installed but i think we have omnibus the omnibus plug-in that'll um put chef on so that you're on the chef side you can have a really clean install on the puppet side at the moment we're still pulling a bunch of box you're still relying on an Ubuntu box that has puppet pre-installed at the right version which is um suboptimal um so uh this part gets hand wavy or um but uh at the moment we're just setting up a basic lamp stack because that's kind of our minimal viable product but the idea is that we want to ship with some simple switches that can say give me your best approximation of aquia give me your best approximation of pantheon so that we can sort of um reduce the come reduce the chances for having different variables right that's one of the big promises of ending it works on my machine is that you can have something really close to production we have lots and lots of people running on basically the same production um it would be really great if aquia and pantheon published um vagrant boxes turning over all of their configuration and secret sauce is probably not something that is easy for them um but uh but they have both people from both teams have been um forthcoming saying you know like we'd like to be supportive uh at some level and and kind of share so the pantheon guys especially have been really open the aquia guys have nodded at conferences and said they'd like to be at least um so we're hoping that we can get a little bit more support from them obviously we won't ever get it perfect because they've got some special sauce behind the scenes um but we think we can get it pretty close um having a really similar setup um and then the idea is that we're going to have some fairly human readable yamal component lists um that pull in sort of uh meta cookbooks and meta puppet modules which would be the only thing that actually lives in our project um so that you can sort of have mix and match things where um you mostly have the same Apache stack across several different kind of um platforms that were imitating or the same engine x stack um probably the same redis release could be you know the same redis version could be the same item that drops into a yamal list um and the idea is that we can have a space in the repository where you can add your own um we're still figuring out the exact best way to model that it sounds like lots of you guys are familiar with uh with chef and there's the idea of the run list which you can build dynamically and basically drop drop roles in that that are the different layers of the stack that we're building so the only thing that needs to be you know you just configure in the yamal what what are the what are the core set of roles that we want in here and we've got those roles defined in our in our project and just last night we hashed out how what the equivalent of that would be in um in puppet just to make it work in a chefy like way that that um that would jive with how we want how we see this this project later in yeah kind of a mix of some custom fact plugins factor fact plugins and some magic to make puppet pretend that it's a dynamic language um so yeah um room to add your own components I think is critical because I know at my company we use some tools that we've written to be able to make synchronizing our environments with our remotes really simple where we're running our own hosting we're going to want to be able to drop that stuff in and we're not going to be able to move from our own system which is on our github thing it's open source but we're not going to be able to move that to from that to the shared thing that we're not the sole maintainers of until we can kind of easily plug in customizations without forking um so that's kind of our kind of next big priority which is why we spent a much time last night kind of figuring it out so um this is where we transition to kind of a a section on imagining so this is kind of a bunch of stories of where we think proviso could be useful to people and hopefully we can get some feedback from you guys on whether this is the kind of stuff you were hoping to see from this project when you read our description and decided to spend 45 minutes with us um so um danger will robinson danger no will robinson danger that's uh danger will robinson with the waving arms there um so the first thing do you want do you want to take this one so uh the idea is uh platform fluidity is the first scenario um so the idea that you know the situation is you're getting ready to host on ubuntu 12.04 you've been developing for a while you've been developing locally with proviso um this is in the possible future where this is a success and people are using it um so uh halfway through the project uh client says that here linus indoors his red hat linux 5.2 can we do that uh and this isn't true when linus doesn't do this but uh but this is an enterprise client and what they say is very serious so in other words linus does say this and it is true um so with proviso the idea is that you can see which platforms are supported and tested at a glance by just reading the reading and seeing hey these are the things that we have tested on and that we have built this stack on and run these individual test suites different layered stacks um and you can actually go to travis and look at the test runs so even if you see that the build status is not successful right now or one platform isn't available you can kind of like you can go through and see all the evidence of maybe where that platform stopped being supported because it wasn't you know it was old and it was like lucid or something like that and you can see you know evidence of um it's very transparent it's not just saying hey we support this you can actually go and look at the tests that say what we support and if we don't support something what you will have to overcome um so sure um and that story uh that that hypothetical story of where a client says that linus insists that this one flavor of linux is the only one that he endorses um that that actually happened i was i was told that linus he takes money under the table from sentos and that's why that you really need to use sentos because he said that but you know client's always right right uh so uh i guess just a little more on what makes that possible like as i said the testing infrastructure makes it possible to easily at a glance look at this um but also the fact that we're using robust community cookbooks like we're not just using a custom cookbook that we built that applies for our platform most of especially in the chef community and more so in the public community um they are the cookbooks are very very multi-platform um sometimes that makes them very large some people have opinions about that but overall it's it's really nice especially when you're new and coming into this the fact that you can just you can swap these things out pretty pretty easily um it's still it's still a little rougher in the public community we're we're still getting there but it's more and more of the community stuff works so um yeah that's scenario one um scenario two is uh the idea of um helping overcome the idea of or deal with imprecise stack versioning so oops so uh just for example my sequel aquia is running 5.5.34 and you're running 5.5.32 on your local machine um a lot of people will look at this and they'll be like yeah it's all it's all uh 5.5 so it's all the same right so no no it's not so if you just look at the um like the the mysql change logs are scary sometimes uh so if you just look at a tiny patch release this is the this is 0.33 the number 33 patch release um you had three different versions of three patch releases just in between that thing that seemed like a small probably a small change um and this is the very top of the page here's the rest of the page and the all of these it's just like itemized bullet list this is one of the small ones that just go down for a long way and each one is a change that has happened internally in the system and each one of these represents a scenario where maybe something crazy is happening and you're seeing a little bit of a a difference between environments and maybe you'll spend a day trying to troubleshoot this um so these this is all the wild card variation that gets introduced when you're dealing with like slightly small pin versions or differences in in versions um so i guess the thought is that uh you um like in this example if you know um the standard version um that's available in the package repositories is one and you know aquia has rolled their own it had a slightly newer one um you don't have to make that compromise and deal with maybe all these big differences um the ideas we're working on this together uh there's we have an aquia roll and we've we've said hey this is important so we're figuring this out we're going to mimic them where this is important um and you know one person does this a few people do the work and everyone gets the benefit um scenario three uh is the idea of this could be a great opportunity to work together on tooling that makes this like not just a development environment but a an SDK for working in the Drupal community a software development kit so it like the idea that maybe it's we're talking about the idea that maybe this could become the de facto way of um of doing regular routine community tasks um so can we um can it be a standard tool to help us say file better support support issues um so you know traditional support issue in the drupal.org core queue my site's broken and some rather scant details i don't know what that is but i guess the thought is um you know wouldn't be great if the uh if we had one tool that we were rallying around and we could say hey could you just reproduce this in proviso that's kind of the bare bare minimum that will ask of you to get our full attention um and uh it's the current approach even if like you know a simple approach of just like proviso as a regular vagrant environment is you run you know vagrant up vagrant ssh um you do a quick drupal um and load in the views module and enable it and then you set a variable just say that's what it needs to produce the bug then go to this page and you see it kind of thing and now uh the person the maintainer follows this advice sees the bug and can immediately deal with it saves everyone time they're incredibly happy but we can even create some um some more tooling in the form of vagrant plugins that serve our needs um and uh that just essentially drive drush inside um so this is this is in some ways tangentially related to building a vagrant development environment but this i guess could form like the issue queues where we're where we're building this are a great place to have these discussions about uh building these tools um there's a you know also hypothetical uh could we create a standardized uh a vagrant plugin that helps us deal with bug reports in the community so um oh yeah that's out of place um so the i'll i'll just skip to the next one for um easy for the could we build another tool for um for easy testing of patches in the issue queues um it is like this old man with a patch there's no reason this has to be here uh so like hypothetical vagrant command which we could very easily do and i'll just walk through that so uh vagrant proviso patch test and give it the um and feed in the argument for the path to the patch the the text file so we can easily get the issue number from this uh we can go to that page um this is easy to do with the vagrant plugin and you know some ruby some ruby gems uh scrape that scrape that page find the core version and the module that it's talking about find the dependencies for those modules by checking um the xml updates um the same thing that you check when you when you're looking for updates um or that the drupal site checks when you're looking for updates um also you know look on that page find the place where that patch is linked and and then find the date of that comment and then load in that version that that head the commit that was at the head on that day because everyone when they're doing their patches they're doing it against the head um so anyway this is just a quick one liner that now maybe this environment this environment actually helps people in the issue queues and it's a you know a commonplace that we're going to just solve our problems and the things we deal with every day which right now have a bunch of different tooling around so last scenario is the idea of remote deployment so just say you've working you've been working locally with proviso and your original plan was to host with say pantheon or aquia uh but then uh you realize something mongo db and no js are freaking sweet you really want to use them but they're not those don't exist on those larger platform providers you see you've been developing on a roll that emulates aquia um but now you can instead of being kind of at a dead end where now you have to totally rebuild a stack that works for you um you've already been developing on one that we have as a community built to emulate say aquia and um and you can just you know there's some work to figure out how to write your cookbooks hopefully leveraging community cookbooks to get mongo db and and uh no js setup um but you do those customizations and we have that that conversation in the commonplace and maybe and maybe you share back for the next person and now you've got um you've got your remote your local development environment and uh simply by using vagrant awas the plugin that allows vagrant to push remotely you don't just have a local development environment you you know you actually have um something that you can spin up and and you know at the very least use it as a scratch base but maybe later you know actually hosts your live site on it um yeah uh those are like yes end of imagineering period uh so anyone have any questions on what the goals of this project are or like what your thoughts are well i mean i'm just wondering how far along are you actually um and maybe i should explain a little bit about my situation uh we're deploying on the amazon and are planning to use opsworks uh which is using sheh uh and as far as i can see we we can get some really really good stuff out of um having a git repository without cookbooks until opsworks to just look for the cookbooks there and deploy and the run list i guess is managed in the in the opsworks configuration um it will be really really great if we very easily could make a a vagrant sheh uh solution that would look at the same cookbook repository and well basically do the same um am i looking at the right project then the like this is a great place where uh where it would be wonderful if we were having conversations in a common place because a lot of like even to build a chef repo the cookbook repository that's done a lot of different ways and there's um lots of thoughts that the wider community talk has about um about how to best organize that and like if i mean i my personal thoughts would be like using librarian or birkshelf and that doesn't um that doesn't it doesn't it's not it doesn't mutually exclude um using this project to figure out how to build your um uh how to build it using amazon service um because it's a very concise definition and just tells you exactly which you know we're if we're doing this right um all our cookbooks aren't living inside this project they're actually out there whenever we need something even a little bit special sauce we're we're publishing a a cookbook to wrap around that that's external to this project we're pulling it in with um using those um those cookbook that cookbook package manager which everyone it is so the thing the fruits of what of the labor that goes on here can if we're doing it right we're pushing it all out anyways you can choose to resurface it and use it with amazon um and that's that's no big issue but i mean hopefully the i guess the idea is the triple community has very specific needs on how to optimize a stack and right now a lot of those really exciting conversations kind of happen in the engine like among the engineers at aquia and among the engineers at pantheon when they do awesome work and they push out great features for us but they don't we don't have any place for these conversations to happen among um you know people who are who are really known stacks right so if the question is um will proviso will proviso help me to also either pronunciation is fine um will proviso help me to uh to take a chef run list that i have in a bunch of chef cookbooks that i have and turn them easily into a vagrant project um i mean i think vagrant only takes a couple of lines to do that part um but um hopefully the idea is exactly like pat said it will at least serve as a place for um you to see vetted community vetted modules and a reference implementation of how the community considers this best done um which isn't to say that like the five of us working on this are the the community that decides how this is best done but hopefully after this session you'll all yell at us and tell us how we're doing it wrong and we can do it better um and then it will be community vetted and and we'll have like sort of a consensus on how it's best done so first of all i want to thank you guys because i have played with a number of the existing solutions and found them all to have positives and negatives and i was at the point where i was like i need to build a dev environment to hand out to my devs that i know is solid and i was going to end up having to reinvent the wheel again and i didn't want to do that so this is great because i will absolutely contribute stuff back i guess my question is what's the scope i mean you went to the imaginary thing and so obviously you can you can go really wide with it but um so somebody in this room says hey i want to contribute they're working on chef they don't know anything about puppet is somebody at that point going to say well okay wait we've got to make sure report some of the same stuff over to puppet to keep them parallel because that seems like a huge complication unless you've got people willing to take that responsibility because that initial contributor is not going to go learn puppet to go put the other side of the patch in um so that's number one and number two how deep are do you want to get do you want to keep this as just being a basic lamp stack is this going to become something where we put pieces in potentially to turn on for developers so we install you know um particular editors you know i mean obviously if it's available through chef there's a cookbook someplace is that going to be sitting i guess this kind of goes to the previous question how much of that is going to get rolled into the distribution and how much is going to be like well you can add that to your own custom thing we're not going to put that in so that's always a tough question and also i realized that we didn't exactly answer how far this currently is um so i think if you clone the repository right now you get the you know github.com slash previso slash previso if you clone the repository right now you get something that um that has the magic to do the puppet or chef librarian work to pull in whatever is defined and build up the box using either chef or puppet all of that stuff is in that repository and then pat has a fork that has the chef kind of lamp stack cooking and i've got a fork that has the puppet stuff cooking and we're about to start pulling that stuff together so at the moment it doesn't build you a functioning the proper project doesn't build you a functioning lamp stack but the work has been done and it's just a matter of pulling that in so as for what's in scope immediately so first off as soon as we get that that stuff merged together and thoroughly tested right testing is the key as soon as we get that stuff merged together and thoroughly tested the next step is is adding the ability for someone to um to add on their chunk in a clean way so that you don't have to fork previso to add your editor your thing um and and then um the idea is that we're going to have stuff that seems of general interest um we've been hashing out a plan to that's related to that to allow you to flip on and off some of those things that are of general interest so mango redis memcash are all becoming common enough components in a dribble stack that we think it should be one line of configuration to turn those on or off um in terms of what about my crazy idea it's gonna kind of be up to the people that weigh in on the issue queue to kind of decide that this is kind of in what should be in one of those like flip on yafi things or not i think what we're talking about last night is the idea that the extensibility part needs thought and it will be like it's not something that's there right now so we're airing on the side of like the most important thing we're trying to do is not alienate someone or not choose to say hey you you're not doing it the way that this project wants to do it um so until we have extensibility solved which might be a while the idea is have this just be a melting pot of different ways and make sure that these can go be turned on and off um and we're not we don't require someone to fork or say oh this doesn't solve this isn't willing this project isn't willing to entertain the way that i do deployments whether i play with cookbooks some people are against that like there's there's lots of different variation um hopefully the core central things is in like what's uh i don't know i guess that what what is how do we optimize the mysql part of the stack that's more clear um and it seems i guess by the the fact that aquian pantheon essentially do this for the tons and tons of sites they deal with makes me feel that this is like we can do this we can kind of come to some consensus but they might also be optimizing in different ways and if you're trying to create an aquia model and a pantheon model because that's what somebody needs they needed to match that you're going to have multiple configurations in there anyway um so i'm not sure that you're necessarily going to want to be like the one true way to tune it because there isn't going to be one true way you're you're really creating sort of a okay here's here's the aquia stack as close as we can come whether they share information or you go look at you know whatever pieces you can get to and say okay that's what we can clone um versus the pantheon stack so our idea there is to create um to create the the thing that we were talking about before about wrapper puppet modules and wrapper cookbooks that configure those other pieces so the idea is that you kind of you kind of wanted to get a sense for what in as far as they'll share or in as far as we can figure out um what they've done to tune you could kind of diff the proviso mysql aquia wrapper with the proviso mysql pantheon wrapper and kind of see how we think that they're tweaking that um trick question the aquia one would be uh percona i think but right and then at that point that wrapper then actually has two pieces one of which is a chef piece and one of which is a puppet piece that's right there there'd sort of be parity so and then and then in the issue of um do we let something in when we get a submission for puppet but we don't get a submission for chef or vice versa um the thing that we've landed on so far and i would love to hear what you guys think about this is um when we accept that pull request for puppet a an issue gets created for chef and so that doesn't require the person that's contributing to do that because that's going to put the brakes on the whole project it's going to seem insurmountable for someone that knows one side and not the other but the idea is that that then creates an issue for somebody on the other side of the team to start looking at and again increasing the conversation of seeing how it was done in puppet and contrasting that with with sort of how it's done in chef and ansible and so there's a skill set here for people who speak more than one of those to act as sort of translators and so that seems like a real need for this project that definitely needs to be addressed this you need to find people that have spent time learning both to be able to do translation at the moment um we're training each other up and expecting that like as other people join the project they'll get trained up to um and i think that sort of serves a need in the community as i've been talking to people a lot of people have some buyers remorse or anxiety about whether they made the right choice because i've heard people on both sides say well if i had it to do today i think i'd go with the other one um because the grass is always greener um but the hope is that we can sort of get a better consensus about what the better sides of these different things are like a puppet feature that i like is that it can show you a diff of what it would have done completely without actually touching your system um as far as we can tell chef just can't do that for some various reasons what's that oh chef 11 can do it nice thanks nick that's awesome um yeah but uh but yeah comparing and contrasting the tools which are obviously getting better all the time every time i come up with something that's like you know what like puppet has this one thing like i can hang on to that this guy's always like no not anymore uh and just want to say like we're talking like at least in chef role like we're talking about the idea of writing wrappers and that's not this isn't like a fringe the thing it's a common pattern in how how people design their infrastructures at least in chef role i'm not sure about about puppet but yeah so we're not doing anything like crazy to solve our problems um it's just yeah it's using a model that lots of other people use when designing i think we're a bit short on time but a few questions on a puppet i've been using puppet this year and i've found that the modules are often kind of hierarchical someone writes module to write a lot of modules which fit together and even just building a lamp stack which we can use for Drupal for service it's not so easy that i find someone like come to camp Drupal just lots of different modules but you really have to go with them and use all the modules but then i find your people a little about this useful and then i have another project where i need postgres and this postgres depends on a wget module which is not going to play together with another module and in the community it doesn't seem to be as homogeneous how or seems to be interference between modules which you don't have for instance in the Drupal community yeah i've done i haven't actually stated a question but it's a question is there such a thing as a pattern for how to use a provision of Drupal server on puppet today that there is a lot a consensus behind me um what we're trying to work on building a consensus is that a nasty question a little bit no no no i think you're right puppet more way more in the public community people have been rolling their own than in the chef community in the chef community there's a ton of reuse and i think the puppet forge has only really started to mature in the last year and it's and it's still kind of slow going and i think you're thinking of example 42 where they have just this whole ecosystem and you really have to buy into their whole stack for any of their pieces to work and it makes some assumptions that just won't work with other module providers i think that's kind of being considered sort of bad form there've been more blog posts about how to build puppet modules that make sense i think puppet puppet has a language puppets puppets piece on format that you use to describe all your manifests has some limitations that are being worked on that have caused some of that fragmentation but there absolutely are a bunch of modules that will play well with each other and don't bring with them a whole bunch of other dependencies other than puppet standard lib which pretty much everything works with so um so so what um are the pull requests that's going to be landing uh shortly that pulls together lamp um relies really heavily on the puppet labs modules those are all well written as you kind of expect um and they've got modules for apache my sequel but some of those are like two years old for instance that lot the lot about ones are way better sorry for the introduction the um better better is relative um and it depends on which one you're talking about i should join we'll discuss yeah yeah um maybe have one time for one more question i think we're out of time actually so um so we should just say uh yeah we want you as a proviso contributor um we would really love to get um to get more hands on deck and get more of these conversations going about what puppet modules don't suck and if there aren't any we need to get the ones that suck least to really not suck or write some of our own um and that's that's definitely some work to do i think on both sides but especially maybe especially puppet um so join us on github um which we're using github so that we can interact more directly with the rest of the devops community which is mostly on github um the pound parse proviso on uh freenode we've got our irc room and um and we've got a google group that's mostly for announcements we do um we do hangouts every other week on friday on google hangout um to just kind of hash out where we're at and what we're working on and what's up next so we hope to see you there thanks a lot