 Okay guys we're a few minutes late here and we're here for discussing basically the orchestration tools and the various options and models that exist in the market today and I know that at least as I am there is some confusion because there is some overlap there is some level of integration that you would expect there is different thoughts on how you approach that and we gathered here the group of expert that will help you to kind of address some of those questions. I will kind of start with stimulating some questions at the beginning but the real idea here is that I'll be just you know here to help you ask the questions and again we have I think a very good list of people from the panelist here. We'll start with a quick introduction so first of all my name is Nati Shalom the city and founder of Gigaspaces, the company behind Cloudify which is another orchestration tools hence why I'm here. I'll go with you. Johnny, cloud solutions architect for Rackspace. Hi I'm Georgie Akerikverto from Miranches. Hi I'm Steve Baker I'm a developer on the HEAT project work for Red Hat and I'm Florian Haas a consultant and co-founder at Hasdexo. Okay so we'll start with the obvious question I think first which is what would be the tools and by tools I mean configuration management like Shetman Pappet obviously orchestration like HEAT there is dockers sorry there is other tools that you know you could even come up with your own what approach would I use to choose the right one when would you use each one of them and when you wouldn't use them so we'll start in the order well actually let's start with Florian. Thanks for putting me on this spot Nati I always appreciate that. So I think the first thing that we should consider when we take a look at this whole array of tools is what are they really built for are they built for actually deploying and orchestrating an infrastructure as a service platform are they built for deploying applications on those are they built for even building our platform in the first place and distributing packages or gold master images and that sort of thing. So when we have this discussion the first thing that we should really do is and this applies not just to this panel here but pretty much any discussion that we have about these tools is what is it that we're actually really talking about that we want to talk about first and for example one thing that we could start out would be when we take a look at how do we actually want to deploy our OpenStack cloud what do we want to be able to do and in what way do we want to automate the actual deployment of our OpenStack infrastructure and there's multiple ways of doing that and maybe you want to enumerate some of those here. So maybe John wants to start with his favorite what's your favorite way of deploying OpenStack? Oh deploying OpenStack yeah. Deploying OpenStack okay well as a test DevStack right it's about the easiest way to go and essentially you know that gives you a working copy that you can well working system that you can actually go and take a look at and kick the tires and for for a lot of folks like a lot of things that I do with it is experimentation just to take a look at stuff and from a development perspective you know that's what you need you don't necessarily. So a question to the audience here how many people here are using DevStack versus let's start with DevStack where's the hand? Leave your hand open if you're using DevStack for a production OpenStack cloud okay great we have a we have a smart audience that's fantastic. So how many people are using RDO for example but a few okay so I think you got partial V on that so it looks like see people are using something else for their for that initial experience well there there's always Chef also right so I know that so I know Matt has actually done quite a bit with the OpenStack Chef configuration or cookbooks okay so DevStack's first Chef would be the second option Steve yeah so I'm of the opinion that I mean like Florian you should use the appropriate tool for the appropriate job and and I think the orchestration in software configuration appear on superficially to be similar but they are actually very quite different problem domains and they do deserve separate tools one to do orchestration one to do software config so as an orchestration guy you know we've got orchestration covered but because we're orchestrating the compute which then has to be configured you know we need to do a good job of enabling a number of techniques to do that configuration there yeah so let me slightly change the focus from like trying so you don't want to answer the question reframe yes yes but actually I want to go back to the it wasn't the right question yeah so uh how we actually select the proper tools and actually the answer is simple usually it's like use your common sense and another way to find out what is the proper tool for you is actually to check what is environment outside the OpenStack because you do not deploy OpenStack in vacuum you have something already and usually if you have a huge like enterprise infrastructure you have like change management tools, CMDB database like support system and sometimes it's actually makes sense to check what tool will like better integrate with your existing infrastructure to operate with this OpenStack not only let's show the audience a little bit do you feel that you got an answer to that question and if not rephrase the question or should we move on okay we'll move on I think that was the voice here the non-voice actually and again don't be shy feel free to ask the question so the next question is to Steve would you change the same answer that you just gave if you're a private cloud guys versus a public out guys yeah so well you know every cloud is different in private cloud you have more control over over infrastructure so if you want to use a particular technique you can heavily lean on your local operators to to give you whatever you need um whereas you might not have that same flexibility in a in a public cloud so yeah yes you you can and should potentially do things differently um at the same time it's nice to have as much consistency across your platforms as practical so for example in the case sorry I can add something to that I think something that's also very important here is to consider the scale of your cloud um and and that's where this whole idea of this is the perfect tool for deploying OpenStack under all circumstances completely breaks down uh if you are a public cloud provider like Rackspace or like like HP Cloud Services yes it does make perfect sense for you to run two layers of an OpenStack cloud and HP calls that the under cloud and the over cloud because that greatly facilitates your public cloud management if you're looking at the tools that these guys are building you may very well come to the conclusion that hey for my scale um that's actually not needed at all because you're not running a public cloud with hundreds hundreds of thousands of of of nodes and cores uh in a in a way it's very equivalent to uh about five or six years ago everyone started adopting the uh MySQL database optimization techniques that worked really well at Facebook and people needed to be reminded that hey guess what you're actually not Facebook um and and a lot of that is is true here as well and I think another thing that's really important is uh if you're familiar with specific tools that you would like chances are that you are going to be able to manage OpenStack with them fairly well uh if you like Chef you can deploy OpenStack with Chef you can manage your workloads within your cloud uh with Chef if you choose to do so if you uh if you're a puppet person like I'm not ashamed to say I am I love puppet I think it's great uh then you might want to deploy your OpenStack cloud with puppet um that I mean keep me honest here guys I think they're they're very comparable and in terms of their support for OpenStack uh and they're both like very very useful and handy tools so um just as a word of encouragement if you're thinking this is the right tool for me and this is what works for me use it for OpenStack but please don't roll your own it's probably really wasted effort to reinvent reinvent the wheel because the number of really really good wheels have already been invented for this so I if I summarize that thread that would contribute to the stuff that's there make it better yeah so so a quick summary of that thread is that it depends and it depends whether you're trying OpenStack first that's the classic answer right it depends if you're a first if that's your first attempt you probably would you want to use something like DevStack if you already kind of have an investment in tools in your organization and you have already in placement for other purposes chef and puppet that's probably going to lead your decision it also depends based on what Florian said on the size of the deployment and the complexity of deployment and also to Steve point and I think also to Florian points whether you're building the stack or the bare metal side or you deploying onto an OpenStack so that might change a little bit the tools that you're choosing to do bare metal provisioning versus application orchestration bases configuration management just do a question for the audience just raise the hand how many people are using chef here good how many people use puppet well that's what I sensed so we have majority for puppet in OpenStack community how many people are using docker that's new salt stack Ansible okay so I think we got a good ratio of which are popular I would say puppet first chef second then docker then salt stack that I think is the kind of ratio without counting yes so if this is your first deployment and you're actually like looking to actually implement this in your organization I mean I think I might be wrong the very first thing you should do is actually DevStack because you need to be familiar with all the different components you have to have a familiarity with the apis and there's a certain part of me that you know when you're actually learning or taking a look at a new deployment of something that you're unfamiliar with I mean it doesn't make any sense even if you're a chef expert to try to deploy an application that you have you know or you know a system or a platform you have no experience with so I think in my mind I'm like thinking if this is the very first time that you actually ever like consider deploying anything I mean you'd want to do it with DevStack or something very easy to just get familiar with the apis that are available familiar with the different projects that are there I mean I might be wrong but I actually Florian nodding a little bit I totally disagree with that actually so I think so if you're if you're looking if you're interested in contributing to OpenStack if you're interested in understanding how you know the various Python modules work together and all that DevStack great awesome it's a great way to you know get your hands dirty on actually hacking OpenStack and by the way it greatly facilitates being an OpenStack contributor and for that I do use DevStack but if you're actually looking to deploy like even a mini cloud a POC why does it have to be DevStack you can do that really really nicely with puppet you could do it really nicely with chef there are images out there for you that can you you can basically deploy I'm currently kind of waiting for when are we finally going to get you know the first mainstream hardware vendors that are just going to bless us with pre-installed OpenStack controller and compute network nodes that would be kind of nice there are multiple yeah I know but they're not they're not the big established ones at this point with their with their and for them and where they are it's not the it's not a very core part of their product portfolio of course they're testing this but I'd like I'd actually I'd like to see more than that because it would you know make it easier to but so this is the one thing though but doesn't that make the assumption that everybody has full knowledge of puppet full knowledge of chef when they deploy it right my biggest issue is I don't think you need full knowledge of puppet to do a puppet module I think there's learning and and and do an actually there's learning curve so was that I think there's learning curve yeah this is the first time you ever deploy the first disagreement in the panel which is good this is good right panel this is DevStack the the next question is really we talked about versus like docker versus chef versus whatever as we know there is some integration already in place for example with heat and chef and puppet I know that we've done the same thing with cladify for a while and actually I've seen that the joint actually integration working pretty well so I wanted to ask Steve if you could comment on the versus versus integration and whether there is a sweet spot for each technology even if there is an overlap in your view yeah so I think if you're if you're already using a configuration tool and you're really familiar with it by all means embrace that when you when you start moving into into heat and and choosing what you what you do the software config part with if you haven't or a few you know you're slightly indifferent about your tool I would at least consider image based deployments where where you split your configuration into two phases one is the image building phase where when you build something and upload it to glance that's really the only way you can be absolutely sure what what your boot and what you boot has what you want on it and then the the the orchestration and configuring part when you actually start your application it's it's really just a sprinkling of fairy dust to bring it to life so then the question is how do you build the image well if it's a docker image you you know use a docker file if it's a real OS image you know there's there's there's a few tools out there and it could be that these traditional configuration tools have a place in the image building phase interestingly there was an attempt to use the the the puppet open stack scripts to to do the image building part of the of the the triple low image it turned out that they required so much refactoring that it wasn't really worth the effort so so I think for traditional mature configuration scripts if you want to go down this path there's a big refactoring where you split it up between the the image building phase and the configuration phase but for for new scripts and you want to keep that tool and you want to build images then maybe that's a good way to do it I think it's too early so that's actually interesting I wanted to rephrase what you just said to make sure that I think I got it and and ask a few more questions on the panelists on that point so basically what you're saying is that if you want consistent deployment dynamic configuration like chef and puppet and even the software stack in in heat would probably wouldn't get you to that point because there is a lot of dynamicism that happens during the provision of the VM and so forth and that might not be deterministic in certain times depending on the resource that you're trying to capture and if you want a deterministic deployment then you would use a VM in that case you would use configuration management to create the VM and not as part of the deployment is that what you're saying yeah so I mean there's a lot of what you want to do is minimize the amount of entropy in your system and you know sources of entropy are you know network failures during package downloads and you know repose that that get new versions of software right in the middle of an upgrade really there's a there's a whole collection of sources of entropy that can be basically eliminated if you move to an image-based deployment especially if you add a you know a validation step where you bring up your image in a contained environment and check that it's a that it's valid good so I'll stop here to see if there are questions from the audience may I also add yes of course so actually let me slightly like argue with Steve yeah because like he's like staying within open stack boundaries but there are a lot of stuff outside and there are a lot of automation tools and not only automation tools by some provisional system which actually on top of open stack and as I see right now in Steve's world so heat is the first so you have like everything in heat template you ask heat to deploy this template it involves software components and once you're done but actually very often again in huge like enterprises not so huge enterprises you have your like outside systems which like integrated with other enterprise tools and usually they actually initiate the deployment and user not necessarily knows that he will use opens stack at all so it's up to this upper level system to decide whether it should go and generate heat template or it can like directly initiate like cheff deployment and cheff will execute this heat deployments so there are a lot of that's an excellent point actually the more I think about what you just said I wanted to kind of bring a question that is related to that and the question I think was nicely articulated in one of the keynotes from the guy from Microsoft I forgot his name forgive me who was talking about you know the Star Wars as an analogy and how the community should also embrace ecosystem versus trying to own everything on its own and and there is this kind of interesting thoughts here that I think Gregory mentioned is that how much of the tool set are things that should be live in the ecosystem for example we wouldn't think of cheff or docker being part of open stack right and still a lot of users would be using those tools and they not necessarily gonna be or it makes sense to make them part of open stack and how much it needs to be an open stack native thing to actually be accepted in the community and so forth so so the question is are we targeting for example heat to be more of an ecosystem play which means that it needs to do enough so that other tools can be on top of that or heat is going to be for example the things that does everything your orchestration your software orchestration you know and and there's going to be one solution that does all of the things that are related to orchestration so it's a very different philosophy if you think about it that way I think that's the way Gregory mentioned that or versus you think about it as there needs to be one thing that does that they need to deal it well and it needs to be an open stack native world I think those are the two thoughts let's hear Steve or not yeah so it's it's interesting about how attitudes of what what what is a fundamental piece of infrastructure changes over time you know when when we started heat orchestration was very much outside that but you know now that you know other projects like Sahara and Trove and triple low are actually building on top of heat and they actually need heat to do their orchestration parts heat goes it's going lower down the stack and it's starting to make more sense that it can be a core thing so you know but it's still not mandatory to use you can you can still configure from outside you can still use other orchestration tools just you know just like there's alternatives to you know storage and you and your cloud for example so yeah it's being being core doesn't mean it's mandatory it's the only way to do it yeah okay again I'll stop here for a second just to see if there are a question from the audience you're being too quiet which means that it's either the topic is boring or the panelist is boring or me not doing a good job so let's see if someone writes here around for a question yes we have a volunteer yes applause to that yes hi so it's interesting to me and I wonder how many of the folks in the room there's some funny distinction between orchestration and basically deploying some software and configuring it there's some gray area I don't think orchestration is really a term of art in a precise sense and and I think we're in the context of OpenStack we may be struggling with that a bit where the ability to manage the resources in a cloud could be seen as orchestration but when we get out to the the enterprise level of the world orchestration is about regulatory compliance and audits and all that sort of thing just curious on your thoughts on that but that is but that is that's exactly with something like like heat in OpenStack actually facilitates one of the things that's really really nice is the ability to define and essentially arbitrary complex stack of various types of resources and being able to deploy them exactly as described exactly as defined in the heat template so what that enables enables someone that uses this stack to do is to say hey look I have deployed this stack in this way in this manner it's been documented this way it's it's perfectly we can we can replicate it wherever we'd like and that actually is a much better description of the system as a whole in order to enforce for example compliance or enable auditing anyone else wants to answer that question yeah so I mean this has become an argument about semantics which you know isn't that interesting but you know we've we're in the orchestration program the heat project and we've determined the orchestration is about invoking cloud resources using their APIs wiring them together and giving you a fully working thing and and and if it's not that then it's not necessarily orchestration just just just for the purposes of OpenStack that's the the definition we've gone for yeah yeah but I would say that was very precise definition of what actually heat does because uh in your heat template you define multiple uh different resources which are not so necessarily collocated and there are a lot of moving parts and the idea of heat engine exactly to orchestrate and make sure that those moving parts are doing this in a right sequence so it's like a conductor who orchestrates the whole orchestra which has like multiple difference layers so I mean I agree with you but actually it is really confusing as far as what the term orchestration is I I did um uh I was a consultant for the operations orchestration product for HP so that's very enterprisey and that was all about workflow automation didn't even really deal with and then here we're talking about heat which is really talking about you know composing these different resources and being able to deploy it so yeah and you know to a certain extent we're even talking about you know um more web services enabled systems service orchestration in terms of you know how they would automatically be able to add themselves into a pool or you know be removed from a pool all these sort of like terms with orchestration I think it's an overloaded term and it's you know I I totally agree with you it just seems very very confusing yeah I mean that to be fair heat is a departure of representation of how you want your stack to look but the but that's there's a missing piece there there's there's there's the workflow piece where you say I've got a job that needs to do this and it has a side effect that that quite validly could be part of orchestration as well but it's not specifically what he does but you know something that does that could live in the orchestration program too there's another question here yes yeah so um there's a distinction I guess there's a question here that thinks in I guess between orchestration and configuration management is uh orchestrating treating actually infrastructure as code right and when you have all of those resources and you have a lifecycle of an application that you deploy to that across multiple cloud providers not just private open stack but amazon as well with for example equivalents like cloud formation that's where you need orchestration that's where it's really important because you have repeatability infrastructures code across all the providers whatever they are I guess the question is what are the alternatives so as we're talking about orchestration and not configuration management so you have cloud formation for AWS you have um heat um the uh the IBM guys were doing some quite interesting stuff where they're extending heat to do uh aws provisioning through custom resource types uh I guess there's lots of other orchestrated products out there that will deal with a complex you know multi resource multi server multi data center whatever types set up what are the alternatives compared to to heat from an open stack perspective or just general orchestration well sorry what was the question so the question is whether the alternatives to heat what are the orchestrators that you would use for open stack ansible salt stack comes to mine the very top for me okay what is the answer again ansible salt ansible salt stack okay but why so and this is something that you know we had kind of a discussion within rack space about heat and you know ansible's role and there's a lot of overlap between these tools in terms of what ansible's able to do and in terms of like orchestrating different resources doing something similar to heat but ansible is more generally applied like it's not just open stack you can do aws you can do google compute engine you can do all these different things and you know not that heat is a bad project or anything I still think it's a great project but you know when you're actually talking about different uh sort of orchestration tools that are out there there also is that piece that you mentioned how do you make it uh something that can interrupt between different clouds and you know those choices become okay well heat's you know obviously it has some backwards compatibility with aws but if you were looking for a more general tool to be able to handle stuff like that then do you start looking at ansible you start looking at salt stack because you know the the orchestration piece for it doesn't just stop at the clouds it's you know dedicated and and actually uh come back to the IBM example that I also heard yesterday that was doing a kind of extending heat one of the comment that immediately I heard actually from someone else in rack space was that is it open source is it you know have you contributed back to open stack and immediately when the answer was no no it was uh then it's not interesting kind of you know it wasn't explicitly like that but that was kind of the mindset that I felt uh that uh came back as a response to that and and and it comes back to the interesting answer that you gave is that uh your alternatives in a way to choosing heat which is very if you're like bounded to open stack was to use someone who is actually from the ecosystem um so I'm trying to see if orchestration that kind of moves up the stack would go through the same flaws we've seen with web frameworks for example we we all know that you know there is so many ways to build web applications today not one way right so there is this tendency that as we move up the stack taste for example or even a flavor of the way doing things becomes an important factor versus uh if we're going down the stack there is usually less options on how to do things so I'm trying to see again back to that question uh uh if there are more options or should open stack embrace more options even competing option within open stack to do orchestration versus and I think that was to your question Florian versus we need one orchestration for all of the components within open stack yeah and I'd actually like to expand that question a little bit one of one of the more heated discussions that we have in the open stack community are always the um the the api compatibility issues uh where tensions usually fly high or at least emotions do um I have a question for you uh for for the audience here um could you please raise your hand if you agree with any of the well for with with each of the following statements like statement by statement uh would you agree with saying it is important for me that open stack has an orchestration capability that is compatible with aws if you agree with that raise your hand if you agree with it's important to me that open stack has an orchestration uh capability that is compatible with vco raise your hand if you're saying it's important to me that uh open stack has an orchestration compatibility that understands toska raise your hand and if you say I'm totally happy with with OpenStacks orchestration capability, I don't care about compatibility with other APIs at all, raise your hand. Okay, that's actually fairly balanced. It's fairly balanced between Tosca and I think, I don't care about things. All the rest was very low rank, so that's interesting actually, if you think about it. So just as far as Tosca goes, we've been slowly evolving the heat model so that aligns better with Tosca. So it's gonna be a lot easier to translate between one and the other. And it's possible in the future that heat will have direct support for Tosca in the future. Many, many caveats around there. Yes, I'll come back to the Tosca question in a second. There's a question from the audience. Yes. Yeah, so my question is also about orchestration because to me, orchestration is not only creating the servers that I need, but also they have the roles and the configuration that they need in one step. And I've been attending a lot of heat talks and it's still really not clear to me how close heat is to getting there in terms of if I wanna not only create servers, but also puppetize them or use them with, or use Chef, all in one step using all one template and not having to go through multiple. Yeah, so just again to make sure that everyone understand the question, the question was can I use heat to do configuration management instead of Chef or Puppet or how well the integration is with Chef and Puppet? Yeah, in conjunction with, so if I want- In conjunction with. With like one template not having to deal with multiple different. Yeah. So we have two options now. One is that you do minimal configuration when you beat your heat provision servers to hand off to the puppet or Chef master. And then from that point on, it's the master's job to keep the configuration up to date. But then it's a bit tricky because then you've got sort of two sources of truth. One is the master and one is heat itself. Heat already has all that knowledge. So another option is that you can use Puppet and Chef to represent the configuration on boot. And that can be mapped back to resources in your heat template that can participate in the heat orchestration life cycle. So in that way you get the best of both worlds. You get the configuration tool that you prefer to use. And that participates in the standard heat stack life cycle flow so that you can push updates through heat tools and Puppet apply and Chef Solo get invoked to actually make the changes on the servers. Okay, there was another question here. If not, yes, is there another question? Okay, so I think one of the, you had a question? Yeah, one last question. Mistral is a workflow tool which is a different service in OpenStack. Yes. How comes heat doesn't use that? Because it's not integrated. Because what? Yes, we can't depend on it in the heat project until it's part of OpenStack. But there's been many, many times during the summit where someone said, we need heat to do this. And we say, no, that's not heat's job. Heat does nouns, not verbs. That needs workflow. We're expecting that will be Mistral. At some point, we really, really want to use it because it solves a bunch of problems that we have decided not to solve in heat. So yeah, we're looking forward to being able to do that. So I think we have only one minute to do closing remarks. So let each one of the panelists to have its own few seconds of closing remarks on where heat is, well, not sorry, where orchestration in Europe is going. Let's start with Florian, closing remarks. Or if you want to rephrase that question, I'm sure you'll do that. Feel free to do that. No, my closing remarks just for everyone are experiment, collaborate, contribute. You're here, you have a chance to make this all better for all of us, so let's do that. Let's change the order. Here, here, right? Here, here. Now let's go drink. So, Steve, closing remark. What he said. Yeah, you know, it's still relatively days, you know. Heat's a young project and we've got a lot on our roadmap. So we're just going to keep on incrementally improving it until it meets more of your needs, yeah. Greg? Yeah, and I just would like to ask you guys to actually share your experience about, like, application and running workloads on top of OpenStack so that OpenStack community can understand what are the use cases which are a relevance for you but not for engineers. So, I mean, you know, I don't know if this is not permitted, but, you know, it's been in the Rackspace public cloud for some time and we've been doing Blueprint deployments, they've been working very well. To answer your previous question, if you want to try it out, it actually, there is a place where you can even kick the tires and see it actually work. So, in terms of, like, as a user or even operations or developers, it is really about kicking the tires. It's really about telling us what we're doing right, what we're doing wrong. So, I mean, echoing your comments, it's really what we need, right? So, I'll add my own closing remark, if I may. My view is that the thought of everything needs to be in OpenStack, needs to change, and I agree, I think, with some of the panelists here. And in my view, the thing that is missing in OpenStack is actually more ecosystem projects like Docker, I think, even Chef and Puppet, to a degree, and many others that actually, if you look at doing stuff with Amazon but are not doing the same level of investments with OpenStack, so I think the success of OpenStack would be embracing a lot of those ecosystem players into, not necessarily contributing in code, but at least doing integration more explicitly, and that means that the OpenStack frameworks needs to invest more effort in embracing them rather than replacing them. That's my closing remark. Thank you very much, guys, and thank you very much for the panelists. Thank you.