All right, I'm gonna get started on time here so that we can keep to our schedule. So welcome, thanks for coming in after the long party last night. I know this is always like the first tough morning of DrupalCon. So you're here, hopefully, for learning about features in Drupal 8. And I'm Mike Potter, and I'm the primary maintainer of the features module and the features override module. The architect of the OpenHRM2 distribution. I'm a software architect at phase two, and if you wanna get ahold of me, there's my email and my Drupal handle as well, and I'll try to get back to you. So we're here to talk about features. Is there anybody here who wants to admit that they don't know what features is or has never used features before? Oh, excellent, because I did mark this as a beginner talk. We're gonna talk about some more intermediate subjects as well, so if you're not a beginner, don't be worried, we're gonna have something for everybody. But I mark this as a beginner talk because I really want everybody who does Drupal to know about features, and that's been true in D7, and it's really gonna be true in D8 as well. But when you hear about features in D8, you sometimes hear things like this. So here's a quote, it says, who has wasted more than 100 hours with the features module? Gone, problem solved. That was a quote from a Drupal core developer about features and configuration management. So anybody have any questions? We're gonna have a very short session today because obviously we don't need features in Drupal 8. So why are we still talking about features? And we're gonna talk about configuration management and all of its wonderful things. But what is, let's go back a step, especially for the people who haven't used features before and briefly talk about what features is and what it does. So when you put together a Drupal site, you have this giant Drupal database. In that database, you put a bunch of different things. You've got your different pages and your different article content, your comments, your users, your blogs, all of the stuff that you would consider the content of your website. That's all stored in the database. But you also have other stuff stored in the database. You have your content types. You have the fields on those content types, not the content of the fields, but the definitions of the fields, whether they're strings or integers or entity references. You also have views. Whenever you make a view in the UI, that gets stored in the database. You have all sorts of site information, your site name, your slogan, all of that stuff gets stored in the database. And we call that configuration or config. So what makes this difficult is, if you're building a site and you have your development environment and you now want to copy your development environment and put it on a production server, you copy this database. Then people start using your production server and they start adding content and they add blogs and they add articles and things. Then you decide that you need to update the configuration of that site. But you can't just take your development environment and put that on production again because you would overwrite all their content.  And because they're both stored in the same database, it makes it very difficult. So you need a way to separate config from content. So what Features does, Features takes your configuration and it writes it out to code. And so it converts that configuration data from the database into an actual Drupal module, which is in code. And so now you can take your production database, update the content, move the new code over, the new code is going to overwrite the config piece without overwriting the content. So that's the problem that Features was solving in D7. And why this was a good thing is, well, if you put stuff in code, now you can version control it. So if I'm making a view and I go make a change to that view and I put that in code and use get to update it, and I say, oops, I made a mistake, I need to go back. I can revert to a previous version of that view. If you did that just in the user interface and went, oops, there's no good way in the user interface to restore your previous configuration. So version control is a great thing. And it lets you solve this problem I just talked about of how do you deploy sites from development to stage to prod? And we're not just talking big enterprise sites here, but even smaller sites. You typically don't wanna be making changes directly on the production server. You've always got some local development version on your local machine and you need to deploy that. It was also used to create reusable modules and bundling configuration together. And we're gonna come back to that. That was actually the original purpose of Features. So Features is not configuration management. Features is not CMI. This is the confusing part. Features was originally built to bundle functionality into reusable modules. The example that people often talk about is your typical photo gallery. Let's say I'm building a website and they need a photo gallery on that website. How do you build that in Drupal?  You put a field in that content type to store the image so you add an image field. And fields have two parts. Fields have kind of the base part. And then they have an instance and this allows you to have shared fields across multiple content types in Drupal. So you also have to capture that instance. And now that you've got your image content type, you create a view of those images and you make them into a nice pretty grid. You add an image style to resize the image to exactly what you want. And there's a few other little config variables that you stick in there too as well. You wanna take all of that stuff. And so you might spend a few hours in Drupal building all of this stuff. And you do that on your development environment and now how do you move that to your production environment? You bundle it all together and you use features to store that into a module. And so now you have your gallery module. And I can then take that module and I can put it on other websites and have a photo gallery without having to do all that work all over again. So it's great for saving time and development. You can build it once and reuse it forever and still charge the client the same amount of money and make great profits. That is what features was originally written for. It was originally written by a company called Development Seed for the OpenHRM1 distribution on Drupal 6 to bundle the functionality that they needed in that distribution. But because it can write it to code and it can deploy, people started kind of abusing it. So why features was bad? Features was bad because Drupal 7 did not have a consistent way to convert configuration into code. The configuration lives in the database. How do you convert that to code? What file formats do you use? Every module did it its own way. And so people like to blame features for some problems, but really features is just a wrapper around what the other modules are doing. So when you export a view, it's actually views module and C tools that's doing that export. Some things we built into features such as exporting fields and content types because Drupal itself didn't even have a way to export those. So it was very, very inconsistent. And by writing it to code, I mean you're taking data and converting it to code and that just inherently has problems. There's the classic problem in features of numbers that are either represented as a number or as a string with quotes around them. That's a different data type, that's strings versus numbers. But when you write it to code, PHP doesn't particularly care because PHP is not a typed language. So code is just not very good for data. And then there is this problem of, well what if I go and I change my photo gallery on my production site like I go change the title of my view, now it no longer matches what's in that module. So it's called an override or a change. What do you do about that? Who wins? Is it the module that's correct or is it what's on the live database that's correct? Who wins? So overrides are kind of the bane of most people with features and they have features that are permanently overridden that they can't get rid of. But with all that said and people like to hate features including myself sometimes, that's all we had. That's all we had in Drupal 7. And it's a hard problem to solve. There's a lot of complexity involved in dependencies and everything else. But in Drupal 8 we now have CMI and CMI stands for the configuration management initiative. And I wanna say just at the beginning huge thanks to the CMI team and some of them are here today. Greg Dunlap, Hey Rocker was the original lead on this initiative. He's now past it over to Alex at chapter three. But Jen and Dries and WebChick who committed a lot of patches catch and really it's many, many others. You know if you look at the commit history you'll see a bunch of commits from WebChick and Dries but those are on the behalf of a whole bunch of other people who put those issues in the issue queue and wrote patches and tested patches. So it was a very large initiative. I'll still make the claim but I think it was the most successful initiative in Drupal 8. It was started early. It had a very focused purpose and they've delivered on that purpose. So why is it so awesome? So the first reason CMI is so awesome and maybe some of you, how many of you went to Matt Cheney's talk earlier in the week on CMI? So some of you have heard a little bit of this. What CMI lets you do is it first creates a consistent data format for your configuration. And then this is the so-called YAML format or YML. This is a consistent output format for data. It's not just, it's not a Drupalism. It's not a Drupal thing. It's widely used throughout the computer industry, the web industry. And it's just a file format for describing data. And that's what CMI uses for every piece of configuration in Drupal 8. And it provides built-in mechanisms for importing and exporting. So out of the box in Drupal 8, if you go to the CMI screen, you can export your view. You can copy that file over to another site. You can import it. You can export your entire site configuration to a single file, move that file over and import that entire configuration into your production site. So it has built-in, import, and export. And it's doing it through a core service. There's no longer all of these default hooks that features created to try to tap in and do all of this stuff. And finally, it just works. It's really painless and easy. I have run into really no problems at all with it. It does what it's supposed to do and does it very well. So with that said, let's compare features with CMI and D8. So they both export the configuration into code. In the case of D8, we have YAML files. In the case of features, we have PHP code, which allows version control. So we can have version control on both features and CMI, which allows us to do deployment. So we can now import and export configuration, move it to production, and everybody's happy. And we can bundle functionality into reusable pieces, except not with CMI yet. So that's what we're missing right here, is the how do you bundle, how do you make an image gallery in Drupal 8 with CMI? So what CMI would have you do is you would go into the export, and let's say you've got that photo gallery, you would go to your view and you would export that view. You would copy and paste that YAML data and stick it in a module. And then you would go take the content type, and you would copy and paste that YAML file, and you would stick it in your module. And then you would go find the field YAML file, and you would put that in your module, and then you would go find your view and your image style. And is there anything else you need? And how do you know you know what else you need? What else needs to be there for that image gallery to work? Are you kind of an expert enough developer to know that maybe you're missing some variables, or have you gotten both the field instance and the field storage? So it's complicated. Modules in D8 are designed to provide the initial value of config. So when you enable a module in Drupal 8, any YAML files that are part of that module will get loaded into the Drupal site as configuration. And so we call it default config. But what if you want to update that configuration? Right now in D8, the proper way to do that is you write an install hook. And that's perfectly reasonable to do. Like, let's say I've got that photo gallery view and I mistakenly show unpublished content. Oh, that's kind of a security issue. You don't wanna show unpublished content. So you need to add a filter to your view to say only show published images. And so now I wanna deploy a new module that has that new filter in it. What I have to do in that module is write an update hook to say, okay, go into the view, let's load it, let's change it and add this filter, save it back. So you have to write code. There's no way for a site builder to do this. You have to be a developer who knows how to write an update hook. And of course, as with D7, in doing that, what if that site has actually changed that view? What if they've changed the title of that view and in the process of writing your update hook, you overwrite that change and now they're back to the original title and so you've broken their site. And so CRI specifically doesn't do these things because they don't want to break your site. This is something that you have to be very, very careful with. Sometimes uninstalling a module doesn't remove all the configuration. This is kind of up to the module to do its dependencies right, but if you have a module that has a view and you install that module, now you have the view on your site. If you disable the module and the dependencies weren't set right, that view can still exist and now when you try to re-enable the module, it won't let you. So it's good that you don't remove stuff. People in features in D7, they were very perplexed that if you had a feature that, for example, installed a new content type, when you turned off that feature, they were confused because that content type didn't go away. And the reason it didn't go away is because you might have data assigned to that content type and you don't want to lose that data. Now in D8, it's going to try to save you from that by maybe not allowing you to uninstall the module because that might cause the field to get deleted. So you can run into kind of these catch-22s. If you accidentally disable a module, you might not be able to re-enable it. You might not even be able to uninstall the module in the first place. And I apologize for saying disable a module because in D8, of course, you can't disable a module. You can only actually uninstall it. And uninstalling it will have consequences in a lot of cases in terms of removing that configuration. There's some issues out there that talk about this whole, can you enable a module that already has config and so forth? I invite people to go take a look at those issues. So we still need features to bundle functionality. So the key features are features. So features is going to let you import, export and detect changes in your feature module very much like CMI. What we've added that's kind of new is a system called assignment plugins to determine how to package a feature. So in features D7, you go into the features page, you have a blank slate. It does not create features for you.  And a lot of people get confused by that. They wonder, you know, how should I build my features? Should I have all my views in one feature? And please don't do that. But what goes into a feature? So in Drupal 8, we have this new system that will actually auto-create features for you based on some rules of configuration that we call assignment plugins. It's a very pluggable system. It uses the Drupal 8 plugin system. Another new feature that we have in D8 is something called bundles and namespaces. So now you can namespace your features in keep and so if you're working on a site, for example, with open atrium, and you have open atrium features, and then of course you have the penoply features, and then you might have your own site-specific features, here you can actually keep those all separate and keep them all namespace so they don't collide, and it makes it a much easier interface. We do have Drush 7 support, and we've brought over all of the Drush commands from D7 into D8. Some are there, kind of deprecated, for people that their fingers are used to typing things and you'll see that in the demo, but we've also renamed a couple of them as well moving forward. It has a modular UI. The feature UI is now a sub-module that you can turn off if you want, if you don't need the UI. And finally, features is more of a development module. When you create a feature in D8, like that image gallery feature, when you move that module to your production site, the production site does not need to have the features module. These are real modules now, not features, not special features. So I have to say, first, this feature in D8 was a collaboration between myself and Nejo Rogers, who couldn't be here, but if you know Nejo, he's a great guy, he's been in Drupal for a long time, writes a lot of modules. When I started working on features a few months ago, I came across this module called Config Packager that Nejo had written, and it basically packaged configuration. I said, gee, this kind of sounds like what features is supposed to do. And so I got together with Nejo, he was very happy to have help, and really what we ended up with is something that was better than what either of us could have done by ourselves. He had great ideas for what features could do. I had ideas from the previous experience with features that I brought in. We put it all together, so what you have now in D8 is actually a better version of features than you have in D7. And this is really exactly how Drupal and contrib are supposed to work along with the fact that you have the core CMI that adds to all of this. So it's a really great open source effort that has produced this. So let's actually take a look at features in D8. If you weren't aware, the features D8 alpha version was actually released last month, so it is not just in dev, it is out there and available for you to start using on your D8 sites. So when you first put together a D8 site, where you find features as you go to the configuration area and then down under development, and then you go into the configuration management. So features is kind of part of the CMI interface in Drupal 8. And that will refresh the screen to get rid of the mobile glitch there. And now you'll see features is a new tab. So here's the normal CMI. You've got the CMI single important export. This is where you can import and export like a single view. And then you've got your full import export. This is where you can export your entire site configuration and import it. And then the features tab is there as the second tab. When you go to that on a blank site, you'll already see four possible things that you can export. The first two are based on the content types that come with Drupal. So you have an article content type and a page content type. And then there's some kind of generic core stuff and then some unpackaged. If you expand the little description area, you'll see the exact components that could potentially be exported to that feature. But you'll notice that the status over there on the right says that it's not exported. So unlike in seven, D8 has this concept of a feature which has not yet been written to disk or is not yet in code. They are basically taking your whole site configuration and kind of breaking it up into pieces and suggesting that maybe you export these different pieces. As you'll see later using the plugin system, you can change how these things are presented. So this is a content type based export. So article and page are your content types. If you want, you can go in and configure it and say, hey, show me my configuration by view. And in that case, it would show you every one of your views as potential features and all of the dependencies with each view would be included with those features. And these are called the assignment plugins that you'll see a little bit in more detail a little bit later. And just keep in mind because those are plugins, if you want, you can write your own assignment plugins and completely change how features packages these bundles of a configuration. So let's see it actually in operation. Let's go and create that gallery, okay? So here is our D7 site and we're going to go build a photo gallery. So we make a content type. We go at the image fields with content type. Now we go add a image style for that content type for our gallery. Now we'll go add a view. We're going to make a grid view that displays our content type, our email style, our views done. Now we need some content. So let's go add some images. And you know me, gotta have some cat images. It wouldn't be for the presentation without cats. So I've got my cats. We're going to add them all to our new image content type that we're building. It's our photo gallery. All right, so now that we've built that, we don't want to have to do that again. We want to create that. We want to put that into a feature. Okay, so how do we take this and put it into a feature? So we're going to go back to the features page. So as I said, we're going to go to development and configuration management. And we'll go to the feature tab. And what you'll see is there is now a new suggested feature called My Image. That was automatically detected for us. If I click on it, it will show us over on the right the same interface you're used to in Drupal 7. With the blue stuff is the auto detected configuration that it's suggesting that we export. So we've got our views and our fields and our content type. Now in this particular version, there are a few little bugs and dependencies. It did not find the field storage. So we go and we add the field storage for the image node. And it didn't find our image style. So we go and then we add the image style. And the interface works as you see, just like in Drupal 7, as you check the boxes, they go down below. We'll give it a name and a description. And down at the bottom, you'll see the two different ways we can export this. We can write it directly to disk or we can download it as a tarball archive. Those are actually generator plugins. So if you want to write your own generator that does things differently, you can write a new plugin and it will show up down there as a new button. So now that we've written it to disk, you can see that it's uninstalled, but they're listed as a new feature and you can see it's kind of separated from the ones that are not actually exported. Now to enable the module, you no longer do that from the features screen. This is a real module.  So that is going to turn on the module. Now you'll notice that this has allowed us to turn on a module that contains the same configuration that we just got through building on the site. So we already had a gallery view. We already had a image field. We already had that on the site and now you can see that the feature is enabled. The features is doing some tricks with CMI to allow you to enable a module that actually has the same configuration that already exists on your site. Normally Drupal is not gonna allow you to do that. So now that we have this feature module, we can now move it to another site. Now this may be small for people in the back and I do apologize for that. I'll try to kind of describe what's going on here. But in the version, this is all by the way based on the beta nine version of Drupal 8. I haven't actually updated it for beta 10 yet. I think it works okay, but I haven't actually checked. In beta nine, there was not yet away from the modules page or the extends page to install a new module from a tarball file. So in the actual release of Drupal 8, you'll be able to take your tarball archive and just upload it directly on the modules page and enable it. But here that wasn't working yet. So I actually had to go to the command line and copy it over here. So here we are on the Drupal route. We're gonna go down into the modules directory of Drupal, which is empty. We're gonna copy our tarball archive for my image over to this directory and we're going to expand that archive out so we get all the module files for my image. And now we can go to the modules page or the extend page and now we can turn this on. Now, this is a new Drupal 8 site. If I look for the features module, it does not exist on this site. This is a plain Drupal 8. There's no features on this site, but I can now go enable my image module and click save and Drupal is going to go enable all of this for us. And if we now go up to our site, we can now start creating content. So we now have a new content type when we go to add content called my image. And once again, we can add more cat pictures and we're only gonna do two of them this time and we're not gonna use any fancy music. We'll just stick two images in here. So now we've got two images and now we can go to our gallery tab and there is our gallery on this brand new site. So it works just like it should. All right, so what about changes? So we don't use the word override anymore in Drupal 8 because people hate that word. We now call them changes. So let's take this, so now we're back on our original D8 site that has the three pictures on it. Let's say that the client isn't happy with the name of this gallery. So we're gonna use the inline editing in Drupal 8. We're gonna go up here and click this button and say edit the view and we're gonna change the title and then we're gonna call it my cat gallery. So now we have a new version of this view on the site and it's different than what we exported to code. So when we go to our features page, we're just gonna go back and refresh the page here. You'll see over on the right hand side it's now says that it's changed. There's that little orange marker that says changed. If you expand the details, you can actually see that it detects. It's the view that has changed. And if you click on the changes, it will show you the changes. And it shows you that in the active site configuration, it's called my cat gallery. But in code, it's just called my gallery. And so they're different. In this case, I'm going to select this and I'm gonna say import the changes. Import means I'm importing the code back into the database. So now this is equivalent to doing a revert in D7. I just reverted this feature and we're now back to the original my gallery. So we imported the code into the database. So in D8, we talk about importing and exporting. So let's go change it back again. It's like, no really, I want this to be called my cat gallery. Darn it, don't override my feature. So in this case, what we wanna do is go back to the features page and instead of importing, we want to export. So we can just click it, say write, that exports the database to the code. Now we just updated the feature and it's now my cat gallery. If I go look at the code for this, for people that are geeks and wanna look at the code, in the feature module, we have a config directory. And if we go to the view YAML file and scroll down and find the title, you can see that the title in the code is now, in fact, my cat gallery. Now, is it gonna keep going? Okay, good, it stops there. So what I also wanted to highlight here is this kind of shows you what a feature module looks like now in D8. So a feature module consists of a config directory with an install directory underneath that and a whole bunch of YAML files. Those are the YAML files that are imported into the database when you enable the module. There is no .module file. You'll see that there is a .info.yaml at the top level for the module. In D8, you don't need module files anymore. All you need is the overall top level YAML file that describes the module, which is kind of like the info file that we had in D7, except of course it's in YAML format because that's the format that D8 is going to use for everything. And we'll see more about that YAML file in the future. But like with D7, you're free to add other stuff to this module. You can create your .module file, you can start adding your own services and everything else if you want to flesh this out and have more than just config in your module. So let's look at something new. Let's look at bundles. So bundles in features are just a way to group your configuration or group your features.  It currently says none. If I go to configure bundles, I have a way to create a new bundle. And this is what is listing all of the different assignment plugins. I'm gonna try to pause the demo here so I can talk about this a little bit more. These are all of those plugin assignment methods that I referred to. They have a specific order. They get run in order. So for example, the first one says, please detect any existing feature modules and bring those in as packages. And assign configuration on the site to those modules. So this is where it's looking at the YAML files in your module and making sure that anything that you have exported is still connected together. We then exclude some configuration that you don't wanna see. And you'll notice that that third one has a configure button way over on the right hand side which you can click to determine what stuff do you want to exclude.  Can you just hide that? Because I've got 500 menus on my site and that just makes features really slow to have to load that all the time. Here you could just go and you could say, hey, just exclude that. I never wanna see that configuration. I never wanna put it in the feature. The fourth one called profile brings stuff into your feature that would allow you to write that as an actual install profile. So Nejo has put in a lot of work to really integrate features with building install profiles. So if you don't like to have your configuration in modules and you actually wanna put them in install profiles, you can now do that very easily. Base type is actually one of the really cool ones and we're gonna expand that one in a minute so I'll come back to it. That's the one that determines whether or not you're doing it based on content type, review, core type determines what goes into that core package that I showed you. And then finally the namespace one implements the bundles and the namespacing and then the last one dependencies. That's the one that will auto-detect stuff in blue. So if you don't like features, auto-detecting things for you, you just come into here and turn off the dependency plugin. You don't have to do anything else. So now whoops, I knew I would do that.  Yes, you can't hit space to pause videos in keynote. You have to use a special magic key called K because that's really obvious. So we're back here. So what I'm gonna do here is we're going to go show you the configuration page on this base type because that's probably the one that you'll be most interested in changing sometimes just so you can see all the things that you can base your features on. So you'll see we've got content type checked. You can actually check more than one item. You could check views but those are all the different things that you can base your features around. Now here I'm gonna create a new bundle. So let's say I wanna start creating a bunch of open atrium features in D8. So I'm gonna create a bundle called open atrium and I'm gonna give it a machine name. This machine name is gonna prefix all of our modules, all of our features modules. So we're gonna put in OA as the prefix and we're gonna give it a little description and we're gonna go down and hit save. So we've now created a new bundle. If we go now to our features page, we'll see that we're now looking at the atrium bundle and there's no features listed there. We can go back to none and we can see we're back to all of our features. So none displays everything. Let's go now move my images into OA into the atrium bundle.  So you don't have to worry about name spaces, that's all done for you. We go ahead and write this to disk and now we've just created a new module called OA underscore my image. Now yes, it just let us write that same configuration to a new module. We now have two duplicate features on our site and you'll see they're marked as a conflict and so we need to remove that first one so that we're only left with our OA. The way you remove things is you can do a bunch of different things, you can uninstall the module, I'm just gonna go in, I'm just gonna remove the files because they're actually features thinks they're the same thing. It still thinks it's the my image feature because of that namespace. So all we have to do is delete the old one, refresh the page and now we've got our atrium one and so now if we go into the atrium bundle we will see that single feature.  Some other developer might be working on the Panoply features, they'll use the Panoply namespace and all of your work is nicely isolated so that you're not messing each other up. So that's bundles and you'll notice it allows you to very easily now copy features and clone features and rename features using this bundle. So what makes a module a feature? How does features know that my image is a module and how do you remove something as being a feature? What if I don't want features to manage this anymore? So here we're gonna go to our image and we're gonna go take a look at the code again. We're gonna take a look at the files and I mentioned the YAML file. If you look in the YAML file, there's this features tag. We can just remove that features key and then refresh the site and now our feature is gone. So now it's just a regular old module. It's not a feature. If we wanna put it back, we just go and we can just say features true and that's enough to get it auto-detected. So now features true, we refresh the page, now it's back again. Because it's namespaced OA underscore something, it actually already knows that it's in the open atrium namespace automatically. But to be nice, the way to really do it is to instead of just saying features true is to under the features key, give it a bundle key and tell it that it's in the OA bundle. But that's also how you can change what bundle of feature is in as well if you want to. So that's bundles, something people have actually asked for in D7 for a long time. There was a real pain to do in D7. So how about drush support? This is gonna be another one of those that you probably won't be able to see in the back so I apologize. But all your drush commands are there. So we've got drush FL is your feature list. Now here I've actually changed that view again. I've called it my cat gallery versus my gallery so you'll notice it's marked as changed. If I do an FL directly on that feature name, it will show me all the config files that are stored in there. If I do FD for feature difference on that, it will actually tell me what the difference is. Same format you're used to in D7 with the red and the green. If I now do a feature import so the new command FIM, that's feature import, that is going to import the code into the database. If you want to export the database back to code, that's feature export or FEX, effects. But for those people that just, oh and then there's, yeah so feature difference. So if you want to take this difference, we still do support the drush FR for feature revert is still there. And of course people just love drush FU so we had to keep it around. And yes, drush FU all does still exist as well. There is also the drush FC command for feature component. This shows you a list of things, a list of different things. So here I showed a list of views and I can use the FA command, the feature add command to add something new to my feature. So here I'm adding the who's online view to my image gallery. And now I list it and you can see that the view is now shown there. If I now come over to my disk, I can see that there's a new YAML file which is the who's online file. I can just delete this from my disk. It's just a file. So now it's no longer in my feature and if I do a drush FL, it's now gone from my feature. So YAML files are cool, but you don't have this problem where you have to go edit your .info file because that's where features keeps all of its stuff. There is nothing in the .info file other than a simple feature tag that says hey, this module's feature, everything else is in the YAML files just like it should be with CMI. So what is features doing that's still bad or kind of bad? How does features kind of violate some of this core CMI rules? So the first one that you saw is that a module can be marked as a feature and can be enabled on your site even if it contains configuration that already exists on the site. So we saw that when we first exported the gallery, right? We had just created the gallery. So we had a new gallery view. We exported that to a feature module and then we enabled that module even though that module contained that same view and Drupal doesn't normally let you do that, but it's really necessary from a developer experience when you're creating your features, you wanna be able to enable these things and play with them on your development box. So we actually overrode the config installer in CMI to allow this to be done if a module is marked as a feature. You can't just do it with any module, you can only do it with a module that's marked as a feature.  Tricks. The other thing you saw us do that was kind of nasty is it allows you to have duplicate configuration across multiple modules. You saw that when we used the namespace to make a clone and when we had a conflict between those two features, we had two features on our site or two modules on our site that had the same configuration. Again, we allow that. It's a temporary thing that you can be doing on development while you're refactoring code, like let's say you're moving a module from Panopoli into OpenHRM or vice versa, you need to copy it. It's something that we want to allow developers to do as a good developer experience but it's not something that you really want to do a long term and that's why it gets marked as a conflict. And of course, it still allows you to import config into your live site. And this is something that we really try to avoid in CMI in general. We really treat the site configuration as gospel. We don't want modules messing with your site configuration because we don't want your site to break. Just because I decided to update an OpenHRM module and I push it to your site and you turn it on, you don't necessarily want all your stuff to change. But with features, sometimes you do and so that's why it's allowed. Sometimes you do want to allow the feature to update itself, in which case you will, just like in D7, lose any changes that you've made when you revert or import that feature. Which leads us to the question of overrides and I'm not gonna really dwell on this very much, but overrides are still an issue. It's something that we've got a lot of thought going on around how we can really improve this. So overrides, again, this is the situation you have of I've changed the title of my view to my cat gallery. The person who wrote that module gives me a new filter on the view or a new field on the view. How do you merge those two changes together? You really want both, right? You want your title plus the changes because that's a security issue. And in the past, it was either or. You could accept the entire module or you could accept the entire site config and you couldn't merge them together. Now in D7, I wrote the features override module to attempt this and it works most of the time with some of the more well-behaved modules like C tools and views and things. Works poorly with some modules that still require array orders and things. And so you have overrides like that. We don't have the equivalent of that in D8 yet and we're still trying to think about what the best way to handle this in D8 is. It is gonna be a submodule in features that you can turn on. And as I said, what we're gonna try to do is provide a way to merge partial YAML files together so you can have the best of both worlds and control that from a code and site builder point of view. So the future. So summarizing features. Features is used to bundle functionality. It's not configuration management anymore and this is a good thing. Features in D8 is a developers module. You do not need it on production. It's intended to be used for people creating feature modules. You don't need it to use a feature module because a feature module is just a normal everyday Drupal module. It has some new functionality. It has bundling, it has auto packaging and assignment plugins and lots of cool stuff. And like CMI, it actually now just works. So that's Features. But I wanted to end with a couple other thoughts because this was a very interesting project for me personally. This was my first look into D8 and I did this in the month of March. Phase two was very generous. They supported me for a whole month away from Open Atrium and away from clients and all that stuff. They let me spend a whole month on doing features for D8 specifically for Drupal Con this year. And I was the one that told Frank, yeah, I think I could do it in a month when he asked me, so how long do you need? And at the time I had not done anything with D8. So the first week I started learning D8, I watched a bunch of videos. If you're a developer in the room and you're just starting with D8 and you didn't go to Larry Garfield's talk earlier in the week on Drupal 8, go find that video and watch it. I think it's one of the best overviews of Drupal 8 that's out there right now. It's certainly helped me an awful lot. What I found was that Drupal 8 was actually a heck of a lot of fun. Now I do have a background and kind of object-oriented programming and model view controller kinds of frameworks. I used to do code igniter stuff before Drupal. And so this was kind of refreshing to kind of go back to the old days where things just work the way you kind of want them to. But it was actually a very interesting experience. When I first installed Drupal 8 the first week and I brought up the site, I was like, wow, this looks like Drupal. It actually looks like Drupal. It's got views, it has content types, it has taxonomies. I'm like, did they really do much? Like, what's been taking them so long? This looks just like Drupal. And then I went and I looked at the code and I went, holy crap, this is all different. It's a minor miracle how much they changed behind the scenes and still ended up with something that we would call Drupal and that we would recognize as Drupal. And so again, hats off to the core developers on that. There is a learning curve. If you haven't done object-oriented programming before, this will take a little getting used to. But this is a good thing.  You want to get bigger, better jobs in the future and get more money. Like, this is good stuff to learn. So learn object-oriented, learn MVC frameworks and learn about some of the stuff in Drupal like services and things. It's good for you. So it only took a month. So my original session submission for DrupalCon was I will show you a dev version of features. And my vision was, yeah, I'll probably show you some Drush commands and we'll talk about how hard D8 is and all this kind of stuff. And what I ended up in a month is a full version of features with new functionality. So it really was rather amazing how easy it was to take a module as complicated as features and port it from D7 to D8. So was this really a port? What actually got involved? Here's some fun statistics, because people ask me these questions having had this experience with a real complicated module. How does the D7 version compare to D8? And you probably can't read all the stuff on the graph there. But the little bar chart at the top, the blue is Drupal8 and the red is Drupal7. So Drupal7, of course, has this big old spike on the right, which is called CMI. Because in Drupal7, features had to do CMI. And in Drupal8, we don't and so there's nothing in blue. If you look at other things, scaffolding is what I call things like interface files, YAML files in D7, those are your info files, your API.php files. It's just kind of the extra stuff that you need around your modules. And people think that D8 is really bloated with all this extra object-oriented stuff. It really actually wasn't bad at all. I'd add it a little bit, but not very much. The base functionality in terms of I wanna create a package or something like a package was pretty much the same amount of lines of code. The UI was actually about the same amount because actually I was able to use most of the UI from Drupal7.  The JavaScript came over almost without change. So it's about the same. Drush commands came over almost exactly the same. Drush is very, very similar, which is actually disconcerting. Once you start playing with Drupal8, you kinda want Drush to be a little different because it's not object-oriented and you don't have classes and class variables and things like you do in D8. And then what we added to Drupal8 in blue were the plugin system and the plugin UI for doing the assignment plugins and bundles and those kinds of things. So overall, the result was it was about the same number of lines of code. All of that CMI stuff I took out, I put back with new features or new functionality. So the overall module ended up being about the same weight. It was not hugely bigger or anything like that. But it also wasn't tiny. And that little pie chart down below shows some of the breakdown of where the code came from. So in blue, that's the code that came from Nejo's config-packager. Now it had to be refactored. We had to rename everything from config-packager to features and do a bunch of stuff like that that took a little while. But that's kind of a third of features is what was in config-packager. In red, that's the code I was able to bring over from D7 without change. The form API hasn't changed. So all that nice user interface, you'll be like, wow, you've got the same user interface. Yeah, that's because I just copy and pasted it into D8. Now you do have to change some things. I mean, form state is an object now, which is actually nice. So you do have to do a little bit of refactoring. You're not gonna find kind of a one-click convert my form into D8 helper module probably. But once you get used to the ideas, it's actually not that bad. In the kind of greenish color, that's the brand new code for doing things like bundles. And then the purple code is the kind of new code that was written for core features to do the packaging and stuff like that. So again, people are just kind of interested in how that broke down. So if you wanna get involved, right now, as I said, we have alpha one available. Like I say, alpha one is for beta nine. So you might wanna wait till I get back for vacation in a couple of weeks, and I'll have an alpha two that is for beta 10, or maybe beta 11 will be ready by then, we'll see. So I'll try to keep up with the beta versions as we go through the summer. Take a look at the code.  See if it does what you need it to do. See if you find any bugs or crashes or problems and put suggestions in the issue queue. I would love to hear from people on that. And help write tests. I will not create a beta version of features until we have full test coverage. And there's already actually been a start. And thanks, Jonathan, if you're out there somewhere for starting that issue. So we have a few tests that I will get into the next version, but that's a great place. Actually, when I talked to Jonathan, he said it was a great way for him to learn how features worked was by writing tests for it, because that got him into the guts of it. And finally, now we can finally stop hitting features and start loving Drupalite. So thanks, and I'll take any questions. So there's a mic in the aisle, so please go up to the mic since we're recording this, we wanna get your questions, but go ahead. Oh, is it on? Still not on. Did it right, did it right? Okay, I already have you guys left. I'll repeat the questions. Yeah, so the question is if features isn't used in production, but I make a change in production and now I wanna synchronize with the feature, how do I do that without the features module? So the answer is you don't do that on production. You do that on your staging server where you have features, and then you use CMI to export your new configuration to production. Obviously, if you really want to do it and you really have to do it, you could obviously turn on features on that. We actually are, for the reverting, we're using another contrib module called configupdater that Jen Hodgins wrote, and you can use the Drush commands from her module actually to import your changes as well if you just wanna take the code and put it in the database. But no, I encourage people to do it on their QA server and not on their production server. Yep. Yeah, so the question is if you do have conflicting config or you have config in your feature that exists already on the site with features on your dev server that works, but then on production, how do you enable that module because it's gonna conflict. Is that right? Because it exists. Yeah, and so again, the way you need to do that is, well, again, kind of almost back to the old answer of do that merging on your staging or QA and then push. Or what you would do is actually go on your production and you'd have to delete it first. If you don't wanna install features, you would have to delete that existing configuration first and install it. So like if it's a view, delete the view. Now, once we get this, in Alex and I were talking about this a day or so ago, once we get the dependency stuff working well on this, you actually may be in situations where you can't uninstall modules that have that preexisting configuration. So how did that configuration get there in the first place? I guess is how I would ask it, right? It had to get there somehow. Did it come from a module in which case it was already a feature and why is it different on production than your QA and why can't you just use CMI to deploy it? So yeah, so the question is when you're using bundles and copying features into different bundles, what happens when you have existing content that's already part of that? So what's changing is it's the namespace of the module. The actual configuration is not namespaced, okay, right? So your existing configuration is actually the same and that's actually why I got away with just removing that old module and having the new one worked. They have the same exact YAML files within the module. So like a view, the view itself wasn't namespaced. Just the module containing the view was namespaced. So yeah, so the question is wouldn't you want a namespace that comes as well? I think yes, there are use cases for that but I think those are kind of outside the realms of features at this point in terms of namespacing configuration because literally you would need to create like if you wanted two different views with two different names, you would do that through cloning the view or something like that or copying that YAML file, giving it another name. And so you can actually already do that through just kind of YAML file manipulation. Making that easier is probably another good place for contrib to do something. So next. Okay, so the question is can I repeat what I mentioned about merging that it might be a submodule? So yeah, as I said, we're still trying to decide the right way of merging and how you would do that. It's for people that actually wanna talk about this later in terms of throwing an idea out there. And again, this is something I talked with Alex about. One of the things I'm thinking about is you normally are supposed to update this stuff through update hooks, right?  And that allows Drupal to run these things in order. So what we're considering is creating a directory within your configuration that's numbered by the update hook. So you have a subdirectory called 7100 and in that subdirectory you have partial YAML files that have just the title change or just the field change and that a new submodule like a feature override module would hook into the update hook system and kind of write the update hook for you and what the update hook would do is go look in that directory for the partial, take the current, do a merge operation. And so it would kind of do what you would do in code normally without having you having to write that code. That's kind of the current idea. Nejo doesn't actually like that idea so I need to talk to him about his ideas and that's why we haven't done anything yet but we need to do some kind of YAML merging there as part of the update process or we're through a drush command or something like that. Next. So the question is in D7 there were alter hooks and that made it very easy to override small bits of things like a part of a view or something like that and basically what's happened to that in Drupal 8? Can we still do that and so on? Part of that I don't actually know if the alter hooks might still exist. It's kind of up to the modules themselves. It kind of, in CMI, the very strong opinion and result was that we don't want alter hooks. That when you go look at your view in the views UI you're seeing your view as it is and there's no magic going on behind the scenes where some module is altering it at runtime only so that it changes like there was specific work done to actually kind of stop that kind of stuff because it makes supporting sites actually very difficult and there's better mechanisms for doing that but I can't actually say for sure that some modules don't still have alter hooks to let you do that kind of thing. Yeah, in views, that was a bad example. In views it would but there were some other things that you could override variables and things and not necessarily see the right one in the UI and stuff like that. So again, we're trying not to do that, trying to provide actually cleaner mechanisms to do that so that it's better. Is that fair Alex? Yeah. So Alex's response for people that couldn't hear it was that when you do it with an alter hook and you then go save your configuration you've now saved that in the database and now that's the live configuration so now there's no longer an alter or an override and that because in D8 your site is your configuration you shouldn't need to do it with an alter hook you just go directly change it on the site and instead of altering it just make it what that site needs because that is the site configuration. Next question. So a very long question. So I'm kind of gonna summarize you have a module with a lot of code and some configuration but the module is designed to allow users to add fields and add things to it. So right now the module just provides the starting point, right? The basic structure of the fields and then on any given site you're gonna have new things added to it, right? So currently you're doing that through features and you revert the feature and because features is not going to care about any other fields that works perfectly fine. That same is true in D8. Every field is a separate YAML file so when your module creates new fields it's creating these, when you export your configuration it's creating these new YAML files and those aren't part of your module because your module's just providing the default config so there is no conflict there it's really gonna work just like you're used to in D7 now. Correct. Yeah, great question. So the question is I have a whole bunch of features in D7. What's the upgrade path to convert those into D8? I've thought about this actually. There may end up being something as a helper because if you look at the YAML files they really have a pretty direct correspondence to things in D7. Like I think I can imagine some basic mappings. I can see where fields go. I can see where views go and things like that. Obviously the actual export structure has changed like even if you look at a view in D8 it has some similar qualities to the export in D7 but views has changed and there's some new fields and new properties and things so there's really no way to take that exported array from D7 and somehow auto generate a YAML file. What's best to do I think is actually rely on the module update paths themselves and I mean upgrade paths is still a question for all of D8 but it's still up to the module. So for example, views may already, may not, I don't know, have some kind of upgrade path? No, okay. The idea would be if you can get that, perform the update on your site so that in the database it's updated the view to its new format and then re-export it with CMI now you'll have the new export of that. So rather than trying to convert the code export of features to a YAML export you kind of load it into your site, let the site do the update and then export it back out again would kind of be what I would say but I think what features can help with is at least give you a helper to say hey, you're exporting these things in D7, you should export these things in D8 and since the interface is pretty much the same it's probably not even that bad of a thing to go and just check the boxes again if you absolutely had to to re-export it. Probably wouldn't take that long but yeah, there's not gonna be a magic and that's true with a lot of arrays in D8, there's not gonna be a lot of magic upgrade or updating going on. I don't think it should be part of CMI, I think they split that really just right in D8. They provided the pieces that should have been in core all along are in core now but I don't think, I think the direction CMI has made in terms of its opinions about site configuration is actually what you want and in terms of packaging that's more of an extra developer experience that should be supported separately. So I am actually not sure I would make much change there. There may be some little things like it'd be nice to have some API functions to do some of the stuff that config updater's doing or some things like that but those are all pretty minor so I don't think I would change too much of that split and I don't think I would move stuff more into core. In terms of the future direction of features I haven't thought about that too much, I mean it's doing its job now so I'm not like somebody who just wants to add something for the sake of adding it, it seems to be doing its job, I think there's been some things still in D7 to help with the UI and stuff that maybe get some tweaks but I don't think you're gonna see any major revolutionary thing. Unless somebody in the community or like Nejo did with his assignment plugins which was a new idea to me, if somebody comes up with that then sure. Yeah, so the question is what about strong arm in D7 that was used for doing variables and configuration variables? So that's actually part of CMI now. CMI has two different types of configuration, there's something called simple config and then there's entity config. The simple config is basically the variable system so it replaces the whole variable get variable set with variables in YAML files. In features, even though your variables, and I'm trying to figure out the best way to explain this, your variables are stored in a single YAML file, like it doesn't make a file per variable like that would be crazy, right? So they are all in one file and yet features in CMI does consider them separate things so you can import and export individual variables even though they are kind of collected in one file and so that does kind of make variables a special case versus everything else which is more of an entity config kind of thing. So yeah, strong arm is gone, it's not needed anymore, it doesn't have to be special.


