 Well, so this is the first summit that adjutants actually become an official project about the stack itself So this talk is kind of somewhere between an introduction and a project update as to adjutant itself Mostly I'm gonna give you a bit of history as to the project itself where it came from and how we built it and why we built it in that way and Also try and maybe segue a little bit into why fitting it into open stack actually is a reasonably good idea and What benefits that service actually provides to open stack itself? I'm also going to do a bit of a live demo and against our production environment of actual use cases that exists already for us and we've already deployed and Hopefully that will go well. So we'll see how that goes. So why does adjutant exist? Open stack is a Powerful collection of services that offer a lot of really good tools when it comes to flexibility in regards to infrastructure as a service but For a lot of public clouds and most clouds as well To manage your users and their details you need a lot more than what is offered in open stack itself You're normally storing information of their systems. You need Custom business logic requirements that just don't really fit anywhere with an open stack itself and You even need workflows for bringing you customers on board being able to set up everything you need for them and fixing all of the pieces in place that it need to exist once that user has been set up or Maybe you need just basic quality of life things like the ability for a user to reset their password or Maybe you know be able to just do basic raw management in a way that is more fine-grained and keystone necessarily offers it Yeah, and the thing is opens that itself Has a lot of the pieces needed for this the primitives are there in keystone and You just need to know how to use them the problem being a lot of them are add-in specific You can't expose them directed to users in a safe way. So adjutant acts reasonably good stopgap to Let you kind of minimize that so We needed the service that could do that it needed to fit in between and basically fit with an open stack But fulfill the goal of handling all this missing logic and act as a little bit of a layer on top that bridge the gaps We needed so so one of the biggest problems is that Customer data doesn't really belong in keystone When you're dealing with things like well addresses and phone numbers and so on you don't really have anywhere to put that and Keystone isn't the right place for that it has fantastic primitives for users and projects information and access control But if you're trying to build a customer entity out of that you need way more than this the customer exists in the in far more than that concept and Open sense and need an information it makes no sense for the information to be an open stack But at the same time a lot of things you're doing an open stack Require information about that you need you some of the ways that your customers want to react with open stack depend on how they exist in your external systems Adjutant in its first divine designs phase actually started as a more complicated service one that would act Partly as a hybrid CRM and the count management service It would store all this information and act as a layer on top handling user automation You know all of these various things it would handle sign-ups basic access control quotas projects and Thankfully wouldn't quite go that far It mostly because no organization really needs yet another place to store customer data Most companies already have an ERP or CRM where they are holding this information. So why not leverage that? Why not? build instead Something that can sit in the middle that can talk to Keystone and the other open stack services that can talk to your ERP and Can kind of merge that together and glue it in a way that makes sense and is reasonably useful and then Four things that do need to affect both Keystone and your ERP Adjutant that service in the middle it can affect both it acts as that bridge between the two you interact with it And it handles the appropriate things you need so We started by building adjutant mostly to handle one task and amusing enough that the task has actually been on the Working group missing feet of the public cloud working group missing features list for a very long time And that was sign up and user registration I've essentially an API that takes some sign up form data and posts it Gets it and then runs through some validation and ultimately creates a valid fully functioning user and customer account and That's not I mean that's ultimately what we needed so we needed something that would take post data from our web form or sign up form validated It would do some basic notes on that and then let us decide whether we wanted that customer and this was the first step This this is probably a little bit more complicated It needs to be but it talks about how there are multiple steps involved in such a process And essentially what you need is a bit of a workflow service So by the end of the process you end up with things created in Keystone and things created in your AP ERP system So once we actually built the sign up or at least most of the prototypes there We actually realized that what we've actually built is Effectively an underlying workflow framework one that lets us build workflows around these kind of business logic tasks And then expose them over specific account management APIs we In turn could actually use that To build a lot of features that kind of help in account management space For example allowing non-admins to invite others to their project Managing the roles of users on your project based on a role hierarchy so that what roles you you have depend on what roles You can also edit living users reset their passwords We have had so many people who needed to reset their password and without that functionality We have to manually do it and email them or text them a temporary password so they can reset it Which is awful user experience which by building a little bit extra logic on top. We've managed to build that into OpenStack Then we have also means of letting users request and manage their quotas And even are working on features that will let them manage their child projects So sub projects and in turn the users on those so that you have a lot more control over the actual access and identity You have over over your customers, but we also realized that well every company has very specific requirements and You don't really want to start putting that into this core code base There's there's no point you end up with a giant mess that no one really knows on anything about or understand it So we realized we had to add plugins because we would not add Custom company code to this not that we wouldn't want to open source it purely because it Pollutes what the service could be and how it's useful to others it makes more sense for us to build a Good framework and a good platform, which then others can build on top of and That's what we wanted We wanted to be something that out of the box has a bunch of features that are useful to a lot of clouds and On top of that also has the building blocks and the basic frameworks that you need to build extra Management things for your specific cloud and integrate with your ERP system or CRM or other features or other systems That are important to your specific cloud now We make fairly extensive use of adjutants plug adjutants plug-in mechanism for our own cloud mostly because we have a lot of custom data in an ERP system and we don't entirely and We don't necessarily keep that in Keystone, of course. So we have in our AP system a concept of actually Keeping a mapping between the Keystone project and the actual customer themselves So in our AP system, we actually have a table of projects which stores the information about the project ID as in Keystone And that that in turn links to a lot of information about the customer themselves Adjutant helps bridge that gap but Adjutant doesn't have any concept of this by default because Adjutant by by its own Situation or the way it's built it and just solely things an open stack But with the plug-in mechanism we have built Customizations to it that do understand how our ERP structure works where that mapping exists to now to make use of it And this in turn means that we can build workflow specific to our cloud that makes sense for it how we store Customer information they're building details their account information or even just their customer history So why is that just an useful and open stack? Well, the problem we're trying to solve is a tough one purely because there is no one-size-fits-all Solution to this. It's a wide varied overly complicated problem Every company is different and has different requirements That's why our goal with Adjutant wasn't to make a perfect solution. They just isn't one In fact, there's nothing been in this space because everyone's been trying to create the perfect solution when That isn't really a way forward so instead what we try to do was create the least awful solution which Sounds a bit counterintuitive, but well It's better than nothing and at least it means that we've got a place now to collaborate So and also because of how we built it and how our coming into work We focus on upstream we tend to focus an open source and we built this so that others could collaborate so that this Service as a good place to start where we can as a bunch of public cloud providers or even other cloud providers Build a service that lets us handle those slightly weird business requirements that don't really fit anywhere else in OpenStack Over time the amount of overlap between All the various clouds will get better Adjutant will grow and the bits that everyone shares will of course We get expanded on but the problem is that can't start until there is somewhere to collaborate until we actually have a service that does this and That is why adjutant was ultimately added to the OpenStack project Why it exists as an official project because we need this and it actually fulfills some of the basic features that are there So What exactly is that? well You know now its history why it exists and that it's an official project And I've probably sufficiently ramble then confuse most of us to what it probably is so let me give you a brief overview and Try to give you a better summary of what the service actually is for users It is an API service with a horizon based GUI that has roll based access control for controlling what API as you can talk to and It limp it gives users access to account management actions underneath that is a framework for building workflows in code API and then you can build APIs around them and expose them to your users without any custom Yeah, and We also have in adjutant itself a lot of APIs that just by themselves are quite useful What out any customizations most clouds will probably end up running them And then we also have many which service templates that you can build on top of Which of the API is your expose is entirely configurable because maybe your cloud already has a password reset mechanism You don't need adjutants So you don't turn that feature on or maybe you Have an LDAP based cloud or federated cloud. So you don't want adjutant handling roles for you. Well, you turn that feature off It's a service that Effectively lets you plug in what you need And the plug-ins let you build additional workflows yourself You can build on top of the primitives we have already there You can build new actions new workflows new APIs and then you install those plug-ins and say I want to enable this API Adjutant also has a horizon based UI component for all of the core features that exist in the API's all of the core API's that Adjutant has we have built API horizon views for so that you can play with what's already there But any customizations would do or any Custom API as you make you'll have to build your own horizon views for and of course There's more to it than that. This is a very quick overview But essentially it is a framework for building and exposing account management specific APIs in a way that doesn't require you to build a Microservice for each with enough reusable elements to make it worthwhile to share the workload Make sure the burden isn't carried just by one company every time And as for features Well, of all the APIs that are present by default. I'm going to show you live demo And Everyone tells me not to do live demos I don't know why maybe they go wrong quite often But I'm risking at this time because I'm actually going to be using our production environment features that already exist are tested and If anything actually goes wrong, I probably shouldn't be here I should be running off looking at logs or potentially drinking a lot of hard liquor, but let's hope it doesn't come to that So first things first Let's start with a sign up and conveniently. I've actually got pre-filled form data here So and I'm going to sign up as an organization and I have Some of the worst addresses then possible and we're in New Zealand now This web form this sign up process here on our website will actually post to the adjutant API And then that will turn will trigger bunch of validation steps Which we can then look at one of our account managers will be notified the sign-up has come in and in turn They will look at it review the information about it and figure out whether this is a customer that we do actually want And the validation notes will tell us is this someone we already have in our system Might they be a duplicate of someone we already have and various information around that and the ability to expand that to Something that tells you whether this might be suspicious customer all that information is possible You can add additional actions that workflow now of all of the API as an adjutant that we built this is the one we've customized the most because there is a default sign-up API an adjutant it's very basic it exposes a panel in horizon that lets you just sign up and ask for a project and That works solely an open stack So this variant builds on top of that API and Instead builds one that's specific to what we need from the customer what we need to put in our ERP system So the sign-up is now done and if I look in my email I have notification here in our system that this sign-up has come through and this here is the email that I as the person signing up get telling me that it's in our system and we're looking at it and Then as an admin If I refresh this there will be a new sign-up here and I can look at the information about it What the actual data as part of the sign-up is and Some basic validation notes There's not too many here because there's nothing too wrong with this sign-up here And it's telling me a few things and telling me what project name it'll create making sure the user isn't there a few basic Because let's say I potentially renamed or misnamed my company We'll go and then we'll actually change that and this is a case where if potentially you're talked to the customer and they've What have I done so there because Occasionally customers do screw up in their web forms alright and now what that's actually done is trigger additional revalidation of that data and if you can see here It's proposed a new project name for me based on the company name that I've now updated so I'm going to go ahead and approve this and This is actually going to create me as a customer on our cloud It's going to create a Keystone project or user a basic default network in a router so that can launch instances right away And it's going to email me a token to be able to set up a password now in this whole process I've not asked for a password because we don't have anywhere to store it temporarily especially since this is a a system that requires us to actually take an approval step so Now if I go to my email I Conveniently have here and I see email telling me about our documentation and a few bits and pieces around Actually, what our cloud is including a link here see all A link here to set up my password So let's set this up and now this sign up is completed everything exists So this user is now a real account on our cloud and now if I take that email I put in here, which I do not want to have to type out I can sign in and I exist This is I can launch instances But the objects to Swift do various things But before I do any of before I play with this, I'm actually going to sign out and I'm going to pretend I forgot my password because this is a surprisingly common use case. So Let's throw my email in there and If my user actually exists, I'll get an email with a token to reset my password which I Have now, of course, I probably want to also collaborate with someone because it doesn't entirely make sense for me to Maybe do this by myself. Maybe I want to invite someone to my project who can actually help me Build with ever infrastructure. I want to build on this cloud. So I'll do that Well, I need is an email. So I'll invite Summit demo to if my keyboard plays nice with me and for now, we'll just give them project member So we've got here saying that we've got this user invited their status is invited They don't exist yet This user when I actually get created until they submit their final password. So if I check my email again I have this in the big invitation it tells me who invited me what project I'm being invited to and provide me with a link telling me that I Can set up my account and if this if this was a user that were busy or they existed on our cloud What they would instead get rather than setting up a password this link would just ask them to confirm that they wanted access to this project but essentially it's A nice simple way to invite and manage users. So now we have this other user But and if I refresh this we should now see Logged me out of both So now we can see that both of these users exist I can see what roles they even have on this project, but maybe my friend actually Needs a little bit more privileges. So what we'll do is we'll actually bump them up to in this case project moderator And what the project moderator role actually does is it gives them the ability to manage roles just like I can But it gives them access to only a subset of the roles I have for example, they can't edit my roles because I have a role above them, which is project admin So it means that while they can actually do a bunch of stuff here They can't entirely remove me from my own project and that a little bit of extra fine-grained control over how you can manage those roles Makes a lot of difference we found and it means that you can start building things that are useful for the customers and one of the other things that we've started playing with is in Adjutant being able to actually map control which roles a user can manage on information outside of just the roles you have so for example in your earpiece system your customers set up to effectively be set up as in maybe a reseller for example and That means that you potentially want them to be able to add additional reseller based roles to their users so Adjutant will be able to check in your earpiece system what information this is and Change that list of manageable roles based on external data And we intend to do that by changing some of the mechanisms in adjutant to be quite pluggable so that in certain ways You can basically Overwrite some of the functionality that is there to make it useful for these kind of specific cases Because being able to control exactly what roles a user can manage in certain ways becomes infinitely useful And it does so in a way that doesn't require complicated logic in Keystone where this kind of business logic for role management doesn't really make sense so I've given you a bit of overview of that and I've also mentioned quota management and in this case This is something that's built into adjutant and in fact actually all of these views other than the sign-up I've been showing you are part of graduate itself. There's a very little customization here actually no customization So it it kind of is just basic stuff We built into service that is should ideally be useful to any cloud so the concept of quotas here is In an hour cloud we found that when someone asks for a quarter increase. They usually want to bump VC views as well as instances as well as RAM so it makes sense to treat these as grouped sizes and I can in this case ask for a quota update in one of our regions and Depending on certain criteria. This might actually be automatically approved I might just instantly get a larger quota because I've reached it and I've been a long-standing customer So in this case, I'll bump up to a medium or asked to be And what that will do is add that to adjutant which will in turn Double-check whether this can be automatically approved and if not it'll notify an account manager who will then look at this Review the request that's come in and either approve it or cancel it. Maybe even talk to the customer and ask What are you going to be building on our cloud that meet that you need this much quota? Which sometimes depending on your capacity can be quite useful, but it also means that ideally all of circumstances You are actually letting your users manage this themselves Ah There we go. So here we go. It successfully created the task But it requires admin approval and down here we have the information about it In fact, if this was approved this would keep the history down here as well So you you knew about your previous quota changes and could see what other people have requested previously and like some of the criteria we're actually going to be doing for this is if a customer has Any unpaid invoices they don't get a quota update approved if they are jumping beyond an adjacent size they don't get automatically approved and They only and the other criteria that we've set is you have to have at least one paid Invoice before we let this work, but once that's the case We don't actually ever have to interact with a customer about their quota This just handles that based on reasonably sensible logic as to what can be automatically approved so The last step actually is a feature that isn't yet in adjunct itself it's actually done entirely through plugins and Some of this will actually exist in adjunct itself once the features are done in keystone but until then it mostly exists as plugins that you can build on top of adjunct itself and effectively adjunct exposes a workflow to let you set up a Multi-factor authentication account a set up on your account Effectively it will require you to scan this and you can probably scan it yourselves and this user will be deleted afterwards so it doesn't matter too much and once I do that I can generate a passcode and pass it to adjunct adjunct now Confirms that the passcode I've supplied it actually is valid and matches the secret it's about to create for me in keystone and then it will turn on multi-factor authentication for myself and it That workflow is necessary because it means that I actually have the ability to generate a valid passcode before my user has that feature turned on and There is work going on in keystone itself to enable full user multi-factor authentication But the problem with it is that it'll still need a workflow like this to make it useful and safe for customers Which is why eventually that workflow as built specifically for the features of our being built in keystone Will exist in cork in core adjunct unlike the one that I'm showing here, and I will actually go through it if I Scan this barcode. I now have a passcode. I Can supply that? Adjunct will verify that the passcode matches the one that it generates It will then activate that in keystone. Did I actually click submit? I don't think I did and Now the passcode has changed. Oh the problems of multi-factor authentication And it will log me out and require me to log in again So now I can actually log in with that user and try And log in with the standard password. It doesn't work But if I supply the passcode It does so Those are the features that adjunct currently has in it and we intend of course to add more so if I go back to Presentation So going forward we do have quite a lot more features planned ranging from proper control for sub projects in ways that don't quite fit in Keystone and adding a bit more kind of fine-grained controls for a bunch of things We also have some plans for managing Additional service users so kind of like application credentials and kind of like the invite workflow that we've got but inviting Service users that specifically don't need to be an email but instead are Built in the format of use of user-specified name at project ID Which will allow something similar to this invite process But allowing me to create fully fledged users that actually connect to service accounts then There's a few more things coming up and we'll we'll be playing with that and updating some of our doc Substream to kind of reflect what's happening But the main focus of Stein right now is internal refactors and it doesn't sound very glamorous But by the end of time we want to clean up some code that doesn't quite make sense and hopefully Encourage other people to well it will hopefully encourage other people to help contribute once that stuff makes a little bit more sense We also want to split the service into an API and workers so that we can start doing some smarter things around Longer running tasks and also potentially more interesting autonomous auditing of tasks and automatic task status checking We also want to make more elements of the service pluggable so that notifications and identity management can be tweaked better per deployment For example giving Agents in the ability to work with Keystone and LDAP directly for managing users So then the case that you have a keystone that's backed by an LDAP and you want to still be able to manage those users Adjutant can instead talk to her at it to add L LDAP or Or active directory and do the editing of users there Or if you do have a pure keystone deployment, then that already mostly works There's there's a few issues around Federation that we do need to work on but part of that is mostly because no one on Our team has really played with it so contribution there would always be more than helpful and I also talked about a lot of the customizations that we have in our ERP system and The way we use it to link back to our open stack deployment and through Agents and of course our building system but a lot of those things are built for custom plugins and a lot of that is actually custom code in our ERP system and one of the pieces of work outside of related to Agents that we'd like to undertake is to actually open-source those specific customizations and We currently use an ERP system called Odoo, which we're going to be migrating away from and once we've settled on a new open-source replacement for that we actually will Fully build our suite of customizations for the for our ERP system of choice and open source them so that Ideally down the line any new public cloud or even non-public cloud who is coming into the space We're able to take what we've built our customizations our ERP system solution Well, the well the same one that we pick it'll be an open-source one and Adjutant and open stack and fit this together and hopefully be in a much better place when they start than we did when we started as a company and That might help but ultimately Where adjutant goes from here depends a lot on the community on the other public cloud Deployers on other clouds who may want to be a renter than using it and Ultimately on growing what exists as adjutant grow getting more developers interested in people who want to help or little features that make sense An adjutant that don't fit anywhere else, but are useful and specific to business logic and account management And we also need more people to play with it so that we get some better feedback So we have some idea about what actually we can do to improve it And the thing is we as catalyst cloud will continue to push this like we we won't be dropping this project We use it in production. We'll be maintaining this for the rest of our lives probably but That doesn't stop us from wanting to make it something that other companies can use we we don't benefit from making something That's entirely specific just for us. It's it's better if we can find some of the works for everyone and Then ultimately it'll be better for us, too So that concludes my talk, and I hope there was some interesting stuff there I'm curious if there's any questions or anything I can help Elaborate on or make a bit clear Yep, sorry, what? You mean out of the python or no, sir, sir, what other oh Different languages. Yeah. No, we could well the horizon elements could easily enough be translated. So that's that's not too bad No, no, no we haven't yet There are a bunch of things that we are working on that will link a bit better to opens that itself But we haven't yet done any translations for the service itself But most of the stuff is built ultimately on on horizon least for gooey elements So those will be reasonably straightforward to translate and a lot of the actual messages in Agenda itself We will start splitting that off so they can be translated as well So actually that I should have added that to our list of features, but yes, there is actually a Review that's been up on Garrett for quite a while about building a workflow that goes through and deletes a project Everywhere an open stack and external systems and there is a session on tomorrow Where which we'll be talking about the deletion of projects as well And one of the proposals I'm going to be making is that rather than trying to integrate this into keystone or every service Adjutant itself serves as the much better place of going delete this project cool I will talk to everyone and handle it because at that point you have a central point that can talk to everything that can Validate the appropriate steps and make sure things were deleted. So yes The answer ultimately is yes because we need this ourselves We have a lot of Python scripts we've written to do this for us And we want to translate that to an API that we can trigger for account and customer terminations And that even customers themselves can go I don't want to bill next month delete all my resources But keep my account active. So yes ultimately That one's a bit complicated because ideally the answer is kind of a little bit. No, because let's say for example Glantz actually already has a mechanism for moving images from one project to another or sharing them and That kind of stuff makes more sense in the projects themselves rather than adjutant and we're quite clear We actually I wrote a long documentation on project guidelines that if things make better sense in the services themselves That's where they should be implemented not adjutant This shouldn't be used as a stopgap measure for smaller things that don't quite make sense anywhere else unless it is specific to more account manager stuff Maybe in some circumstances we could treat it as a more global I want to move all my resources to somewhere else, but it would something we'd have to look at and figure out Yes, you have a question. Oh He's just Holding an apple anyone else No Yeah, so it does We are working on actually making adjutant multi-region in a more useful sense the sign-up process does actually know about regions to an extent and in fact the Quota management does work across multiple regions if you talk to the API directly and ask for a bump up to a different size it'll do it across all regions or just the one you specify and The sign-up process you can specify what the default region is so that when it creates that initial network and router Adjutant does so in the region you specify So there are other things outside of that which we'll be doing to make adjutant a little bit more aware of what region that's running in and a few more things so that it is a little bit better to Properly make highly available across multiple regions But that is sadly technical debt that we're not yet getting to but as we're doing actions across multiple Regions, that is very much a thing which we need to support that's if the things we're building done We're across multiple regions and the use case requires it then it kind of defeats the purpose anything else oh Yes Sorry Glance actually has a means of letting you share an image or change image ownership with another project and Effectively it lets you share that and then you on the other end say yes to that so It's it's an odd one because There are services that do that and it makes sense in circumcertum stances I don't know how to do that nicely because also a lot of the services to do that kind of change We need to either have API's themselves or you'd be looking at SQL based changes to the change ownership of a project without the Service itself supporting that sorry the change the ownership of a resource battle service itself supporting that it can only really be done right now via SQL and That is not something that I would ever want in adjutant itself In fact, I don't think that would ever fit as a service. We should not be calling raw SQL on other open-stack services In adjutant that is just a terrible idea Well, if there are no more questions, thank you very much for coming to my talk and