 All right, so welcome to our talk. We are planning to share some of our experiences on how to create OpenStack Project. So we're not exactly speaking about the low level details on what you need to do, but rather share some high level details, some pointers on what exactly it means and what's the experience of creating OpenStack Project. So who are we, guys? We are Susie Hackers. Let me present you Adam, Adam Spires, Terp Mueller, and I'm Pranav. And we have some really unique OpenStack projects. And they are quite different from the standard OpenStack projects that you see, which is basically the Python-based projects. So the biggest reason why we're here is to basically share the differences, the experiences that we generated by the differences between the standard OpenStack projects and what we have. I think that it's a great idea to take your cool idea of solving a problem in the OpenStack and the Cloud ecosystem. This problem need not be the hot topic like NFV or Docker containers or maybe even something like networking. It could be a very small tool. It could be a library, but it could be very handy. And that's something that I would like to encourage from the community because we need every possible problem to be solved to be a great project to realize OpenStack mission. And I hope that we could motivate you guys and get a great Cloud product and hope that it gets better and better every release. But before we get into the high-level details, should I create OpenStack project? What are the reasons? So the first thing that I would talk about is why I should not create OpenStack project. If I want to promote myself, if I want to promote my employer, create some sort of a competition between two projects, it doesn't make sense. To reinvent the wheel is probably not ideal. It's not exactly a bad idea. So in case of orchestration, we have Puppet, Chef, Ansible, and they're basically trying to solve the same problem. But it makes sense to have these different projects. But it doesn't make any sense to have another networking project while we have something as amazing as Neutron. And these are some of the reasons why you should not create OpenStack project. It's OK to make two long slides. It's OK. And the next thing is why should you create OpenStack project? Or why should I create OpenStack project? The biggest reason would be to help realize OpenStack mission. We all want to create open-based open source, open standard, open development-based cloud, which everyone can use. And I guess to grow my team, my project, maybe I have a great idea and I want to share it with the world. I'm solving some really good problems with it. And I would like to take it up into the community and let everyone take advantage of it. Also, at the same time, it helps me for my personal growth. And it's very obvious on how it helps. So I would like to hand over to Dirk, who is going to speak more about governance and what it all means. Thank you for enough. So before we start in getting all the nitty-ditty details on how to actually do it, I have to bore you with a little bit of theory behind it. And I apologize, but this is how it is. So when you think about creating a new project, the main thing you want to think about initially is how your mission or how your vision of the new project is correlating with the OpenStack mission. So what is the OpenStack mission? The OpenStack mission is on the web page, blah, blah, blah. It produces the ubiquitous open source cloud computing platform. It's for public private cloud. It's simple to implement and massively scalable. So this gives you a lot of opportunity to resonate and think about how your project goals and how your way of improving the OpenStack software ecosystem could be resonating to that mission. When we talk about the OpenStack governance, of course, there's this mission statement, but there's also the technical committee. The technical committee is elected by the developers of the OpenStack project. And it embodies the technical leadership of OpenStack. So what's its goal? It enforces the OpenStack ideals. And I'm going to go into more details just after that. And it decides an arbitrage cross-project each year. So it's an embody of trusted developers that have been elected by the OpenStack community. And they are a task to resolve conflicts. They are a task to set the mission into an implementation. They are a task to actually represent the ultimate board of conflict resolution if there are such on the table. OK, so one thing you cannot avoid when you talk about the OpenStack principles is the four opens. So what are the four opens? Open, open sign is clear. First thing is open source. I'm going to go into more details about that just now. Next thing is open design. And this is usually a tough one for people who are coming from a more enterprise-related environment where you have an in-house organizational structure that is slightly conflicting with that. The open development model, this is quite a change for people who are not used to work in the open, especially for developers. I mean, and last but not least, the open community. So coming back, what is open source? Open source means your project has to be under an open source license. The TC strongly recommends Apache version 2.0. I think most of the projects are following that. And what does it mean in addition? It also means the project is the whole thing. So there's no way of doing your business with like doing an open source variant of it that has less features and you sell the enterprise edition. That doesn't work. It has to be non-open core. It should not depend on components that effectively impact the distribution of the project. So if you think about creating an open source project that is only a wraparound like some non-resistible non-open source components, then you will have a hard time in entering the open stack governance projects. Going further, what means open design? And open design is what you exactly experience here going forward for the rest of the week. Everything is happening at the design summit, which happens twice a year. People from all over the world are coming together to gather the requirements to learn about the roadmaps, to develop the roadmaps, to resolve conflicts, to make a plan on how their projects are moving forward. And you need to be ready for that, which basically means all your road map is being developed in the open. You accept the input from others, like other companies, other contributors, other projects that have an interest in collaborating with yours. Your communication about the project goals, about the project development, about the project vision mission is done in the open. And you do all the communication, which are central to your project decision on how you move forward through public mailing list. Next item, open development. So this is the part where some developers might get a bit less happy about the situation. So every change to open stack projects has to be done as a pull request in the open. So everyone can go, and I actually invite you to do that before you even think about starting a project, can go to revieopenstack.org, and look at the upcoming pull requests. Anyone is allowed to sign up for an account. Anyone can comment on pull request, can suggest improvements, can basically act to change, and think this is common on it, and vote on it, that this is a good change. And Adam is going to go into more details on that fairly soon. You've got to define an open group of core approvers. So the core approvers are a group of trusted developers around the project that have special privileges. So they have the privilege to merge changes into the project. And this group is not closed. This group is not secret. It's documented in the public, and it's open. That means other people have the chance to become part of that core group. And the project needs to focus on cooperation. This is a bit of a hot topic, because at the one side, open source projects can compete when they think they have a better technical solution for the same problem. But in general, and in a majority of cases, this is not seen so well. So you should prefer to think about how to cooperate with other projects, or how to have interfaces with them, how to enable other projects in integrating with your project, and vice versa. And you should be very open to reusing code and code patterns that are developed alongside in the OpenStack project space by others, which means you should avoid reinventing the wheel just because you want to reinvent the wheel. One specific topic about the development part is the testing. So OpenStack has a very, very massive automated testing infrastructure. And it's part of the things where the TC or the OpenStack developers are really proud of. So every change has to have a test case associated with an data test, very strict guidelines on how the testing for each project needs to be set up. It needs to be in the public. It needs to be reproducible for people so that they can run the tests on their own. So it can't be on some secret environment that doesn't provide log files or anything like that. And in addition to that, projects are healthy to follow a strong coding style. For Python projects, that's easy because there is a standard for that. And every Python project is following that. For other languages, use something that is similar. So don't bike shed over coding style. Use a tool to cover that part in the site for a tool and then move on. And the last point is about the Open Community. So OpenStack projects are proud to build a healthy and vibrant community. What does that mean? So the primary principle on which the community is supposed to act is the model of lazy consensus. So this basically means if you're intending to do a change to the project, your primary assumption is that you're allowed to do the change. So instead of first going to other people and asking about whether you should or whether you're allowed to do the change, you simply do the change and you put it up for review. And other people are allowed to comment on it. But by default, you're acting in a model that you are empowered to do the change that you want to do. In addition to that, it means processes are documented, which means when there are specific requirements for your project, this knowledge needs to be documented in public so that other contributors who are interested in contributing to your project can read about it and can learn about it without learning it after the fact. It also means you as a project have to come up with a project team. And this project team has to choose a technical lead. For governance-run projects, every six months you have to vote as a contributor group for a PTL, so a technical lead who is for the next cycle, the ultimate liaison for the technical committee and for other projects to have an interface into your project and a communication point. And last but not least is that your meetings are held in public. And the standard way of doing that in OpenStack is to use the public ISE infrastructure. And Adam is going to go into more detail tonight. And with that, I hand over back to Pranav. Thanks, Dirk. So I would like to discuss a few things about setting up your project. So the biggest discussion on our topic is Big Tent or Not. I would say that it's not so important to think about Big Tent or Not to Big Tent to start with, because it's your project, it's your idea, and it has to solve the problem in compliance with the OpenStack mission. The right approach or more idealistic approach would be to think what exactly a project needs. What are the resources? What are the things that are already existing in the OpenStack ecosystem? Sometimes it makes sense to go for a specialty team or a sub-project, or maybe a project in Stackforge. And this is very important, because you need to do the right thing, to choose the right technologies, and you also need to base your decisions based on technical facts. That's what the technical committee is looking for. And also, of course, you need to take care of how your repository looks, various things, depending on what is your programming language. You need to decide how the CI system would interact. And testing interfaces, you need the right sort of unit test, functional test. And it fairly depends on what exactly you're trying to solve, and what are the technical decisions. So there is some really good documentation on how to set up your project. And it gives you all the information you need with some brief description of the history, of the mission statement, what are the four opens that Dirk explained. And that also gives you a starting point to allow you to start giving the pull request for creating your initial project or the repository of the project. The more important thing is to make sure that you get your patches reviewed and merged. If it's a project in BigTent, then you need your patch in the governance repository to be merged first, and then rest of the patches in the infra and the other places would automatically follow. This may require quite a bit of discussion, depending on the topic, depending on how easy it is to convince the technical committee. But you can make it easier by checking your repository, by checking all the things that you need for the CI system, for the review system, and to gather the right people who are your core approvers. And of course, you need to choose the right name for your project. It's a bit funny, but if you guys are following Neutron from quite some time, the rename from Quantum to Neutron, it was not so easy for the rest of the community to follow it. And it's misleading, it's confusing, and it would be great if you can take a look into this, make some research, and choose the right name. And if you're starting from scratch, then you should think of using the cookie cutter, but you may not really need it. And it depends on your project. So if you're using Python, and if it's following some sort of standard OpenStack projects design principles or the way the repository should be laid out, then it makes sense to use the OpenStack cookie cutter, because you'll save a lot of time. A lot of things, the way your repository should be laid out, the right structure, all of these things are already present in the form of templates. And you just answer a few simple questions, and you get the starting point of your repository. But of course, that's just a starting point. And I would invite Adam to explain more on what happens after you create your project. Yeah, thanks. And just before I go into this section, I just wanted to quickly mention, in case you didn't notice at the beginning, we have put these slides online. And if you want more details about the specifics of the things we're talking about, which repositories need to be changed, or how to get the cookie cutter, or that kind of thing, these slides have a whole ton of hyperlinks in them. So you can just look at the online version and then go follow the links and get all the technical details you need. So code review, as Dirk said, open development is a critical part of OpenStack projects. So code review is obviously essential for collaborating with other people. Everyone knows the plus one vote when you like somebody else's code. That's always very straightforward to give. The minus one is a bit more tricky, and especially in the OpenStack context, you need to be a bit more careful about how you go about doing that. So of course, constructive criticism and collaboration applies to any project, whether it's in an OpenStack or not. But in OpenStack, I think it's particularly important to remember that you're collaborating potentially with hundreds, if not thousands of developers all around the world from a huge variety of different cultures and backgrounds. So just being aware of how you offer constructive feedback, the sort of cliche is that you give some positive comments and then your negative comments and then some positive things and it kind of cushions the blow. But that advice is, as you can see from the diagram, putting something in between two suite layers is not always necessarily a way of making it more digestible. But at the same time, just being positive, welcoming, open-minded, and aiming to leave the contributor, wanting to come back to collaborate more is the ultimate aim. So as the person who set up the project, you will automatically become a core reviewer. And so you're responsible for giving the plus two vote when you think changes are suitable to be merged. You will also need to bear in mind who else needs to be in that core reviewer group. And as your project changes size and shape over time, the list of people on that core reviewers will need to change potentially as well. So there are other review mechanisms. There's the minus two, but that's like a really strong veto. So try and avoid that unless you really want to make sure that something is definitely, have no chance of being merged. And then there's these workflow plus one and minus ones, which is basically telling the CI should it go ahead and merge something or not. So you can use the plus one is the final of the workflow is the final indicator to the CI say, yes, merge this. The minus one is for stuff that changes that are still in a sort of draft form, work in progress. There's also like just a zero vote. You can add useful comments to review without voting and maybe people sometimes neglect that. But if you're indifferent to the change, but you have some opinion or suggestion that you want to offer, then you can use that. So there's a link there to the core reviewers guide for more information. And there's also this useful tool that's worth mentioning, this dashboard creator in Garrett where you can compile custom dashboards that give you a view of your, the particular review queue that you care about. So in the OpenStack World CI, as we've already heard, is incredibly important and all the infrastructure that we have for CI is very good, very sophisticated. So we need to take advantage of that. This is a screenshot of kind of a bit of a Hall of Shame thing on status.openstack.org. No one wants to be in the Hall of Shame, so make sure you're looking after your project's CI and that it's always passing and that will breed confidence in your project. And also remember that just having passing CI and just not enough code coverage is also important. So release management is an important topic, especially if you're in the big tent, then there are some recommendations around how you should build your release model. There's the various options there. I won't go into the details, but there are tags which can be applied to your project in the governance repository. And the, yeah, there are links, but actually the link at the bottom here will give you more information on the different release models. There's also an existing mechanism for building and publishing your Tar Balls whenever you make a release. There's a tool that was announced recently for, fairly recently, I think, for automating the build of release notes which might be worth looking into if you want help with that. Of course, there's the whole mechanism for doing translations if your project contains human readable strings that need to be translated into different languages. And there's a standard established open stack mechanism for that, which you should tie into. And yeah, as I said, the last link on the slide there, it will give you lots more information on this. So support, of course, is essential for the health of your project. It really is the difference between success and failure, I would say, or one of the differences. So bug tracking and issue tracking is an obvious part of this. Launchpad is always recommended, I think, as most of the projects tend to use Launchpad these days. And as with any project, really, just being responsive and ensuring that your bugs and your issues are always in a correct state so that if somebody's joining the project, they can see some accurate information. It can be quite demotivating when you come into a project and try and understand the status and all the information is out of date. Mailing lists are a core focus, focal point for communication within OpenStack, especially OpenStack Dev. If you haven't seen it before when you join, you'll be astonished by the volume on there. And that can be a problem. One thing you can do to deal with that is these badges or labels that you can see in the subject line that will make it clear what the topic is and then people can set up filters and avoid missing important emails. IRC, as mentioned earlier, is also a focal point for communication on a quicker feedback basis. And there is the possibility to set up your own channel for your project if you want. It doesn't always make sense. First, look at what's already out there and then talk to the OpenStack Infra-team to decide whether it makes sense to create a new channel. And yeah, if you have a channel, then obviously look after it and make sure that if somebody comes on there, then they get the responses they need. Otherwise, they'll just give up and never come back. At first, your project may be quiet, so watch the channel and hopefully things will build gradually. One way you can add a small bit of immediate value to the IRC channel is setting up the IRC bot which for Garrett notifications, so if people are submitting changes, then you can get the bot to automatically announce them on the channel, which can be quite good for making people feel connected with the project. Here's an example config and an example output at the top and then the config for setting that up. And so that's kind of reacting to giving reactive support when people come in and ask for help, but then if you really want to accelerate the growth of your project, then being more proactive is important. I think there are several ways to do this. As mentioned earlier, there's the IRC meetings and one important point here is that if you're setting up IRC meetings, which you can do by reading this Wiki link here, then you have to, or at least very strongly, encourage to hold the meetings in one of the existing dedicated meeting channels on OpenStack IRC rather than holding it in your own channel. The reason for that is to try and minimize the number of clashes between different meetings. So there are only about five or six IRC channels dedicated to OpenStack meetings. So if you go in one of those, then you'll avoid clashes with other meetings. And of course, we do all this online stuff, but meeting face to face. Everyone here obviously appreciates the importance of that, otherwise you wouldn't be here, but there's the other opportunities outside the summits for meetups in local meetups and mid-cycle meetups and so on. So if your project would benefit from that kind of thing, then do think about setting that up. And then of course, there are all these different other ways that we're all familiar with, which are mostly not specific to OpenStack in general, but a couple of points, maybe if you're blogging, which is a great idea, then get your blog aggregated out onto planet.openstack.org. Work with the, if you have some changes which affect multiple projects other than your own, then maybe the cross-project working group can help out and there's also the product working group which can kind of represent the user side of the community and connect the technical aspects of your project with what users actually need. So we'll talk about our three different projects that we set up and just give some lessons learned from those. I'll go first since I'm already talking and so my project that I set up, I guess about seven months ago, I think it was just a bit before Tokyo was a project called OpenStack Resource Agents. And these slides are especially for Florian because they're full of bullet points which I know he loves. And I'm also gonna do another great presentation technique which is just to read off the slides. So yeah, this project is for managing OpenStack services, which inside Pacemaker, which is a clustering technology, so making OpenStack services highly available. It's been around for several years. It was started well before I got involved in this area, actually by an ex-colleague of Florian. And it's used by quite a lot of people but the maintainer left the OpenStack world and went on to other things. And at some point after it had been unmaintained for a while I said, I think people are using this we need to move it into the OpenStack world and everyone agreed. So and I by suggesting it accidentally volunteered for the job. So and a lesson here I think is worth collaborating with the community even before you start thinking about creating a project just to check that it's worth it. So how did I do it? Well, I imported from the existing repository. There's a trick for that which is documented in the project creators guide. I had no volunteers for co-maintaining which was a shame but it was also great because it means that I'm in control of everything you can take over the world. There was no CI. So I had to use just this no op jobs thing in to set up the CI which yeah, just pretends the CI but doesn't do anything. There were no stable branches that's fixed now. There were no releases and no release model that's in the process of being fixed. And the point here is it doesn't have to be perfect before moving it into the OpenStack tent. It still can be worth it. On the government side, there was no suitable team with the PTL to put it under. So at the moment it's not in the big tent. And if I wanted to create a team then something like OpenStack HA would be too broad because that high availability in OpenStack means lots of different things. So and we need time to prove that the project is gonna be around to stay. So the lesson here is yeah, you don't have to go into the big tent straight away. There's still value. You can put effort into earning that place. And we have the IRC channel that I set up, Launchpad Tracker. We have weekly IRC meetings which are helping with the momentum quite a lot. We have a mailing list tag on OpenStack Dev which is helping filter emails. I've been giving talks and momentum is building. So things are going well so far and on to do. Thanks. Just quickly going over the RPM packaging project that we launched or the idea was spread in the Vancouver Summit, which is roughly exactly a year ago. And initially it was just like yeah, we should collaborate on RPM packaging. So currently there are big players on the market. They are differentiating themselves on providing an OpenStack distribution, which is good, but it's also bad in the sense that it makes the work for the upstream projects harder because every existing packaging mechanism was slightly different. And the idea is simply we shouldn't differentiate on the packaging level like how you name the package or how it's just more confusion than it's worth. So the idea was to start an effort to consolidate that. This initially started directly as a BigTank project directly from with Codds from the three major players for OpenStack packaging or RPM-based packaging. And after quite some time of discussion and defining the project team and the actual project scope, we got an governance approval for entering the BigTank right away without actually having anything. So we started with a really empty repository. So at the top of this, you can see the graph of the commits of this repository. It's also slightly spiky and not very exponential like we saw in the keynotes. But overall, the benefits of the BigTank project for me were very variable. For example, we suddenly had a single point of contact for other OpenStack teams defined. So other teams in the BigTank who were like forward, okay, I need to talk to someone who knows about packaging, how do I do that? And suddenly there's a single point of contact because there's a project around that and you can hop on the ISC channel and you find the right person to talk to. Also being part of the BigTank meant that it enables cross-project dependencies. We are not currently using that but we are trying to do that. Basically what this means is that all the Ansible's cookbooks or playbooks, playbooks, sorry, and all the other conflict management tools, they can gauge their changes against the common packaging going in the future. So different projects can make sure that they are all compatible for each other and this on a change by change basis which is a big step forward to what was happening before. And another benefit as we had is entering the BigTank meant we had to follow a lot of governance principles but that was actually a good thing because that gave us guidance and structure because initially we were like newly found a project and there are like 500 ways to reinvent the wheel which doesn't make a lot of sense. So just by following the governance, impose BigTank principles, we solved a lot of discussion points. And last but not least, it finally moved all the downstream development efforts that the distribution maintainers are doing back to upstream. So the lesson learned that I have to take away from that is creating a new project, especially if it's not like a standard Python OpenStack project is complex. Creating a team and finding regular contributors and getting everyone on board is challenging. We had both like to set up the actual tooling for that because there was no existing project to build upon or while there were too many existing projects to build upon and we didn't have a project structure initially and the lesson learned here was really by following the BigTank principles we had a chance to establish the project going forward. Thanks, Pranav. Yeah, so I want to talk about training labs. It's a very tricky topic, training in OpenStack and basically what I'm creating is a tool to automate deployment of OpenStack on a very small lean basis on a laptop or on a computer. And what we try to do on the technical terms is the other way around, we try to deploy OpenStack on as small and as minimalistic cluster of VMs as possible so that everyone can just do a one-click installation and set up the entire cluster so they can learn OpenStack, they can play around with it and that is quite challenging also on a few more things which is the basic point of trying to explain this project to the technical committee was very difficult. Although this project was existing as a part of training guides, which is related to training but to deliver the documentation or the presentation, I think the upstream university is based from training guides and we forked from training guides because we had a different way of working, different way of release model. And the biggest issue was that how to exactly push a project based purely on Bash which is using VirtualBox and KVM as the backend to deploy OpenStack while people are designing OpenStack to scale out and into massive data centers, we are trying to do the opposite. And this made us decide to add it as a specialty team so maybe we had a chance to create it as a separate project to try and gather everyone doing training around the world and create a big 10 project but it made more sense to be a specialty team and a documentation project because we are very closely integrated and working with installation guides and also with training guides to a big extent. And the other thing is that we kind of benefit from the existing infrastructure, the existing team of documentation team. I think documentation project has some really amazing people up there as the core approvers and their guidance has been very helpful. The biggest reason is that we have very small team about three regular developers and around two or three developers who sometimes appear to some work for a couple of weeks and then vanish for another couple of weeks. So this allowed us to also have some sort of backup reviewers in case one of the three guys or two of the three guys were on vacations. We were basically on the same time zone so we have a similar vacation pattern. Then there are other people from the documentation project to step in and provide reviews. Sometimes we need to do some changes based on maybe the some things which are like housekeeping or management of translation or the things that we need to take care of. These are automatically committed by the documentation team, the person responsible to update everything in there and that reduces our workload and that's actually amazing. And the biggest decision or the biggest lesson that I learned with training labs was after creation of this project. I had a very long chat with Defi Helman which I assume who is part of the release committee of OpenStack. And I realized that he was really trying to understand how the project is delivered or how we plan to deliver it to our users and that the release cycle is not set in stone. That it is actually something that we have to decide and it should be flexible as per our project and our users and not as per the standard way of releasing an OpenStack. And I think that was a really good experience to try and get one of these weird projects into OpenStack which kind of doesn't fit in but it's also quite important. So I would like to invite you guys to ask some questions or comments. I mean if you have a question, if you could go to one of the, I guess that's the only microphone. So that microphone. I'll just pick up, you can repeat it. Yeah, all right. You give a recommendation about creation project that's written in Python but could you give some recommendation how to create project that's written in some different language? Yeah, so I think I have to do that with training labs we started with Bash. And so you need to understand why the repository structure of a standard OpenStack project is laid out. If you understand the reason behind it. So the doc folder is basically having this, the Python Spinks based documents marked on RST and it's for delivering the developer documentation and other different documentation of your project. So you can really try to understand that, okay, I don't have to worry about this. I can deliver this or I can think of another way. Maybe you're using Golang and you could use different way to parse it and get the same output and deliver the docs to maybe the documentation team or wherever it's required. And if you are able to understand this and if you have a very good reason why you're not using Python and also follow the conventions, if your project is in line with the mission, then it should not be very difficult to convince but maybe there would be some resistance but it is possible to add your project into OpenStack ecosystem. I don't know if there are many projects which are not written in Python and are quite technical in nature but I think it's possible and I think people are talking about it. There were some talks in the past few summits about using different languages to improve the innovation of OpenStack. Okay, thank you. With that I think we are way over time so when I conclude, if you have any additional questions, feel free to just talk to us directly. Thanks a lot. Thank you. Thank you.