Hello and welcome to the session. My name is Mansi and I am going to help you with the following question. Now the question says, prove that the circle drawn with any side of a rhombus as diameter passes through the point of intersection of its diagonal. So let us see the solution to this question. We see that A, B, C, D is a rhombus. Then taking A, B as diameter, we draw a circle. First of all, we see that what is given to us. Here we have A, C and B, D are its two diagonals which bisect each other at right angles. Now what we have to prove that a circle drawn A, B as diameter will pass the point of intersection of its diagonals and we see here that the point of intersection of A, C and B, D is O. So the diameter will pass through O. First of all, let us do some kind of construction here that helps us solving this question. The construction would be we draw P, Q that means this F parallel to A, B parallel to A, D start with the proof to this question. Is a rhombus therefore A, B is equal to C, D. So first we have A, B is equal to D, C is equal to D, C so this implies half of A, B is equal to half of D, C. We see that half of A, B is equal to half of D, C. Now we know that C will be D, P. This happens because we see that this will be the center of the circle. So A, Q is equal to B, Q. So similarly Q becomes the midpoint of A, B equal to D, P because that you understood the question and enjoyed the session. Have a good day.


Hello and welcome back here to the channel as you can see we have the wheel cam and the pedal cam all turned on for today's episode We are here on torture for torture of Tuesday We're gonna be trying to get settled with the wheel here on torture So make sure you guys follow me on all social media all that you found in the description box below So like I said, we are here going to be going into practice trying to get the wheel more comfortable We're gonna start up the slab and we're gonna continue our way into other tracks. We're gonna be doing some practicing Here on free roam. We're gonna be running the tortriff to BRZ thousand horsepower It's car. I haven't driven a lot of so it's something that I actually want to start driving more of so We're going to go into the game with this car base tune and see how we can do hopefully we can Do a decent run? So first ascend on the wheel for today's episode Notice my puddle cans a little bit off, so we're gonna rotate that a little bit. There we go Well, this car already wants to go sideways I'm gonna clutch kick it in kind of try and be smooth. You have the trajectory lines and everything on all the clutch kicks and actually off the rip this car is handling quite well For only being on this game on the wheel a few times, I'm actually thoroughly impressed with how this is handling This be harder dirty e-brake grab kick that in the third Back into fourth. All right. Oh, so I could officially say that out of the cars I've driven so far here on torque drift little clutch kick entry this car is Probably the smoothest one right now on the wheel for myself personally and I think we're actually Getting it so I am gonna work with this car more Maybe change up some wheels and stuff if I can because I think when I got this car came with a bunch of wheel options And things of that nature throw a livery on it do some tuning dirty break grab Gently into the barriers so for a first Run out. I'm actually quite impressed with this BRZ here on torque drift on the wheel seat fake clutch entry Left a break so these wheel settings that I'm running are Just kind of a shot in the dark with a setup here clutch kick and it's Working out quite well actually we are on smooth with no assist. Oh, I stalled there Needed more clutch kick and I think I think we're ready to step up to another track Here with this BRZ I'm not gonna go into tandems yet. I want to get more fluid on it so that I can actually throw down a decent line To go in the tandems and if I can start getting more comfortable wall tap. Sorry. Sorry devs If I can get more comfortable in this I will be rocking some online Maybe Tandems battles with the wheel here on the channel getting back to the live torque drift battles But be running a wheel. I want to be super smooth about it because I would definitely be at a disadvantage with all the You know mobile players and players on controller and things of that nature really wide third It's so nice to be able to have a shifter and a clutch and Breaks and left foot breaks and things that nature and no bumpers So I think we've escalated to go to another track. So let's head to another track and see what we can do with this car another track Now we got to figure out what track we want to do. I was actually Wondering how that was gonna go and it actually worked out pretty well So I think we should probably try and drift a longer track Maybe a big track So let's go to We'll go to the yard The art is definitely a fun track elevation changes and things like that We're gonna go free roam So we can not change tires. So that's the unfortunate side of using this car But I feel like the tires are great for the car full send fourth gear oh Um Did not expect the jump to hit that hard. So let's let's we try that You guys won't keep seeing tortures here on the channel No, let me know down the comment section below tap that like button. It's how I know you guys won't keep seeing it We've messed up the bumper again, but it's fine clutch kick. Yeah, see this is much More complicated than the slab We're gonna try our best to complete a lap here third gear probably the best gear right now Much twitchier Here on the yard that I was on the slab because it's a lot more change of angle and transitions Trying not to smack the wall And I'm also trying to be very smooth and understand my steering inputs and where I need to be Because this is a whole new ball game for me And we managed to complete a full lap not the cleanest run, but a run nonetheless Hard flick on that see if we can maybe link the track Nope, I should have pulled you right there so I think I Feel with a little bit more practice on the wheel and maybe some tuning on the car Which I think is gonna be the biggest thing is the tuning aspect I feel like we should be able to get back to where we were on the mobile platform and be Comfortable enough to run some live tandems and things with you guys on the channel here on torque drift again Definitely fun to get back into this game after a long hiatus. You guys have been asking for it Well, it's here. We're on the wheel. We're trying our best to be smooth on the wheel But I just got to find my wheel setting So if you guys are on the wheel here on the game and you have a good setting or good wheel settings Let me know down in the comments what your settings are because I'd be very curious to see what other people are running as Their wheel settings if they are running wheel or wheel you guys are running So for all my torque drift PC wheel uses out there Let me know what you guys are running and setup wise because trying to dial in this setting on my B2.5 is gonna take a little bit of time. I feel but once I can get that set I Feel like we can go back to dominating here on torque drift I'm actually having a lot of fun with the wheel right now in this big FRS BRZ. Oh That's a wall. Nope. We got it. We're good. We're good So make sure you guys follow me on all social media all over Japan in the description box below bit of a wheel video Here on torque drift. I know you guys have been wanting to see more and more of this So we're here. So like I said, make sure you guys follow me on all social media all the time You guys are part of the patreon and you guys want to join it the link for that will be down in strict from box below as well I'm gonna be releasing patreon exclusive content this week So as always, I thank you guys for coming back and watching those the pole Always at the wall instead. I run a football happy for rabbit. I'll see you guys on the track


