 So good morning and welcome for everybody coming here, and I have a feeling that's really loud Yeah Surly my name is Carol Barrett. I'm with Intel Corporation And I've also been doing work here in the community around And that a group called win the enterprise Which is bringing together a group of folks who are focused on driving open stack to be successful in the enterprise IT market places and Coming together to understand what we need to do in multiple ways around open stack to go ahead and be successful And today I wanted to talk with everybody about where we started and where we've come to and Where we want to go to and I'm looking to go ahead and bring new members into the teams that we've formed for the last Couple of months so that we can go ahead and achieve the goals that we want to set forth for between now and taking us to kilo so And I So what we've done is really focused on Identifying what are the barriers for enterprise IT to deploy open stack today? Not what they need six months from now not what they need a year from now But what is standing in their way of being able to deploy it today? And we found that sometimes those barriers are around technical features and capabilities that we can go ahead and Address in a short term through a series of different approaches Sometimes it's around documentation and how to guides Sometimes it's about awareness and perception. They're not aware of open stack or they have views on how Capable and complete open stack is and how ready it is for enterprise deployment And sometimes it's about being able to see case studies and other reference Architectures to see how other people who are similar to them have deployed open stack today And what value they've gotten out of it so they can build their plans around it and their business justifications to deploy it The group actually came together In Atlanta, so six months ago. We had our first bird of a feather session and we brought together a Group at that time and then additional folks joined us over the course of these last six months And we initially kicked off five teams. We identified that the barriers Segmented themselves, so we kicked off an application availability team a Manageability team service availability, which was referring to the open stack services Security and compliance and a marketing and a business team, so we went ahead and brought together about 70 people from 25 different companies Across these teams and these teams operated to go ahead and identify what were the key barriers Look at how they would prioritize the ones because there were pretty long lists in each of these areas as to what the issue were Created a ZBB line identified what were the top three that we actually thought we could do something about in a six-month period of time and Took that list to the open stack board meeting in July Which was in Portland, Oregon in conjunction with Oskon that was going on at that time and showed them what we had Identified and what our plans were to take action on them They told us to go ahead and move forward And so coming out of that we identified that there were some common Barriers that went across application manageability service availability and security compliance And they were around open stack deployment and upgrade Monitoring and then cattle and pets. How do you go ahead and on board existing IT enterprise workloads into a cloud? So we formed three additional teams coming out of July and since then the teams developed action plans and have been executing to them What they've What it looked like was that we ended up with over 75 Participants and there were a lot of individuals who are multiple teams because folks have interests that span multiple areas And they have development teams that span multiple projects and multiple areas It was over 25 companies that came together We've had a series of folks who have joined us even in the last couple of weeks Folks from Oracle and Stratus Liberty Mutual Insurance EMC and I'm hoping to build with that list here today And we've got eight work groups that are actively working today and over the last six months We've got over 1200 of collaboration hours across all of these folks working to Execute on what we identified as the problems and the actions to fix and what those fix look like was in the case of the Marketing team and the business team We did some content development to provide the support of messaging and being able to show proof points Around open stack deployments and people getting value out of open stack for their business We updated documentation that filled some of the gaps and aligned the documentation with the current capabilities in open stack specifically around federated identification We went to the San Antonio operators summit in August and met with a series of open stack operators to understand What their real barriers were around monitoring and deployment and onboarding existing IT workloads into the cloud because we needed more Requirements and details of what was stopping them from being able to move forward So we could understand what we needed to do to get rid of those barriers for them It gave us good information and so from there We went ahead and developed a series of blueprints and proposals that are actively being worked through the design summits that are going on And what you see is by the different teams What the titles of the blueprints are what projects they're in links and I'll go ahead and post the slides up on a Google doc and there's an etherpad that you can find in the schedule notice and I'll put a link to the Google Docs file in there as well And feel free to go ahead and you know go to the etherpad and put any type of questions I'm looking at it and I'll log into it as well And then you can see the folks who are going ahead and driving Those different blueprints and conversations today We have actually the monitoring cinder conversations going to happen later on this afternoon and tomorrow will have the capacity headroom Nova conversation happening. I'm not sure what the timeline on all the other ones are off the top of my head so we really tried to get focused on again, what are the barriers today and What can we actually take action on and solve in a short period of time and either by making the modifications and driving enhancements to OpenStack Some cases it's working with Ecosystem partners because it's through that combination of OpenStack and an ecosystem Partner solution that we can actually create a whole solution that can be deployed but really looking to Make impact now not in the future and so today What I Would like to do is really a goal is to bring more community members into the workgroups there's a lot of desire to continue to push through to the L release and That what we're trying to figure out is what's that next set of barriers that we're going to go after all right What are you seeing hearing from your customers or your partners that are preventing people from deploying OpenStack today? Who in your organizations can work with us to go ahead and Understand those barriers define the solutions to them bring resources to developing those solutions and Driving it into the design summits and then out into the marketplace And Around that is do we have the right teams in the right focus areas? Do we need more? Do we need to redefine how these teams are operating or what they're specifically looking at and how would you want to go ahead and Define success around the needs that you know of and the things that you would want to see happen for your businesses between now and kilo so there's a as I said an etherpad that we've got open so if you Have comments questions or want to go ahead and put your name and an email address So we can go ahead and link up that would be a great way to go ahead and get connected There is a mail list a mail group. That's also Set up through the OpenStack Community list and it's Enterprise WG And then sort of two other things before I go ahead and open up for conversation is Tomorrow there's two follow-on Conversations that I wanted to share with everybody There's going to be a longer deeper working meeting around win the enterprise Where we'll probably do some work in the specific teams and talk about very detailed barriers to try and come out of here with a Start of a focus for the next six months for us And then there's a telco working group that's coming together tomorrow morning Which is going to include both telco cloud operators as well as the NFV sub team that's been operating within OpenStack today to go ahead and look at how do you work to address telco barriers today, so generally maybe some things around scale and performance So that they can go ahead and expand their OpenStack deployments and then continue to work into the future as they migrate from where They are today and SDN into NFV And so looking at that from being a development Operators and business and marketing type of a focus as well So I wanted to share that in case you all have interest in multiple segments Which I hear from lots of people that they do so I'd like to I'd love to have some conversation and hear your thoughts and What you hear from your customers and partners around barriers for them, right the enterprise Customers to be able to go ahead and deploy OpenStack today Yeah Okay, and on the the maturity are there features that come around that You know, how do they what are the examples they'll use that? telling you that Sure, I'm sorry. So he was saying that what they're hearing is that people are the customers are talking about a couple things So that OpenStack Is lacking maturity stability and upgrade ability and that They need a longer term roadmap to be able to go ahead and understand where the products going so today We'll publish something around a six month roadmap. They'd really like to see an 18 month roadmap And that when they talk about stability, they're really talking about things like live migration Right needing those capabilities and needing those to be robust Yeah, so one of the things we just recently ran into in the ice house release is we upgraded in Keystone from a stable ice house release to I think it was dot-two and A change got put in that totally broke ad integration. It's a thing to deal with like utf-8 characters and I Couldn't find a bug That that got tied back to so it seems like we get a stable release which should be I guess feature frozen from a standpoint But there's still features getting ported back into it Which I can understand if it's solving a bug or something like that But there's I mean if we're dealing with if some of us are used to the red hat thing where it's like it's frozen And there'll be some stuff back ported, but it's like API compatible. It you end up with a I'm on a stable branch Everything's working. I upgrade the version and now it's totally busted And there's no bug or anything that's related to it. It's it's kind of hard to I don't see a Bear or a line that says what gets back ported and what doesn't in Terms of getting back ported into versions from from trunk Was it the API that changed and that's what broke or was it some internal function? It's internal code So it was basically anything that goes through a LDAP query. There wasn't an appropriate function So in active directory if you had a picture it tried to do a UTF a conversion on binary data And that just totally broke every function related to it. So Like Keystone refused to work with active directory Yeah, there is later on. Yeah. Yeah, I think there's a desire to actually get that to be much longer than that Yeah, okay Thank you. Hi, I'm Ronan Kaufman morantis. Hi, so Until last week I was with Oracle, so it's changed for me But so one thing that we do see when we go to enterprise customers is, you know The first thing they want is a two to three year support. No question asked. That's what they want Their test cycle is probably more than six months Anyways, and I think the community is by definition right now is dropping the The release that was released like six months ago. There's no vulnerability management Actually, the foundation will deny you of the name open stack if you're not supporting one of the two latest releases So it's not like you can say okay I'm staying on ice house for three years don't leave me alone because the rules and the whole mindset is around You got to move fast Which works great for development and we don't want to stop that But we do want to make sure that customers could remain on a version supported for two three years and maybe That's something for you know the textbooks answers like yeah your distribution go do it Well, first of all the foundation won't let me Right now technically I think that's an easy easy one to solve it I think even bigger problem is that we encourage as community people to move forward to the next release and that's something that Is difficult for for the customers is difficult for the partners who are developing plugins and have to update them every six months and it's you know, there is only so much you can do on Garrett and Checking process to checks for scale. For example, you can't check things in a hundred notes scale and those will break and so I think There there are two avenues this could work out one It's distribution will do its own thing, you know red hat said that ice house will be supported for three years Cool, and then kill Juno comes along now Juno is going to support for three years and kill comes along now Kiehl is going to be support for three years all of a sudden red hat needs to support five different versions for three years In any given time so I think five six Exactly so my point is this I want to make a point here and maybe and that's a suggestion Everybody's welcome to comment is the community as a community needs to think about a release which will become the long-term release and Long-term support release and then you know, we continue every six months to deliver We don't want to stop the innovation, but customer wants to Stabilize or a partner wants to write a plug-in writes it to that long-term Supported release and then you know if red hat wants to backboard something Miranda wants to backboard something fine But we are responsible for maintaining those APIs though interfaces and and and I think for a lot of enterprise customers This will be a very useful way to do things that's like to send some What other people think about that? Please yeah, I was expecting somebody from canonical to kind of jump Just I have a little comment about that, you know the train moves on always there are new features But at some point you got to say okay here is a good baseline and then you know the Distributions could differentiate but adding more features if they want to but as long as they keep things stable So that question that you raise is like is Juno good enough? Well as kilo good enough is the L You know good enough it will never be good enough But you have to say if we want to get serious about onboarding enterprise customers you got to say here is something I'm starting with and You know you may correct in two years but you don't want to start that only in the you know for releases from now because You know every enterprise customer and you know my former life I was dealing with these guys a lot and They're just it's an unstarter, you know six months major release major upgrade forget it It's just not something that they will even start I think from an open stack point of view There's the desire to keep everybody close to the trunk And so how do you balance that between having long-term support and stability and trying to keep people close to the trunk? I think it's a Yeah, that's a so excellent question. That is definitely not something. I think it's private develop It's like community developer viewpoint. I think much more so than the customers that we're trying to serve But I would imagine that It could be that the customer challenge becomes fragmentation Right, and so some of the value propositions around open stack and the ability for Enterprise customers to choose across different distributions depending upon what their needs are that value proposition could erode over time If we see a lot of fragmentation in the distributions that go out because everybody gets away from truck And maybe those are the the two sides of that So Bill Bill Franklin HP So I'll Partially agree and partially disagree with one or two of the comments that have been made so far There are a lot of enterprises that are actually actively doing work with open stack They've deployed it. We've seen I mean, you know Rajiv Khanna was speaking from Expedia the other day Comcast guys were talking in Hong Kong There are a lot of companies that have deployed this often It's in a proof-of-concept environment or it's in a green field development environment, but there are enterprises using it and for You know, are there any? Enterprise customers in this room are all we all mostly vendors Enterprise cut great your enterprise we got we got a couple of them in here So I spend about half of my time talking to a lot of HP's enterprise customers So I would encourage the Enterprise customers that are in this room To tell the open stack community particularly if you've currently deployed open stack The things that you want to see us change to make it easier to consume And more importantly make it easier to take it from a proof-of-concept or a smaller project to The standard we're really at the point where the client server revolution is starting to change and it's shifting in corporate Global corporates to a cloud based infrastructure. So my my first point would be yes I think there are enterprises using it and you know, they're having trouble cutting their teeth on it It's the same way. I'm an older guy It's the same way Unix started in you know between 85 and between about 82 and 85 or 87 So that would be comment one and then comment two Is there is a a tension within a lot of the enterprise community that I talked to Around how close they want to stay to trunk and it and it's really if you look back in history It's the same thing that existed with some of the very large early Unix distributions and then Linux ones It's this David Comey's sitting here who used to be a chief architect at Sun and it was a whole investigation of the You know the arc of change that you want in the in user land in Unix and in Linux And I think if you talk to developers in the enterprise They want to stay close to trunk if you talk to the infrastructure people that deploy Infrastructure as a service and the cloud they want to have as much stability as possible so it's that tension within the enterprise and Ways that we can solve that for the enterprise so that the Infrastructure components maybe don't change as fast But the parts that some of the developers are really interested in have an ability to change it a slightly different velocity It's a hard technical problem to solve But often if we go back and look at what we all did in the client server world That was the place where we met that gap and we allowed the change to occur up in user land and the Infrastructure stayed a lot more stable So maybe we want to think about that. I don't know Not necessarily you know if I was queen for a day, I wouldn't necessarily look at it in terms of Separating it out from dev to prod because you really want to be able to have a constant constant Progression and look at some degree of continuous integration. It's an aspect of what do you what do you want to update? And what do you what do you don't and if we could have a way of saying Lockdown this Don't allow this to change but allow this to change up here And even better yet have an understanding of the dependency graph of if I change this up here What are all the other packages that need to be modified to make it work that would allow an enterprise to maybe say For compliance reasons these things can't change. We've certified them for our own specific compliance requirements But these things over here can't change and we don't really give them that capability yet We do we have in the client server world, but we haven't quite gotten there yet with open stack Yeah, other comments or thoughts on Bill's point or or other go ahead. Yeah Well as one of the few enterprise customers here Thank you for coming to a to visit with us. So I haven't really thought this out, but I've been asked to Put open stack into proof of concept in my enterprise so I can tell you what my problems were Okay, to begin with installation Because we had to make a lot of choices and Seriously, most of the choices seemed simple, right? But I had to make them at every single point of installation. So was I using rabbit? Was I using zero MQ or Cupid or whatever? So basically I had to roll my own Passwords and everything going through the docks that were changing but I already told them It's gentle about that And so that that's one thing Basically, I would have liked to Install a package right because I was going from the red hat the red hat packages I Would have liked to install a package with the controller and the package with the dashboard and Just configure the dashboard With one database or one controller So maybe maybe it should work I don't I don't think it does but I Was configuring nova config files at one point and the notron config files at one point Could there be a common configuration so that basically installing a module whether it's Nova or notron or Or compute or whatever just pointed to one IP with the one password and it gets its configuration from there That would be one thing The other thing which I haven't really looked at with monitoring Because We're a small team and if we're going to use open stack it has to be 24 hours and The guys were working at four o'clock in the morning. They are not going to follow anything open stack they want a red light to come on and We do that with nodules and truck and things like that and When the red light comes on they click on the instructions and do they have to relaunch something do they have to Call someone or whatever Heat by default maybe So that's you You don't you don't configure when you install It should be by default He is running and is saying that these services have to be up that would be very much very much simpler Gotcha So just a really basic configuration that I'll install to that you can work off of and and commonality between the components So you don't have to do each one of them the same Exactly and most of the choices that I was supposed to make Seemed simple to me when installing open stack at a proof of concept. I didn't care about Cupid or rabbit or whatever if I just pushed a button and Given an admin password My ideal would have been to put in put in a DNS name of my controller and When I'm finished I can point to to the HTTP port of that server and Put in the admin password and I would have an open stack running and that would be perfect And then I install then when I install A swift or a cinder or when I install a data storage module it should only ask me what are the Disks I can use and then it should present those Gotcha, so we need to make it We need to be able to make it consistent across releases and then within a release We need to have some commonality or consistency across the cut the services Okay, so some way of being able to have here's your core. Here's the next tier it. Okay That's good Right Okay Good, so you need more of them that actually talk about integrating the different Open-stack services in different ways as you're trying to What was the last part? Are they the ones that you see today? Are they not focused enough or clear enough on the use case that they're trying to solve that you can really? map them Okay, there are some up there are some up on the website. Yeah, we should talk about that Yeah So so we are out of time But Ruchi I always have time for you Okay Alrighty, so thank you all really appreciate the conversation and the thoughts and again We've got more opportunities later on this week So please come join us tomorrow afternoon and let's continue the dialogue and I will go ahead and mine the ether path between now And then as well. Thank you