 While we're letting any more trickle in, why don't we go ahead and I'll introduce myself. My name is Rob Locke. I am one of many curriculum developers within Red Hat Training. I started teaching the RHCE program back a whole lot of years ago as a contractor, primarily in the Manhattan area in New York, and then a bit of traveling associated with that. Before Red Hat, I've done pretty much all the different training vendors that are out there. So I did stints with Cisco, before that, computer associates. Before that, I really cut my teeth, I'll say, on net wear. If you remember that whole thing, yeah, way back when. Nowadays, I get to work out of my basement with some equipment and writing the books and things that you see in our classes. What this particular session amounts to is something that we call Taste of Training. So what we've done is we've taken a little excerpt from a course we have, Red Hat OpenStack Administration, course code CL 210. It is the one that's associated with a certification exam that we offer with regard to OpenStack. And so this is the course you would come to to prepare yourself for that particular exam. What else? One other housekeeping thing I do want to give a whole lot of credit to our partner, Dell, who were nice enough to loan us the computers for today and give all of us a chance to do some hands-on with, in this session, installation of OpenStack. And then later on this afternoon, we're going to start playing with Neutron and do several things with the networking piece. So CL 210, let me talk a little bit about the course for a moment. Classically, the layout of the course, you know, you've got a number of units. This gives you sort of an overview as to what we're looking to accomplish in that course. Day one, we've got our introduction. We talk a little architecture. We start reviewing all the different names of all the different components within OpenStack and try to remember which one's Cinder and which one's Heat and which one's Neutron and all that sort of stuff. Then we move into OpenStack installation, and that's what we've extracted here for this session. We're going to take a look at two methods of installation in particular in this chapter. One is the use of PackStack, which is very appropriate if we are doing an all-in-one sort of a demo installation. We want all of the components, the controller, the compute node, everything on a single physical box. And so we'll use PackStack to make that happen. So we'll go through that process first. The other tool that we have is Forman. Forman is more of a deployment environment. So we'll have to set up a Forman master. We'll modify the configuration that we want to use and ultimately deploy, and then we'll start pushing the scripts out to a couple of, in our case, virtual machines. There is a third way to install. For those of you that have played with OpenStack for a long time, you know there's the whole manual process, right? Install the packages by hand, modify some config files, run some scripts, and get the thing going, do a whole bunch of typing is what it boils down to. So we do that a little bit in this course too, where you get a chance to take a look at that manual installation process if you want to have complete control over exactly which little pieces go where you want them to be. But then we go in to the various components, taking a look at what they're providing for us and how we can go through things. And then of course at the tail end we have a comprehensive review. This is something we're doing in a lot of our courses, particularly those that have certification associated with them. Everybody wants that last-minute practice Thursday afternoon before the exam on Friday. And so our goal in the comprehensive review, as the name implies, is to sort of give us a chance to go through all of those elements together. So as I mentioned, you know, classically we'll go through, orient you to the classroom here. On your systems, oh, that's wrong. Your physical systems are called hostX now, instead of desktopX that we have here. But then we will have a number of VMs installed on each of them here. But this is trying to give you a little bit of ideas to some of the connections that are being made to the outside world. As I mentioned, we normally talk architecture. We're skipping over that because you've all seen this type of slide enough times already and it's only day two. So where are we? We're into open stack installation. Now what I did is I took the first section and the third section from this chapter. Normally I have two and a half to three hours to do this unit. We only have an hour and a half. And I wanted to focus on the two installation processes. So the first section has us working with pack stack. The third section has us deploying with foreman. What's in the middle is the use of the horizon web interface. If you stay for some of the afternoon sessions, you might see a little bit of use of that horizon web interface. But you'll also see some of the command line deployment pieces too. So how do we go about installing Red Hat open stack? Now again, I've shortcut it here about how to get on your machines and all that stuff. Normally that's done in the introductions and things. So let's go ahead and sort of rapidly get you typing. Most of you are probably staring at a login prompt with one username on the screen named student. Anyone want to guess what the password is? Student. All right. So username student, password student. Red Hat would have been a good guess too. All right. We use that a lot. Once you're logged in, I'm assuming most of you can navigate a little bit. There is a track point in the middle as one way to navigate on these laptops. There's also the track pad at the bottom. If you prefer that, we left both of them active on these machines. So whichever combination you're most comfortable with. You know, you can right click in the middle of the desktop to open up a terminal. You can also go up to the menus up above. And I've been playing on REL7 too much, so I don't even remember where it's hiding. But what I want you to do is I want you to open up a terminal. Now to get into a particular virtual machine, I want you to notice at your terminal window your prompt. Your prompt is host, you know, username student at host followed by a number. The number is very important. Because that's how we'll know that you're getting into your virtual machines and not someone else in the room. Because you're all on the same network. Well, technically no. You guys are on one network. You guys are on another network. We're doing a lot of downloading and I was trying to segregate the traffic a little bit. All right. So you've got it open at a terminal prompt. We're just going to use SSH to get into our first server. So do an SSH, space, root, act, server, the word server, S-E-R-V-E-R, your number, dash A. I should have shortcut it. I always forget that's there. All right. If you don't like typing server your number dash A, you can type A your number. That's another host name alias we have in there. Password for that one? Red hat. Red hat. There you go. So I'm going to go ahead and do that too. Now, those of you that came up to a keyboard, you would have found there a bunch of paper. These are the practice exercises, the workshops that we're going to be going through here. All right. So we have two VMs that we're using. There's A, your number, and there's B, your number. We need to be very careful to keep straight which ones which. In the first case here with pack stack, I want to be doing it on A. All right. So I want you SSH into A. And in order for us to use pack stack to perform an installation, the very first thing we need to do is install the open stack dash pack stack package. And so you'll see there in step one on the very first page. We're going to do a yum install dash y. And it's open stack dash pack stack. I did the dash y because I don't like waiting around and having to answer yes later on. But this should go ahead and install the packages. Now please, please, please make sure you're on your virtual machine. Please do not be installing open stack dash pack stack on post X. All right. You need to be doing it on the virtual machine. Otherwise it messes us up for the rest of the day. All right. We've got to reinstall your machine from scratch in the whopping 10 minutes we have in between sessions. So let's make sure you're on your VM. All right. So it's installed pack stack forming. Now one of the things pack stack will do is for the machine that we're deploying to, we want to use SSH keys to be able to communicate with that device. And pack stack will very nicely deposit that SSH key for me. But I need to generate keys first. So how do I generate keys on Linux? SSH dash key gen, beautiful. So that's what we're going to run here. SSH dash key gen as you see there in step two helps if I hit enter instead of shift. Ask me what file I'm going to save it to. Just hit enter. Passphrase. We don't need no passphrases. So just hit enter. We're not concerned about security. We're just making this happen. Well, it's a flip of the coin. You know, do you want to keep entering the passphrase or do you want to enter the password? Yeah. Is that what it's up to now? Yeah. All right. So we went ahead and generated the key to make it easier to deploy this stuff. Now pack stack as a command has already been installed for me. So let's take a look at the help for pack stack. So you'll see there in the third step we're going to run pack stack minus H, pipe it to less. And what we'll see here are some of the options that are available with pack stack. Dash dash gen answer file. And then the name of the answer file we want to create. We have dash dash answer file. So the difference between the two of these is gen answer file will generate a template answer file. Actually reading ahead that's apparently what we're going to do in step four. And then we're going to edit that template. And then we're going to apply our edited file using dash dash answer file. But you'll notice we have a bunch of other things. We've got install host where we can identify a set of hosts. We want to do this out too quickly. We've got all in one other options. But then everything that's inside that answer file also potentially has a corresponding global option we can set here. So we could either be creating a pack stack command that goes on for about 20 lines. Or we can gen the answer file, edit that template and then go ahead and apply it. So I like the second option. So let's go ahead and do pack stack dash dash gen answer file. And then the name we want to give that file. We're told to use root answers dot text. Output wise it doesn't generate much. But if I go ahead and them or VI or I didn't install Emacs, I apologize. I'm going to go ahead and edit root answers dot text. We can see, yes, it generated the file for me. And so we can go ahead and look to enter some things. Now there are three keys according to step five that we want to manipulate. At least in our generic quickie at the moment. The first one is config SSH key. If yours is blank right now as opposed to looking like mine, it means you didn't run SSH key gen. So it looks for an existing key, a public key to be able to put in here. It doesn't exist. Well, you did it as the wrong user or you didn't do that step. Further down, we want to do a search on NTP servers. So I'm just going to do a slash and then uppercase NTP to go ahead and search for that. Conveniently that brings me down to the key config NTP servers. And I'll go ahead and add to this the IP address 172 dot 25 dot 0 dot 254. Which happens to be the instructor machine up front, which has been configured to be an NTP server for the classroom. So we can make sure our certificates and our times are all in sync. The second thing I want to look for is configuring horizon SSL. So I'm going to search for horizon slash horizon. I see the horizon host but then right below that there's horizon SSL. And I'm going to change the N to a Y. Now what this says is that we're going to go ahead and for the horizon service configure it to answer to SSL connections. Since I'm going to be logging in with a username and password combination with, you know, potentially the keys to the kingdom of OpenStack. I probably don't want to be sending that username and password over the wire in gorgeous ASCII text. Particularly when I'm doing it from some Starbucks cafe and over there wireless. So we'll go ahead and turn on SSL. Those are the only three changes we were looking to do here. And you'll see on the second page we have sort of a little description of what each of those three keys were that we were in manipulating. But in here there are configuring each of the various components. Which ones we want to enable, which ones we don't and so on down the line. I'll go ahead and save this file and we'll go ahead and kick off pack stack dash dash answer file. And then the name of the file root answers dot text. We go ahead and hit return. Now it's got to initially send the key into that VM. So we need to go ahead and type the password once and remember roots password was red hat. Now it's deposited that key and the rest should be done without intervention. And we wait because this is going to take a little while. I mean think about what it's doing. It's installing the packages of all the various open stack components. It's going ahead and applying scripts to each of those components based upon the values that we have in that answers file that we went through. And yes, there's a myriad of things you can change in there and manipulate. And the stuff you as you saw had some nice comments next to each of those configuration parameters. So you can go through and sort of look at some of those on your own. Yeah. So the IP address is an all in one by default of me. So it's the machine we install the open stack dash pack stack to the package. So it was my own IP. Because you'll see on mine it's 172.25.0.10 because I'm on a zero. Yours will be 172.25 dot whatever your host number is dot 10. That way we're using all the same images and we just pick up IPs as the VM's boot. Now, further down once the install is done looking at your sheet here. What you'll see is that we have various methods of verifying what services are running. And I'll be honest with you, I'm not a very patient man. Just ask my wife. So I'm going to leave that workshop for a moment. And I want you to flip a couple of pages ahead until you see the next practice header. And it should say practice installing foreman. So we're going to get ready to sort of do some things in parallel. Remember I said there were two VM's so in theory I could be doing two things at once here. Well let me go back to my slides for a moment. What you saw here and what we are stepping our way through is the workshop of installing Red Hat OpenStack using pack stack. The section we sort of skipped over is using the horizon web interface. So the idea is once the pack stack install is finished we have this all in one configuration set up on server A. We can then use the horizon interface to go ahead and create a flavor. Go through and ultimately set up an instance running in that all in one environment. And that's what we normally do in section two. So we create the tenant or project, the flavor. We create a user who just has a user role rather than an administrative role to the tenant. And then we create the instance in horizon. So flipping ahead I'm now moving into deploying with foreman. We're going to take a look at doing this on server B. But warning, at the very top of this page it says to do a lab reset VM. Well don't do that because pack stack is running over there. Leave it alone for a minute. Give it some time, we'll come back to it. I'll tell you when we need to do the reset. So sort of skip over that for a moment. We're going to, oh yeah I had to add a step here. So in step one, you'll see that the prompt is server X-B. So we're going to go over to the B virtual machine here in a moment. And you've got this big long yum install command. Well what my cohorts did to me last week is they decided that we shouldn't run on the version of OpenStack that the course was written for. Which was the original REL OSP4. But they wanted us to update to async 3. Which was an updated version of REL OSP4. And it turns out that what's installed by default in REL 6.5. Which is what we're doing this on. The August Libs is slightly outdated. Versus what is shipping with OpenStack. So we need to just manually update that one package. And I blame force. So what I'm going to do is come up here. I need to leave this terminal open and running. So I'm just going to come up to file and open up another terminal. And from that other terminal I'll SSH root at B my number. To get onto that second VM. Password should also still be red hat. So the very first line there is really long. And so if you have a helper next to you. Or if your helper is a better typer than you. Alright. Consider offering up the keyboard at the moment. I can sometimes talk in type. But other times. Do I? Oh yeah. x8664.rpm. Now if you mistype the name of the package or something like that. There won't be really much in the way of a harm or a foul. It'll just come back and go can't find the package. At which point you up arrow and correct. Whatever the typo was. Somewhere in that line. In the real world. Your rel65 system would be subscribed. Alright. To redhat.com. And it would be getting its updates. Or have its updates available. And a simple yum update. Alright. Before installing foreman. Would have been sufficient. Since we're not literally registered with redhat.com. And sucking the life out of the wireless here. Alright. We copied down the one package. To go ahead and do this. So hopefully everybody got that. Update package installed. You'll see a little bit further down there in step one. Another yum command. Which has us installing. Open stack. Dash foreman. Dash installer. Which sets up the foreman master. And because. I refuse to make. Dan Walsh cry. We will also install foreman se linux. And you'll see it'll install. What is it 146 packages. So this will take a few moments. Again this is installing the foreman master. So the picture in foreman. Is not a install pack stack. And install everything on the machine. That I just installed pack stack on. Rather this is a setting up a foreman master. Where I can modify the configurations. Using a web interface. We'll see here in a moment. Then I can deploy out to other hosts. So it's in this one. We're going to have to know our IP addresses. And where we're pushing stuff. And all of those kinds of things. As we go through this. Alright so these packages are installing. Let me hop over to A. And see how that's going. So what's happening with A. Looks like we've got. MySQL. Keystone. Glance. Cinder. All installed. Now we're starting to put some Nova stuff out there. Alright so it's progressing. We're getting there. Let's come back over to B. For a moment. Yeah question. So we are. Yeah so we are using. Red Hat Enterprise Linux. OpenStack Platform 4. Async 3. Alright which is the latest. Released at the moment. Within a couple of weeks. I heard our product manager say. Async 4. In another session. He said that's coming out in a couple of weeks. And we've announced the beta. For 5. Sorry. Huh? So the names are the numbers. So 4 is Havana. 5 is Ice House. Okay. Did we announce. The 5 beta. Maybe I'm telling you news before. The guy out there is supposed to tell you the news. Alright. But yeah. There's a 5 beta. Coming soon. Alright. And a lot of this stuff is sort of shifting with each one. For example in Forman here. That we're working with. I'm working with Async 3. Async 3. Does not include the HA scripts. So if you want to deploy. OpenStack in a highly available configuration. With. Mostly active active. And a couple of services that are active passive. Alright. That's in Async 4. Alright. So the. Videos we saw in another session. From one of our product managers. He was showing off Async 4. And a highly available configuration possibility. He wasn't doing it live. Like we're doing it here. With 40 or 50 of us. Okay. Alright. How am I doing? B still going. A still thinking. We're racing along. Yeah. So. One of the things we do notice sometimes with pack stack. Is that it has some built in timeouts. And sometimes those timeouts are sufficient. To getting everything done. And sometimes they're not. If you get an error. During the running of pack stack. The simplest solution is to hit up arrow. And hit return again. Since many of the services are already configured. The timeout will hopefully. Not happen to you. The second time. Okay. So if some of you are starting to see some of those errors. Go ahead and switch over. It looks like maybe I did too. Yep. Woohoo. I get to play too. Alright. I didn't have to do the SSH key again. So. I already had that. So this will go through each of those services and things. And we'll hopefully finish that one up here. In a little bit. My guess would be is. Given the number of us that are all pulling from the instructor machine. At the moment. Across the network. That this is probably extending our timeouts a little bit. This is a little larger than a normal class. Alright. For us. Question in back. Yeah. Mm-hmm. So. Depending upon the parameters you're talking about. You may find them in the answers file. What I would do is point you to the answer file to see about that. If it's not there. No. Yeah. Or. Or. Do the base with pack stack and then tweak from there. Yeah. Our general goal is really pack stack is more for that all in one proof of concept. You know. Play with it in the lab. Foreman is more of the deployment piece. And you know we'll. See some other things coming in about true. Hardware deployment and that sort of stuff. Coming in new versions of satellite. For example from our perspective. Looks like my packages on foreman are just about done. And I can already see that my pack stack has gotten further. It's up to the finish the API Nova now it's on the regular Nova. So that's looking promising. We're on a verifying here. So we'll continue on I think with foreman looks like it's finishing up first. For now. Yes. We are committed. All right. We are continuing to suggest its use in the all in one. The sort of experimental phase. The longer term I think foreman and the scripts and such that apply with that as a deployment tool. I think is more of our focus. At least that's my interpretation of what I'm seeing. In an open stack development cycle. You know next week. You know I don't know. So yeah it's. You know there's a lot of interesting things happening. But it all seems to be centered around form and scripting. You know so even the the stay puff project that we've started working with to help us integrate it into satellite. You know some of the other projects that are out there that we're helping to contribute to along those lines. I think we are going to just a little bit of a wait and see see which one we as a community. You know all decide to get around and continue forward. But at least from what I've seen foreman seems to be pretty central to most of them. All right. How am I doing. Hey I got a word complete. That's a good sign. So hopefully most of you are getting close to the form and packages finishing installing on B. If you're still in the verifying stage it's not much that I'm jumping ahead here. Step 2 on page 33 has us downloading some parameters. So I'm going to do a quick W get from instructor example dot com slash pub slash materials. Oh you know what I don't remember if I did this in both sides of the room. Well we'll find out here shortly. Well I know it exists in both sides of the room but there's a change here. You'll see in a moment. Do me a favor and cat the resulting file. We're just going to do a room wide double check here as to what I remembered to do earlier this morning. It should look like this. If you have a bunch of other lines. And so since I did this on this side of the room I know you guys are good. The question is over here. You got a few other lines. All right. So the other lines get rid of them. They're useless now. They worked for the original shipment that we had of OSP for open stack platform for. So our initial Havana release. What we had were some shortcuts in the form and scripts that would work off of the private controller IP and the public controller IP. And try to automatically populate the form and scripts and variables with some values. That's been done away with now in async three. And so I remembered to remove the lines on this side of the room. I didn't remove them on this side of the room. If you're on stage left edit the file and you should only have form and gateway and form and provisioning as set to false. Now what are these guys mean. Well this boils down to whether or not we're looking to do actual provisioning. So bare metal provisioning since we're doing VMs that are already installed with Linux. I'm not provisioning that system. So I don't need to install Linux first. So I don't want those services running because it just makes this whole process take longer. So we'll just go ahead and say false to both of those. Actually it should ignore the parameters that are there. So if you were as long as you. Yeah no it's not till the next one. Yeah. No I think we're probably good. So what I need to do is I need to source the file that we've downloaded. And what that'll do is it'll set both of those environment variables for me. We're going to cd into user share open stack form and installer bin. And we're going to run form and underscore. I always do a dash for some reason. Server dot sh. And again the goal here is to set up the form and installer. The master if you will. And so this is going to go off for a while and do some things. Now what you'll notice is a little note on the back side of this page. The use of private controller IP and public controller IP and companion variables has been deprecated. What this means if you're looking at some old documentation is that you're going to have to modify certain default parameters. Which is what we'll do in the last workshop is actually edit those parameters. So the controller private host, the MySQL host, the Cupid host, and the controller public host. Alright so this will work for a little bit. Let's leave this one and I think at this point we can go back to A. Now hopefully you should see some green duns at the top and some nice additional information. Mine says did not create a Cinder volume group because one already existed. Because we already have these on our systems. One of the keys here is the mention of the file root keystonerc underscore admin. This is a file that we will be able to source that will create environment variables of the admin username and the admin password that was used by default by PaxStack. We probably should have gone into the answers file and tweaked the password to something human memorizable and typeable. We did not. But I'm letting you know that that is a possibility if you were to do this in the future. So going back to that earlier exercise of installing with PaxStack. What we have done is we have completed step six which if you look at the bottom it was page 19. If that helps since the stuff is not in binding I lose track of my paper. So back on A what I would like to do is continue with step seven where we are going to run open stack dash service status. And really what we are doing in the last couple of steps here is just showing several different ways for us to go ahead and see some status information. So when I do open stack dash service status I see a bunch of the open stack services. We see neutron up there. I see salameters, cinder, glance, some nova services and we see the various ones that are running. So that is one way for us to check services. Another way for us to check some services is in step eight. But this one I need some administrative privilege. And so the very first step in step eight they have me cadding the file that we are about to source. The Keystone RC admin. And what you can see here is the open stack username, the open stack tenant name and the open stack password. And so that was the password that was in the answers file. So now you can break into my open stack. What I am going to do is I am just going to source this file. Now one of the other things we will notice from the Keystone RC admin is the very last line there was export PS1 to change my prompt. Because I want to know when the things that I am typing have certain administrative privileges. For example, one of the things we normally do in CL 210 is later on in the course after we have created a user and we want to be doing things that don't require administrative privileges, we create a Keystone RC underscore user. And we source that file with the username and the password and then can go ahead and perform those operations by hand. So once I have sourced this file I can now do Nova commands like Nova host dash list. And you will see here it tells me which one is my console, my scheduler, my conductor and my compute node is again the all in one configuration. It is all on A. Another one that might be of interest is to do a service list with Nova. And so this shows me similar information in just more columns. We see the status is enabled, we see that the state is up for each of those services. Another command I sort of like to dump my whole status is open stack dash status. And so this is sort of a combination of the things that I have just done. It starts off listing for each of the services. Well this is all scrolling off a little too quickly here. Let me scroll back up. There's my open stack dash status so we see my Nova services. At some point we probably should fix that dead to be inactive. Particularly since it's disabled on boot. I mean the dead thing scares me. So, but it's disabled on boot so of course it's not running. But there I see the other services that are currently active. Then it gives me a list of Keystone users that have been defined. And remember we have a user name for each service. And that's how the service registers. We'll see any images that perhaps we've uploaded which at this point we haven't yet because this is a fresh install. But if we had uploaded some images we'd see them there in glance. We see my Nova managed host. Just like the service list command we had done a few moments ago. Any Nova networks. Well we're not running Nova networks. There are my flavors. And then it ends with a list of any running instances at this point. So that gives you a little bit of a flavor of different ways we can go ahead and check the status of a now installed pack stack. So that's all good and happy and functional. So let's blow it away. So I'm going to exit from A0. Ooh, forest broke me. He left. Well I don't think this will work. But remember that lab reset VM command? Yeah we need to do that. But I don't know if it works as a regular user. Let's try it. It will in a new classroom environment I just put together. Yeah script must be run as root. So you all need to SU dash on your host in order to reset. The password on your host is not red hat. It's change me. I stole it from Foreman. So again make sure you're on host x. And we're going to do a lab reset VM. Now by default lab reset VM will reset server A. And none of the others. Because you know we've got the Foreman thing going on on B. So we don't need to pass an argument. But if we wanted to reset B for example, we'd have to put server our number dash B. But in this case I'm just going to hit return. This will destroy the virtual machine server zero dash A and reset it. Say yes. Blow that puppy away. Goodbye pack stack. And it's gone. So that first workshop done over with we saw how pack stack can be used to create a simple all in one installation. Just tweaking a couple of parameters in the answers file. It generated a Keystone RC admin file for us so that we can have those administrative privileges to be able to do our various commands and continue to operate with that running open stack environment. So I'm flipping back over to B now. My catalog run has finished. So hopefully a few more moments. And we should wrap that one up. So again this is the form and installer that we are putting into place at this point. The manager. Yeah. This is Havana. How can we tell? Yeah, if I do a yum list installed. Wait for this guy to finish. But yeah. You'll look at the version numbers of the open stack packages. If it's four, it's Havana. If it's five, it'll be Icehouse. Yum list installed. We'll give you a list of the installed packages. All the network stuff forced is going to do this afternoon. I'm going to defer you and make you come back and listen to him. So. But the general idea is the physical host for us right now is being bridged those interfaces to the VMs using traditional Linux bridging at the moment. So then any of the neutron configuration is all being done inside the VM at the moment. Hey, mine's done. All right. How's yours going? Other folks getting the form and installer looking good? Progressing? Good. So I'm going to go on on page 34, which is back in our form and installer operation. I'm up to step five. Now a couple of things I probably should point out. The output at the end of a lot of these scripts, useful information. Sort of gives us a prescriptive, hey, here's the next step as to things we should be doing. So what is this one telling me? Formin is installed and almost ready to use. We'll find formin if we point a browser at server B. The username is admin and the default password is change me. So their suggestion is that you go specifically to that URL and immediately change the password. Well, that's step six here in a minute. So I'll get back to that in a second. Let me finish reading what's here. Once we've secured our form and installer, then there are some parameters that we probably want to be adjusting. Much like we edited the answers file for pack stack, there are some parameters that we need to change here. Now, in the older releases, and what you might see in some of the older documentation is that we could skip some of this because the public controller IP and the private controller IP auto-populated some values in there. And so I could do almost an all-in-one configuration without having to edit much of anything. But if you're going to do all-in-one, do it with pack stack. This one is more for multi-host configuration. There is a file that was placed in temp by this formin installer called form-in-client-sh. And what we want to do is we want to copy this file. We'll do this in a few later steps. We're going to copy this file out to any client nodes that we're going to use and push scripts out to. So what form-in-client does is that it says hello to the formin installer, and then the formin installer will now know about that host. And then you and I can put that host into what we call a host group. But we'll see how that goes here in a moment. So what I need to do is I need to open up a browser. So along the top here I've got Firefox. Let's go ahead and kick that one off. Of course, since this is the first time we're doing this, it's trying to phone home to Mozilla. Go ahead and close that little tab. In my remaining tab, I'm going to go to the website it's suggested, which was server-my-number-b.example.com. Again, we're doing SSL here. This is an untrusted connection. Yeah, I didn't get this registered with any certificate authority. So traditional self-signed certificate that we just click on, I understand the risks, add the exception, confirm the security exception. That's what we've taught all our users to do, right? So once I get past that, we'll do admin, and then again the default password is change me for formin. No, don't remember my password. Now, the output from the formin installer gave us a specific URL we could go to to edit. Let's go ahead and just sort of navigate to there. So we can come up here to admin user, my account, and as I scroll down a little bit, we see a password field and a verify field. We're suggesting that you go ahead and put in red hat. I know, we're going from one secure password to another one. We'll put red hat in and you need to fill it in for both password and for verify. Scroll down in your browser, once you fill those two in and click on submit. You'll see an upper bubble in the upper right-hand corner that appears and disappears saying successfully updated admin. So we've gone through the process of changing the password for that admin account. So what does that get me up to now? The next page, which is around here somewhere. See what happens when it's not a binder? Those are so out of order. Yes, page 36. So again, one of the other things that was mentioned there was the existence of a formin client SH file, which will then go ahead and register a remote host to this formin installer. So let's go ahead and back in my terminal window. Remember when we did the reset of A? Well, now I want to get back into A. So let's SSH back into A, our number. Remember to SSH in is root. And once we're on A, now what we're going to do is copy that formin client file over to this system. So they are in step one. It says we're going to scp root at server our number dash b colon slash temp formin underscore client.sh. And I need a target. So I'll just put slash root to copy it to roots home directory here on A. Remember root at server B's password is red hat. And so you should see it successfully copying the file over to your local system. I'll just take a quick look at this. You'll see it's doing a YUM install of August and Puppet along with some other things, testing the agent, turning on the Puppet service. And so this goes ahead and gets us configured to be able to point to server B you see there under AUG tool, which is the Puppet configurator. So let me quit out of that. It wants us, we need the AUG-US libs before we can install AUG-US. So you remember that nasty YUM install we did earlier on B? We get to do the same thing over here on A. L6 underscore 5.1. Did I miss something? Grab the file so I type it in and examining the files already updated. That surprises me, but I'll go for it. We'll see if the formant client just barfs. Maybe somebody was already on A0 on me on this side of the house and did those steps, which is why mine ran so quickly. So somebody's playing on my machine instead of their own. Remember you're supposed to be on A your number, not A0. I don't really care. It means less typing for me. So yeah, I'll need to mention to you, at the tail end there, you do see a warning. 400 on server, failed to find. And that's because this host doesn't yet exist in the database. It hasn't been assigned to a host group or anything like that in the formant installer yet. So this is one of those chicken and egg things. We need to get the client saying hello to the installer before we can get the installer to start doing things with it. So I am up to step two. And step two wants me to start playing with host groups. So I'm going to do this the easy way. Up at the top where I've got my HTTPS server 0-b.example.com, I'm going to replace users with host groups. And it will bring me over to the list of host groups. If you don't like typing, look under more. That's where you'll find host groups. So what you see here are some standard scripts, predefined sort of deployment scenarios. And so what we have are a controller and a compute, depending upon the type of networking you want to do. So you see I've got a controller for Nova Network and a compute for Nova Network, and then I have a controller for Neutron and a compute if I'm using the Neutron networking. We also have one to set up the Neutron Networker. We have one for setting up different types of block storage, load balancing, and so on. So according to our lab, what we're going to do is we're going to play with the controller and the compute, assuming that we're going to use Neutron for networking. So in the first case here in step two, they want me to click on the controller Neutron link. This brings me into editing that set of scripts. I've got several tabs across the top here. We're going to go to parameters. Now this is sort of a curious web interface, I find. Is that a nice way to put it? So it gives me a list of all the parameters for this particular one. We've got the name and the corresponding value. But if I want to change anything, we've got a button over there on the right called override. And when I first came in here, I clicked on override and expected I'd be able to enter something right there in value. And then I realized, oh, it's down at the bottom of the screen. So I did my first one. I clicked on override. I went down to the bottom to change it, and then clicked on submit and it kicked me all the way out to somewhere else. I'm like, oh, I needed to do more. So here's the sort of game we now play. I have a list of five parameters I want to change. You see here in step two. What we're going to do is we're going to gradually scroll through the list and we're going to click on override of each of the five. Not putting in the values yet. Just click override to each of the five. So I find here admin password. I click on override and you see it puts a little line through the value. That's fine. Override button went away. That's fine too. Let's scroll a little further down and look for the next one. The next one they want me to change is controller priv host. So I got down a couple pages here. There's controller priv host and you'll see the default IP is 172.16.01. That's not the IP address of my machines. We're in 172.25 networks, right? So these are ones I'm going to need to override. So we'll click on override of the private host and we'll click override for the public host too. And then scrolling a little further down, they say the next one we need to do here is the MySQL host. I'm almost there. There's MySQL host which also has the 172.16.01. So the old private controller IP environment variable the public controller used to take care of these for me. Anyway, click on override for that one, MySQL, and then the last one we're doing is the Cupid host. So it's all the ones that basically have the IP address in them. So once I've clicked on override on each of the five, we'll go down to the bottom of the screen and there I see the five of them happily sitting there with little boxes with fields to change. And so because I don't want big long passwords from admin, we're going to change this admin password to Red Hat. And this is where you want to be careful what you're typing. Make sure you match what's in your book. Now 172.25, the private network, there's math involved. I hope you can handle this one. You remember your number. You were say host 12. So your number is 12. In the third octet, I need you to take your number 12 and add 100, making it 112. I happened to have been zero, so my math is really easy. But please don't put 100. Put yours. So that's private. So the private we put up in the hundreds subnets and the publics we put down in the regular subnets. So you'll notice that for the public host here, it's 172.25, just your number, whatever your X is, .10 in the chart there on your page. The MySQL host we're going to do on the private side. So 172.25, 100 plus your number. So does that work well? Now in the real world, one of the other ones you might be manipulating would be your tenant network type that we're using for neutron. We're using the default GRE for this sort of test installation. But if you wanted to use VLAN or something else, you'd need to adjust that parameter up above and push it down here with override. But that's another common one a lot of people might be manipulating. So I double check these all match up with what I see there in my page. I'll click submit and it will have changed controller neutron for me. Step three, I need to do the same thing for compute neutron. Now what we're going to do is we're going to deploy the controller out to server A. That's why it was .10. The compute we're ultimately going to put on top of our form and installer on to server B. So again, we're using form in here not for an all-in-one configuration, but for a distributed multiple configuration. So let's come over on compute neutron. We'll go over to parameters. And again, we're going to play the same game. Click on override to the ones we want to push down. So admin password gets pushed down. Now interesting, we're pointing to the controller for all of these. So we're still using A's IP address. So controller prove host, controller pub host. The MySQL host, which is not as far down this time. Here we want to identify the open V-switch tunnel interface. So we'll click override there because EM1 is not going to cut it. That don't exist. Cupid is the last one. So this time I've got six entries that we're tweaking. So as I'm down at the bottom of my host group parameters, we'll put red hat in for the password. 172.25, remember 100 plus our number.10 for the private. And so we'll get all of these put in. The OVS tunnel interface is the interface we have in the VM, which is in our case ETH0. So again, get it all to match what you see there in the table. And then go ahead and click submit. So this is the basic process. Go on ahead and we have defined some parameters here using this interface. So now what we want to do is we want to map the host group that we've just set the parameters for to a particular host, ETH0. It's on page 37, the back side. So in step four it says we're going to map the host group to our machine. So they want us to browse over to the host tab. So up top I see dashboard host, this is the second thing there. And see I've got two systems, A and B. So I'm going to go to, let's see, which one am I doing first? So it says find the server A machine. So I click on my server A machine, I'm sorry, and we're going to click on edit to edit that host. And you'll see at the moment my host group is blank. So I'm going to go ahead and choose controller neutron because I need the controller before I do the compute. And we'll go ahead and click submit. Now what this means is I've now scheduled a deployment to server A. And server A, since it's running puppet, will periodically phone home to server B and go, hey, you got anything scheduled for me? So how much time you got? Yeah, not that much. So I'm going to go over to server A in step five. It mentions that by default the puppet agent will only check every 30 minutes. Yeah, well we're going to speed that puppy up. So I'm going to manually run the agent, puppet agent dash TV on A. Client already in progress. Somebody's doing this on my machine. So, huh? Yeah. So that's off doing its thing. My agent is running. Once the controller is finished, we can go back to the form and dashboard, go back to host, and we'll deploy the compute neutron to server B. But we need the controller running first. All right, so we have to wait for this controller to finish. And this will take a few minutes. But then we can go ahead and pass along to compute. Ultimately, we should be able, once the installation is done, we should be able to open the regular open stack dashboard to HTTP colon slash slash server R number dash A and be able to go ahead and manage using horizon and see those nodes in action. So I'm going to leave you all to finish up those last couple of steps, all right, which will go through and get your horizon pieces all running. So perhaps up this particular lab that we're going to go ahead and do. So our goal here was to take a look at the installation processes for Red Hat Enterprise Linux OpenStack Platform 4, which again matches Havana. We've seen the use of pack stack to create a quick and dirty all-in-one prototype. We've also seen how we can use the form and installer to go ahead and push these scripts, push this activity out to your different systems. So finish this up and then I guess it's lunchtime, right? How'd I do? When was I supposed to finish? 12.45. And this will take another 10-ish minutes of deployment. So, ha! Yes, questions? Well, actually, you're on this side of the room. So you're doing it to that machine that I actually wasn't on. Ooh! Fascinating, all right. So, yeah, right. So because the zero A, all right, is in the zero subnet, so the third octet is zero rather than 15. So that's why that was happening. Virtual machines on your system, yes. Yes, by default, the puppet agents that we deploy here with form and client will be checking and phoning home every 30 minutes. Right, so we can redeploy with form and it can wait 30 minutes or you can do like we're doing the puppet agent-tv because we don't have the patience to wait. Well, all the ones that are there within the GUI, all right, within the installer GUI. So there are probably some things that are not mapped into form and at this stage. Right, if form, yes. It could revert some things on you, possibly. Yeah, question? No, step six can be skipped, but what step six is doing is verifying that your A is fully deployed because you're able to launch the horizon web interface. So, and you need to make sure that you're fully deployed before you do step seven. So, yeah, yes. So the pre-configured scripts that you see there for the host groups, you can be defining your own host groups, contributing them back to the form and project, you know, and that sort of stuff to extend all of this beyond if you want to. Make sure if you're grabbing our stuff that you grab async four, do very, very shortly. Okay, if you've got async four, then we will give you four predefined environments, whether you're doing Nova or Neutron, whether you're doing HA or non-HA. All right, so those are the two different configurations. Now, I will tell you that the HA scripts that we're providing are very prescriptive. It's a three-node configuration, all right, for your controllers. That I'm not 100% sure of. I know that many of the services are active-active configurations. A couple of the services are active-passive, because they don't support active-active yet. For example, I know off the top of my head, Cupid does not support active-active configuration, at least what we have. Right, so RHEL OpenStack Platform is our productized version. Upstream of that is RDO, all right. So in RDO, which is, and somebody correct me if I'm wrong, but it's openstack.redhat.com, all right. If you go there, it's redhat.com slash openstack, one of those. But if you go to RDO, we will have things there earlier. We have packages available there for both CentOS and Fedora. It depends on the version. So, you know, for example, I would expect RDO might have Ice House packages before we've productized it, because that's sort of how stuff gets tested. Sort of like Fedora does for RHEL, you know. New technologies tend to get introduced into Fedora first, and if they're deemed enterprise-worthy, or we've got customers demanding them, all right, we find them moving into RHEL. You know, this form and stuff is all appearing in RDO, typically, before it appears in RHEL. Deploy Just Keystone. I don't know of a predefined script for doing Just Keystone. Yeah, so again, what we've given you in the package are those prescriptive host groups. And so, now, it's all open and there, and you can see the stuff under the hood, so you're more than welcome to write your own prescriptions and add your own host groups that might break that out if that's what you're interested in doing. Okay, well, go ahead and finish this up. As you see fit, when you're done, just leave the machine on. Leave it logged in. Please don't close the lid or shut the machine down or any of that sort of stuff. Just leave it up and running. We have scripts that are going to go out on all that you've just done. And prepare for the next session on Neutron.