All right. Yeah, okay. Hi. Hi everybody. Welcome Today we are going to be talking about easy multi tenancy Coronet is free by many storage with club provider open stack and Manila CSI My name is Victoria Martinez and La Cruz. I'm here today with me I'm Tom Baron. I worked with Victoria. I was the Manila PTL the last three cycles, but not anymore got to miss so What are we going to be talking today? We have really a short amount of time and and this was intended for a full Presentation so we have a lot of content, but we are going to try to fit this in 10 minutes a bit more maybe So today we are going to be covering what is Manila CSI Then we are going to do a quick overview on well why we actually need river many for Kubernetes with Manila CSI Then we are going to go directly to show a demo of how are you going to deploy Manila CSI? and Finally, we are going to be covering the use case for the application developer side So basically is how you are going to be using Manila CSI as a well user actually finally we are going to leave a link With summary and resources you can use if you are interested on this topic So you can check it out later all the slides are you have a lot of content But the idea is for you to actually have some sort of resource if you need to check it out. All right, so First of all, what is the Manila CSI plug-in first I hope you are familiar with the many with what Manila is if not just the quick basic introduction Is that Manila is the share power system as a service project for open stack? and CSI basically is the solution we have the standard solution We have if you need to have persistent storage for you in Kubernetes The actual Definition for this would be is external dynamic provisioner plug-in for persisting Kubernetes volumes serve up in true open stack Manila a good thing about is because there are several implementations, but CSI is a standard and The great thing about it to be a standard is that basically you can use it with any Continued orchestrator is not only Q&A is But still this code lives in the Q&A is cloud provider opens our repository So a bit of Motivation on why we should be using The cloud provider opens our plug-in with Manila instead with that maybe implementation for a vendor specific or back-end specifics Storage and basically is The our main reason would be is you know Manila has support not only for one storage, but also For nearly 35 different storage vacancies Basically, you can use this a Single Abstraction layer to interact with any storage you might have and this is pretty convenient. This is flexible So this is a good reason for you to be using Manila on Kubernetes So a really important point is that in open stack we have multi-tenancy Basically, you are getting this for free In Kubernetes something that basically you don't have right now in Kubernetes And it's not nearly to be done in the short place So if you are looking to have a deployment with multi-tenancy, this is your your way to go okay, so Why use Manila instead of other solutions in open stacks for instance like Zinder We have a plug-in for Zinder But the thing is that is read rate only Thank you, and in Manila you are getting read by many So there are different use cases is like if your use case actually requires this capability then Manila is your way to go In Zinder is a different use case, but well it depends on what you want to do and Well, what what would you want to use a storage in Kubernetes? Basically? Well, it's easy to scale and Basically manage any application you might have that would need persistent storage All right, so All right, so Let's see a quick overview of how this demo is going to be look like How is the the topology that we are going to be presenting in in for here? So basically you will have Open stack deployment like a minimal one with Manila And Manila is not on the data path is in the control path You will have different tenants for with your Kubernetes cluster here have cluster a cluster v and Here we depict an scenario in which you will have two different storage possibilities So for instance a vendor storage and in the other side Seth with NFS Ganesha gateway in front of it Basically, you can interact with Manila to provide a share and just get the share directly attached to your pod and That in a simple scenario that well we are going to show and it will allow Tom to actually perform the demo sure So what we want to show first is what a Kubernetes? cloud administrator needs to do to work with CSI so cloud administrator is The Kubernetes admin is oh, yeah, I'm sorry. This is right. Thank you So the administrator is an open-stack user it has an ordinary open-stack user rights but the administrator of the Does not need administrative privileges and open-stack itself. Okay, so we showed a picture with Kubernetes cloud a and Kubernetes cloud b and they're each separate open-stack tenants And our ships in the night to each other as they interact with open stack. So In the Manila CSI provisioner The Kubernetes administrator works with a bunch of YAML files to install the plug-ins that are required So we're showing here an example where they're using an NFS partner plug-in to just do the mount Nothing else in the NFS CSI is used similarly you could use a sep fs native provisioner to do the sep fs mount and then the controller part is Is run as a stateful set with replication one So you only have one one of them running a time that's in charge of orchestrating that The actual stuff it interacts with Manila and the control plane to get provisioning done and then there are node provisioners Which do the actual mounting from the Manila standpoint and interact with these Interact with the protocol helper so All of that is canned Okay, it's just the same as boilerplate It's the same for every kind of deployment except which protocol you're going to use to hook up with what you have to do though is set up local secrets with your normal credentials and the code to do there's a script to do that in in the code that was Provided with the Manila CSI provisioner and then you have to define storage classes Kubernetes users refer to storage classes when they do Persistent volume claims the storage class concept is abstractly a whole lot like The Manila concept of a share type and indeed you map this in that when you do the storage class definition You not only say how big you want it. I need two terabytes or whatever, but you say What Manila? Storage storage type share type matches the storage class So you might have a Manila share type called gold or something and it will get mapped there in your storage class. So This is something that's done one time There's a helm chart to do a lot of this now that's in here We're not using it in here and then downstream For instance in our distribution with OpenShift we intend to write an operator that will wrap all this up and just make can it It's still pretty easy even like this Next slide, please Oh, yeah, okay, so I Think these points I've made basically we're gonna do a little screencast that shows you what the administrator does to set it up with these manifest Thank you Okay, here we are Play okay, we have a Kubernetes cluster It's running 1.15.1 I Can't type so you get to see me type and retype. We have a master node and three worker nodes Here are the manifests that I just saw earlier that I just had on the slide for example the secrets file Looks like that a script produced it from your OpenStack credentials Here's the storage class that's defined at the moment here I Will you can see here? The storage class has a name. It's using the Manila provisioner and Has a Manila share type so the you the Kubernetes administrator needs to talk to the OpenStack Administrator at some level and say what share types do you have out there? Just like any other user it wants to use share types They have to know which types there are the Kubernetes administrators guide those that in this case Right now you can see we don't really have much going on in the Kubernetes cluster some bare bones one We're going to create we're going to use these manifests We'll see if they them start running in a while Actually the way I sorted those they start running right away so It's fast and easy The hardest part is typing kubectl right without inverting the letters and You can see that there are a bunch of pods here running with these different parts of the Manila CSI plug-in and What else did I show here? Oh? There are no persistent volume claims made yet There are no persistent volumes made yet We didn't create any manually at a time and the dynamic creation of them by Like persistent volume claims hasn't happened because we're just the administrator setting things up for ordinary users Who are going to use do this? Manila Also on the back end didn't have any shares corresponding to that We can go go on now Let's move on to the next slide. Thank you Victoria Okay, I What I want to show you is that's something this one time administrator does for it over in Kubernetes cluster a Over in Kubernetes cluster B the administrator did something similar. They don't know about each other They're running on open stack and getting opensack storage right now. How does an actual user is typically a developer or DevOps person? interact with this now so an application developer using Manila CSI can get RWX storage RWX is the Kubernetes jargon for read write anywhere Which is just means essentially that I can have applications running in pods that are writing Concurrently to the same persistent volume safely Okay, the jargon is our RWX versus RWO or the various read-only modes So as Victoria mentioned earlier Sender for instance will give you RWO mode, but not RWX at least when you're using file There's a new raw black block thing. We're not talking about right now So The idea is an application developer ought to be able to define their application in a pod and They ought to be able to find persistent volume claims and use that in a cloud native area running on Alibaba or Azure or AWS or something like that and then move the same application over into an on-premises OpenStack Environment and run the same thing they're gonna have to change the names of their storage classes But otherwise they ought to be able to run and the reason they have need to change the names of storage classes is not because they're moving from Alibaba or AWS to An OpenStack based thing just because they're moving to a different administrator people name things differently They might use their own native language for instance It's the names of them you got to be able to refer to the storage classes that have been defined by the administrator Okay, let's move along now So I made a bare-bones simple multi writer Application so if you look at the red part, this is an application a simple DOM application writing Running in a pod the application Echoes the date into a path Slash M&T path and it's using the host name of the of the node Here hostname here hostname here ends up Different I have two of these writer one and writer two the only difference is the name and the name shows up in the hostname So that means you can write into a different spot in the file system. We're using the same application We're mounting this through a pbc and the claim name is my claim We can look that this will all be online I'm gonna run through it quickly because I'm running out of time, but you can see how it works later now We have web that my claim shows up in a pbc and The pbc is read write only I mean rewrite many 10 gig and It referred to the storage class that the administrator created Okay We'll go run through this of quickly in a screencast again, you can see this We're running out of time, but it'll all be here and our contact information's at the front So if you need to ask us questions Feel free So we don't have any pbc's yet the administrator just set things up user hasn't done anything That's the pbc. We're gonna use this one. I showed on the slide we create we create a We create that persistent volume claim and now if we look there is a persistent volume claim where that was blank before and There was a persistent volume fulfilling it and once you get the credentials, right? We'll see that there's a manila share Corresponding to it now. I'm cheating a little way in running manila commands here of doing it For the sake of showing it to you the end user of the kubernetes cloud isn't gonna know Anything about manila? They don't need to know anything about open stack just you can see on the back end That's how it's getting fulfilled as I showed you in the slides. I've got an application same one We put on the slides. There are two versions of it. They differ only in the name It shows up. We run each of them Look at the result Come on. Can't type pester. All right. So what we're here here what we're doing Might be running off the screen here basically They're both running and they're running you'll see it if you run this on your native And you'll see they're running on different worker nodes. So they're distributed out over the cluster now what we can do is Run a command in the pod called writer one And we're just listing the the file tree under the mount point all I'm showing you here is you get you see the same thing from both pods Which are running on different worker nodes Right and not only can you see the same thing? You can look at the file that's being written by the other pod on This on you know on writer one you can see what writer two is writing and on writer two you can see what writers one's writing So these guys not seeing this a million times in in Manila You know with read with without calling without the container context So You can also see and hear that that the files are both both show up in both places and You can see that they're up top that mount with the It's running off the screen here But it's mounted in both places in inside both pods So the scoop can tell cuddle Exact commands are running in both pods. So this will be posted the slides will be posted the screencasts will be available The manifests will be downloadable when you come back after this, you know in a week or two when the Conference is all settles So you can follow up on the details of that stuff at that point I Have another I'm going to skip it right now You can obviously do read write once as well the demo and screencast show you trying to run the same apps The first one comes up fine the second one blocks. That's what you will get the sender or etc With the sender CSI plug-in with this kind of application. So summing up with Manila CSI you get read write anywhere access from any nodes in your in your Kubernetes cluster you can run multiple clusters on open stack that don't know anything about each other But that are still using common open stacks Alas elastically available large-scale storage behind it that's available to all of open stack You can run multiple back-ends. I can run Saff plus net app plus I don't know in spur, you know, etc. And I can put them all in there Or I can pick and choose among them as the open stack administrator and nobody has to know anything about it Who's using Kubernetes? so That's basically it the slides cover some more stuff like futures that are developing with I think that's about wraps it up will be around if you have questions and stuff This is liking talking and we're already running over our time. So thank you for letting us do that


