 So, welcome everybody. I'm going to go ahead and get started. I'm doing something a little bit different than normal right now. A lot of panels are from people who are veterans of OpenStack. I'm much greener than the average panelist. I'm going to be going through some of the experiences and other things that I have learned in my first year working with the OpenStack community. My goals today are to share my personal experiences, to examine some common pitfalls experienced by new OpenStack users, and to provide some tips and recommendations for people interested in contributing to the community. Obviously, my experiences may not reflect what everyone else has experienced, but I still think it's kind of interesting to see, from the point of view of a new user, what is this OpenStack community and how can I get involved? Month zero. I'm going to be going through kind of a general timeline of my time in the community. A small disclaimer, my first year is going to go through the first nine months. I have not actually been in the community for a full year yet, but my first nine months in the community kind of gets a little bit verbose. Here's some background information about myself. My name is Emily Wilson, and I am a QA engineer for Tesora. Tesora is based out of Cambridge, Massachusetts, which is right outside of Boston. They're an enterprise-class database as a service provider. They are also the leading contributor to the OpenStack Trove product. So naturally, when I came on board to Tesora, I was expected to be familiar with OpenStack and become involved in the community. This chart here kind of demonstrates the role that Tesora plays in the Trove community. As you can see, they are pretty involved. I have been a QA engineer for about four years now. I have had prior experience with enterprise storage and a functional but limited knowledge of OpenStack. So basically what that meant is I set up a Keystone server. I wondered why my Swift requests weren't going through and getting authenticated. I reset up the Keystone server and repeated that until I was finally able to actually write to my cloud. But other than that, I had a fairly limited experience with both the project and with the idea of working in an open source project. All of my previous experience had been kind of with solo companies. We used some open source software, but we were consumers. We did not really give anything back to the community. I'll discuss later some of the similarities and differences behind those two different environments. Month one, getting started with OpenStack. So as most people do when they're encountered with a problem, I hit Google. I opened up my browser, went into Google, getting started with OpenStack. There's the first thing you hit. I decided that the first thing to do was to set up a development environment. This page, how to get started with OpenStack, pretty much says, try DevStack. This page had a good amount of basic information on it. A lot of it was geared less towards the technical side of things and more towards the consumer side of things. But I was able to find, what is DevStack? DevStack was what I wanted. This was going to be my test environment. This was going to be how I would set up my first OpenStack stack. DevStack describes itself as an opinionated script to quickly create an OpenStack development environment. And as it turns out, that's exactly what it did. I was able to spin up a DevStack environment and it was great. But I quickly encountered one of the common themes of my first experience in the community. Many of you might have what I like to call utility scripts. These are scripts that you might create for a specific purpose, say provisioning an OpenStack environment for development. Now, one of the problems with these scripts is they quickly outgrow what they were originally intended to be used for as new features and new functionality is added to the project. And eventually you get to the point where you have a script that wasn't necessarily designed for what it was being used for. I found with DevStack there were certain options that maybe didn't work quite as well as one expected to and required some manual massaging to actually get them up and running. At this point, I learned pretty quickly that the ecosystem is really, really, really complex. So this is a general diagram of the different components of OpenStack. Compinatorics was perhaps not my favorite class in college, but one of the things that I learned really, really quickly was that if you have multiple parameters and you're looking at how many different options these different parameters have, the number of possible combinations gets really, really high really quickly. I learned pretty quickly that not all necessary possible combinations of OpenStack were tested and were necessarily, like, tested in combination with one another. So while one thing might work in isolation, you might hit problems when you were, say, running on VLANs and Nova with cinder-based storage that you wouldn't encounter with Swift. Those were some kind of interesting gotchas that caused me to kind of stumble and definitely were indicative of how complex the OpenStack environment was. Month three, testing the documentation. So fortunately, despite the complexity of the project, there's a rich set of documentation. There's a link for you guys. It's docs.openstack.org. It's a great resource, but there is a lot of it, so it can be kind of challenging for a new person to figure out what exactly they need and where exactly they should be looking to try to solve the problem that they're trying to solve. As a new user, again, in my first few months, I found the installation guides very useful. I'm not going to talk about those at length in a little while, but basically they provide a step-by-step process for how to install a particular component. The administration guides were also good when you wanted a slightly more in-depth look at something. I found that... So QA is kind of interesting in that you need both a really high picture of how all of the components work together, but you also need to know kind of the lower-level technical details to really be able to figure out how to test something. So a challenge when you're first starting on a big project is figuring out what is the lay of the land and what are the trees, what are the small details that you need to know to figure out which tests are best. If I have a limited time to test these features, what areas should I focus on? And the administration guides were useful in both figuring out the how-to and also kind of the why. Also the project-specific guides were very useful. Those provided a lower-level look at a specific project. An interesting kind of point at this is for some projects, the documentation was a better resource, and for other projects, the wiki was a better resource. The level of up-to-dateness of the wiki depended on the project. I remember encountering one project that the front splash wiki page hadn't been updated since 2014. Whether or not the information on it was still relevant or correct, I am uncertain, but the fact that it hadn't shown that much activity was definitely something that as a new community member I kind of had to take a step back and look into, like, is this project still active, is this project still relevant? So at this point I had figured out about three months into my community experience I had figured out what OpenStack was, how I would set up a development environment in order to kind of test any changes I would make and how to look at the different components. I was working primarily on the Trove project, but there's no one project in isolation. You obviously have to have some familiarity with all of the different aspects. So around month four, it was time for me to fix my first bug. Again, one of the biggest differences between working for a company that uses completely closed software versus an open source-based company is that there's a certain expectation to give back to the community. It's not really great to be in isolation in that environment. One advantage that I had is that I had a lot of mentorship within my company. I think that for anyone who is new to the OpenStack world, locating and identifying a mentor is a key component to their success. I found that there's a lot of little things, and having a mentor was able to kind of guide me through what I needed to do, where I could be helpful, where my skills would be most useful. I was able to do that via my company. EmRyth right here is the PtL of Trove and heckled me from across my desk as I was working on stuff. For those of you who are either independents or aren't in a company with as much involvement in the community yet, Women of OpenStack has a great mentoring program for pairing mentors and mentees. Although it is based out of Women of OpenStack, it's not specifically limited to women. So gentlemen, if you're looking for being a mentor or being menteed, that's a great resource. I think this morning they had speed mentoring, which is kind of like speed dating only, finding your OpenStack mentor. So I'm not going to go into too much detail about this at this point. It's a basic diagram that describes the general process. This contributing to OpenStack is really well documented. I think the biggest obstacle new community members have is just kind of getting over the intimidation of actually submitting their code to the world. Basically, the how to contribute will walk you through which accounts you need to set up. This is a small, I guess, aside. It's not that many accounts, but I find the fact that you have to make more than one account and sign a bunch of waivers a little bit. It was not the smoothest process. I think that a one factor might have been a little bit straightforward, but this is again mostly me complaining as an aside. The community is pretty great about having beginner-friendly bugs. Obviously, as a new contributor, you don't want to be tackling an intermittent issue that may or may not exist. Unfortunately, Launchpad does not yet have a category that's fixed by adding logging because a lot of bugs seem to magically disappear the moment you start to try to debug them. But again, fortunately, the community is pretty good about identifying good bugs for beginners. My first bug was a logging issue where there were certain cases that the exception would just get dropped on the floor. So it was a pretty simple change. I just needed to add a clause to catch that exception. And I think that in general for new contributors, it's a lot more beneficial to actually fix bugs versus fixing typos and other kind of small problems in the comments or what have you. I'll talk a little bit later about how those who don't have a coding background can contribute because there are lots of ways that one can help out in the community even if they're not comfortable pushing their first fix. My first summit. Thank you. Let me restart this and see. Gotcha. Sorry. Accidentally, I pulled the plug a little bit. It's interesting actually how it kept, like, the old information, but anyway. So my first summit. My first summit was Austin, 2016, this spring. I had actually never been to a professional conference of any scale before that. And I found the opportunity to participate in a summit at that stage in my open-stat career, a really amazing and really valuable experience. So you guys are all here at the summit today, so you can kind of understand how working with OpenStack and working in the technology industry, you get a vague idea of the scale of the project and how many different companies it supports. You don't truly get a chance to internalize that until you're in the marketplace seeing all the different vendors, seeing all the action. It was really a great way to kind of confirm that my choice to work with OpenStack was a good choice. Like, I'm working on something valuable. I'm working in a community that's vibrant and growing and diverse. So again, attending the summit was a really, really interesting and really valuable experience. I definitely would encourage people to try to reach out to new community members and where possible, encourage them to go to summits if they can make it. The panels were also interesting. It was really fascinating to hear people with great depth of knowledge talk about their products and what they were doing with OpenStack and it was kind of a great motivator. One thing I find sometimes is that as you spend a lot of time working on one project, you sometimes kind of get tunnel vision where you only, you vaguely know what's going on in the other projects, but again, the summit kind of brings everything together. The biggest and most interesting thing I found at the summit was the design summit. I had been involved in helping design the implementation for various software features before. But the design summit was a really interesting insight into how the community balances the ethos of the open source ideals behind OpenStack as well as the needs for the various companies that are part of the community. It's something that is not always an easy cohabitation between the two. There were definitely some tense moments in some of the design summits where people thought it would be better to have it implemented this way versus this way. But in the end, we were able to figure out the best way to continue to design the project moving forward. Newton was actually my first release that I saw from start to finish. So that's kind of a special experience. So at this point, I had been to a summit. I had submitted fixes. I knew what OpenStack was. I was very familiar with various things. But I still wasn't an expert. I was beginning to find myself involved in different resources. Ask OpenStack is something that I found really useful and really valuable, especially as you're getting technically involved in OpenStack and you have enough experience to cover the basics. But you still might have questions that either are of a scenario that is too simple to necessarily warrant being documented or too much of an edge case to warrant documentation or you're doing something completely wrong and don't understand something and need to get straightened out. Ask OpenStack was a great resource. The mailing lists were also a valuable resource. I'm going to be telling a little bit about some of the advantages and disadvantages to the mailing lists. As I was involved more with the community, I encountered my first mailing list disagreement that simmered into something that needed to be resolved. And also kind of as a side, the IRC channel is incredibly valuable and is also a great resource for those who can't necessarily make it to, say, a summit or are not fortunate enough to be in an area with lots of meetups. You get to talk to various members of the community and you also get to kind of keep your finger on the pulse of the community. You get to see how the release is going, who's working on certain features, how these features are going along. It's pretty much the lifeblood of the technical side of OpenStack. So this is kind of a side note. I found that sometimes it was challenging to locate these intermediate resources and the resources that I discussed in the previous slide were the most useful for intermediate technical resources. Document verification, month seven. So this marked, I think, my first and biggest experience in seeing how the community worked as a whole. As I had mentioned earlier, the OpenStack documentation is a really great resource for a new member, but it also can sometimes be a source of frustration. For example, the installation guides. Obviously, it's very important that a project has an installation guide. And the installation guide is also used as a marker for maturity in a project. So you want to have an install guide and you also want the install guide to be correct. At this point, I had been asked to do some verification of the Trove install guide. And it was wrong, which is worse than not having documentation as one would have it. It took me a little bit of time. I kind of iterated through it and eventually managed to get a version of the document that was correct. Unfortunately, around this time, we unfortunately, fortunately, they were changing how they were doing the install guides. And again, this is what I had mentioned about there was a disagreement that was brewing on the mailing lists that I was not necessarily as in tune with as I should have been for someone who was working on the install guides. I submitted my change and we were then told that we don't want this, we're changing the way we're doing the install guides, so we don't have kind of the traditional install guides. We're moving it around. Wait, we don't need this. Eventually, again, we kind of worked it out and figured out that, yes, this was something that we wanted. This was from Ataka towards the end of it in the last week of the release, which shouldn't be submitting changes in the last week of the release if you want them to be accepted, but it's another lesson learned. And that was just kind of interesting because there was a conversation in the community that I was not necessarily aware of because I was not paying attention to the documentation, mailing lists as closely as I maybe should have been. But, again, things were straightened out and the problem was resolved and now we've changed the way that we do documentation so that even though it's all linked by the project, it still appears in the nice index. This is kind of another aside. For those of you who do not have an incredibly strong technical background, I think that contributing to the documentation is a great way to kind of get started. As I mentioned, it's not uncommon for new people in the community to look for typos and fix bugs like that, but I think that there's actually a lot more value in trying to go through some of the documentation and verifying it and working to submit fixes that way. And then, you know, as they get more knowledge of the project then maybe move on to doing more nitty-gritty code-based work and that way they're able to contribute something that is a visible value to the community. So, at this point, I become more active in community participation. I really am fortunate, as I had mentioned earlier, we're located out of Boston, which has a really vibrant tech community. This is a map that has basically all of the OpenStack worldwide meet-up groups. Unfortunately, there are some gaps in the map where individuals might not be able to look at their meet-ups, find one that's happening next week and take the train over to do the meet-up. Subsequently, for those of you who live in an area where there is not easy access to meet-ups, the IRC meetings are definitely a great place to get involved with the community without being there face-to-face. A side note, it was really interesting on my first summit to kind of put faces to the names that I had been seeing over the past few months. That brings us to here, my first panel. I had decided that I wanted to do a panel, and I submitted three different propositions, one of which I think was the differences between how we hope interoperability works and then the reality of what happens when you try to have different components of your OpenStack stack at different releases. The other one was about the challenges of having Trove handle all of the different databases in kind of a one-size-fits-all, despite the fact that different data stores are very different underneath the covers. And then this panel, which is my first year in the community and kind of an overview of some of my experiences and a rough guide as to how I got started and the best way, I think, for people to try to ramp up. I was surprised and excited to be accepted, and I'm really glad to be able to share my story with all of you guys. So in conclusion, I think that it's really important for a mentoring program to exist. I think that having someone to help guide you through the different aspects to becoming a technological contributor is pretty much key to your success. I also think that that kind of helps people locate resources. The community has a great number of resources for people of all different experience levels, but there's so many of them, and they are so diverse. It can be challenging sometimes to figure out which resource will answer my questions, which one is the best one to use, which ones are correct, which ones are valid for the release I'm trying to work on, and also participating in the community via, like, attendance to local meetings and face-to-face. One of the biggest differences between working for a closed source company is the fact that your community is whoever is employed by that company at that particular moment. You don't really get any outside use cases or outside views into how a related project solved a similar problem. So out of curiosity, who here would rate themselves as new to the community? Excellent. Do you guys have any experiences you'd like to share or feedback for which programs you've utilized to kind of get in here? Nope. Oh, excellent. Congratulations. It's a wild world out there, but the OpenStack community is pretty great, and we're glad to have you here. Anyone have any questions? Yeah, and while they're similar again to a lot of source control, I've definitely spent some time and some embarrassment being, oh no, that's not completely what I wanted to commit. Another thing I didn't actually mention about the women of OpenStack mentoring program is that you can define what your goals are in the community. It's not necessarily a concrete you must get to this point. You can kind of figure out what your own career goals are and your own contributor goals. Let me see where we are on time. I have about like 10 more minutes still, but any other questions heckling? Thank you all very much for attending. Thank you. I hope that you've learned something. It was great to be out here. Thank you.