 All right, everyone, we're going to get started. I'm Ryan Lane of WCAG Foundation. I'm joined today by Tim Bell of CERN and JC Martin from eBay. And we're going to be discussing the OpenStack User Committee. And we're going to be giving some information about feedback and metrics from the survey that we've conducted. So who here is familiar with what we're actually supposed to be doing to begin with the OpenStack User Committee? Good. So now you will, hopefully. So when the foundation was formed in the bylaws, it was one of the things that was brought up in the bylaws is that user committee would be founded. And from that, the board of directors would appoint one member. The technical committee would appoint another member. The board appointed Tim Bell. The user committee, I'm sorry, the technical committee appointed myself. And the bylaws said that we would appoint a third member. And that is JC Martin of eBay. And from there, we would create the initial user committee. So the initial scope that we're looking at, first of all, is that we're going to define the bylaws, the actual structure of the committee. That's the first thing that we have to do. I'm going to go into more information about that soon. The next thing that we're going to do is to define the actual types of users that we're going to be representing. Third, we're going to take information from the users as a whole. And we're going to aggregate this information. And we're going to present this with actionable proposals to the technical committee and the board of directors. Next, we're going to take information from these users. And we're going to track what they're doing, how they're using the software. In the software, what things they're using, like if they're using KVM, if when they're using Nova, or if they're using Zen, or when they're consuming the APIs, if they're using XML format or JSON. And then we can take these things, and we can present aggregate stats, and also be able to take these and provide them as information back to the technical committee, to the developers, et cetera. Last, we're going to work with the managers of the user groups that are currently in place globally around the world. And we're going to help them make their user groups more, they're going to help strengthen them and make the entire system kind of work better. So the actual structure itself. We've been working on this for the past few months. We have a document online that will be in the slides, we'll be sharing the slides later as well, with links to where you can go and actually see how the structure works. But I'll give you a quick overview. First of all, the structure of the committee is to have a number of representatives in the user community that will represent the user community as a whole. And this means that we'll have members that are representing all of the different types of users that we've defined over the market segments that we're defining, as well as over all of the geographical regions that we're also defining in our documentation. So with this, obviously the community or the committee can probably grow pretty large in this. Because if we have a very large number of types of users and a very large set of geographical regions with a lot of market segments, then the committee can become pretty unwieldy. And what we want to do is kind of limit the size of this to make it kind of manageable, while still having it large enough to properly represent the community as a whole. So we have a number of things where we're limiting the size. The first one is that we're only going to allow one representative per company that is being represented total. This is to ensure diversity. It could be that we have one company that actually covers very large numbers of market segments over very large number of geographical regions, but we feel that it's better to have individual members from different companies that are representing all of these things that we get more input and better input from the community. Next, we're going to limit the number of representatives that we have from any single market segment. And as well, we're going to limit the number of representatives that we have in any geographical region. But in that limitation for geographical region, the way that we're looking at doing this is to have the representation be roughly proportional to the size of the representation in those geographical regions. So regions that have a very large number of users are going to have more representation. We've already gotten a little bit of feedback on that, saying that it may not be terribly fair to some regions. That's why we're saying it's gonna be roughly proportional. So some regions that we feel have the potential very large amounts of growth will probably have a larger representation than other portions. Also, there's two seats that are reserved. There's one that can be appointed by the board of directors and there's another that can be appointed by the technical committee. The initial way that we're going to bring community members in is that we're going to appoint them. Originally, we wanted to do elections for these and we got a lot of feedback from the board saying that for the initial set of the process, it's probably gonna be too slow to do elections. And we want to get the committee set up and actually bring in data and being able to present these things. So we'll probably set up the initial committee by having appointments for all of the positions. And then after a certain period of time, we're thinking probably maybe a year or six months that we will hold elections for all of the positions that are currently there and people will have to actually try to get elected for the positions they've been appointed to. Once all of these folks are elected or appointed, we will have a chair and a vice chair that will be elected from voting process inside of the committee itself. So going back to the actual types of users, I think this is something we can all relate to. We're all users, right? Who here is a user? Excellent. So now I get to categorize all of you. The first type of user that we have is a consumer. These are people that are using cloud services that are OpenStack cloud services. And this could be people that are using storage, cloud storage or cloud virtualization services, et cetera. Or this would also be people that are consuming the API but not specifically people that are building software and services using the API that are using the build for OpenStack trademark. That's something separate. The next group is the operators. This is the people that are actually running the software. I fall into this category. So far, I think this is the group of people that we've gotten the most feedback from total. Operations engineers love the complain. I should know. I love to complain. Next is the ecosystem partners. This is specifically the group of people that are writing software and services that are using the build for OpenStack trademark and are held by those requirements. Lastly, we have distribution providers or application vendors. These are like Red Hat, Susie, Canonical, PistonCloud and other groups of people who are making OpenStack distributions and or making appliances and things like that. So the current status. We have the initial members. That would be the three of us. We all have NEA signs. So any of the information that is shared with us is private within our own group. We don't share it outside of the user committee at all. Any of the survey information that comes in only comes to us. We provide only aggregate statistics. Same with any of the other information that's shared with us. This is also another reason that we have to kind of limit the size of the committee because every committee member is required to sign an NEA. We've also created a mailing list. Currently this mailing list is set up for anyone can subscribe and read but only the committee members can actually post to the list. So we're looking at changing this possibly to instead make the process more open to where anyone can post. We're still kind of figuring this out. So if anyone wants to talk to us about how you think we can better work communication pathways we'd love to involve you. Lastly we're finishing up the structure which is why we're presenting it to you now. And also we've started collecting information with the foundation. And this is more than just the survey. This is also, this is like the membership directory. Basically we're gonna have a centralized system that holds all of the information for everything in the foundation and we'll use this system to access data and provide, like create the statistics and aggregate data and such. The thing that we've done that we're gonna be presenting on soon is the initial user survey. This is also going to feed into the system. I don't think it currently is. Is it currently feeding in? Oh good, it is currently feeding into the system so. So that should help us. We have a number of priorities for 2013. Not working anymore. So the first of all and the most important thing is this for actually, for us to get the committee set up and working. After that we're gonna start expanding the membership by doing the appointments. Next we're going to look at all of the data that we've collected and we're gonna start forming a comprehensive view of the community so that we can actually give reliable feedback to the board and to the technical committee. Lastly we're gonna set up the communication pathways. The first is gonna be changing how the list works or setting up a new list or something along these lines so that we can take active feedback from the community that's public. But we also need to set up communication pathways that are private. So for organizations that are not necessarily willing to say that they're running OpenStack or not willing to divulge some information about their clouds, they have a way to provide us with information and such. Lastly we're gonna provide metrics which is coming up next. I don't think this is working anymore. Okay, great. So in March we ran a survey emailing out through the foundation to the various members, tweeting, contacting various people. And the survey would allow people to come onto the foundation site. They didn't necessarily need to be members of the foundation. People could also just register just for the purpose of the survey. And with that they could give us their feedback. We were pleased to have 400 plus answers. And with that it was intriguing to see the distribution of the geographies. So as expected the US was a substantial chunk. After that Asia, so India and China. And then two surprises for me which was France and Germany next. After that there's a huge tale. So we're talking about 56 countries overall. It demonstrates the global aspects of the community. At the same time when we asked people to classify what kind of user they were. So we clearly had a large number of cloud operators. This is understandable given the current state of the project. Not so many cloud consumers. We aren't expecting that the people that are using the public clouds or the private clouds are going to be the ones currently involved in this in terms of the communication paths tended to favor those people who were related to the openstack.org site members of the foundation. And then after that some answers from service providers and ecosystem vendors. So we've got a fair distribution there which confirms much the approach that says we want a balanced user committee that's allowed to represent all those different perspectives. When we come down to company size things fit roughly one third, one third, one third between the different sizes. So below 200 employees, one third, between 200 and a thousand, another third. And then whoops. And then the big guys which are over a thousand. Look at the read your mail. And then when we come to the industries where people were involved so clearly information technology comes out highly. A fair chunk of the academic research telecommunications is getting to be increasingly a significant market. And a fair number of government and defense replies. What was interesting on the industry's aspect is that many users who were working for the same companies actually defined themselves in different sections. One of the difficulties with the surveys is always that unless you write a massive user manual that comes along with the survey explaining the finer details of every single answer which probably no one will read you won't get completely consistent answers. So we should look at this in terms of the total statistics rather than in terms of an individual answer as being so significant. And that's why getting over 400 answers is good because it allows us to be reasonably confident in the ratios that we're seeing. So in this case we asked just what area of industry do you work in? And we gave them a set of classifications like healthcare and finance. So in this case it will be companies whose involvement is in the information technology industry. So amongst the other things we asked the users for along with their industries, their geographies was what things they actually wanted as far as further enhancements goes to the product. This was a free text field and we had over 190 answers. So people spent effort to give us this feedback which is greatly appreciated. The one that came out top this is in priority order. So out of the 190 probably around 20 people were mentioning installation and configuration difficulties. After that the next one that came in was migrations. In particular how we go about migrating from one version to another version without any downtime. Documentation was a key item. Some people wrote just documentation, documentation, documentation as the feedback. And in particular some of the comments were actually not to provide more but to provide easy ways under which you can get at the latest copy. It's also easy to drop into Google and pick up the cactus documentation of the command line. So we need to find ways under which we can mark documentation as archived. And so even though there may be some instances that are running that version, it makes it clear that people should go somewhere else in order to get the info. Security clearly an important item and in particular making sure that the basic communications and infrastructures can be encrypted. Horizon came up quite frequently. People were often encountering that there was a new feature that's coming out. But when it comes out, Horizon wasn't there on day one with the support for that feature. They needed to wait until the next release. High availability, so here wasn't clear what people meant, they just said high availability. Some people were more explicit and said we want the nova infrastructure to be highly available. Others were clearly meaning virtual machine high availability, restart a virtual machine after a hypervisor crash. And then finally active directory. So at the end, probably the active directory one we had three or four people who were saying that to give you a feeling of the kind of curve. The second question we asked people to fill out was on the foundation priorities. So this is separate from what you want from the product. What do you want the foundation to be organizing? Both foundation staff, the board, the technical committee, and the user committee. And here top item by a long way was to ensure compatibility between open stack clouds. Secondly, to look at stability and hardening not just improving the underlying function. So get in there and work out those places that are causing us pain when we're running these clouds in production and fix the underlying root cause of the problems not just add on additional function. Certification and training, putting in place the sort of infrastructure that you get commonly now around the Linux distributions so that you can get certification for the engineers. So you can get the full range of training options from an early start engineer right up to the specialist and guru. And then work through with the user groups, especially outside the US. You can see this clearly from the stats that there is a wide distribution of user groups across the US, but then when we get outside of the US it starts to become a bit more patchy. And there we need to work through the user communities and try to identify how to encourage user groups around the rest of the world. Over to JC. Thanks. So as part of the survey, there was a question, optional question for people to fill out a description of their deployments. There's multiple deployments possible pair users. So what you are seeing here is that there's almost 200 deployments and it's likely that there will be less than half of the users who filled out their deployments. There was an option for people also to specify if their deployment was public or private, meaning do they want to share the information about their deployment? And we are taking that very seriously. If someone is telling us that they are fine sharing their deployment data but they don't want to share it outside of the user committee, we are going to make sure that this is ensured because that's kind of the trust that we want to build so that we can collect as much as possible the information from the users. So when we looked at the deployments, as Tim was saying, it's difficult to put a user manual with the survey so that people fill out the survey correctly. So we ended up with some types of discrepancies where people would check all the boxes or they would basically say that multiple incompatible answers were selected. So bear that in mind. But the clear thing that we can see is that the main type of deployment that we got was the on-premise private cloud. So what it means is that people were deploying open stack in-house on their own infrastructure. The other type of private cloud was hosted. So for example, you are with Vario or other Austin companies or Rackspace and you're running your open stack cloud there. And the last big chunk was the public cloud. So we then asked users to categorize what stage they were in for their deployment. And that's where we got multiple answers which kind of is weird because you cannot be at the same time in POC and production. But we can see that the highest number of deployments were in Dev QA and proof of concept. But a fair chunk was in production. So that's interesting. And the notion of production also doesn't exclude the fact that you can do Dev and QA on the same cloud. So for example, at eBay, that's what we are doing. We are deploying the next version on our previous version. So it could also be the reason why people checked multiple boxes. With regard to the version, almost half of the deployments were on Folsom. And that's great because it means that people are upgrading their cloud. There's only 5% on Diablo. So the good thing is that there's no CAC-T or previous version but there's still 5% on Diablo. So maybe it's back to what Tim was saying is that upgrading open stack is very hard right now. And we had at eBay to develop a tool to even migrate VMs between versions because the upgrade between SX and Folsom was not easy. And it's clear when, for example, you have new projects like Quantum becoming part of the mainstream, it's creating a lot of disruption and people might not be able to upgrade that as much as possible. The other interesting part is that there's almost 10% of people running the trunk. Which is like maybe in their CICD type of project where they run the latest version. We asked then users or users what features they were offering. And you can see that the dashboard is coming up higher. But the interesting thing for me at least was that the compatibility with EC2 and S3 was last. So it means that maybe people are less interested of having like an Amazon like cloud than having something that they run internally. So that's an interesting point. In terms of components that users were running, the main components are up there, right? Like Nova, Glance, Keystone, Horizon, the four main components. And then the interesting thing is that Quantum and Cinder which are new, coming just in Folsom and Grizzly already deployed quite a bit. So that's an interesting point. And Silometer and Heat, they are even not main project right now and they are still having some deployment. So it looks like even if a project is in the inception or incubation phase, as user we still use them because there's value for those projects. Or maybe they are just the users that develop that project that are listed there. I don't know. So the next, we looked at the detailed features. So what it means is that we double clicked on all those components and said, what driver or what version do you use? So the key thing here is KVM is big. So either because it's the default hypervisor and it was the only well supported hypervisor for a while but you can see that the other ones are less than 10% each of the deployments. Then we asked users what storage drivers they were using. And here it's a bit clear. The surprise for me at least was the safe RBD part. LVM and NFS are kind of abuse. They seem to be the easy path to use storage drivers. But safe is not like an easy deployment. So that was surprising. For network drivers, the interesting part is that there's as many open V switch deployment as there's Linux bridge, which is nice. It's nice to see. It's maybe because now Linux adopted open V switch as a core project. So people are starting to be more comfortable using it. Cisco has a big part of the drivers also, which is nice. And then there's the other orders that are there. Identity driver, Ryan was surprised that LDAP was used because it looks like you have problems with LDAP or no one was answering your LDAP questions. So but still there's a third of the users that are deploying LDAP for their identity driver. And in terms of APIs, Jason is a big winner, which is nice, I prefer Jason than XML. The next part, what we did is we looked at the scale. But because there were so many POC deployments, I removed those POC deployments out of the numbers because they were kind of skewing the numbers down to the smallest deployment. And it's not very representative of what people will run in production because they tend to try a lot features, for example, on the POC than they would in production. So there's still a lot of small clouds there, like less than 50 hypervisors, right? And it's 70% of our clouds, which means that in terms of maturity, we will see a lot more skew toward smaller cloud and users that are less sophisticated in operating a cloud because when you operate 50 nodes, it's less difficult than operating thousands. But you can see that in terms of number of nodes, you have almost 5% above 1,000 nodes, which is interesting. So there's the two spectrums. There will be a large community of users that is interested in starting using a cloud and deploying to scale. And then there's a population of very sophisticated users that are already running a very large cloud at scale. So number of scores and instances are proportional. So I think that we have to keep in mind the two populations when we look at the needs and the requirements. I think that this will be important. Sinder deployment, same thing, removed the POC deployments. But then you can see that, again, almost 50%, very small deployments, less than 10 terabytes of storage. But on the other end, there's very large users with more than 500 terabytes. So very wide spectrum there. Last one is Swift. There's 47 deployment of Swift outside of POC, which is interesting. Smaller deployment, 50% almost. But then there's a very large deployment like more than 500 terabytes of objects. So there's a lot of project storage, almost 10% of the users. And on the number of objects, there's almost 5% with more than 100 millions of objects. So that means that Swift being maybe more mature than some of the other Nova components, you see a lot more large deployments of Swift than maybe other components. So the survey is still open. We do kind of a rolling upgrade or a rolling update of the survey data as we get more data. And we'll try to maybe clean up the forms to make sure that multi-selection is maybe disabled in some answers so that we force people to split their deployments in multiple instances instead of cramming everything on one deployment survey. And if you have any feedback on the survey, when we open the mailing list for general contribution, you will be able to give us your feedback or ask clarifying questions on those. So again, it's an initial evaluation of the numbers. There's other things that we can do with the numbers like for example, all the numbers are presented pair deployments, but not pair the number of instance. So for example, how many KVM deployments actually instance would be an interesting data to get? Like we know that there's like 50% of the deployments that are using KVM, but how many instance does it represents if for example, a very large cloud is using Zen, right? So that's something that we will do next and double click on some of those numbers and do more pivoting and correlation between numbers. Yes? No, so that's one of the issue that we had also is sometimes there's, so the user survey, you had multiple users giving their feedback for the deployments, it worked very well. There was no duplicates, but I don't know if it was enforced in fact. One of the things that people could do was to put a description when they defined their deployment. And so we went over the data and removed the cases where there were multiple descriptions that were identical. So the aim was to avoid scenarios where you had two reports of exactly the same deployment. Yeah, we did a bit of cleanup also and we removed some of the answers where people checked all the box. They were very excited about the survey. As JC mentioned, so anyone who hasn't done it already, it'd be very helpful to fill out your deployments as part of the survey, since that data is going to be an ongoing data set that we'll carry on maintaining. But maybe what's important is if you know that some other people, like it could happen in very large company that you don't know if someone already filled the deployment for your organization. Maybe it's good to coordinate maybe among yourself to make sure that we don't have to do the filtering. Because the worst is when you don't have the same answers. You have the same deployment from the same company with different answers. Or you're using Folsom. No, I'm using Essex. So we try to avoid that. I think what we can report is in terms of what people are deploying. I think there is a risk in that becoming a reference architecture since it might not necessarily be the correct reference. So clearly we are reflecting what people are deploying and therefore probably to what extent the operations guide should be assisting that. But I don't think that we should necessarily assume automatically therefore the right answer is KVM open V-switch for the reference architecture. Yeah, what we can say is we can say that those are typical deployments. Or maybe like if you have a getting started section where you want to look at getting people fast with the running cloud. It's likely that those drivers, like drivers that have the most response will be the one that people will want to run first. So like selecting a big switch driver would not be the best option for someone trying to get started. So default, default, right, right. Technical committee should give rather than the user committee or coming out of this data. So we're providing the data so that maybe the technical committee can do this kind of thing. I mean this is also not necessarily the kind of thing that individual projects should do either, right. It's something that's a reference implementation across all of the different projects saying these are the things that are best supported and these are the configuration options. And maybe that it's not a specific reference implementation maybe it's like for these specific types of environments these are the ones that we're recommending but these are definitely kind of things that technical committee would be best at doing rather than user committee. Yeah, I think that's why what Ryan was saying is that this group will influence the technical committee by providing the data. And I think that if it's a feedback loop and we get to see the recommendation and someone says oh you have to use this vendor so XYZ as the default will say oh come on it doesn't make sense, right. Individual vendors can make their own reference guides and that's perfectly fine. Everyone has their own ability to do so and their own marketing but it's probably not something that we would support as the normal reference. And in fact maybe the most sensible default would be the open source default. Not like a vendor specific because then you are biased to a vendor. I'm not seeing that coming from the user committee. I think the user committee is there to represent the views of the users back to the technical committee into the management board. It isn't there to enforce a kind of technical implementation. Right, so therefore what the user committee can do is to raise the fact that there is a concern there is so there is a need for a reference design and take that back to the technical committee and the management board as input from the user community. It's not for the user committee to be defining that. It's more a question of raising the concerns of the users to the bodies that can then get on and solve them. The documentation and the operator guide is it out of the technical side or like which body if you want is responsible for those? Technical committee. But they are part of the technical side of it. Part of the technical side, yeah. I think that's maybe one that's rather a bit the two sides. They need to work closely with the user committee definitely. Yeah, yeah, yes. So the aim would be that in something like 12 months time we will then produce a new report. So from this data we'll be doing a write up which will include more. We only had a week to do the data processing. So it was somewhat hurried. But we will then go into a more extended description with that and then we would look to be repeating that on something like a yearly basis. That's what we'd hope, yeah. Now with people hopefully filling out the survey as things progress then we could even be making it for basic statistics on a smaller granularity. Yeah, I mean that's exactly the kind of thing I think now that we're opening up the lists then we can have that kind of discussion amongst the people that would like to get involved. That's where maybe the double click by doing some more pivoting. Like for example, we presented the operator but all the data that are coming after that slide is global data. But if you say, okay, operator, how did they answer the survey? Or for a private cloud, how did they answer the survey? So that's the next double click that we can do and it will influence your persona a bit more than what we have right now. There was something. I think Josh, we can't yet. Sorry, I'm not doing something. So we've had some prototyping of something like that. And certainly one of the things that is clear from the comments is that some people are making, oh, this is a problem, this is a problem. However, if we then ask the community overall to be starting to vote to say, yeah, this is something that is my top priority, then that input would be very useful. So what I hope to be able to do is to take the comments and produce the first 10 initial seeding proposals and then start to get input from everyone in terms of documentation is the number one or installation and configuration is the number one. And then we can take those items as being the things to the technical committee management board to be looking at how to fund and how to solve. And I think this is actually a very important thing because currently the only way that we can really take feedback or the only way that we're really getting feedback right now is mostly from the developer lists. The IRC channels seem to be mostly dead for support and a lot of the other input mechanisms that we have for taking input from regular users that are not developers is not, none of them are very good right now we're working. So ask.openswork.org. Yes. It's new. So hopefully that will help as well. But we definitely need to be able to take feedback in a number of different ways. That's probably very good for support but it might not be as good for figuring out what users actually need from features. So yeah. I think in particular the thing that I'd like is to be able to have people who can say what their pain points are without knowing necessarily what the solution is. So many of the people using OpenStack won't know that the fix is to be re-architecting this component but they will know that this doesn't work. We're hoping the opposite that you would help us. Yeah. Really we're looking at more having a feedback mechanism where the user groups can collect feedback and tell us the problems that people in their areas are having. I mean the interaction between the committee and the use groups is one of those things that I'd like to be having a number of copies with a number of people during this week as well. Because getting that structure in place given that the user groups are the local contact is very important. That's a way to scare it because we are only three for now. So yeah. You have the local contact, you have the cultural links. So from that point of view that is a key part of getting that feedback loop in place. Good. Okay, great. So thanks so much. I'll be right about sending it around.