 Okay, looks like we're going to start two minutes early Okay, so The title of this talk is taking the long view how the Oslo program Reduces technical debt. So just to introduce ourselves. First of all, I'm Mark McLaughlin. I Guess now I'm technical director for OpenStack at Red Hat I would have previously been on the OpenStack title committee I was previously Ptl of the Oslo project and I helped start the Oslo project And so I'm here really not as a currently active Oslo contributor I'm here to provide some of the more historical context of how the project started and More Doug is going to provide a more kind of recent view of what's going on these days right and I'm Doug Hellman. I'm a Employee at HP my job title is something like OpenStack contributor So it's I work mostly on upstream work and I'm the current Oslo program Technical lead. I'm also a member of the OpenStack technical committee All right, cool. Yep. All right, just to start with explaining. I guess what the Oslo project is about and what we're trying to achieve So This is a mission statement. I came up with in the early days of the project and so we're trying to produce a set of Python libraries Containing code shared by the OpenStack projects. So the idea here is, you know, if you look across OpenStack projects They're all doing quite similar things and start in terms of the basic infrastructure of the project And we're trying to identify that similar code amongst all the projects And I'm talking about the server projects in OpenStack Identify that shared code and basically move it out into into library projects That kind of sounds pretty straightforward and obvious And I think but one of the impediments to doing that is You know, you can't take you can't take code from projects that weren't wasn't designed to be reused and just put it out there You have to really Create an API around that a really, you know, stable forward-looking API around that And so the way I talked about that was, you know, we needed the API to be high quality stable and consistent Documented and generally applicable. And so the mission of the project is to identify that code that's shared amongst projects and then create this, you know Stable API out of that code Yeah, and I think the one of the aspects that gets into the technical debt is where we find that Projects have slightly different patterns for solving the same problems and trying to meld those things together And we'll talk a little bit about how we get that done All right, so the motivation for the project that we've talked about a little bit is Not just reducing technical debt, but also providing consistency for Deployers so that for example, we manage the library that deals with configuration files So that each project has the same syntax in the configuration file You're gonna see the same kinds of patterns You'll see the same names for options in different projects and that sort of thing so that it's more familiar and it's easier to understand the whole open stack project We also want to see consistency from a developer's perspective So inside the code base of a given application. We want them to be using the same API is the same patterns for doing development we talk a lot about patterns and That gives you an opportunity as a developer to contribute to multiple projects because you don't have to go and learn a Whole separate set of tool base, you know each time you go from project to project once you're up to speed on some of the more Common tools you can hop around and focus on the application level Problems and not Every tool, you know every project has a different config library or a different way of doing database access or whatever And then we want to encourage the development of those patterns because it also encourages new developers to come on Not just to open stack as a whole but to be able to make smaller Contributions and we we talk a lot about our gigantic contributor base A lot of those people are bringing one or two patches fixing one or two problems But as they see the same pattern over and over again, they they can start to add features and More contributions across the whole project And so one thing that's very different about Oslo, you know really It's quite an unusual project in the sense of most open stack projects are you know They're essentially silos. They're very much focused on this very specific functional area and have a community built around those And so open Oslo is really one of those few Projects where we're trying to I don't know whether we're a more responsible project or more broader thinking project or whatever it is We're trying to You know, we're trying to do things that isn't about a specific functional area We're trying to you know, think about the long-term sustainability of open stack more generally and kind of try and help Effect change that really helps operators of the project So, you know, I kind of like that we're kind of taking this Responsible approach that isn't so much about tactical features in a specific functional area But just more about the kind of sustainability of the project and usability of the project Right a longer term view that we talk a lot about vertical projects and horizontal projects and documentation and release management and Oslo sort of fit into that horizontal project realm and So talking a little bit more about that motivation and the long view that we're trying to take So I don't know if any of you are familiar with the long now foundation It's a group of people who are among other things building a clock that will run and be readable and usable in 10,000 years Which is a pretty audacious sort of thing and it's it's inspiring I don't think that open stack is really something that we probably want running in 10,000 years We probably want to have moved past that by that time But it gives you the idea of looking past the immediate need and thinking about how can we make open stack last? 20 years, which is a realistic timeframe for a project and Sustain not just our current stability, but growth and expansion Yeah, and for me very personally like my motivation was very much in this area And I kind of almost a selfish motivation in terms of you know, I was getting involved in open stack I was coming from you know a red hat background of working on software that we were going to have to maintain for 10 years In terms of Linux and I knew we were going to get to that with open stack eventually And you know looking at the code bases and the technical debt that was accruing I didn't want to be on the hook for maintaining some of this stuff in the very long term So a very selfish motivation here almost as well exactly So yeah, that gets into the early days of the project and I guess when we were preparing this presentation We just briefly said we should talk about the early days of the project, but You know, I really had to take into the background to really understood understand even myself how the project came to be I knew I had some awareness that there was the notion of a project like Oslo before I even got involved with open stack so what I dug up was that In in a right in August 2010 which I guess was almost the month that the month after that open stack was originally announced J pipes at that point had already registered an open stack common project in launchpad When we move on to November 2010 Todd Wiley was starting to try and populate that the That repository with some code December 2010 Jay, I think saw that the configuration options problem was one of the first things to tackle and Added a module there with it with an API around that but things got quiet then until the summer of 2011 When Brian Lamar tried to pick up some of the work and then in October 2011 was my first open stack summit and I remember going along to the open stack common session at that summit and there was a Real sense of frustration in the room from the likes of Brian and and Jay that you know This is a really important problem. Why is no one working on this problem? And I remember Vish at one point saying Talking again about that the configuration options Problem has been one of the harder problems because glance and Jay was the ptl of glance at this point Glance had a specific approach to configuration options using any any style files Nova had another approach to configuration options, which was using a file that kind of had It seems strange to remember it now But it was a file that had like command line arguments in it one line each Can you conf library? No, it was the G flags flags. Yeah. Yeah, so vicious point was basically Please don't try and start with that config file options problem. It's too contentious We'll never get agreement on it and I thought okay. Let's start with that So and that was our first success story. Yeah, absolutely. So I think that the next slide goes into some of that So after that summit session, I guess Jason Kolker created another repository to replace the existing open stack common repository I had my first prototype of that the config library that we have now and propose that and Kind of quickly got it included into the nova project Which is quite surprising because it implied a a change in config file format and got glanced to adopt it And I think then in the Essex release we were you know starting to say Here's our first success with the open stack common project. We have this config API at that point The code was still actually Living in each of the projects, right? So we had a copy of the same code in the in the nova repository and the glance repository And so we came to the fall some summit then and I organized a design summit session there where I proposed this notion of managed copy and paste and so What what I saw going on the project was similar code being copied and pasted amongst different projects and I said okay as a baby step beyond that they did these This code doesn't have you know good APIs that we can split it out into a library yet But at least go from this unmanaged copy and paste process We have to a managed copy and paste project process Whereby we take some of the code from the projects put it in a single repository and have an automated process for copying pasting it Between projects and the idea there was to at least stop the divergence of the this copy and pasted code And so I think we moved on from there to August 2012 When I guess people saw there was momentum around the project Realized that this was a worthwhile project in its own right needed to be recognized as a separate project and Basically recognized that it should have a ptl of its own right and then there were enough people involved There was enough momentum behind it at that point that it was a real thing It wasn't just people wishing for it and at that point the unusual thing was it was the first project really I think That Was around a code base that wasn't a specific functional layer it wasn't a vertical code base. Yeah, yeah So then in the grizzly time frame I was the first ptl I Decided that all of the other projects had a nice funky code name So I didn't like this project being called open stack common. I called it Oslo The notion there was OS to stand for open stack and then Oslo the Oslo piece accord not really analogous But I don't know. I remember you saying something at the summit about let there be peace among all the projects Yeah, that's nice. I went along with that. Yeah, and and frankly part of the open stack common project is about creating Kind of peace between the projects in the sense of in the config option case we had one project with a very opinionated approach and another project with a very opinionated approach and It appeared at a time that we'd never see All open stack projects have the same config file format, which now seems ridiculous But anyway, just moving on from that. They are there the team grew We defined our mission statement, which I just talked about we released the Oslo config library as a standalone library as opposed to this copy and pasted Ridiculousness and we renamed the open stack common repository to Oslo incubator to kind of highlight the fact that What was in this open stack common repository wasn't was never going to become a library in its own But it was more incubator why we worked on APIs and stabilize them New things would come into being and grow and evolve and then be released from them. Yeah, exactly. Yeah Yeah, and so after the grizzly summit moving into the Havana time frame we Well, you worked on releasing Oslo messaging Which there was a whole pile of RPC related code and there were big API changes in that library as it got released I remember going through several iterations of that new API. That's been successfully integrated into all of the projects at this point Yep, and then we also during ice house Well, that was when the adoption happened and we started evolving some more of our tools that we use for working on the code that We're sharing and as we grow and do release management and things like that And then during Juno this past cycle, we had a major push for graduating libraries So we looked at all of the code in the repository in the incubator repository very critically Decided what code was stable enough and had decent API that was ready to turn into a library and we created seven new libraries from that We also created the liaison program so open stack as a whole has grown enormously since the time that we started doing the Oslo work and in the beginning the Oslo core developers would work on code in the incubator and then take it back to each project and sink each copy in and Make sure that it worked and as we were graduating libraries We would go and make the changes that the projects needed in order to adopt the library versus using the incubated version But as the number of projects grew that just became untenable and so we sort of reversed the Responsibility and said that each project needed to provide us with a developer and work with us directly and that's worked out pretty well We had a few bumps, but over the course of Juno We were able to release seven libraries and many of them were adopted immediately and the rest are on track to be adopted During kilo and what's really impressive about both what dog has done here Is like in contrast to the early phases of the project where my attitude was look I've done this once with the config Library, I've you know, I created the stable API made a library out of it And I did the work myself of making all of the projects adopt that You know and other people will be coming and ask me about When are we going to do this for other projects? And I just expected other people to look just follow my example and do the same thing over again Instead dog kind of really created a framework around this project liaison notion in terms of sharing the responsibility of Projects adopting these libraries, but also really started cracking the whip in terms of you know Let's let's really start graduating some of these and let's stop waiting for someone to come up and start doing Amazingly motivating when you delete code from somebody's repository. Yeah, so Adoption has really taken off and since dog is taken over in the last year or so So the I did not do all of that work on my own there we have a Small but very devoted team on the Oslo project. It's kind of divided in just as the rest of it so I look at Oslo as a Self similar to the rest of all of OpenStack, right? So we have a horizontal team of core members who are responsible for a bunch of the projects that are managed within Oslo and then we have some vertical teams that are very focused on Managing a specific library. So a couple of examples You know, there are four or five of us who help with the release process and get the ball rolling on a new Graduation and that sort of thing and then there are a bunch of people working on Oslo messaging and Oslo DB and Oslo config and those sorts of libraries where they don't really worry too much about the release process they worry about how Do I make RPC work with? Zero MQ versus rabbit or how do I make this particular kind of database? You know Postgres doesn't quite work exactly the same way as my my SQL So I've got to deal with different exception handling cases and things like that so we have a lot of opportunities for Contributions if you're interested in a particular focus area or if you just are interested in general, you know Software engineering kinds of responsibilities Yeah, and I think like as you say there is parallels to to the generalist versus specialist split and other projects But I think it's especially marked in Oslo whereby you know the generalists care about things like API designs and you know properly thinking about configuration options and you know There's a real broad set of things really important things to think about it in terms in Oslo That is very very general and spread across all of the projects But you some of the libraries we have are extremely Specialized areas in terms of database and messaging especially and the ability for someone to Take an interest in that area and go very very very deep and be very very specialized and just focus completely on What looks like a small? Library to begin with but it's actually a really complex area So this this split between these kind of specialists and generalists. I think is especially marked in this project Yeah, absolutely So let's talk a little bit about where the code that we get comes from so you mark introduce the idea of taking code out of the projects We also do create some of our libraries from scratch. So a couple of the examples there Oslo Sphinx is a Documentation theme for developer documentation. So if you go to docs dot open stack org slash developer and look at the Documentation for the projects there. That's all themed using a library. That's managed by the Oslo team It's pretty small has a very fixed API because it's basically plugging into a framework for a documentation tool So we just sort of wrote that one from scratch The packaging library that we use called PBR is another example of that where we we're following an API That's defined by somebody else. There was no real need to do an incubation process and evolve that API We also have adopted a couple of libraries that were created independently of OpenStack the cliff command line Framework that's used in the common command line tool and in neutrons command line tool Was sort of put together with some requirements that I knew about based on some open stack work But it's actually used outside of open stack in some other projects stevedor is another example of that it manages plug-ins. So we used to have a library or module in the incubator for importing Dynamic code so it was used for loading drivers and things like that and stevedor is a more refined using some standard library tools for that Task flow is used in a couple of different projects now for managing long running tasks You can pause tasks and rewind things and that sort of thing and all of these libraries were created outside of the Oslo program and some of them were created outside of open stack entirely and then when they grew to a point Where they were sort of big enough and being actually used and we said yeah We'll adopt them and they'll be official programs and that gives us some benefits like being able to put them in the gate so we can Make sure that it changes to stevedor don't break Nova It also gives us the opportunity to have those contributors be part of the open stack community and their Considered active technical contributors and that sort of thing. Yeah, absolutely So what you see in Oslo in with these libraries is Some of the projects you can think of them as being quite open stack specific in the sense of you really don't see them being used a lot Outside of open stack whereas the likes of stevedor for example, which Doug created is extremely general You know, it's a it's a lovely shim layer on on top of the the kind of python pluggable code concept But I think what we might see over time is some of these Libraries that we see right now has been very open stack specific There's a huge amount of scope there to maybe to you know make some of the open stack isms a little bit more optional Maybe drive adoption in other projects You know and some some level of maybe misconception about how open stack specific some of these these these libraries are like the Oslo config library for example You know, I think could be reused in plenty of other places Yeah, there's there's nothing open stack specific about that And and that is definitely something that we think about when we look at code You know, I spoke last year at open stack in action about the amount of code that open stack has and at the time It was I don't know some a million something lines of code and that was an awful lot of code We could probably shed a lot of that and so this is one way that we're dealing with that It's trying to push it into libraries that are more general purpose than some of the things that are actually open stack specific And so I think we have even seen interest from contributors plenty of interest from contributors to some of these libraries that You know, they're really not open stack contributors They have no real interest in open stack itself But see the libraries and find the development process easy enough for them to contribute to and yeah No, stevedore is a great example of that There's a member of my local Python user group who has no real interest in open stack at all But he's a core reviewer on stevedore because he has contributed significantly to the documentation and some Features and that sort of thing so when we had our summit in Atlanta He came to the core reviewer party in Atlanta as a core reviewer because he was available and and You know that that was part of the arrangement. So he's There you go work on one of these little libraries and get that right. Yeah party. Yeah, exactly. Yeah That's what open stacks all about right parties. Yeah Okay, so in addition to The code that we have created from scratch and the code that we have adopted from other places We also have the incubator process That you've talked about a little bit already. Yeah, so dog has created some nice nice pictorial representation I guess of what I talked about here before so what you can kind of imagine here that between the squares and the circles is It's funny. I didn't talk about them in colors because I'm colorblind. So I don't realize that I'm sorry But so on the left That's left-hand side. Okay, so on the left-hand side You know You can think of that as a project say like Nova for example and it has a bunch of code for doing Configuration options and on the right-hand side is glance and it has a completely different set of code for doing configuration options in a completely different way so the first step of Next slide the first step of what what I guess I did with the config options Work and we do with all of the other similar cases is we're we're trying to extract the code out compare kind of the use cases and what they're doing try and find similar similarities and overlap and you know essentially You know bring the two of them together into into code that's going to work for both use cases but at this point You know, you might still not have a perfect and perfectly stable API that you're sure isn't going to kind of need a lot more work yet So at this point the code is now in the incubator and is copied and pasted You know using an automated Process into each of the projects and you can do the work to integrate This new implementation of that work into into these projects and kind of make sure the API really does work for those use cases So then as we take that incubated code and we prepare it for graduation to turn it into a library We found we've already talked a little bit about some of the problems that we find but One of the big issues is that That use of the config library throughout the application is pretty you know pretty flat pretty straightforward But if you start having libraries adding options to your default application group Then you you sort of are mixing and matching purposes So we try and standardize on naming for groups for options We try to make sure that the option names themselves make sense We clean up the API so that the options We don't want the options themselves to be part of the programming interface So we don't other parts of the application or other libraries to be poking around in the Configuration options of a new library to see how that library might work. We want them to pass that stuff in blind We also Try to make the API Configuration free because that makes it easier for that new library to be used outside of OpenStack So every OpenStack application is using our configuration library But applications outside of OpenStack are not generally using that library And so we want to provide an API that doesn't require the use of that library if that that's possible We also find a lot of cases where a Module will because it's been developed in the context of an application sort of assumes some Global state that's managed by that application or it will update data That's being read in some sort of sneaky way And so we want to plug all of those holes and make sure that we have a nice clean API So that if we make changes inside the library, we're not going to break applications and We also try to make that API as small as possible so that As we release new versions, we can add things pretty easily But taking something out of an API requires a long deprecation period and it requires a lot of changes and applications And so we want to avoid that as much as possible And then of course we have to give it a good name. Naming is one of the hard problems in computer science, right? So I think one of the more challenging Graduation processes we've been through is the Oslo messaging library, which I created so In the beginning that the messaging code that was created in that the nova project was a very very, you know simple shim layer over the It wasn't combo. It was carrot. I think was the original But it was a very small little shim layer over a mqp messaging The API was all about creating topics and you know, you just wrote a dictionary into, you know onto the message bus and You know, there was very little hiding of the kind of a mqp concepts there You know very little hiding of state in terms of connections You know, there's a real kind of API that when you worked on the code underneath it you really You know, you really felt that any little change at all was going to break the consumers of that API So, you know before splitting that out into a library We needed to really make the API contract very very very clear because one of the goals of Oslo messaging was that while the current Drivers while the current implementations of those APIs were a mqp based and we wanted to support Alternative drivers we wanted to encourage some innovation around the usage of this API and you know even To add an mqp driver that didn't use a message bus for example And just to make sure we had a very clean API that was as abstract as possible to support all the use cases that in the current projects But, you know, so abstract that we could actually support multiple different different concepts So I wound up taking, you know code that was very much AMqp send a message and message bus type code and create two different abstractions One was around rpc servers and clients and the other one was around kind of notification Senders and receivers and so that's that you know those abstractions have completely hidden the You know then that then really kind of messaging technology underneath So for example, you could imagine a notification Implementation that just sends notifications over htp for example, but doesn't implement the rpc contract constructs And a counter example to that is what we did with the database library where There's already a nice python library that gives you a good abstraction from different databases So we didn't recreate all of that that's sql alchemy So we built on top of that and are managing the configuration of the database connections and we're providing some fixtures for use in tests and things like that and Managing them the database migration script So we're trying to get off of sql alchemy migrate and onto a lembeck as a different tool That gives us some more flexibility and that sort of thing So putting all of that stuff in oslo.db hides it from the application developer But we didn't have to recreate all of the different You know abstraction layers that we needed for the messaging library All right, so once we have that code in Ready in a good state ready to graduate then we can oops We can turn it into a library Is it not animating okay, so imagine that the Triangles up there get fainter and there are lines between them There we go. Okay. I guess I did it twice so At that point then we can turn it into an actual library and follow the usual kinds of code sharing patterns that you expect With a shared library you you have releases. You have a stable api. You have contracts about when you're going to deprecate things that sort of thing so You make that sound so trivial yet We actually have quite a bit of debate going on about how to evolve that How we do the releases of the the libraries for example, we do actually we have a couple of different issues with that right now So for example, there's the debate about whether We should you know tie these like the library development cycles with the Open stack release cycles. So for example, we'd work on new apis in a library over the kind of six month period going to feature freeze and then do a release of those Or whether we just actually release these libraries kind of as we add a new feature We had immediately release a new version of them. So it's that's an interesting problem It's interesting. I mean so during june we used a lot of alpha release numbers So we would sort of anticipate what the final release was but we would release alpha versions leading up to that And that led to some confusion about whether the library was actually ready for anyone to use or not And we had some projects that were reluctant to adopt it because it seemed to be of alpha quality where we were really using that tagging as a protection against deploying into a continuous deployment environment where Something that we we were not declaring as stable but was ready for development use We didn't want that to show up if somebody was doing stable deployments off of say the stable ice house branch or something like that and then I don't know we have a session later this week I guess tomorrow to talk about whether or not to continue doing that based on Experiences and feedback And then some of the libraries some of the ones that we adopted in particular We were going ahead and just releasing those using regular version numbers because they they have a history of doing that So and they're a little bit further along Okay, so let's uh speaking about what we did in june This is what the incubator looked like at the beginning of june Each of the little fuzzy grade dots is actually a module name And there were enough of them that they don't all fit on the slide The lines are relationships between them So Those are arrows and if if you can tell they're there's some cycles in there Which means that we've got module a imports module b imports module c imports module a again Which is not something you can do in a library. It works. Okay in an application But it it's not something you can really do with a bunch of libraries So that was one of the first things that we had to sort out was breaking all of those Relationships up in logical ways that allowed us to turn those things into libraries And that's what but like I hadn't thought about it this way, but I guess when you were trying to push the graduation cycle of libraries you're trying to Take take elements of this out and figure out a kind of a tree Order that you were going to create Yep, exactly. So we had to figure out Not just what the relationships were and create a graph that didn't have any cycles in it But also based on once we had that graph What order do we work on this stuff because if we start at the top And pick some libraries that are using incubated modules Then we end up copying the incubated modules out into all of those libraries as we release them So we started working from the bottom up so that we would have for example the internationalization library the very bottom Lots of things import that so they can do translation It does not really use any of the other tools because it's built on top of some other standard libraries And then we worked our way up and we have oslo utils and serialization And around that point we started finding that we had some code that wasn't being graduated That was using code that was being graduated and we started running into some issues within the incubator that Let us to change our policy about backwards maintenance and and things like that So we had planned to keep modules around in the incubator until Projects had had a full cycle to adopt the new library But it actually turned out to make adoption more difficult because if a bug was fixed in something that wasn't graduated It would be possibly importing A graduated version of something that was still in the incubator So now in in Kilo what we're going to do is as soon as we break something out into a library and get the first release We're going to delete it from the incubator. So it'll still be in the stable branch But we're not going to maintain it in master Which will make adoption easier because you'll continue to be able to sync the other modules that you're using So the the colors up here gray yellow. Yeah, okay. So the colors the yellow ovals are the libraries that we released during juno the blue ones were released prior to juno So either in ice house or prior to ice house that includes A late adoption in ice house the pi cdf library Which is now actually being managed by another program. So the keystone program took that library over from us So we it's found a couple of different homes in its lifetime and we had it for a little while But it's it's fitting into the auditing work that they're doing. So That's another aspect of what we do not every Not every shared library actually has to be owned and managed by the oslo team So we helped some of the other teams get themselves set up with the right kind of tooling so that they know how to create a new library and Make good use out of it All right Okay, so talking about the libraries that we did graduate We so oslo config was the first one Uh way back Oslo db was just about ready to graduate in ice house But it came out early in juno It got it was close enough to the summit that we held off Because we didn't want to be too disruptive and there were a couple of issues that we had to to fix Oslo internationalization itinen Came out that that's for as I mentioned it's for translating user facing messages So that includes things that go into the api error messages as well as log messages So we actually have different translation support for different log levels So if you're in a locale where you Would like to be able to have your logs in your local language That's an option depending on whether the translators have caught up with all of the messages or not Honestly, I Find that the work we've done on Oslo itn quite surprising and interesting. I think it's It's very unusual. Actually. I've never seen another open source project, which You know really distinguishes its translation efforts between which ones are going to be user facing which ones are going to end up in log files You know allows Translators to prioritize user facing log messages over user facing messages over error messages over debug messages It's pretty cool stuff And I'd be surprised if it wasn't also useful to to lots of other projects I'm gonna call you on that one. Deployers are users to Log messages those are users too. Okay, so but yeah I am not aware of anyone else doing anything like that and when it was first presented to me I thought I don't know that seems a little Odd, but sure it was we had enough demand for it. So we went ahead with it And we've got some plans in this cycle to add features for dealing with things like plurals and Context so I don't know exactly what that is But you you can apply context to a translation to give it a little bit more information as it's Generated. Yeah, that's cool stuff. Yeah Messaging we've talked about as our rpc layer Oslo middleware is a set of Whizgy Middleware which is used for building rest apis. So whizgy is the python standard for composing pieces of code together in a stack that makes a a nice HTTP interface And we've got a couple of different whizgy middlewares in that library Oslo root wrap is Basically our wrapper around sudo or a replacement for sudo if you're not using sudo in your production environment the serialization library Was going to include both jason and xml, but jpipes really hates xml So we're kind of dropping xml as a project and so right now it's mostly tools for working with jason Oslo test is an internal tool It's used among the other projects for writing unit tests And it's got a bunch of fixture support and base classes for making tests easy to work with and then Everybody has a utils module So oslo utils is sort of the catch-all where there's a bunch of little things that aren't big enough to be their own library And they end up there and we try to limit that to things that don't have other dependencies because we don't want Somebody who uses oslo utils to drag in a bunch of other client libraries for talking to memcash and things like that Okay, so one of the other things that we do in the oslo program in addition to looking internally at open stack code Is we try to look outside of open stack and how we interact with the rest of the python development community and other development communities We try to Not recreate things that already exist We try to take problems that might appear in some of our applications that can be fixed upstream and help Make connections between the application developers and the upstream developers who aren't working on open stack I've talked about adoption So one of the libraries that we adopted this last cycle is called pi lock file Which is a long lived python library the maintainers have basically stopped maintaining it And had been looking for quite a while for somebody to take it over We decided that we were using it We wanted to make some changes and move some of our code into that library So we've adopted it and that we'll be making some new releases during the kilo cycle with some new features added to that library And it's funny you talk there about the connections between the open stack community and the python community dog I think would have been the first Real python beasted kind of community person to join open stack I think so I think it's very very very appropriate that you're running the oslo project now you know for a community like open stack that is I don't know how many 500 developers contributing every month. They're all python coders Tiny tiny tiny percentage of those people actually have you know been visible in the python community before Which is an odd situation, but it's really great that you're helping kind of That's changed since I came on board too. So we have a lot more people who attend the python conferences and other Events and have more of a history So another thing that we deal with is the the port to python 3 So if you're not really aware of what this is python 3 is Has some syntax changes and their standard library has rearranged a few things and replaced some apis So moving from python version 2 7 to 3 3 or 3 4 Is a nontrivial effort in some cases and especially for us with some of the dependencies that we have So we have a couple of members of the oslo team We're sort of leading up this effort and building some features into our libraries to make that transition easier Yeah, and the key part of this effort recognizing just how long it's going to take Is to figure out what the baby steps are and figure out how to get people Interested in contributing towards making those baby steps. Yeah open stack is like an aircraft carrier You have to be very careful when you're steering it. It does not move quickly So during kilo I talked a little bit about Continuing our big push for graduation This is a rough estimate of a few of the libraries that I know that we're going to have So we have oslo log, which is our log configuration library the concurrency library just barely missed the cut for Juno, so we'll be getting that finished up Early in kilo and then the other one there is Allegible Yeah, I can't remember which one that one is You make that out it's fuzzy from this angle Don't know uh cash maybe yeah Okay, so and we had a session this morning where we went through all of the code in the incubator that you know What was left and talked a little bit about where it might end up living and what needs to happen to it before it can graduate And so we'll have a couple of other libraries graduating as well And then I think at the end of kilo We'll have some code left in the incubator That is either going to be deprecated in end of life Or doesn't really have a lot of adoption and so we're not convinced that it's stable And so it'll stay in the incubator for a little while And then we'll be working mostly on the existing libraries and and identifying new places and new patterns for bringing more code in So yeah in terms of you know, I guess what we're trying to get across here is what the oslo project is about and And you know try and encourage people to to get involved first and foremost You know in some ways, it's like any other project how to get involved You know you maybe start doing reviews you start looking for you know small easy places to kind of get involved and start You know fixing obvious things Actually talked to a developer last night who you know was interested in open stack wanted to start getting involved And I think he tried to run the oslo incubator unit tests on his debian box And it broke in various places and he went because it was using python 3.4 instead of 3.3 And this was his you know He found he he was delighted because he had found an avenue for him to actually start getting involved and start fixing something and start Being useful So look out for places like that But you know, I guess the oslo project is different in that It is cross project all of open stack You know, you can work on a library that is very Nice and self contained and you know a nice kind of area to work on You have this choice between whether you want to be a generalist in terms of api design and stuff Or whether you want to be a specialist in one of the areas of the libraries Yeah, you know you have anything uh as small as oslo utils that has some string manipulation tools and things like that which are very Very easy to to wrap your head around all the way up to oslo messaging which Requires some expertise in dealing with message queues and and other messaging technologies and that sort of thing Or if you're interested in databases, there's the database library that's got a lot of active development right now going on But yeah, there's all sorts of different ways to get involved and the team is pretty small right now So interacting with us is easy. We meet on irc in One of the open stack meeting rooms I think it's open stack meeting alt on mondays at 1600 utc So you can join us for our meetings. We'll start doing that The monday not the monday immediately after the summit, but skip a week And then obviously on the mailing list if you have any questions about oslo code you can Tag your subject with the oslo tag so that the developers are sure to see it I know that I filter those and and give them a higher priority for reading because the mailing list volume has gone incredibly high All right, well, we're four minutes over now, but you know if anyone had any really burning question Well, it's four minutes over at the end of the day. So Um, anyone got really burning questions or maybe you can just ask us directly afterwards No, okay. Well, thanks for coming out. Thank you all