as I step on to your side you capture my eye Karbala I see heaven has been placed beneath your skies Karbala feel the darkness of grief within me Karbala I feel my heart heavy with my wings and crows Karbala I've lived now I meet with my demise Karbala I shed my tears wondering what I have been I come to you dressed in all my lies and sins now I'm here in Karbala Karbala It starts with a beginning since tears are flow We are condoling In caribous blood was filled the ashore I did hear ashore My master have you What takes change there between عضس زينابان فهوسين It's only present you have been My master have you but seen What takes change there between Karbala I've lived now I meet with my demise I've lived


Hi, I am Harsh Vyas. I'm from India. I'll be an E4C program coordinator in 2021, advancing the sustainable development goal, goal number two, that is zero hunger and goal number seven, that is affordable and clean energy. I want to apply my engineering skills for social good because I believe as an engineer we could leverage those skills along with technologies to create a positive impact for the society around us. As an E4C program coordinator, I'll be working with organizations such as Senergy to optimize the design of the product which converts the sanitation waste into useful agricultural product like manure and briquettes. I'll also be working with S4S technologies on solar conduction dryer to optimize its design for efficiency and lowering the cost. I'm most excited for this fellowship because I would be meeting with like-minded engineers from around the globe and sharing knowledge with them, discussing ideas to solve the real world problems. In 10 years, I hope to implement multiple social impacting projects and also motivating and leading the younger generation of engineers to create an impact at a larger scale.