 All right. Thank you So for those of you who are not here for the trove project update When look at your schedules quickly and figure out where you want to go My name is Amrit. I'm the ptl for trove Have worked on trove since about ice house just before ice house I Think I have about 35 or 40 minutes, but I don't have stuff for that much time. So if you have questions Let's make it interactive So what does trove do? Trove is the database of the service project for open stack. How many of you here have deployed trove? How many of you have it in production? Okay What databases are you guys using way over in the back? Okay, anybody else other databases? MongoDB, okay, anyone else? Okay? Anything else? Anybody interested in databases which are not supported it yet? Okay, so Trove is a framework trove is not the database trove is a framework within which you can Orchestrate manage life cycle of many different databases like you've heard here mango Maria my SQL The Objective is to make it easy for you to manage a enterprise deployment of an application which potentially has multiple databases in the back The project itself was Created by the folks from rack space and HP It was incubated before the ice house release. It was integrated in ice house. This was when we still had the integrated open stack in The most recent release which was okada. We had 25 or 30 contributors between 25 and 30 contributors and Some numbers from the user survey Trove is in production in 3% of the deploy in 3% of the surveyed companies 13% of the people who were surveyed had deployed trove 10% were testing it and 33% of the people surveyed were interested in using trove in the next cycle I Think the numbers have been relatively consistent over the last couple of releases The consistent as in and there has been growth I think the only thing which is kind of new on the slide is we have the fancy new logo Which you can see on the top which you've probably seen for the other projects as well so in the in the pike release The significant things which we're looking to do are the two community goals one of them is to put the API behind the whiskey server and Support Python 3 The controller side is now fully Python 3 enabled the guests are Potentially not completely Python 3 enabled for those of you who are familiar with the trove architecture You realize there's a control plan component and a guest agent component And there is some code in the guest agent which is potentially Python 3 questionable at this point So we're hoping to get that done by the time of the release The other thing which is currently in flight is to support Xenial for all the databases We currently have a mishmash of support for Xenial and trustee Many of the databases currently have Xenial support some of them don't we're trying to get that up to up to snuff With the pike release we are not going to be testing trustee guests or Trustee controllers, so for those of you who are using trustee you probably want to keep that in mind So the release themes for pike The major thing which we wanted to focus on for for the pike release was just focusing on resiliency of the project We've done a number of things in this area, but for those of you who are not familiar There has been a significant transition in the project during this release Till the previous release till okara Tissera which was the largest contributor to the project is now no longer officially part of the open stack community So that change has left a significant You know void in terms of contributions, which is the reason why there's a whole number of these things which are Excuse me marked as minor focus This has basically resulted in a significantly smaller number of contributions during the pike release Which is the reason why we're diminishing the focus here so Looking ahead to the next release though We are we had a bunch of meetings during the summit. There's a number of companies which are Interested in continuing to see trove success succeed and who are willing to put up the resources to make Trove have significantly more contributions In the queen release there for the significant issues, which we're going to talk about are I'm going to start from the bottom one of the things which is At this point a little bit out of date is documentation and we need to do something about that The second thing is that there's a big Gap between the capabilities which are available in trove through the API and Capabilities which are available in trove through the CLI or through the horizon dashboard And in the area of the CLI we're still using the legacy CLI and that is something which we have to fix and move to the Openstack CLI so that's all collection of things which come in the in the area there of user experience There has been in the okada release a significant set of changes which deal with security There are some more which are planned for the queen release These specific areas where we're thinking of hardening the system includes the way in which we use configuration groups right now Every time you spin up a database instance. There's a security group which is created for that instance Which is not really the best way to do it Some employers have asked for the ability to specify a configuration group for multiple instances So they can make one change to the configuration group and have a whole bunch of Database instances be impacted by it. That's the capability which we are considering There are other Security things which we're looking at in the area of how the day the guest images then surf our belt are built And put together But that is still something which is up in the air In the area of interoperability. I was thinking of most of the things related to upgrades and the way in which we handle upgrades right now Excuse me. There was a fair amount of work which was done in the pipe in the okada release for upgrades And we have to pick that up and bring it forward again for the queen release for for the queen release So those are some of the significant things on the on the bottom line there Um modularity and manageability are two which I want to talk about kind of together trove has Been on a relatively fast clip from the time when we came out with the first release a nice house to You know, maybe the okada release we added support from what was originally one database my SQL to now having over a dozen databases And along the way we picked up. I think technical debt is an understatement It's technical monumental debt and you know, there's a whole bunch of code refactoring which is required at this point So the manageability is not just the manageability of the system manageability of the source as well And part of that is modularity. So those are some of the things which we're going to be looking at because one of the places where it's now really hard for us to extend the project is that Bola spaghetti is probably an understatement as well. So That's Unfortunately where we are and what we have to get out of right now So these are some of the things in addition to what we had what I just talked about which we're looking at as capabilities for Queen Trove does support the ability you handle replication clustering of multiple different databases, but we're trying to deal with clustering and configuration management improvements One area which is specifically lacking at this point and some of you who are there at the session this morning Recognize this multi version support, which we talked about Currently you can have only one deployed version of any database and so my skill you can have five six or you can have five five or five seven Not easily have multiple of these That's one of the things which we have to deal with because when you are operating a production cloud It's not going to be realistic for you to assume that all of your tenants are going to migrate all of their Version x databases to version x plus one in lockstep We started working on the open stack client integration. That is something which is We literally just dipped our toe in the water. We haven't gone really far with that. We need to do more of that I believe that's something which Maybe a requirement for the Queen release. I'm not sure I don't know if anybody's attended the Queen release community goals thing Another thing which has been long overdue is databases and containers. How many of you are interested in databases and containers a curiosity, okay? Any preference on container technologies? What would you like Alexi? Okay Docker required? Wrong answer try again, okay, so we were thinking of doing this in with Libwirt Alexi At least as a first step The reason why we chose that direction is because trove has one standard compute API the only API we talked to is Nova The Nova Docker project is no longer supported So that's reason why it's at this point not Docker However, if you're interested in Docker if there's some way you can think of making that easy happy to chat with you about that And As I mentioned earlier, there is a monumental amount of technical debt and we're trying to address that for those of you who are familiar with You know this data for CI we have to you know improve that one of the complications of courses that we every time you make a change We have to test the change across a dozen databases and potentially different configurations single instances clusters and so on The the mechanism which we have for that is Not really ideal so no matter what kind of change you make even if it's a One-line change in a dock file it goes and tests all 12 databases, which is ridiculously expensive That's one of the kinds of things which we have to fix One area which has long been a bugbear for people deploying trove is how do I get guest images? And we had some conversation about this this morning One of the ideas which we did have was to push up tools to make some guest image creation available to all And that is something which we're hoping to do in Queen as well And like I said at the beginning part of the usability our documentation needs a little bit of rework so Looking even further ahead. I'm not Sure. I can say anything other than it's everything that we want Do I have specific ideas of what these things are at this point? No, but we're planning on having something which Trevor wanted to call a trove reboot in a couple of weeks where we're gonna have a better idea of what the roadmap is looking forward at which point hopefully will have as a community a better idea of what each of these things are but My goal is to get more people involved in the project and more contributors of the project to the point Where we can actually do something in this area so With that this is I believe the last slide I have We are at a point where we're looking to actually Make this forward-looking roadmap of what the capabilities are that you want I'm gonna start at the bottom of this list and say to help answer many of our questions We need the actual feedback on what issues you're having from deploying trove in production or attempting to put it into Production or even take it to a POC and what are the capabilities which you find are missing? Moving up from that we need contributors to the project and contributors are not just people who contribute code By the way, we need people who do code reviews as well If everybody wants to contribute code, but nobody wants to review it. Nothing's gonna get merged unfortunate but true And the last thing is to figure out what things you want code written for we need some input on that So if there's actual feedback you can provide us that would be awesome. I Don't have a whole lot else if there's something you want to say now I don't want the session to be just me talking. I'd like to go away from the session With some input as well. There's a bunch of people in the room who are also going to be participating on trove So if you have feedback now is a great time to put push it up The mics are obviously not working because none of you are saying anything Yeah Yeah Okay, great question. How stable is it? Why isn't it in your favorite distribution? I've used it for a fair amount of time. I've used it since since ice house or give or take change I know of a couple of people who have deployed it The issue with true is not stability It's just the overall experience of getting it up and running. It is a definitely a non-trivial project Why it's not in your favorite distribution? I I can give you a couple of answers, but I can tell you I'm not a Distribution vendor so I can't speak a thoughtatively. I can tell you what it looks like from the other side Distribution vendors are typically tending to put things into their project into their distribution that they intend to support The cost of supporting a project like trove is significant Put yourself in a position of your distribution vendor and say you're supporting trove trove supports a dozen different databases Are you going to be testing all of these? If so, what versions are you going to be testing? Are you going to be testing upgrades of these so on and so forth? So until there's until there isn't more people using trove. I Don't see the distribution vendors wanting to put it in there But until the distribution vendors put it in there. I don't see you wanting to use it I have no way to break that. I hope that answers your question or at least Peaks you to the peaks your interest enough to ask another I would point out that trove is in a bunch of cloud archive I don't know if that's your favorite distribution, but trove is they do have W packages for conductor API the client Python client. It's all in a bunch of cloud archive Now you have to go to canonical and ask them about support, but it is in a bunch of cloud archive It isn't that different. Yeah, so so I would interpret the question of is it is it in a distro? Is it in his favorite distro as being is it something which the vendor is willing to support another vendor? has for a long time had it in their documentation that show was in preview and They would work with a quote trusted partner to do this. Well the trusted partner ain't there no more so What are people who want to use to trove supposed to do? What is the development model? So at this point if you were to submit code who's going to review it. There's probably a half dozen people in this room Who are going to be the people reviewing it? Who is going to who's going to commit it? It's the standard development model as any other opens that project so The mechanism is relatively straightforward You clone the trove repo You make your code change You push the code change up using git review because OpenStack uses Garrett and it gets reviewed Tested by the CI and merge to that point What kind of changes are you looking to push up? Okay Unfortunately the presentation this morning was not recorded the onboarding sessions so That would have been the cool YouTube video, but at this point, it's I think only audio Sure, absolutely. I think all the PowerPoints are are being shared by So you will at least get the slides If you want the cool YouTube video the only thing I can suggest at this point is we either do it face-to-face or personally or Webex or something like that and you know drop me a note on IRC or Email or something like that, and I'm happy to help you Okay, you'll I'll definitely make sure the presentation goes on that mailing thread, but since your question is A bootstrapping question. Are you on the mailing list is I guess the first question? So you get on the mailing list Since you want to commit code. Have you signed the individual contributor license agreement? Are you therefore you have a launchpad account already? Yeah, but 90% of the way there Okay, other questions I Don't know the definition of done. I know the definition of not done and we meet that one on a per data store basis Okay, so we've not had a good set of processes around that what we do have is that If you're gonna push up a new feature a Significant new feature you will have a spec If you're submitting a bug fix, you don't need to have a spike by extension when you commit your code If it's for a significant new feature and you tag it with the blueprint tag That is supposed to trigger the documentation process where the documentation will get updated the implementation of that is that our dock liaison will get notified of it Trevor and he will Do the magic to make it actually get documented the documentation at this point is Not bad. It's out of date and It's a perfectly fair point if you were to say what's the distinction between the two It was accurate at some point of time not too long ago. It's a question of catching it up at this point, please Generate samples why don't you turn around and I'm sorry. Okay. Does this work? Yeah, or okay I'm trying to like reconstruct the how you generate examples for documentation because right now it doesn't support clusters And it was written really really long time ago. So I really don't understand a whole lot of how it works I'm just trying to plan on like probably gutting it out and redoing it all over So if anyone has experience and just you know simple like API generation And not like create snippets or how normally they're listed. Can you reach out to me and can we work together? I'd be great. There's already a bug filed for it. It's because like there's no Cluster documentation whatsoever because it only supports like one instance ID speak to Monk see Monk see okay, so you're the guy we have to blame for that thing. Okay Hmm no, no Yeah No, this this the specific thing which he's talking about is the documentation of API's The way it's currently done is you run a test job which invokes a whole bunch of API methods and Something actually captures. What is what's the request? What's the response in a successful case and an error case? Nobody wrote that code for clusters That's about it The tests which actually exercise the API for clusters don't exist. Okay Anything else going once I Think we're gonna have to if so so let me repeat the question when is our first reboot meeting We need to find a time which is going to be convenient for Paris you in the UK At least as far as the Midwest. I don't know if anybody on the West Coast wants to show up or not It's gonna be a little bit early in the morning. Sorry about that We could do the alternate thing or whatever it's probably gonna take a week for us to get the meeting time nailed down because That's that's a commit which gets reviewed and merged. I suspect we can have the first meeting and probably a week So sometime next week or No later than the week after that The idea of waiting till the PTG to have this. Yeah, no on that. It's got to be way sooner than that Let's just have a quick show of hands here 10 a.m. Central work for you Work for you Paris 10 a.m. Central is what time Paris 5 p.m. Paris could be okay. All right 10 a.m. Central. I'll try and see if I can get a bridge. I Don't know if there's a bridge available All we have to do is find a IRC bridge which is available at that time. Okay, Wednesdays still the same thing Okay Sounds like we have at least starting point of the consensus Other questions mugsy your hand up. You had your hand up In what way the guest agent was right now pluggable, but oh Yeah, the config map is currently a mess in that that is one of that was one of the things on the we need to do this That is the Yeah, that is something which we're looking to do Are you signing up to do it? Sounds good. Thank you. It's on the record Other questions going once twice sold. Thank you folks