 Good morning, everyone. My name is John Garbert. I'm a principal engineer at Rackspace. I'm the current Nova PtL I was also Nova PtL for the Liberty Cycle If you want to get in contact my IRC name and Twitter handle is at JohntheTuberGuy so today this talk is about the friction between upstream priorities and internal priorities and when preparing this I think it all boils down to one particular question which is You've been busy working away. You've installed OpenStack. You're using it and Yes, not quite a wood tool workshop, but still you're busy working away and you come up with a great idea You're like this is fantastic. How do I get this upstream? There's lots of talks talking about Why you want to get upstream? I'm just going to concentrate on how you start taking that idea and Communicating it with the upstream community Before I delve into that I wanted to start with talking about why I'm here talking to you about getting ideas upstream in the community And share some of the experiences I've had doing this over my time So My first sort of experience with OpenStack where I started with OpenStack was back in December 2010 I was working at Citrix. I just moved to the sort of cloud research group and we're like well, let's try this OpenStack thing Let's see what it does and play around with it There's these Rackspace folks trying to use n-server and OpenStack. This will be fun. We should have a look And we'd looked at like what can we do with this and we thought well Everyone else needs to be making a private cloud package or talking about it. So let's do that. That sounds cool So we created this project Olympus and we were building this private cloud packaging using pop it and all sorts of different bits and pieces and We had like nice in-jokes like we'd come up with this idea of Pinocchio So we thought well clearly the puppet master has to be called Gepetto because that's Pinocchio's dad So like sorted we've got a product. We're fine Things changed we sort of got things working. This is I'm my sort of experience as a taking OpenStack as a consumer and packaging it and that kind of thing but the experience sort of changed because Citrix acquired cloud stack so Being adaptable as I am I thought well, I don't want to create a competitor to what we just bought So let's think of a different thing to do Now the important thing is is like Even at that point there were originally there were plans to sort of combine the things But the key point was is we need Citrix n-server as a as the vendor of Citrix n-server to work really well with OpenStack Certainly there were lots of predictions at the time of we need to make sure you know OpenStack isn't a reason to move away from Zen if you're invested in Zen invested in Zen server OpenStack should be the perfect choice for you At the time while still today the sensor the pools are quite small and using it's really good fit for using a sort of Cloudy kind of world. So I was focusing on this I Always remember sort of my first design summits Crazy scary. I was in the room with lots of these people who'd known each other and it's like how do I Contribute here. I was lucky to have mentors who have sort of brought me and said hey, you should go meet these people and get to Introduce them and you get to get that face-to-face contact And you start to get pulled into the conversations and as a kind of really interesting experience as you kind of On board in the design summits and I remember sort of switching between. Oh, no, there's this Cinder session It's talking about Zen server specific volumes better run over here and then there's this nova thing over here better run over here Fun times it's good Anyway, so Talking to the summit with lots of people as these rack space folks building this huge cloud And I thought well, I did kind of be kind of fun to work on a massive cloud So I moved over to rack space and was working The main change was the focus in the compute section So I work on the in the compute part of the public cloud team As part of that I discovered The wondrous nature of code reviews and how actually useful they are to actually start to understand the system It's genuinely true like doing code reviews and you get to see what other You know what all the other reviewers are saying about well not not sure your code But the other code that you're reviewing and you go plus one. This is great minus one There's this massive problem that breaks the whole world. Oh, well, that's kind of interesting Like there were lots of sort of aha moments as you sort of learn through this whole process Over time I sort of started to look into helping out with the nova drivers team looking at blueprints and design reviews mostly because of It's all getting involved in the design summits. It just sort of spilled out from that Eventually us became the release CPL, which isn't a strange kind of robot The CPL is the cross-project liaison for the release team. So I was looking at What blueprints land where I do we actually have any blueprints that are finished, you know What's the state of them helping coordinate all that stuff and In the beginning of the liberty cycle I became an over Ptl and got all sorts of more kind of fun seeing so sort of it's an interesting journey from Being a package over the system being a vendor making sure that my product is a vendor worked and sort of Being on the other side, which is an awful phrase to use But sort of going from you know leading the project talking to all these different people in different ways So one of the questions that I often get is you're called at John the Tuba guy Do you actually play the Tuba? No one really believes me. It was very expensive to stage of this photo. No, so this is this is me with my quintet I'm me playing the Tuba With corona brass. So if there's anyone in the Cambridge area in the UK that needs a brass quintet Hopefully someone once on the video once it's recorded what I might actually do that do get in contact We do weddings and all sorts of things I mean if you pay for the travel we'd probably come over here, you know anyway So for those of you who pick sessions by the title this slide doesn't make any sense For those who either read the description are probably just as confused But what I wanted to add in here was a literary reference my partner Sally she's Does sort of English and is really interested in English literature and runs book groups So I wanted to have a nod in her direction by saying I'm gonna reference this literary text. I say I Was talking to this with Sally and she said oh, that's your favorite book. I said yes It's the only book I've actually probably read from the beginning to the end and really enjoyed it. I Actually studied it, but it's we'll get back to that So I wanted to start by thinking about what What do we want? The opens that community to be And as a community we've been quite explicit about that. We want to be an open community there's lots of Details and definitions about what this open means There's open source. It's not open core. The whole thing is open source patchy license There's open design, you know, we have design summits. We have open development open road maps Everything's open. Is it great? You know, we want a vibrant community of users and developers all working together Then anyone can come and join in and We strive really hard for this and you'll see if you read the main list and everything else. We're really We really really appreciate where we're pulled up where we're falling short on these things So where we can do better and better and better at being more and more open. This is like a key goal so when I was Researching this apart from the fact a picture of an elephant is kind of cool. I came across this story of Three blind people meeting an elephant Some of you will know this very well It was relatively new to me actually so the first person comes up and they get hold of the The leg of the elephant go well, this is a a crazy feeling tree trunk. That's kind of interesting The other person gets hold of the ear and it's like well, there's this leathery kind of flappy thing. That's Confusing and someone else I do others this massive fire hose with teeth That's interesting. It's even more interesting and Well, they're kind of all correct, right? But it can cause an argument. So they go away. They sit down They go to a bar and have a drink together. They're chatting about this thing that they saw in the woods And you know, no, no, it's definitely like sort of this shape and no, no, it's definitely like this If you've been to a design summit You could call the elephant all sorts of things you could call it a problem Lots of people seeing different parts of the problem Like one of the great things is where you have all the three people get together and describe all these different pieces And you get a much better understanding of the whole It's really It's really rewarding as a developer when you actually see that happen. You're like, I didn't think about that That's super interesting and you get all these different pieces fit together And you get a much better solution that doesn't lock you into a particular mindset or It's kind of where the The anti-lock-in really comes in it's more about thinking about the whole and you're starting to put stuff in and I Can talk about ours for that. So I'm gonna stop so Another thing I came across When looking at this is this ladder of inference It's kind of lots of words on a slide but the the basic idea and this is My bad interpreted philosophy that seems to just make my point But so there's an awful lot of data in the whole world and as human beings We naturally filter that down to a very kind of small set of data so Yeah, we filter this down You add in your assumptions of the world and you come up with conclusions That gives you a sort of set of belief systems and based on all this stuff You decide what you're going to do and the other piece is that like your beliefs and everything else also tend to influence the Data that you select and there's kind of like a cycle where you you can get like bubbles of knowledge Where people have shared context so you have two different groups of shared context and they could be In order to get people to work together. You have to look at like what's behind that and understand your shared context Let's make this a little bit more real. There's an interesting example of Someone doing an interview so you're sat down doing the interview and the person walks in ten minutes late You have a chat everything else who seem okay. They go away. You'd like why not today come ten minutes late Clearly, they just like don't care. They turn up late everywhere. That's super annoying Well, given the data you have that's a reasonable conclusion to come to what you didn't know is that they were rushing from the hospital At the other side of town they gave an hour they get stuck in 17 traffic jams and they just forgot to tell you about that because they're embarrassed and It's interesting how you can easily get the wrong end of the stick release. That's a phrase where I come from And I just like how this particular description kind of describes that scenario people of people. It's not that It's easy to get into these nasty situations One thing that I often get asked about particularly more being PTL is Why does the core team seem quite cliquey? Now the real the real answer is is the core team and all the different sort of levels and different teams Are really trying to be open. That's why I started with the openness They're not Attempting to be this but you do have teams that are quite highly gel that have been together for several years with an awful lot of shared context and As a community we have to work hard to make it really easy to gain that context We have to be able to mentor people and reach out and pull people in and it's really it's hard work And we have to keep doing that and have to keep striving for it but this is all about you know pulling everyone together So I've been talking lots of theoretical things I'm a technical guy, so I thought I'll draw some diagrams to try and describe this world so There's lots of ways you can view like the set of problems that open stack is trying to solve but Let's say I simplify it to a red circle because that's really nice It has great properties. It's like beautiful. It's round. It's a nice shape It seems perfect as a low-energy state. Everyone loves it. So it's like this perfect view of the end mission So it was the Nova PTL, you know I've got my view of the Nova project sort of like 10 years time Well, I'd love it to be and it looks like that bear with me. It makes some more sense in a minute Today What would I say Nova looks like? Well, it's a little bit like this, right? So that's not gonna work on a screen as it never mind So there's a hole in the middle. There's bits that are in our vision, but just haven't been implemented yet We really want to fill that hole badly because it would make it much much prettier bit more like the red circle There's a whole lot of that gum from the outside that sort of slightly darker red bit This little bit at the bottom we might have deprecated this other bit We sort of forgot to deprecate but people are using it. These are things that like the project It's in the project. It's kind of being used but it doesn't really fit in with the mission and we kind of need to find a way of Fixing it So now let's have a look at like the internal view of the mission Like with my internal hat on how I see the project looking. It's very easy to sort of think Well, it's you know, slightly smaller scope kind of looks like this rounded square. It's also pretty It's also beautiful, but it's completely different to what the other people are thinking And that can cause, you know, that's like this. I'm trying to visualize the mismatch of the context So at the beginning I said I was going to talk about getting my idea upstream So what's my idea? I love my idea. It's fantastic. It sits there. It's perfectly in the mission So I work away. I Implement it and someone says, you know, you have to get it upstream, right? Oh, yeah Oops, I should probably go talk to those folks. So you upload your code for review and The people reviewing your code kind of view your solution a little bit differently maybe So sometimes it can feel it can look a little bit like this. So There's this bit at the bottom over here Super excited about this piece here You're filling one of my you're filling one of the gaps that we've been looking for for ages And that's the most amazing thing we've seen for a long time So people get really excited about that, but it doesn't solve your problem You want all these bits around the edges that kind of are in scope you're depending on something that Nova is trying to deprecate your Maybe re-implementing something that's already in the project and that's kind of Causes friction So this is where I insert the random literary reference not really random So I think the key to actually resolving this is about empathy. I Like this quote The idea is right you don't really understand the person Until you look at that point of view you walk around in there You climb into their skin get in their boots and walk around in them, you know That's sort of idea of visualizing what the other side thinks now. This is a two-way process The people reviewing your code need to understand where you're coming from and vice versa, right? It's a two-way street. You'd empathy definitely on both sides So let's get back to the problem in hand So I wanted to take a slight deeper dive into this diagram and talk about some of the Outcomes of discussions about this squiggly cloud thing So one thing that sometimes happens is right you come with your solution And people go not really sure what you're trying to do here So after some discussions you get actually down to what the real problem is you're trying to solve and The answer can sometimes be really exciting good news. We already have tested that and created it for you and it's over here So you one reaction is Sort it use it sit down That the extra piece I'd like to add is well you probably well maybe didn't read the docs But it would be really good if you could actually help other people find that too Because clearly When we wrote the docs and understood everything we didn't get your point of view correctly and didn't communicate that well So that's a failure and that should there's still stuff to do even if you find your problem solved Another thing is you go. Yeah, what's idea? You know solution up. Well, actually this guy over here is already working on it Mel over here is busy working on this. Can you help and my request at that point is very often Can you help review it? Like even if you can't split that work up into pieces just help review it make sure it does actually solve your problem test it out And that there can be a great thing One thing that does happen sometimes is you go. Hmm. There's a tick on this hypervisor support matrix That means I can use this crazy live migrate thing. That sounds awesome You set it up and okay, so maybe it doesn't quite work as you expected in your particular configuration Now that's great data You may not even realize this or there may be 17 books in launchpad already saying this But getting people together that actually have the same problem get together and work together to fix that That would be awesome So let's look at making sure that the red is actually red. It's not just a sort of Weird beige color. Okay. I'm stretching that way too much So what's the other case is? Oh, yeah, that's that that's that Whitey-bluey bit over there. That's the piece that we've been looking for for ages. So yeah, I mean, let's try add that That would be awesome There is another piece which is you talk about the problem and then you end up saying hey, maybe this is out of scope. Maybe Maybe you're building on something that we really want to try and move away and there's problems and well It's trickier right. Let's get to that. So what if your idea is out of scope? Well, it's Just to reiterate the point First discuss your problem and then talk about the solution. It's really easy to sort of get Maybe this is particularly as a developer, but it's really easy to start talking about I've got this amazing solution I know if I do this this and this everything's fixed the world's normal is amazing and That might well be true But I think the key thing is is if you get people if you talk talking about the problem You start building that empathy people start to understand the problems that you're seeing in production They start to realize why your users are not adopting this particular piece because of this this and this not quite fitting together as it Should be and then what they do is actually sometimes very exciting believe it or not the person goes oh That's kind of interesting problem now I think you do this this and this and you start Collaborating with all the different people because you build that empathy And very often you find it's just not out. It isn't out of scope after all the solution may have been out of scope Your problem at a different solution may be bang in scope and maybe exactly what we've been looking for Or it might be that we have to expand the circle with a big mark pen around the outside because you realize that actually We need to expand the scope here. There's all sorts of different answers, but fixating on the problem It really helps So there is another option which is Okay, so it's not out. It's not in scope. This project's got way too big. We just can't scale it. We need to create something else It turns out this is actually very effective. This is where the heat project came from Heat the people in the nova project saying hey, we've got these Groups of VMs and we need to orchestrate all this beautiful stuff and I was like that's a really good idea But we're trying to fix this thing over here, and it's really hard So it's kind of like And we don't want to stop you and we're like we can't really help you we think we don't know Don't talk to me so In that world they created a whole new community and they sort of started working on this and attacking the Attacking the problem themselves and they came up with a fantastic thing So the fact it's out of scope can be the best thing that's ever happened to your problem It's not a negative thing in many many many cases There's an interesting case that's happened recently, which is this concept of instant server ha in Nova so that the idea is You monitor and you hug a VM and make sure that if it goes away, you notice really quickly and do something about it This is one of those orchestration pieces that inside Nova. We're just trying to fix the The stable API's and make it work But when talking to the people who wanted this instance ha thing they're like well We've got half of this solution that kind of monitors these pieces and can do all this stuff But we're missing like this primitive and like these little tiny primitives if you just add these things in We can do our thing outside of Nova, and we're really happy Very often the project will go actually we need those API's anyway like that's just something we forgot to do It's another one of those holes So work together add that in and you still you get your you get your projects running and and steaming ahead So I've talked a lot I wanted to get down to sort of like where do I start? I'm possibly maybe lying to the next slide And you go. Ah, yes, I'll go find out about the process and So I'm oh, I'm perfectly allowed to take the mic of this diagram because I wrote it It's not as complicated as it looks, but I would say that so I wrote it Then the next reaction is this one Which is my reaction when I saw the diagram after I finished it the day later and The next reaction that follows on from that is okay, so I'll just do it internally then never mind a I Don't think this is the right solution, but I want to work with the solution for a second so first of all if You have internal patches There's people upstream still writing code regardless of what you do about it And even if you try and do some of your patches upstream and some downstream you end up having this Bifurcated development process. That's cost number one. I'm not gonna count the costs as well you any of them So just going through this let's do the thought experiment. I say as a thought experiment This is something we have to do for a case. I'll get to So you you you've got this set of patches you create an internal patch because Something's on fire over here. You need to fix it. You need to get that in production But you've got your patch upstream getting reviewed So you kind of have this like parallel process you have the thing working here But now we can't wait for that to merge. So we'll get this done fixed here That means like every time you try and deploy you need to take all the stuff from upstream merge it with what you have Retest it because you just invalidated all the testing everyone's been doing really well and then You have to add Then you suddenly think well, I need to add a feature on top of that thing I just added and oh dear and that has to go in the Internal patches and it all snowballs and gets a bit of a disaster. I referenced ply here As an aside, I'm not gonna go through what ply does. It just turns out to be a really useful tool if you have a very small patch queue One of the things we had with a big team is if you have to rebase and then force your branch It turns out to people force the branch together at the same time. It doesn't go very well. You lose patches So it turns out this is an interesting tool to like just keep a set of patch files and merge them with upstream and other bits and pieces it The larger that stream of things are the The bigger the snowball of problems So I want to talk about open stack process This could be a double session talk And for that it could be interesting and I realized this writing the slides that I thought you should have also put that one in but never mind a The first piece is the process is designed to help you You may not feel like that, but it really is designed to help you I I'd ask that you always ask this question why Like if you want to like understand the process ask why people will answer that in Nova I've tried to make an effort of like creating FAQs and writing it down The reason is people ask you on the IRC and I can now give them a URL rather than having to type it out every time because I'm lazy Someone show me that trick. It's kind of handy so The first piece is idea feedback really when you look at the process there's an awful lot of Informal and formal processes all about like talking to people understanding your idea and the problem you're trying to solve There's the ML as IRC I see his old school with a bouncer and everything else It really does work and people really have great conversations on there. Honestly, if you haven't tried it definitely do There's some ML summaries that people are starting to produce that are going to help people keep in sync with what's going on the Developer mailing list definitely look out for those if you look for the weekly summary email It's actually right in there right now. I think it's getting split out, but anyway yada yada The other piece of specs and blueprints This process isn't as scary as it seems. It's all about making sure that we understand the problem and we document the problems We're fixing blueprints are really about telling people hey We added this feature. It's in here is links to the docs. You probably want to and it's just a way of tracking things The other thing I want to mention is the design summit. It's It's hard to underestimate how useful being at a design summit is for a developer Getting that face time with the people who are going to review your code You have a face to that person who just gave you a minus one. I'll talk about in a minute you Or you can create a prettier voodoo doll and whatever the the key thing about the summit is It's where people talk and get to talk and lots of the processes you look at like the six-monthly cycle it's kind of Influenced by travel budgets So it's basically, you know, you can you can realize that getting to pick the people every six months is a bit of a stretch anyway for most people's travel budgets, but We sort of work around this like six monthly getting all the As many people as possible together every six months So you have this kind of regular sink and you can get all your frustrations out the system face to you know face to face It's super useful for resolving conflict. I Said I'd be brief and I failing miserably and so I wanted to very quickly cover the types of git commits that are generally in imported Like I've gone about this forever, but generally you've got feature things which are often Tracked by blueprints specs or speckless blueprints or An ether pad or it varies by project and then you have bug fixes very often using launch pad And then the stuff that isn't either of those isn't marked as those but it's kind of a general Thing when you think about which bit the process do I fit into that's the main three points Is it a feature? Is it a bug or is it an other? The others are quite slow to get reviews. I'd make it one of the other ones. That's just my tip The other piece is talking about code of view and speck review Garrett is kind of the lifeblood of the open stack community. Honestly the review systems and everything else They really do help people collaborate and record the collaboration and the asynchronous collaboration would be basically impossible without this I Live in the UK and work with people across the world And I'm very very grateful that this is here if it wasn't here I couldn't get to the tuba rehearsals with my quintet and that would be a disaster But she just play awfully but It's really important. The other thing I wanted to bring out is testing another lifeblood is the testing making sure that every patch actually works Going back to my original experience. I remember pulling down the open stack code before they had a gate Yeah, too painful So one topic I was going to cover is why all the deadlines and Nova I never really found a good way of describing this data Talking with people anecdotally into my team or other teams. I realized that there was this People didn't realize quite the scale of some of these problems that we have I Would love lots more reviewers. I would love Yeah, lots more reviewers. I won't say again. I Don't mean core views. I mean lots of reviewers like the more people we can have helping with all the things that we need To review would be absolutely fantastic During the Liberty cycle, I noticed that we got over a hundred approved blueprints Bearing in mind that the design review of those like each Like the initial review usually takes me half an hour of a spec pretty much and you need two core viewers to do that And the amount of effort going in to get to that level is kind of crazy We actually got 60 of them merged there's about 400 bug fixes The scale is pretty huge. So the deadlines really my sort of punchline was the deadlines turn out to be mostly crowd control It's kind of like we need to stop thinking about this thing here So we can actually do the code reviews here and need to stop thinking about that kind of code of you So we can do the priorities things here Are we going to this for too much detail? But that's the kind of general summary there. I think the key takeaway from all this There's lots of numbers There's usually a reason why people do the things that they do the process is there for a reason We're always open to changing the process. We probably change it too much But do engage in the debate And do you know do helpers like with ideas and stuff that really welcome so I wanted to cover a piece on the level of involvement that you have as a contributor and what that What that actually affects So one type of contributor is the one-off contributor is a quick doc fix is a big quick bug update Update and there's I need this flag here because it's really important to change this value. Why did you hard-code that? They generally may not have met anyone face-to-face, but these contributions are truly truly valuable to the community like one of I think My memory tells me that one of the reasons we chose Python was to enable these kind of one-off contributions because it lowers the bar to entry there. They are really important They are costly for us, but they're super important and are the lifeblood of the community. It's important But when you're doing these one-off contributions, you only have a certain scope of the context So you have to kind of learn the context of in your contribution during that phase and that That can be sometimes be a lot of work Sometimes it's almost zero work because you have better context than the person reviewing it But it depends on exactly what you're doing Or the end of the spectrum There's a regular contributor. They're sort of bought into the mission. They're on the IRC all the time Really all the time in some cases. I don't know how they do that and they read the ML lists go to IRC meetings They've got all this information coming in. They've absorbed it They've dropped off of it on the floor, but then they absorb it again You know that they're sort of bought in and when they create a patch and when they're doing the reviews and everything else They have like a lower overhead to try and gain that context of what they need on that particular piece that they're doing because they've already Spent all this time getting the context on all these different places No one really actually understands the whole of Nova. That's just a I pretend to Actually, I don't I tell you who knows But it's there's a different cost there Then there's a sort of infrequent contributor which is sometimes Sometimes honestly can be the hardest because of the moving context upstream runs really fast, so you kind of have to Regain the context when you come back And there's kind of a phrase that I sort of came up with I don't know if I came up there I've probably heard someone else say it anyway, so this idea of community debt Like when you've gone away and come back again There's you have to sort of regain this context and this kind of community debt thing if you have gone away Like halfway through a project and left something unfinished and people go home to do that next time and this is like kind of debt and Trust building exercise again. That's probably a whole talk, but Just wanted to nod in that general direction Okay, so I'll try and finish up with you Thoughts like how do we how do we all get forward like the how does the community move forward on this? How do all the contributors? You know get to a better experience. It's definitely It's definitely work on both sides So one thing I wanted to talk about is a book that I read Okay, so I did read another book. I lied So that there was this book called gung ho I'm a very cynical developer. I suspect it was being a developer. He type person I don't like frameworks that tell me what I meant to do but this one describes Things in an interesting way, so I like it Maybe I should be more cynical about myself anyway So the starting piece is the spirit of the squirrel the squirrel thinks I need to get in dots Otherwise, I'm gonna you know perish in the winter. It's really worthwhile work. You know, they want to concentrate on getting the nuts So this is about getting people bought into the mission and understanding why they're doing it You know what they're doing is really important The next piece is spirit of the beaver where the beaver knows that it needs to stop the dam from leaking if the Dam starts leaking the whole thing falls down They're not telling people what size twigs to use clearly someone had a huge log But it's kind of everyone's kind of working you're to get people in control of achieving the goal. This is more about Being clear about you know sharing the context and giving people the rules of the game The final piece which is really quite important is the gift of the goose And this is where like if you see geese flying apparently they're encouraging each other on they're like We'll make it to the migration. We'll keep going. They keep switching and it's all this encouragement And that's really important as a As the project and all the contributors we have to sort of encourage each other wrong So this is actually what I'm trying to do right now with the nova project Why we're trying to get people aligned on the mission like bits for the product working group and everything else It's all about getting this gel team So I'll finish with some top tips Going back to this problem first solution second. I think that's It's a corny thing to say, but it's so It's so so and helped me over the years to try and win people over it's kind of develop a marketing in a way It's get people bought into your problem get to agree the problem on the sun the scope. It's super useful Ask why and debate don't shout keep asking why learning more and you know actually debate And the more you get involved the more fun I've had that's my experience So if you fancy getting more involved, I'd recommend it. I Was gonna finish with this quote I think all of this a lot of this boils down to empathy So everyone understanding each other better and taking time to make that understanding on both sides. I really do believe that Anyway, I want to thank you very much for listening to me. I hope It really helps you on your journey with through open stack Thank you very much for your time And if I think we might have a few seconds for questions If there's any particular questions if not I can talk to people afterwards Thank you very much