 So my name is Stefano Maffulli, and I'm the community manager work at the OpenStack Foundation And today we're going to talk about a little bit About the tensions inside the community and try to have a debate A lively one, so we're going to be welcoming questions also from the audience to gentlemen have agreed to represent Two sides of the community if you want So why don't you guys introduce yourself with better words than I could be using I'm Randy bias the CEO and co-founder of cloud scaling We're well known and regarded for doing a lot of the early production OpenStack deployments for Korea telecom Internet and AT&T And before this I have a long history in the cloud I worked at a company called go grid which was the second public cloud provider in the United States and I built the startup before that that was a right-scale competitor that was I essentially a cloud application management dashboard And I prototyped that on Amazon's elastic compute cloud in December of 2006 while it was in private beta before most people knew what cloud was and before That terms had been Coined and I've been blogging and talking about cloud at both the infrastructure and application layers ever since Hard to hard to match that Scott Sanchez director at rack space and do a lot of evangelism Join rack space about two and a half years ago to help build out the OpenStack ecosystem and Working with Mark Collier and the team that has moved on to the foundation and Jim Curry and those folks to Help a lot of folks just understand the value of OpenStack and what it can do for the users once we all work together to build something and bring it together, so We kind of proposed this talk we submitted similar talks that got voted on reasonably equally and Figured out how to combine them and just say hey, let's let's represent You know Randy's kind of grew up on the on the infrastructure side and very heavy view of how all that should come together And I've been more focused on the user side and that's hopefully what we are going to talk about today A frost dichotomy, but it's okay. It is I mean I spend as much time on the infrastructure as you spend on the users But it's right. It's definitely we have to pick a side here. So those are the sides we picked today So let's let's get started then since you already mentioned it I You know OpenStack as a project has been growing very fast very rapidly. It started with developers started with solving solving problems and it's been Historically probably driven by developers meeting at the summit the initial summits if you think about it We're just the design summit, which is now a very small session a set of sessions down do in the corridor and the the user side of the Summit itself has become much larger. So How do you how do you guys see this this? Tension between users on one end that demand features and the infrastructure or the developers Driven development of OpenStack Is there what what's your thought? What are your thoughts? So I got asked at the end of my AWS repatriation talk on Tuesday I got asked what do you think the biggest challenge is to OpenStack and I had to actually sit back for about 30 seconds and think about it and You know some of this stuff's been percolating for a while and that and the sort of epiphany I had right at that moment and that I explained to the crowd was that there's sort of a disconnect between the wishes and desires and intentions of not to but three different constituencies You have the end users of the cloud and from now on for the rest of this debate I'm going to refer to end users as people who consume the APIs of a cloud the publicly facing APIs to deploy applications You've got the developers around OpenStack And then you've got the operators the people who build deploy and actually run a production system of OpenStack and their desires are very disconnected The end users all want standardization and interoperability. They want a common platform They want OpenStack to be ubiquitous so that they can build apps and have them have them run on any OpenStack cloud The operators all want to be able to get in under the hood of their car and hot rod it This guy over here says we're a VMware shop. We've got to have VMware that guy says I need EMC that guy says I'm doing and that guy says I mean I need VLANs and so on and so on every single one of those guys Kind of wants to have it their way on the cloud operator side in the middle You've got the developers who have mostly to date been taking input from the cloud operators And to some degree ignoring the end users of the open of these OpenStack systems the deployed systems and the developers You know with no offense meant largely are trying to scratch an itch They're here because they can do innovation and they can build something new They're very excited and you know that passion is great for the community But a lot of the times disconnects show up in terms of what the developers deliver as it doesn't necessarily feed Especially the end users and also quite often the cloud operators actual desires. I Definitely feel the disconnect and have for years between the developers that are here and Designing what should go into the next release and what I hear when I go out and I talk to SMBs or startups or enterprises about what they want to do with it. I think they're there really is a disconnect Between the developer group and the consumer group of users, but the the providers. I also think are Working for a provider you came out of that space as well. I think that there's there's often a disconnect there between Where a provider thinks they want to add value or be differentiated and where the end user the consumer user Actually wants to see that value. So you mentioned I want to pick a particular kind of storage or I want to do something Different at the infrastructure level So the developers that are here that are building OpenStack Feed on that because that's that's the cool stuff that's happening But the end users don't necessarily get the value out of that or they may not be ready to consume the value out Of that for two years and there's a lot of things that could have been happening in the meantime to make their lives easier Or make the outcome for them better so What what you're saying is that what I hear you saying is that you have we have this tension and Maybe the project since it started without an architect in mind without having The one person that has the vision for the project and where the innovation will drive Is how is that shaping the innovation inside OpenSack? How is that because I'm you know, I'm going back to some some Some wasn't it Steve job that said the users don't know what they want You have to tell them you have to give them the innovation because if you wait for them to innovate They will never do it maybe an offensive way of describing the users of Apple products, but in what what do you think? I mean we don't have that Steve jobs inside OpenSack Is that a limitation or how do you think the innovation will be coming from OpenSack? I mean, that's a really hard question to answer I mean we're a different community than the other open source communities that came before We're charting our own course in many ways And I don't think it's fair to compare it to a sort of communities that have had benevolent dictators On the other hand, you know, you definitely see Some shortcomings in the technical decisions quite frequently in OpenSack For example, the default networking model is completely and utterly broken in every way possible that you could pop That you could imagine for a production system and it hasn't been fixed in you know years And if you probably got you know, ten different developers around the table to talk about it They give you ten different answers about how to fix it and none of them have a network background Right and so that's a little bit of a problem On the other hand, you know, I do like this democratic process I do like the fact that we come to conclusions by going through a struggle of ideas Where the best ideas rise to the top I mean, you know, I put a lot of effort into building a cloud scaling team to have a certain amount of diversity of opinion And I got a lot of opinions back home And you know, the whole reason for that was to build a team where people could find each other's blind spots Because quite frankly in the early days when we built off of my single opinion as the benevolent dictator I made a lot of bad calls in terms of the technology I made some good ones I made some bad ones But what I didn't have was a good track record and no individual I think can have a good track record But a group of individuals acting as a team can actually work together to have a very good track record In tactical and strategic decision-making from a technical architecture point of view But you actually have to construct it that way We don't really have an architecture team to replace that in OpenStack, right? Amazon Web Services has an architecture team, I don't know if people knew that You know, I have an architecture team, you know So why doesn't the OpenStack community have an architecture team to supplement the technical committee that can really provide input, right? Because at Amazon Web Services how it works is that if you want to do something new or different that's going to change the architecture You have to take your idea out to Werner Vogels and James, I forget what his name is, Marova Madrova Huh? James Hampton James Hampton, thank you And there's several others there and then you basically have to prove that your idea is valid And they beat up on you and you have to keep coming back until, you know, something comes through So that's, it'd be nice if we had that It's a different kind of meritocracy It's a meritocracy with a little bit of a wisdom and oversight added So I think that the way that we as a community do code review as things get written and committed and checked When we look at the user committee and some of the recent efforts spun up around that Talk about an architecture overlord group that keeps track of things I think that that group shouldn't necessarily be technical architects as much as it should be users, right? And so when you think about a feature, you think about a decision or a direction that fundamentally alters the path that we're on I think it's the users that should have to kind of check the box and say yes And that user group isn't just the end consumers, it's also the providers and the operators and other things I think a lot of the decisions that get made here at the summits and in between are driven by kind of the new hotness Or, you know, what the vendor that they're representing is in the market selling And that doesn't always necessarily bring the best outcome for the end users Having said that, we've made a lot of great decisions And the number of users that are here consuming the platform is evidence that for the most part we're doing the right thing But like you said, there's been decisions made along the way or new projects spun up or other things that users may look at and not feel great about End users can't make architecture decisions End users are for providing requirements into the system And so as those business requirements are interpreted, you figure out how to build an architecture that serves those business requirements It's like going into a doctor's office and telling them, I've got the, you know, I've got the plague give me penicillin, right? I mean, you can't go in and do the diagnosis yourself because you're not the expert What you can go in is you can go in, you can explain your problem, and you can actually help the doctor understand what you're trying to accomplish And then they can actually solve it for you And I think that's finally happening, right? We've got a large of mass of users, whether it's service providers or the bigger group Which are the people building applications on top of OpenStack That a lot of that's happening back through the folks that are now representing, right? If we look up through Diablo, Essex, there just weren't really a lot of users to have those conversations with But there are now, and I would guess that most of you have had actual conversations with actual customers about what they'd like to see in OpenStack How they wished it worked Let's And so I'm not saying that they should come in and dictate the technical architecture Let's stop using the word users I'd like you to use either operators or end users because right now if you look at the user committee There are three people on it, and they represent cloud operators Right Ryan Lane from Wikimedia, Tim Bell from CERN, and JC from eBay And all three of them are built and operate their cloud, they are not the end users So that voice that you're talking about, I totally agree I think we're in alignment that it needs to get in there, but it's not there It's not there today The user committee does not have end users of OpenStack in there, you know, basically giving that voice And I completely agree that we need their requirements in the system And I think that it would shake loose a lot of this crazy spaceship building that you sometimes see in the OpenStack community Like, you know, does it make sense to go build X, Y, and Z if, you know, the actual end users who are consuming OpenStack clouds Just don't care not consuming that Yeah, I completely agree, I think that the method that that occurs in can't be in a vacuum user group The stats and the data that's coming End user group The operators, to me, are almost the least important group Yes, I agree The operators should have the user committees in their own companies that drive what they want to say But the mass group of people that are over time going to make OpenStack more successful is not the operators It's the people consuming the things that all of that is providing It gets, we got to that point finally We got to the point where we finally facing developers that are using the OpenStack clouds OpenStack powered clouds And when we get to that point, we start to getting a little bit probably closer to other set of problems And Randy had a blog post during the summer about this, about talking to these developers And maybe you want to discuss a little bit about what are the differences The new things, the new challenges that you end up facing when you go beyond OpenStack itself as the software When it starts running on top of real infrastructure and when you start bending OpenStack with opinions Giving opinions to OpenStack to an OpenStack powered cloud What is that entails for developers? Yeah, I mean, I guess it's funny because I started off in cloud actually at the application layer Building this tool that would deploy applications on EC2 So even though I am mostly historically an infrastructure guy I have a lot of hands-on experience actually using these public and private clouds as a developer and user Writing Chef code, writing Ruby, all that stuff Writing low-level stuff to call the EC2 API, XML parsing, like pretty in the weeds stuff The thing that became really apparent to me while I was at GoGrid was that The infrastructure is, even though it's sexy right now, is pretty much totally irrelevant from a business point of view There's no inherent value in infrastructure Nobody gives a shit when it comes to the business It does not make, if you have an EMC VMAX, right, deployed, and your competitor does Like neither of you has competitive advantage over each other All of the real business value is up the stack from the infrastructure and the platform and the applications That's where the true business value is But instead of paying attention to that and saying, okay, let's standardize on what the infrastructure looks like Let's only have a few flavors Like there's only a few flavors of electricity or a few flavors of Linux distributions What we have is we have a bunch of snowflakes Every open stack deployment is its own snowflake that's completely unique Everybody when they want to play with it, open stack wants to build a yet another snowflake Because they feel that they've got some different requirement So that they need to build their infrastructure in some slightly different way Which doesn't serve the purpose of allowing the end users to be successful And it confuses things in the development community because we're an inclusive community And the development community wants to serve everybody's request They want to serve the cloud operators and the end users They want to respond to the fact that this guy over here wants support For some strange esoteric storage system that nobody but him is going to use And if you look at the user survey results, you'll see there's a long tail Of all kinds of different technologies that people want to use with open stack And every one of those actually incurs some technical debt And I know it's going to be difficult to get everybody to rather run the table Around a few flavors of open stack that are essentially interoperable and compatible But it seems hard to realize the value of the platform and application pieces That we want to run open stack unless we can actually do that It's one of the things that makes me question why there seems to be a lot of friction As a community when we try and do things that are more up the stack To try and serve those end users better When you talk about the providers, they're trying to serve those same users But they're doing it really with some blinders on In terms of, like you said, thinking this storage will be better than the storage Or whatever it might be And that friction that I continuously feel up the stack Wherever it is, it is frustrating because as a community Those are the people that matter The folks that are building clouds with open stack We're trying to serve those users The people that are here learning how to build applications for open stack You are those users And a lot of the discussions that are had about Should it be this format or this format I feel like there's this divide between how much should we decide for them And push to them and say this is just the way it's going to be Should it be three flavors or 30 flavors? Should it be one kind of storage or 50? Should we push that to them or should we let them pull and tell us? I actually don't think enough of the people building applications on open stack Or any cloud for that matter There's not enough people that actually know what the heck they're doing yet And I do think that the smart people in this room need to tell them more As opposed to give them more choice Well, I feel like it's a dialogue I think that's part of what you're saying is that We need that virtuous feedback loop Where we get the requirements in that Don't tell me how you're sick Tell me what the business problem is that you're trying to solve So that we can talk about that It's that whole challenge that Henry Ford had around talking to people And they said, a car, what's that? How do I feed the car grass every 20 miles or whatever? I mean, I want a faster horse, make me a faster horse Except a faster horse is a longer process And you can have any color you want as long as it's black Exactly, so we're at this tipping point Where we're starting to figure out how to build these private clouds And deploy applications on them that are highly scalable and elastic And we need to get that virtuous feedback loop in there Not just an open stack but even the product companies That are building stuff on top of it as well Yeah, the folks that were here exhibiting And I was amazed when I walked in this morning That the entire expo hall is completely gone overnight But the folks that are here, I mean, we all have conversations With each other and with our customers every day And we've all got different things that we want to make available In open stack for whatever reason But I think you take a step back and you look at How is a user actually going to consume this over this? Is there value in doing this over this? Should we consolidate the way that they look to the users And abstract that complexity? Or do we expose that complexity? Is there value to the end users in those cases? And I think in a lot of cases the answer is no But the users don't necessarily yet know what they're supposed to ask for Right, to go back to the original question Do they know? One of the things that was emerging from your conversation Was that it seems that open stack is one project One set of code but still we end up getting A lot of different snowflakes type of different implementation So what you think is If the code is the same and we should have All the same clouds with the same behaviors What is going to be the differentiating business factor? Why am I going to be able, as a company Investing in open stack, how am I going to say I'm going to be better at this than another If everybody behaves the same So there's kind of two pieces there, right? So if you run the same software You don't necessarily have the same cloud I mean, people need to stop thinking about open stack As being like downloading my SQL and creating a database Create database foo, semicolon, boom, your database is up It's not like that, it's like downloading the Linux kernel Enrolling your own Linux distribution, that's what it's like And so, you know, all the choices you make Once you download it is what turns it into a snowflake Right? The simple example I gave on Tuesday During my talk is IP auto assignment I have two open stack clouds One I've got floating IP auto assignment And the other I don't Configuration options, same code, same release Completely different behavior, right? So that's a problem, that's why I keep ranting on The fact that we need these flavors Because then you can compare it, right? Is this an AWS compatible cloud, a Rackspace compatible cloud A vCloud compatible cloud, what is it? What kind of open stack cloud is it? And then the second part of the question was Remind me How to differentiate business How to differentiate So like, hosting providers have been very successful Like Rackspace, pre-cloud Without a lot of differentiation And the reason is that, you know Asking to differentiate infrastructure is like Asking to differentiate water and electricity, right? It's like, oh, am I going to get water from this guy Who's distilled it and has colored it red Or am I going to get water from this guy? No, you're just going to want to turn on the damn faucet And the water comes out, that's all you want Because what you're actually trying to do is the application Of that water, of that utility, right? You just want to boil something or cook something Or if it's electricity you want to power something You know, you don't really care about that Lowest level commodity So these service providers need to be looking At ways to actually help customers Solve problems where the business value Is that the platform and application layers Because that's fundamentally where there's true value Whether I use an EMC and you use a NetApp Or Seth or Gluster or something else That's, there's no inherent value In that infrastructure technology to a business Yeah, to use the water analogy, we want to make it easy To get the water when you need it and make it hot or cold When you need it and give you a comfortable glass To drink it in and that's where the differentiation Should be coming from, but you're right, a lot of people Are looking to re-engineer how the pipes look Behind your sink that no one will ever see Exactly Hey, this water comes out, you know, with more air in it I really don't care about that, right? It's evaporated before it gets to my lips How does it taste when I drink it And how easy is it to use I think Or where the differentiation needs to come from The whole experience of using it And how it benefits me is where the differentiation Should come from, but as a global community I think the folks that primarily are represented here Not all of us have made that journey yet Maybe this is a good time to ask for questions Ryan So I just wanted to make you aware of the three users Many members are all operators But we also have large groups of users Who also give us feedback from these organizations But past that, realistically, the reason that We've focused on operators so far Is because the feedback that we're actually getting From the community as a whole The priorities at this point are so dire On actually running OpenStack and making it work That it actually trumps any feedback That you're getting from the users The biggest feedback that we get Is that OpenStack is too hard to resolve And that it's too hard to operate If you can't get past that point You can't even get people to use OpenStack And that means they're not going to have users To begin with That said, our first iteration of getting feedback Is mostly directed to operators So our next priority is definitely getting it from the users Great Yes, sir I have kind of a super long response to some criticisms That you hear of engineering and the snow place Not criticism Observation Healthy debate and observation You say we should have a dialogue The way you have a dialogue in the business world Is you offer different products And you see which ones get bought That's what's going on with the snowflakes We're actually doing the dialogue In a way that makes a difference I'm not sure you're really honoring The significance of what the engineers And developers are trying to do Everybody who puts in a new kind of file system Or whatever, why aren't they doing it Because they think it actually delivers Something that's valuable to end users Right No, I value it But so I was a Rubyist for a while I haven't touched code for a couple of years now But one of the things that frustrated me the most About the Ruby community Is that at the drop of the hat They would reinvent a new piece of code Like, oh, I don't want to use a messaging system In Java So let's just write one in Ruby Because one doesn't exist That's great One out of 20 times Some amazing thing came out of the Ruby community The other 19 times Garbage came out And you would go out there And I as a Rubyist would try to use tools And I would go and I'd find out they were half dead There's not really any community around it No contributors And code isn't where it needs to be And I don't have the time to go fix that And it was very, very common There was almost like a graveyard of projects That were subpar And we're out there Just kind of taking up space in the mindshare And so I agree with you to a point But I think the reality is Is that we don't need to go out And invent everything in OpenStack There's lots of other things out there Why aren't we building our own database? Why do we use MySQL or MariahDB? I mean, we should be thinking about that And I'm not trying to criticize to criticize But why did we build Keystone? There's so many identity management platforms out there That are extremely robust Why isn't that a pluggable part of the system? And if we were going to build it Why doesn't it use OAuth 2.0 Instead of some bastardization That looks like OAuth 2.0 But isn't OAuth 2.0 and isn't interoperable? I mean, those are design decisions that don't make sense They actually hurt us and incur technical debt That is not good for the community, the developers, The operators or the end users So my only comment there Would be the way that we've done things like SDN In Neutron, right Where things are pluggable And it gives the community a chance to experiment And the users a chance to pick what wins I love that model, right Storage is the same kind of thing, right The way we started doing storage wasn't the best model It was a community we figured out Hey, we should have more drivers We should move this thing out Let people experiment more Let's figure out, you know, let's really innovate And so OpenStack, for example, has become the place Where SDN is coming together And where the real innovation is being driven from That's great, the users are picking the winners You can see in the user survey what's starting to take shape I love that Other decisions that we make as a community Whether it's about projects or related projects Or ancillary projects or any of the other names That we give things If you actually go back and look at what the users Are asking for, it's not always those things You know, you brought up databases as an example, right We focus a lot of time and debate, healthy debate But debate about different things That aren't always what the end users, The consumers of these platforms would be looking for If we ask them Okay, so we have so many flavors And we are fishing so many snowflakes As an operator or consumer of OpenStack Do you have any suggestions, you know, that we can make The best out of the currently known non-mayors? A lot of folks that are using the Rackspace Cloud Do that through some kind of abstraction layer And it's not necessarily the best solution You could argue for or against that model For a lot of companies But that comes from the fact that many people moving To OpenStack and OpenStack-powered public clouds Are moving from Amazon or moving from VMware Some other platform that they've already coded against And so to the Snowflake example There's some things which make even an abstraction layer hard Like the way I give you a network Or the way I authenticate you That doesn't necessarily just change your target endpoint And be done But I think you're going to see a lot of that No matter how hard we as a community work We're still going to have a bunch of that In the foreseeable future And they're going to have environments That encompass technologies that are in OpenStack too So I think you're going to continue to see Some of that abstraction layer Whether it's homegrown or some other project The important thing, you know, what I want people to take away Is that we do need the flavors and not the snowflakes, right? I mean, that's great that people want to experiment I want them to experiment I'm not saying don't experiment, don't innovate I'm just saying that for the stable production OpenStack deployments, you know There needs to be some opinion in there And they need to be somewhat more standardized And we need to use things like ref stack Which Josh and others are working on Combining with Tempest tests to test those flavors Like here's the AWS flavor Or what we call the elastic cloud flavor Here's the Google Compute Engine flavor Here's the vCloud flavor Here's Rackspace, public cloud, whatever they are And then, you know, people can actually check To see whether they conform to compatibility And interoperability with those systems And then, you know, kind of to your point, you know Hopefully end users will choose what they like And then, you know, the winners will rise to the top And we can all get where we want Which is, you know, the final emergence Of a few things that are dominant This car drives on the left This car drives on the right So I'm not saying this to pimp my personas talk after lunch At 1.30 in this room But I don't think the end user characterization Is even useful So you've made the distinction between operators And end users, I think that's good But you've got the people who buy the cloud You've got the people who deploy the cloud And you've got the people who operate the cloud And then you've got the people who deploy applications On the cloud And the people who deploy applications on the cloud Actually have very little input Into the technology choices of what gets deployed That's the problem So when you said users decide who wins I don't think they do I think the people who buy clouds decide who wins I think that the people who are building the applications That are influencing or even more and more making the decisions About where those applications should live Are ultimately the ones that are going to decide Who wins and who loses So if you're a provider You make a choice to build Snowflake A Version of OpenStack And that's not what the people Building and deploying applications Ultimately think is the best for them Then they've made the wrong choice And so I agree with you that the end users Of these things are not the ones influencing What necessarily is going into a data center What's going into OpenStack And what's coming out as the product But they should be And if they're not natively in our cycle They are at the end of the day with their wallets What's interesting is that the tension in our community Actually mirrors one that exists in the enterprises Which when you look at them They're sort of the centralized IT infrastructure teams And then there's application developers I'm talking about mainstream enterprises Not tech companies where it tends to be a little bit different And a lot of these application developers today They go to centralized IT folks And they're really trying to reduce their risk Of their deployment So they give this long laundry list of requests Including very specific hardware I'm deploying this application I need F5 load balancers Because I'm using iRules I need EMC storage and so on and so on And the centralized IT team Their whole purpose in life is to cover their ass CYA, that's how they have to make decisions Because they're on the hook if anything fails So in order to make sure that they can meet that request They'll say, okay, you want this much stuff I can give that to you for $10 million in 18 months But that application developer He needs to get going now Because it's all about tying the market for him It's all about trying to be successful And delivering new value to the business Well, maybe I'll go to Rackspace Or maybe I'll go to Amazon And I'll just get up with a credit card And go right now And he gets that much Or she gets that much of their actual requirements That laundry list becomes this And they fit their application to that system Now, yes, they had to conform to the infrastructure But on the other hand They got the value of getting to go immediately Paying by the drink and so on And I think that that's something that We have to think about If we want to help enterprise centralized IT teams The operators be successful at deploying OpenStack clouds The value of the OpenStack cloud has to be similar To the value of an Amazon or Rackspace Or one of the other major public cloud providers Because that's the only way for them To actually fix that sort of dysfunction Yeah, the biggest way the end users will get value Out of cloud, not just OpenStack Is to build for it And not try to build it for whatever broken Application development models they have now I just add that I think as the project started We were serving our own needs And that's why a lot of people were involved And users were us And users were us So now this is expanding The project's getting larger Now commercial interests are getting involved And we're getting some enterprise customers And end users starting to get interested So what I would just finish with is I think one of the real benefits That we don't have a benevolent dictatorship That we have a merit-based activity Inclusive organization That it's always self-balancing And so initially we were balanced Focused on just our own needs And as we evolve And we start including more organizations More applications running on OpenStack That will constantly be rebalanced In some decisions we've had But that's kind of the price we pay For being this kind of organization That hopefully, like Keystone Parts of Keystone being broken We will fix them Because it will be brought up And people will actively go off After that problem Right, there's overhead to our process That we've chosen But the best idea should emerge over time Yeah, I've got a couple of sessions About OALF It feels to me like the shift From we're building for ourselves As providers, as infrastructure folks To the users is not happening As fast as the actual shift Of attendance at these things To actual end users And so that's something We as a community should pay attention to So I know this is the moment That you've been dreading Since you got on stage So in specifics I've been doing what I can To address this problem Like my original approach was Everyone should do what I say Which obviously does this, Kale Then it was the creation Of the user committee During the drafting process Which I think has been Not as successful as we would have liked But certainly has been very important Very important Now it's ref stack But just from each of you If you have maybe the one thing That you think we as a community Should be doing To constrain, sprawl In our options The thousand option problems Where 90% of them don't really work What is the one thing We should focus on? The one thing I'd like to see Is a formal acknowledgement Of the fact that there should be Sort of flavors of open stack Not snowflakes And that we should use ref stack And or tempest And in the CI system be testing The AWS configuration options For open stack Because right now According to my team I did not check this myself But there's a bunch of AWS Compliance tests That we don't actually run In the CI system Because the default open stack Options actually don't cause Those to fail So I'd like to see us testing These flavors in the CI system And sort of tracking from release To release That we're making sure That we have a flavor of open stack That's conformant With all the flavors we think Make sense And we should allow anybody To come up with ideas For making flavors It should be a really easy process Just like it is to add code So that we can get a whole bunch In there and then what people Choose to use Is the top end We'll all follow that So we have set up ref stack To run all the tempest tests Including the sort of Not on by default one So we can look at it And say oh well The reason we don't run those tests Is because nobody's cloud Actually supports them Right Go through that Yeah and thank you For that work Josh The one thing that That I would look to do Is to better Maybe more crisply define The operator user And user type of roles And make sure that those roles Are adequately represented In the technical committees And other groups Whether they're elected Or appointed or self identified That the ratios Maybe it's every six months When we come to these things That we survey and we look And we say okay How many people fit into these groups Let's make sure that the Representation we have on the groups Making the decisions reflect that I think to Sean's point A second ago That's kind of Switching over time And I think the balance is Going to be If we look a year from now It'll be much heavier On the end user side And we should make sure That the efforts we're doing Like Josh or anyone else Represent the people That are consuming What we're building Let's take one last question So is it possible to have Experimental or lab section In open stack So that you know For my requirement Maybe it's a special requirement For telecom Maybe like you know All the instances should be Extremely you know In the same host Currently maybe the Scheduler is not doing it It's maybe it's supporting for Other and other cloud providers But for telecom This is a requirement Could be So if we turn on this Flag or you know A feature, experimental feature It helps people to reduce The snowflakes And try it out And then you know Yeah that's a good example Give it back to the community Right there should be A flavor or a couple Flavors for carriers Because they have Very special requirements So Basically opinions Publish and maintain Opinions for open stock So So I have one last For the panel But I'm really afraid to Throw it at the end So any other question So this isn't really a question As much as it is a little A bit of an opinion But talking about the Snowflakes versus the flavors I think having things as Plugable and modular as possible Is how you speed innovation And allow people to research In a specific niche of the stack And that's highly useful Going to flavors though I think the issue of how hard It is to stand up a new Open stack instance And get it useful for end users Perhaps reference implementations Might be a better way to think of flavors And come up with a standardized set Of reference implementations That go through tests And have documentation Of here's how you stand up This reference implementation And meet this set of Requirements And that might be the area That an architecture board Or something might be useful for To take hey is this new module Or is this new feature ready To be put into a reference Implementation Yeah that's really the intention It's to get the flavors Defined and then to use That to actually build You know heat templates Or some other kind of description That triple L or something Like that can then use To stand up specific deployments But I just want to point out real quick And I know this is going to be Real hard for people to swallow But you know one of the epiphanies I had on Tuesday about the mission The original open stack mission Is that at the very end it says The objective is to be simply Installable and massively scalable Those are two very opposing Approaches right You know I've built my system To be massively scalable And it's freaking hard to make it Easy to install And if you go and you say Okay can I get Amazon Web Services And just go installing Amazon Web Services With a push button no you can't Because it's really massively scalable And so those that's part of the reason I think we need these flavors right Because what somebody needs in a lab On a couple racks is really different Than what somebody needs across town Or 20 or 30 racks right Like when I pan the open stack networking You know it's fine across one or two racks It's totally fine it's absolutely acceptable For a lab environment it's just not acceptable For production but why isn't there Like the easily installable lab environment Flavor of open stack right That's like really vetted you know To plug my competitors product You know something like piston has Got an opinion in it so you can stand it up Really quickly on five to ten servers Without a lot of trouble and I think That's very useful for very specific use cases Josh I'll argue with me and it's okay And then you know we're a little Different because it you know I do Average rack deployments of three to five Racks and I need a multi network strategy And getting the network setup takes the bulk Of our time because it's not just a couple Switches it's like eight to twelve switches Initially so we get the same question About our public and private cloud Like why isn't it a hundred percent The same code base well our public Cloud spans many global data centers And our private cloud is a download That you can put and run in five minutes Right and it's the same outcome For the users it feels the same Once you've installed it and used it But the way you get there is different And if you have conformance testing For rack space public cloud you could Have a private cloud actually You know meet those conformance Absolutely I think one last note On the flavors you know that You kind of have different use cases For the infrastructure and the way The infrastructure is built and the Things it's trying to achieve and Then you've got workload flavors And the end users they want flavors Of cloud that help them With data problems or with web scale Problems with other things So to wrap up I think that since we run At the time and thank you the panel I think that we're living up to the Problems of being the operating system Of the cloud it looks like we really Have so many different options so Many different things and we're Doing a lot of things well correctly So no matter what who wins Users versus developers infrastructure Makes the choice it looks like we are Struggling and that's the normal Way to go so that's to be expected Thank you very much for attending And