Good morning, and thank you so much for joining us as we close out our Part 2 series of Winter is Coming, Get Ready for Year End Giving. I am your host and your chat facilitator, LaChica Phillips, and today's presenter is Michael Stein. Michael Stein has been a writer and a digital strategist to progressive social causes for more than 20 years, and we are really, really glad to have him to present today. We also have helping us with chat today is Susan Hope Bard. If you have any technical concerns or any issues, feel free to chat your message out, and we will handle any issues that you have. Again, thank you so much, and happy Friday to everyone. And as I mentioned, this is Michael Stein, the digital strategist, and again, my name is LaChica Phillips. Before we get started, I want to make sure that everyone is comfortable using ReadyTalk. So again, as I mentioned, if you have questions, even if you have questions during the webinar, questions that you have for Michael, feel free to also chat those in the box, and we'll be sure to address those as well. Please also know that if you are on the phone, all of the lines are muted, and you must be online to chat. Also know that if you, for any reason, you lose connection, no worries. Simply rejoin the webinar by using the same link as before. And also, once the webinar is over, you will receive an email with links to today's presentation as well as recording. And be sure to check out our website, our new website for all of our upcoming webinars at TechSoup.org. And as always, if you are on Twitter, please tweet and share what you are learning today. You can tweet us at TechSoup, or simply use the hashtag at TSWebinar. As some of you know, for those of you who are not new to TechSoup, you know that our mission is to build a dynamic bridge that really enables civil society organizations and social change agents like a lot of you that have joined us today to help you all gain effective access to all of the resources that you need to design and implement solutions for a more equitable world. And we are doing all of this outside of the sunny and bright San Francisco this morning. And we are really curious and we want to know, where are you joining us from? So if you will please take a second and in the chat box, this will also help us to see who has any issues chatting out or using the chat box. So simply just tell us where are you joining from? Wow, we have learners from all over. I see Mexico and New York City and Washington D.C. We really, really appreciate you all joining us today. And all of the places that you've listed, I've even seen Nashville, that's my hometown. Thank you all so much for joining. But I really want you to be aware that this map that you see before you and all of the places that I've mentioned and all of these places that people are chatting out, this is where TechSoup, all of these places that you see in the shaded blue area, these are the locations where TechSoup provides and facilitates donation programs. This is pretty massive. And what we do is we partner with companies like Microsoft and Adobe and Cisco and all of the companies as you can see here listed right before you. We partner with them and they help us to be able to provide all kinds of technology and resources from our website. And so what you can do to learn more, again, go to TechSoup.org. And I always recommend check out the nonprofit favorite section. So if you haven't had a chance to check out the new website, TechSoup.org, and there is a new section there it's called the nonprofit favorite section. So be sure to check that out. So Michael, as I mentioned, this man, he is just a wealth of knowledge. And if you joined us for part one, then you know that you are in store for even more information to really rock out the rest of this year with your organization. But for those who are not familiar with Michael, he has authored three books and he has written several articles about the rise of digital marketing, mobile, and online fundraising. He is also a contributor for our TechSoup blog and he also works as a consultant to coach other nonprofits and foundations and educators. So again, Michael, thank you so much for joining us and take it away. Thank you so much, Leshika, for that introduction. And hello everybody. This is Michael Stein coming to you from Northern California. It's great to see where everybody else is from on that list. So that's great. Today we are going to spend the next 25 minutes or so talking about year-end giving with a focus on digital strategies. And I hope that some of you were able to join us for part one on November 17. And I actually wanted to start by doing a very quick review of what we covered in part one just to set the stage. And I'm sure not all of you were able to be there. So here's what we covered in part one. And first we talked about planning for Giving Tuesday. And I hope that many or all of you had a successful Giving Tuesday campaign. If we had more time I'd love to hear more about it. I know that Giving Tuesday can be challenging as a fundraising event. But I still think it's an important opportunity for nonprofits. And I hope that many of you were able to take advantage of that. And last time we talked about preparing your website for year-end fundraising. We talked about the importance of putting content on your homepage with clear calls to action and headlines. And we also talked a lot about pop-up light boxes and other ways to feature content on your website. The third thing we covered was creating an email appeal series. And just the importance of doing that across the month of December to create a story and to bring your donors along for that experience. The fourth thing we talked about was the importance of engaging your donors on social media and really the importance of doing multi-channel messaging in the year-end. And then the fifth thing we covered was just the importance of measuring everything you can just so that we can learn as much as possible year to year. So let's quickly talk about what we're going to cover today. We're going to talk, first of all, about finding good spokespeople for your fundraising appeals. We're going to talk about using a challenge match to encourage giving. We're going to talk about promoting monthly giving in addition to one-time gifts. We're going to talk about mobilizing your email so that they're easy to read on mobile devices. And finally, we will close out by talking about the importance of optimizing your donation pages since that's where the money comes in. Great. So our first topic today is finding good spokespeople for your year-end fundraising appeal. And I still think this is really one of the most critical elements to good storytelling at the year-end. And being able – you're obviously going to write good appeals, but it's really the storyteller, the person who is presenting it, I think who is really important. And this person speaks for you and is going to represent your work. And I just think it's really important to focus and find good folks to do that. And the question you're really asking yourself with these people is, who can speak for you and really inspire your donors to give? So I think your traditional folks that you're going to be using as spokespeople are going to be executive directors, they're going to be someone on your board, or they might be a project staff. And this example actually over here on the left, is kind of a good example of a project staff. But I also just want to encourage you to be creative about spokespeople. Maybe there's someone, a community member that you've worked with, a partner. Maybe there's like a volunteer who's been really active in the community and represents your work. And maybe there's even a donor who can also be a spokespeople and an author, either an email or have a picture on the website or something on social, maybe even do a video. So really I just encourage you to be creative and really just try to be authentic as you're coming up with your spokespeople. Another couple of examples, I always love this Jeff Bridges one from No Kid Hungry. I know not everyone has access to celebrities, but always an example of how to put people just front and center in emails when you're doing fundraising. And here's two other examples from Mercy for Animals. Again, just the importance of figuring out how to put their voices front and center, and to connect them to the work that you're doing. So I think these are good examples that I wanted to showcase for you. Okay, let's go on. Our second topic is the importance of using a challenge match at the year end. And the reason why we see so many of these challenge matches, frankly, is because testing has shown us that it really works. It really makes an impact. It catches people's eye, and either in the subject line, or in social, or in other places. And the important point is that you just want to get people to make gifts. And there's going to be lots of people who are going to be ready to give at year end. And then there's going to be folks who are on the fence and not quite sure. So really the purpose of the challenge match is to get people to give a little bit more, and then also to get people to get off the fence who aren't thinking of giving you a, yeah, let me give a small amount because I know that it's going to be doubled. Also matches can work at kind of a different giving level, and it's important to sort of think a little bit about how to frame that. This example, by the way, over here on the right, which is from the plowshares one a few years ago, was actually for kind of a mid-level appeal to people on their file. So someone gets $75 to get doubled, et cetera, et cetera. But these are slightly higher giving levels. So this is what I mean by if you're just going to your main donors, or to people who have not given, or people who are last donors, you may want to use examples that are a little bit lower, like a $10 gift gets us $20, or even a $5 gift gives us $10. So it's important to think about the giving level. And of course, challenge matches, you can use those. You want to promote them throughout your different channels that you're using. Email on your website, on your social channels. And let me show you a couple of examples to inspire you a little bit. So here's a challenge match that I love which was used by Berkeley Humane a couple of years ago. I thought this one was super clever. Well, first of all, it wasn't just a double challenge match. It was a triple challenge match that they rolled out just for one day which I thought was very smart. And then in addition to that, they were just able to, in a very kind of clever way, kind of focus on the animals in the case of dogs and to tie it in. And I just thought that was nicely done. And they tied in clearly like they need the money especially at year end because they have more animals in their shelters. And so I just thought the call to action was really strong here. Here is a quick example of a pop-up light box that features the match challenge. This one is from, sorry, the name of the organization does not appear, but this is International Medical Corps. I thought this one just was nice the way it kind of blends the call to action with a photograph. I mean, I tend to like it when these headlines talk a little bit more about the value proposition and what the money goes towards. But I think the image is obviously strong enough and they are going out to the International Medical Corps community. I think people in that case know a lot of what they do already. The other place that is important to promote the challenge match is like on the donation page which is actually a super important place to put it that people are either clicking on an email or they are clicking on social. They have gone from a light box and they end up on the donation page. And so this is a good place to remind people of how they are going to get doubled. In this example, they are getting, I don't know, are they getting 3 for 1 or 4 for 1? I think it is actually a 4 for 1 match, but it does say 3 for 1. Anyway, but just a good place. This is an example from Defenders of Wildlife and it is just an important place to feature the match. Our third topic is the importance of promoting monthly giving during the year end giving season. And this is really an interesting topic for me recently just because monthly giving, in other words people not just giving a one-time gift of say $50 but giving a gift of $10 a month which is then repeated every single month. It is just one of the fastest growing types of charitable giving and the reason why of course it is popular is it gives people the ability actually to give a little bit more but to spread it out. So in these kind of lean times where people are giving to multiple charities, it is really a great way for people to give. It is very convenient. People can put it on one of their debit cards or a credit card and it runs automatically and people feel like they can make those gifts all year round. And of course, the other from when you are managing a donation program, obviously you want, it is nice to have bigger gifts at once, but the data shows that when people give smaller monthly amounts, then their value as a donor typically goes up. They tend to become donors longer. They stay longer on your file. And then you typically raise more money from those individuals. So again, the importance in monthly giving, it is important to try to, even when you are doing it year end, I mean when you are asking for a year end fundraising gift you do not have to just say make a gift of $25. You can say make a gift of $25 or $50 or give us a monthly gift and help us all year round. So you can really kind of massage that language a little bit to make that really, really interesting. And super important to remember on the donation pages. So let me give you a couple of quick little examples here that I think are useful. Here is a good one which talks about becoming an investigator ally, donate monthly, and in fact they are combining a match with the monthly gift which is actually kind of a pretty clever kind of approach there as a solution. Here is a good example of promoting monthly giving on a donation page. So this is actually a Giving Tuesday campaign as you can see here. It is from the No Kid Hungry Organization. And they have the one time button that is already highlighted, but they are also very clearly promoting monthly giving right here as I am highlighting for you. You can see the text. I hope you can see this that a monthly gift does even more to help hungry kids which I think is a really good way to promote monthly giving within a year end campaign.  So in a perfect world that gives people a lot of great choices. Another example, I have a couple of other quick examples of using pop-up life boxes to promote monthly giving. These two examples that I have here are not actually from the year end, but I think that they are just inspiring examples of how you can talk about making a monthly gift and the importance of just highlighting whenever possible, even during the year end time frame. And then finally, another approach that I have seen people use to promote monthly giving campaigns at the year end is just to talk about it as a goal. So you don't only have to talk about we need to raise $10,000 this year end. You can also talk about we need to find 100 or 200 new monthly donors this year end. So this idea of creating a monthly giving campaign within the year end framework is something that I am seeing more and more of. You can do it at any time of the year but obviously the year end season I think is a perfect time to do that. And I certainly encourage people to give that a try. Our fourth topic is the importance of mobilizing your emails. In other words, making your emails mobile responsive. And I think this is particularly important during the year end framework, the year end time frame, principally because there is such a deluge of email that are being sent out to prospective donors. And more and more people as you know are reading their emails, browsing their emails on their phones. And so the importance of having mobile responsive emails is just critical of doing a little bit of testing. If you create an email, make sure you have people on your staff or some volunteers who can get a test message and can tell you, gee, the image at the top is too small or the text is too small or I can't see the links or the buttons are not visible, just all that kind of testing is important. There are some platforms that you can use like Litmus and Email on Asset if you want to really get into the nitty-gritty of mobilizing emails but even just doing some basic testing on your emails is super important. So this example, I'll show you on the next slide. I've got a couple of examples just to talk a little bit. So you've got this corporate accountability example on the left, this Teddy Institute and another corporate accountability. Again, these are just three classic examples of how to keep emails very simple with the design, very easy to read on mobile devices. This one on the left here as you can see doesn't have really any images at all. It has a button at the bottom. It's got links throughout the text. This one is going to read really nicely on a mobile device. The one in the middle, a little bit more fancy. It's got images. In fact, it even has a video at the top that's embedded here. You'd have to click on it which then takes you to a website to see the video. But as you can see, everything is centered in one column. And this is going to look really nice on a mobile device. And the same thing with the one on the right, it's again all single column. But again, I think just ultimately the importance is making sure these headlines are really easy to read, making sure that there's single column, that there's no fancy grids and layouts and stuff like that. And just to do the testing and to do it with a couple of volunteers or with your staff that are using some different types of phones, different types of different sized screens. And I think that is going to help you get better performance out of your appeals. People are going to be more happy to open your messages in the future. And then when they do open them, you're going to get more clicks on these links and hopefully raise more money as a result. Our fifth topic, an almost final topic, is just the importance of optimizing those donation pages, making them as good as you can. Because this is the end of the funnel. You're messaging people on email, on the web, on social media. People are clicking on your links. They're clicking on your email. They're getting to these donation pages. And this is where you still have an opportunity to inspire people to give. And it's important – well, a couple of things. One, it's important that when they get to the donation page that all the messaging and all the visuals and everything that's there is matching the fundraising messaging that you've got as they're coming from other locations, from the web, from email, from social. So your headlines should be the same. The images should be either the same images or similar images, but it should all kind of interconnect nicely. Certainly the photos, I believe donation pages should have really strong photos to create good emotional feelings among prospective donors. And anytime you can sort of reduce the clutter, keep these donation pages as simple as possible, those are all going to be elements that are going to improve your conversion rate and lead to raising more money. Let's take a couple of quick looks at a few of them. Here's a really nice one from the International Medical Corps. I really love this headline and value proposition here at the top of this page. You are instantly reminding people why that donation is going to save lives and relieve suffering around the world. I think this is really helpful. You've got a strong photo here. You've also got examples of the impact that their donation is going to make on the work. So this is a terrific page. Here's a nice one also from CARE just recently from their recent Give Me Tuesday campaign. I really love the way that they do this little feature mission statement and show people where the money goes towards.  I think they are always just trying to make sure that that's clear out there. So these are nice ones here. Here's another really nice donation page recently from the National Museum of African American History. They were doing a Giving Tuesday appeal which included get this wonderful hat to show your pride in the museum. And they have hat on the donation page which I think is just so important. You are connecting the dots with the donor. When they get here, they are seeing the gift that they presumably were interested. So I think that's nicely done. And then here is another example from Fruits and Friends. I just think this is nice and big, clear design. Boy, is this a nice, simple donation page. I don't know what platform they are on but I think this one is going to look super nice on mobile devices and hopefully lead to good response rates and lots of good fundraising. And then I will just throw in a quick bonus 6th topic because I always like to talk about measuring things and just want to reinforce the importance of measuring and capturing analytics and data. So the key things are certainly what worked this year, what worked better than last year. So you are just trying to understand year over year where the differences were, which one of your e-mail appeals raised more money. You want to compare issues like the money you've raised, the number of donors that gave, and then the average gift and help you to draw some conclusions about how different appeals on different dates had better performance. Hopefully if you've done the monthly donor recruitment or promotion, that is probably an important area to be measuring. Did we get more monthly donors this year than last year? What did we do differently? How can we improve in the future? You certainly want to look at your different audience segments and just understand which audience segment did best. I mean you may be dividing your audience in various ways. They could be small donors, lapsed donors, old donors. They could be your monthly giving donors. They could be mid-level. They could be non-people have never given. So you want to look at performance across all those different areas. Or you may be measuring performance by how you acquired people's e-mail addresses if you did it with a certain project or with a partner. You certainly want to be measuring profit to your donation pages if you can. How did people get to your donation pages? If you can measure people who came from e-mail click-throughs, people who came from social media promotion, or people who just came just to your website completely organically, if you can measure those different types of traffic that gives you a wealth of information that helps you learn about what's working for you. And then if you can measure it, the conversion rate on your donation page, in other words, of the people who reach your donation page, how many complete a donation? I mean, the average, believe it or not, is way below 50%. Only half the people who get there are going to give. So this is a good measurement item and for you to keep learning about. And then finally, just always focusing on understanding how your social media presence is impacting your revenue. So if you're able to have like one donation page, for example, that's just for click-throughs from social media that would allow you to track that, for example. So I think that's another really useful thing to be measuring. And that gets us all the way to the end. So I will thank you and turn it back over to LaChica or Susan for any other items we want to cover today. Wow, thank you again, Michael. Thank you so much. Again, another day of a lot of information for all of the learners and the organizations that have joined us today to really go back to their office and maybe pull one item from your presentation today and possibly implement for the year-end. Now we do have a couple of questions before we close out. You mentioned a platform for mobilizing the emails. Can you repeat that? Sure, there's two platforms. One is called litmuslitmus.com and another one is called emailonacid.com. I know, a strange name. I didn't make it up. But both of those are places where you can upload an email and then it will show you how the email will be rendered and viewed on different types of mobile devices and different types of emails which are really useful to understand how your emails are going to be perceived on mobile. Okay, and the other questions, I think we have two more questions. A couple of questions about the match. From where will the match challenge come from? The money come from? And then he's asking will they have to line up someone to actually match the donation amount? Someone else is also asking about advice on how to get match donors. Sure, so typically a challenge match is obtained from one of your larger donors in your community. So it might be someone on your board. It might be someone who is a founder of your organization. It might even be a business partner or it might be a funder. But basically it's someone who steps forward and says, yeah, I want to put a $5,000 gift or more or less. And I want to challenge people in the donor community and I'll match all gifts up to this amount. And so therefore you can use that as part of the messaging. I've seen oftentimes I often see boards, board of directors that step forward to offer that kind of stuff. But I've also seen businesses do it as well. So they can come from various different locations. Okay, now Joanne here, she brings up a great point. She says that nonprofits associated with ministry are exempt from matching gifts. So she wants to know if you have any thoughts or suggestions on what they can do. Yeah, that is a good question. Yeah, I don't know. I probably turned to her and asked her for some ideas. I mean I would imagine that there's other strategies at your end that may work best. But I was not aware that that didn't work. I was not allowed in the ministry. Sorry about that. Okay, and we will send the links out. You will receive a recording. And Michael, can you go ahead and share your contact information if anyone wants to reach out to you? Yeah, I think probably the best thing would be to reach out to me either on Twitter, or on Mstein63 on Twitter. Or you can just go to my website which is michaustine.net. That's michaustine.net and there's a way to message me, contact me over there. Okay, thank you so much. I do see a couple of other questions coming in and we will email you the responses to those questions. We want to go ahead and realize that we are a little bit over time and we really want to respect everyone's time and appreciate you all for joining. Again, Michael, thank you so much for all of this valuable information. And before we go, we do have one second if the people who are participating today, if you want to chat out one thing that you've learned, a takeaway from today, or if there was something that you feel that your organization can take and implement today, or maybe even next week, feel free to share that out. We would really, really want to know what you're planning to do with this information and if it has been really valuable for you. So before we go, I want to show you the upcoming webinars that we have. We have one on December the 19th. It's actually part 3 of a series for libraries going deeper with social media. And then when we come back for the new year, we're going to get started on January 9th with Adobe Design. And you're going to learn tips and tricks for your next annual report. And then later in the month, we're going to give you some information and give you a great tour of our GrantStation program. And then we'll follow up on the very next day with even more information about GrantStation. So thank you so much everyone for joining us. We will follow up via email with the link and recording from today's webinar. And in the meantime, don't forget to check out the TechSoup.org website. And you can find our upcoming webinars and our archives here at the link shown on your screen here, techsoup.org, 4 slash community, 4 slash events dash webinars. And thank you again to our webinar sponsor, ReadyTalk.


Alright. Hello, good morning. Thank you for joining us to talk about leveraging CICD to improve OpenStack operations. My name is Maria Bracho. I'm Product Manager for OpenStack at Red Hat. I'm Dan Shepard. I'm the Product Manager for Rackspace Private Cloud, powered by Red Hat. Alright. Thank you for joining us right after Keynotes. We're excited to be here, excited to have you here. I mix up two companies working together at the open source way and to the light developers and you guys that make OpenStack better. So we're going to talk about bringing OpenStack all the way from upstream to the customer in a continuous way. So keeping track of OpenStack changes is a little bit like counting stars. So there's plenty of developers today here at OpenStack Summit. There's plenty of developers committing right now. And I bet some of you are thinking, how can I keep up with all this change? And will my API still be there tomorrow? All good questions and very difficult to keep track on. Testing OpenStack individually is very hard and it proves that it's not, it's probably a futile effort because it's really hard to keep up with it. So it comes in a joined way of developing OpenStack and testing OpenStack. And this is what we came here to talk about with you today. So both working with upstream OpenStack, with a Red Hat OpenStack platform and with you, our customers, our partners and the ecosystem at large. So what we do in our development process really is have our delivery team come in changes upstream and then those changes go into a version control. And once they're in, it triggers a build and unit testing of those changes. If they pass, then we move through. If they fail, they go back to delivery. We check them, we test them again, move them up and see once that wall passes, it goes into Red Hat's QE environment. So quality engineers test it into multiple deployments and deployment architectures. If it fails, then it goes back to the development. And the same thing goes through. Changes happen. We improve the changes and the patches that we submit. And once it passes QE, the idea is that we then distribute it out to our partners. And that is before we go and announce that this OpenStack version is GA. And why are we doing this? So we found partners that are eager and waiting to test every little change that we make to OpenStack before we announce a new release. And the reason is they want to make sure that we know, and they want to make sure that they know all the changes going in. They can test it against their own environment and they can certify faster. For us, we want to make sure that we're testing OpenStack in the use case that we care the most, which is really our customers and our partners. Our QE team tests hundreds and hundreds of different architectures and different deployment scenarios, but we can't really cover the one scenario that we care about. And that's why we partner with folks like Rockspace to be able to deliver to them pre-release deployments of OpenStack. And then once that is ready, then we're ready to announce a release. We know that the release that we announce is really tested not just in-house, but also with our larger ecosystem. And this is what we're calling distributed continuous integration, our ability to deliver pre-release versions of OpenStack to our larger ecosystem of partners and customers and be able to receive feedback from them before we actually go and release. What DCI is trying to do is really change the way that you interact with us Red Hat and with OpenStack in general. We have seen that happen in our relationship with our partners. It really doesn't change the work that we do because we've been working together to build OpenStack anyway, but it really changes the way that our conversations go. So before it's like, did you deploy it? Did it work? Did it not work? How did you test it? Where did you see the fall? Can you help me report a bug? To really elevate that discussion to, oh, here are the logs. And this is my DCI deployment, and this is where it failed. So we really elevate the conversation to direct troubleshooting and not fact finding. So like I said, latest OpenStack builds get shipped over into our partner sites and our customer sites. They test in their own environment, which we have no control over. And it really speeds up the time for certification. So if you're a partner and you're trying to certify a specific plugin on the Red Hat OpenStack platform, it would be, it would behoove you to try DCI because it allows you to see the changes faster. You're testing hundreds of times more than what you originally would test just to prepare for certification. The idea is that you're continuously testing and then you're continuously certifying your solution. It simplifies the upgrade process because, as you know, Upstream has a six month release cycle and from release to release, a lot of things change. A lot of projects get added, APIs may be there or may not. And you don't want to find out what happened after the release. So think about it. If today you're testing OpenStack, so Newton, as it was just released, think about it. If you don't test a new version of OpenStack until the time Okada is released six months from now, all those changes that are being discussed right here at Summit that have been discussed at mid-cycles and will be discussed in the next mid-cycle, you're going to have no idea how that looks on the code, how that looks on your infrastructure if you're not continuously testing that. It's a shock factor and a surprise factor to test after the fact. What we're trying to say is you should test a lot sooner, you should test continuously and you should automate your tests. DCI also provides automated feedback to Red Hat on the test that happened on our partner environment and that's awesome. So here's what DCI looks like today. And let's just say from the line to the right-hand side of the screen, or the left-hand side of the screen, it's Red Hat environment and upstream all the way to the left. And to this side is Ruxmas environment. So like I mentioned before, we can see a more code from upstream from the OpenStack foundation. You would notice I just changed it to the new logo catching up right after the keynote. And we port it from upstream and we create what we call our downstream repost. Whenever we think that we have a release or a pre-release OpenStack kind of ready to go, we put it in a DCI repository. And then after installing a DCI agent on the Red Hat side, on the Ruxspace side, sorry, we've been working so much together that it's interchangeable at this point. Now, after installing a DCI agent on the Ruxspace environment, this agent picks up every new release and all these new changes and then orchestrates the deployment using Red Hat OpenStack Director of an automated deployment of an OpenStack cloud, including both the under cloud, the director node and the over cloud with the infra nodes. We also orchestrates that and we run a battery of tests that can include things like Tempest. If you're familiar with that testing framework for OpenStack, Rally as well, another project of OpenStack. We run BrowBeat, an excellent testing framework that is also sponsored or folks from Red Hat work on that. And we also run a battery of tests that form the Red Hat certification test suite and any other partner or customer-specific tests that you want to run can be run with DCI. After all these tests are done, the results get ported back into this DCI repository so that we can have access to the logs. And then DCI also presents them in a user interface where testers and developers can see what happened to this new version of OpenStack that we just got released, this pre-release version, what failed, when it failed, how do those failures look like, why did it fail or why did it pass? And it allows you to test multiple different versions of OpenStack. So right now, well, I'm not going to spoil your part. You can tell us which ones you're running, but you can run multiple versions. So what we're trying to do at the beginning, we said keeping up with OpenStack is kind of like trying to count stars. It's hard and the more you count, the more they show up. And you really depend on what kind of instrument you're using to count those stars. What we're trying to create here is not to remove that because that complexity is going to be there, but we're trying to create something beautiful that we can do together. And with that, I'll leave it to Dan to tell you a little bit about OpenStack. So that brings Rackspace Private Cloud powered by Red Hat, a product we launched back in February that leverages Red Hat's OpenStack platform for us to take the Red Hat distribution. We wrap fanatical support around it, and then we deliver it to customers as a managed service. And anyone who's familiar with Rackspace knows that fanatical support is really what we're about and taking code from upstream or from Red Hat's distribution and then applying our practices around it to give customers something that is truly differentiated and production ready. So before DCI, we would build our cloud for our customers. We would test every version as it was released from Red Hat, and then we would run these 1,600 tempest test cases manually. So someone had to log in, click the button. Well, someone had to build the environment, then log in, click the button, watch the run happen, get the results, figure out what failed, why it failed, and go through all of that to figure out if we needed to raise a request with Red Hat, or if it was something in our configuration or where that problem really existed. So every time we got a new version from Red Hat, then we had to re-kick the environment, leverage a bunch of scripts to get everything stood back up, and it took us literally weeks of testing from the time Red Hat would announce the GA of OpenStack Platform to when Rackspace can announce the GA. And then once we got done with that, then we had to go back and do the same set of testing all over again for upgrades now. So with DCI, we were able to take those 1,600 test cases, run them automatically, they run daily against a build that is automatically configured from DCI, and anytime there's a failure, it automatically creates a log file, raises the request, sends it over to Red Hat so that their QA team can get involved and start checking it out. With that, we were able to go from what was about a month between a GA announced from Red Hat to a Rackspace announced for a GA down to right about two weeks. In fact, with OSP9, I think it was 12 days, so very much able to shorten our timeline just because we have access to an automated testing tool. So what does testing look like at Rackspace? 1,600 Tempest tests, you can see kind of over here. What it looks like, they run through. Our test cases right now are all upstream. We're currently developing some Rackspace in some of our customer-specific test cases, but everything that we're running right this minute is upstream test cases. Some of the things we're working on developing the additional test cases around are really more for our monitoring agents, some of the custom use cases that our customers have for their very specific workloads so that we can further validate and make sure that those key scenarios that customers are providing to us are going to work every time we get a new build from Red Hat. So why do we do all that? It really comes down to all clouds are unique. OpenStack means custom. We're all here because we all have some sort of private cloud that we've probably customized in more ways than we want to admit. We have hardware variations, we have networking changes, everyone has a different use case. So with all of that, you really end up with complicated deployments. Even at Rackspace where we standardize and use reference architecture and build based off of our own best practices, all of our customers end up being unique at some point. Whether it's in their data center, whether it's on some hardware stack that we're not running anywhere else on any other customer, everyone ends up with some unique thing. So having the ability to get to a point where we're testing that unique thing in an automated fashion is really important for enabling us to accelerate adoption for our customers and keep moving them to the latest and greatest OpenStack. So in addition to that, as Maria indicated, we have a lot of collaboration between Rackspace and Red Hat.  How do we do things better? So building on that DCI comes out, we start using Rackspace hardware in the Rackspace data center, but Red Hat's managing the deploy force through the DCI tool, so we've given them the hardware, they're running the deployment scripts. We come in with our test cases, those result in bug zillas for Red Hat to go squash, we don't even have to pick up the phone and call them, we don't have to create log files, it's just there. We can just track, hey, these bugs are moving forward all well before a GA happens from the code, from Red Hat upstream. So the end result really comes down to Rackspace testing, Red Hat patching, and then Rackspace verifying what has been patched all before a customer ever even knew there was a chance of having a problem in the next release. So in, sorry, my turn. In the nutshell what we are doing, what we're trying to tell you is testing OpenStack manually is a bad idea. Automating your deployment of OpenStack is a good idea. Automating your tests of OpenStack is a good idea, and not only is it good, it's gonna save you a lot of time, even though it's a lot of time consuming to actually do it, it's gonna save you a lot of time in the future, it's gonna help you keep up with the pace of OpenStack. And as Dan mentioned, not only we're just collaborating with Dan and Red Hat and Rackspace to make OpenStack better, but we also have another list of partners that we're doing the same thing with. So who benefits? It's really OpenStack. Every time we test with a partner and we find issues with a partner before RGA release, we're able to make those changes sooner in the release cycle, and sometimes those changes actually get merged in the release cycle that we're testing in, which is fantastic for our customers, for our partners, but for OpenStack in general. I mean, we all talk about it quite a bit with software developers, right, and anyone who's working directly with developers in your organization. Developers are out failing fast, they're creating test-driven development, trying to test early fail often. It's applying that same method and mentality to your infrastructure.  You get to see every day, you get a peace of mind of knowing that things are failing or things are not failing, and hopefully you start off with a lot of failures early in the release, and by the end of the release, right before GA happens, nothing's left that's failing, but generally that's getting to that point earlier is very interesting for the engineers working on OpenStack and for your downstream customers. Yeah, and also the way that Red Hat works is obviously upstream first for us, and what we're trying to do is get to a release of a new upstream-based OpenStack distribution, and we want to do that release a lot faster, we want to test as much as we can, like I said, in the use cases that we care about the most, which is our customers and our partners, and we want to sort of bring also the customers and partners closer to upstream to start working on the latest and greatest as soon as possible. So we talked about distributed continuous integration, so in a nutshell, we shipped this packages before their GA ready to customers and partners. So what is the next step? Also is enabling our customers and partners to build OpenStack the way OpenStack Infra builds OpenStack. So income software factory, so host your own OpenStack in front. If some of you are OpenStack contributors, you're familiar how OpenStack Infra works, you've probably heard about Garrett and Sewell and others, and know that the gating process of building and testing OpenStack is what drives this wonderful code. So what we're trying to say is we're packaging an OpenStack Infra-like environment on your own data center, so that you can test and build also your own changes and patches. So if you look at this graph, it's pretty similar to what I showed you before, where we send you this Red Hat pre-release version of OpenStack, but also we now give you the ability to build your own changes to OpenStack using software factory and then deliver those to DCI, so DCI can also run the deployment of that change that you did and you can leverage the same tests that we're doing right now. And you can do that sort of interchangeably or intermittently, one time coming from OpenStack, another time bringing in your changes, maybe one of them running Red Hat OpenStack version 8 or then 9 or then 10, and then testing your own changes on 8 or 9 or 10 if you're so wish to support that and see how those behave. And this is the UI of software factory. It basically, if it looks a lot like Garrett, it is because it is. And then also leverages and integrates all these other tools that help you build your own, either patches or changes to OpenStack or to your own distribution. And so then what now? So we want to enable the customer directly. We want to be able to let customer handle their configuration as code, make this, given the customer's a Garrett infrastructure so that they can build their code that way and test it out that way and use DCI as a gate for testing and making sure that passes that CI gate before you commit a change and then merging. And then at the same time from a DCI perspective have used DCI to provide the continuous delivery of those changes, testing your workloads, leveraging the test cases that you were already testing with, whether they were your own tests or some that were provided by Rehab. And so what's in it for me? What's in it for you? What's in it for all of us? How do customers and partners benefit? You can track and test all of your changes, can validate, use their changes, can be your configuration, can be new code, can be simulated workloads, whatever you're doing. And you can integrate with tools like Browbead, which I mentioned before, so do even more rigorous testing and benchmarking your changes, seeing how your OpenStack Cloud behaves at some point and then before the change and then after the change and then after a certain amount of time, after that change, and really just give you more data to work with and make decisions with. And how does OpenStack in general benefit? You were basically allowing for the OpenStack 9 release, which was metaka-based, and for the OpenStack Newton release, which is gonna be Newton-based. We were giving feedback from customers and partners that we never gave before, mainly because that testing happened manually, that feedback happened a lot slower, and we just didn't have a way to automate all these changes or to test as many times as possible because testing OpenStack manually takes time. I remember the first time that we had DCI up with Rackspace. In a weekend, we basically got more data and more test results that Rackspace had gotten in months. We went from executing maybe a test every couple weeks, just because of resourcing and time from having an engineer working on it to we could get two to three in a day. So, all of a sudden, this feedback cycle started happening and we were giving poor people like Gonnery, who's sitting in the front row here, just piles of data that would have taken us weeks to come up with on the old system. And Gonnery's now trying to figure out, well, how am I supposed to parse this and find what's meaningful to change first?  So, but that's his problem, not mine.  Like it's good problems to have. Similarly with Rackspace, we also had other partners that were interested in DCI because their main focus was not producing a fanatically supported cloud, but actually operating their own cloud. And their feedback was, well, we needed to be Red Hat certified. And in order to go through all the process for Red Hat certification and all the tests that the Red Hat certification require, they had to spend a lot of time and a lot of resources. And by resources, I not only mean sort of dedicating their data center to do that, but they had a team of over six engineers, including a project manager to orchestrate when the test will happen, when will they come to fruition. It took them almost three to four months to achieve certification. And we release every six months. So the cadence wasn't really aligned and catching up was hard. So the first time that we did this with this other partner, their feedback was, well, now what are these six engineers gonna do? And our reply was, get them to automate some more tests to put them in. So all very, very good feedback. And of course our partners now say, okay, now that this is solved, here's this other problem. We have more data. We want to parse it. We want to make smarter decisions with it. We want now these changes to make it into this release because you already have the results so go to the mid-cycle and push for this change. So all great things. We were able to take our engineers and send them out to go talk with customers and start building those test cases against the customer use cases that we didn't necessarily have full vision of before because there just wasn't time. So now we have customers going out. We have engineers talking with customers trying to understand more of the use cases so that we can pull them back into DCI and create more of those meaningful tests and get more data back upstream for gonorrhea to figure out how to handle. So is it open source? It's my name Maria, of course. The source is over here. It will be provided with your slides, tick picture, and you can get to that. Both DCI and software factory are open source. Some of the developers are here. Raise your hand. And that concludes our session. Do you have any questions? So one of the questions that I've heard is what about using DCI against upstream OpenStack as opposed to using packaged Red Hat distribution? So what we're doing, what we can do is it definitely run DCI against upstream and package upstream or RDO, which is a package distribution of upstream and do that sort of at the beginning of the cycle because at the beginning of every cycle we don't necessarily have a release candidate ready or as often as we do at the end of the cycle where we have many release candidates ready and open multiple times per day because we're sort of committing a lot faster. At the beginning of the cycle, there's a little bit of a lull trying to figure out what changes we wanna commit, what changes are coming. Maybe those are not even passing testing so it's really not meaningful to deliver those to customers and partners but maybe they want to see, well, what's going on upstream. So we can start distributing RDO which is really upstream packaged and then we can start seeing how that behaves on that environment. The idea is that this is a test dev scenario, is a test scenario. So if the CI fails, it's okay. We just wanna see where it fails so that we have a heads up that we need more testing, we need to look more into these changes, we need to look more into these APIs, et cetera. So yes, we can test against upstream. Any other questions? I can keep going. Yeah, yeah, yeah. Do you have a question? Yes, hi. So the question is, how does the CI help post GA and how does it make upgrades easier? So post GA, we don't really have a concept of a static code post GA. We may say this is a release nine but later after that there might be bug fixes, there might be security patches. That release nine or 10 version is not steady. So you'd still want to continue to test on that one. So that is helpful that way. Another way that is helpful is we have partners that develop applications on top of OpenStack. So you want to make sure that that OpenStack is there, sort of running underneath and then you test your applications on top of it and make sure that with each changes that happens in OpenStack on a certain release, bug patches and fixes, that application sort of remains whole too. And then how does it help upgrade? Well, imagine this, once you have DCI running with OpenStack nine and you have been continuously testing with all the changes that we're pushing between version nine and 10. If your CI is sort of passing, then you know that you're gonna be that much closer to have a passing OpenStack 10, for example. The idea is that we don't ship you a whole new version. So we don't give you here's OpenStack nine, here's Red Hat OpenStack 10, but we're giving you hundreds of little incremental changes to that so that we ease you into the upgrade. And then from a Rackspace standpoint, we treat upgrades as kind of two pieces. There's does the next version of OpenStack meet all of the requirements for our consumers and for our operators so that we can say, yes, this is something that is production ready and supportable. Answering that question is what we're leveraging DCI for. The next part of that question is, is what happens during the upgrade process and does that break anything? So right now we leverage DCI to shorten that cycle of, is this ready for our users? And then we come in and run a manual upgrade behind that to say, okay, let's validate that the upgrade process works. And so we take our 1600 test cases, we run a smaller subset of those, then we do the, before we do the upgrade, then we do the upgrade and then we run that smaller subset again. So the idea there is, we ran 500 test cases, we had 495 passes and five fails before, we ran it again at the end, we had 495 passes and five fails, so things are the same. So it becomes this two stage process. So you'll see there are times that we announce, hey GA is ready, all new deploys will be the next version and then it will take another week or two before we'll announce the upgrade path. It's because we're going back and retesting and maybe working in partnership with Red Hat to fix something that went wrong in the upgrade process. And we really rely on this feedback. How do you manage? So the question is, with growth of CICD test cases, you're creating really a longer running test scenario. So the answer is you'd run less builds in the day and if we found that, hey we're not getting through all the testing we want to get through, we would potentially add a second CICD environment to split that workload. We're not there yet, but if that's a good problem to get to, that means I have lots of testing happening and we have a high confidence in what we're building. So right now it's early and we're still building our first set of kind of customer use cases. I expect patterns to emerge there and eventually I'll get to a point where the customer use cases won't necessarily require additional scripts, right? It'll be, oh, we'll just flag customer X on the script that we created for customer Y, so. So I think you asked also about different kinds of customers and how do you manage that growth? So once we had DCI open running with Rackspace, one of the ideas that came actually from Laren from Rackspace was, well, now I have all these different customer deployments. Can I have a DCI agent running a specific deployment for a specific customer where you only run the test cases that are relevant for that deployment? And then can I have that going? And our answer is you can have as many DCI agents running as many different OpenStack architectures per customer and then limit your test cases to whatever's relevant there. The number of test cases is gonna grow. I mean, OpenStack is growing, they're building more things. Those things have a test case associated to it. So that's the problem that's gonna continue to be there. Did Laren pay you for that shout out? I mean, he's back managing a support team in San Antonio, so I thought maybe he paid you for that. No, he didn't, but we find that with Rackspace and I can say Dell because we also announced with them, Dell is another partner that is doing this. They actually give us a lot of new requirements because now they have seen this. It's like they have seen the light, like, oh, this is great. And it freed their minds from a lot of other busy work and it seems like their minds are just as busy just creating other busy work, not busy work. You know what I mean? Just figuring out all the problems to solve and to continue to make OpenStack better. Yeah, so our development team for DCI is actually right here. So you can really talk in depth about that but I can tell you that when I approach a partner or a customer and they ask me about, I want to install DCI, what do I need? Really what we tell them is we need this DCI jump box that can be a VM. So our footprint in your data center is as big as a VM. And then everything else in terms of how does that deployment look like can be as many nodes as you have in your OpenStack deployment and it can have, it can be a mixture of virtual or bare metal and if you want to certify, for example, sender plug-ins, well, you're gonna need to have the gear that goes along with that but we don't tell you that there's a bare minimum. In fact, I have some partners running, certify their software SDN plug-ins and so their OpenStack deployment is 100% virtual. So this thing is just VMs. For Rackspace, the most complicated part was figuring out how we were going to get the director built out inside of our existing deployment process for bare metal deploys. So once we worked through that, which was just figuring out, oh, how does orchestration happen now and how do we make sure that we keep our tools in alignment, it was very easy after that. Yeah, to have access to Rackspace hardware we found out was hard because they want to keep their hardware up and running 99.9% of the time. Any other questions? Hi, the question was how much time is it between an issue found on a customer side and then the patch or the fixed scene upstream? Well, isn't that the question that we all want to know? And the answer is like, it depends on the patch, right? It depends on what the issue is and how we're tracking it. I tell you though that with DCI, the time it takes to actually report that issue upstream is a lot shorter because we're finding it sooner. And then if you find it during the development cycle, say if somebody commits a patch during, for example, right now, the Okada cycle, I'm able to send that patch over to Dan in Rackspace and we see that failing. That is logs that we can just push upstream and say, hey, this failed here. So think about that before it actually makes it to the product. So that time, I can tell you it's faster. The time to fix it, it's another thing. It could be, yes, if we're using, for example, RDO, like I cannot tell you that a patch that lands today can be in a week in one of our puddles, in one of our pre-release versions because we do a lot of that testing ourselves. So it may be that we catch that bug before it goes to our customers. So it may not even go there. And in that case, we report it upstream right away. And it may be- When the stars align. And it may very well be that somebody at Red had made that freaking patch that then messed up in the customer, which is what we find, right? Because we test the patches that we made in our own gear, as well as all the third-party ACIs from upstream. But we tested on our gear, but now we're just, honestly just extending the QE environment that we have to have our partners too. And in the case of Rackspace, some gear in the case of Dell is a lot of gear. So, and we're expanding it to other partners as well. Two questions. How long does it take to run each build? Using DCI. And then the second question is, how long does it run a patch of the build, or does it run the whole build? Okay, so the first question is, well, it depends on what kind of open stack you're deploying. So it depends on how does your environment looks like, right? Oh, for the 16,000 test case. So in your specific architecture, how long does it take to run a build? Once everything's built out, the run takes, I wanna say like 20 minutes. And then it takes a little bit longer for us to look through the logs and make sure that everything ran and pulled the file out. So maybe an hour total. The deployment, no. So the deployment in front of that, we basically get close to two runs a day right now from build the environment, run all the test cases, collect all the logs, build the next environment. It's gonna vary it on the number of nodes that you're building, right? And we're building on physical nodes. So everything gets redeployed. And the hardware we're using is not bleeding edge hardware by intention because we are trying to support a wide variety of use cases, right? So.  Yes. No, so the question is, does it run just a patch or does it run it from the beginning to end? And the answer is, right now, we run it from beginning to end. That's a good use case to just run whatever change. But because we do the orchestration with director, we just sort of test the deployment and do it all over again. So any last question? I think we're out of time. Thank you so much for coming. And I hope you have a great open stack summit and walk a lot and enjoy the week. Thanks, everyone.


When everybody thinks about Texas history this is the first and last thing they think about is what happened on March the 6th of 1836 here outside of the Alamo. In fact just across the street there is the cenotaph. This was commissioned in 1936 during the Texas centennial to represent the heroes that fell at the Alamo. But the real victory happened 220 miles away on the banks of the San Jacinto river where Santa Ana and his forces were defeated by Sam Houston and his Texian forces. And without this victory we wouldn't today be learning about Texas independence. The Texas revolution started in 1830. We tend to normally think about it starting at the Alamo but it actually had its origins before then. We talked in the last lecture about people who were moving into the Texas region from the United States brought along by people like Stephen F. Austin and other empresarios. If we look at the period 60 years before the Texas revolution you have the American revolution. And the American revolution this enlightenment ideology of people determining the government influenced other revolutions who all looked back at the American revolution as a starting point being the French revolution, revolutions in Mexico and other South American countries that we talked about a few lectures ago and certainly the Mexican independence movement. The Texas revolution was part of that revolutionary timeline. And here are some of the images of Texas that I mentioned earlier. The Cenotaph Pompeo Capini built this in 1936 to celebrate the centennial of Texas independence at the heart of the Great Depression and also the Alamo which is right across the street. But we have to go back further to look at the roots of the Texas revolution. I mentioned a few lectures ago about freebooters who were coming in filibusters who were coming in to try to take Texas the region that's now Texas away from Spain and later Mexico. One of those was the Fredonian rebellion. This happened around Nacodotus in 1826 where several brothers the Hayden Edwards and his brothers led a rebellion against Spanish rule. Stephen F. Austin actually came in and helped to put that rebellion down. He led the military force that came in to put the rebellion down. A few years later the Mexican army sent General Mayor Iterán to Texas in order to figure out what the boundary was. You remember back in 1819-1820 there was the Transcontinental Treaty the Adams and East Treaty that said the boundary between Spain at the time and later Mexico at the time would be at the Sabine River on the east and then the Red River. Well it's all one thing to say that. It's another thing to actually mark out that territory. In those days they didn't have GPS they didn't have satellite imagery so they actually had to go look and mark the land and record the territory. And that's what Mayor Iterán was doing in 1828 and he passed by through Texas and he saw various Anglo settlements and he reported back that the idea of them becoming Catholic and becoming true Mexican citizens didn't seem to be taking place. They weren't learning Spanish either. And so in April 6th of 1830 the Mexican government passed the law the Bustamante Decree that you'll find in your primary sources that began restricting further immigration from the United States. This led to a series of disturbances by recent immigrants who were upset at these and other regulations that were coming from Mexico. The troubles began in earnest at Fort Anahuac which is on the eastern side of Trinity Bay just east of Houston. And it was there at this fort this fort that was there to collect duties on imports and exports coming into the Texas region. A military garrison there captured two runaway slaves because the law in Mexico was against slavery they were going to free the slaves but people like William Barrett Travis and others were upset about this and demanded the slaves be returned to their owners. The Mexican commander was not willing to do that and so this caused a lot of problems that just continued to escalate and show the divisions between the centralist powers and the federalist powers in the regions around Mexico. The problems between the federalists and the centralists these two factions of Mexican political groups would further exacerbate the differences between white and Mexican settlers in Texas. At the turtle bayou resolutions were drawn up and these were protesting some of the actions of the Mexican government. And this led to two conventions one in 1832 and another in 1833. Your book will detail these more but it was a convention of 1833 that actually decided that the time to separate from Mexico was a possibility. And so this is a timeline of some of the events of about 1835 to 1836 and you see starting in August of 35 the Texas settlers began organizing committees of safety and correspondence much as had happened in the American Revolution. Mexico sent general cost to land at Copano Bay by Victoria to come in. One of his duties was to go to Gonzales and retrieve a cannon that had been loaned to Texan settlers there. And this starts the whole come and take it event. Between October and December of that year you had the battle for San Antonio and this was an attempt by Texians as they call themselves to gain control of San Antonio which for many years had been the seat of colonial authority away from the Mexican government there. A permanent council is organized and at the same time you have the consultation what it actually does start moving steps forward closer and closer to open rebellion. By January you have an expedition called the Matamoros expedition and this are a group of Texans who go down and invade Mexico and it ends disastrously. At the same time the so-called runaway scrape begins. This is when settlers are beginning to fear hostilities and to begin to flee western parts of Texas. This is around San Antonio and move further and further east toward the Louisiana border in case outbreaks of war do occur. Houston at that time also orders destruction of the Alamo. Of course we know that didn't happen. William Travis decides to take Fort Anahuac in June of 1835 and then you have these other problems that occur these other situations that occur. You have the siege of Beja. This is a battle for the Alamo and you have war and peace parties going on in Texas. Some American settlers want peace others want war and want independence. The siege of Beja. This is in San Antonio this was laying siege to the Alamo and the surroundings. In the events of 1836 on the timeline we again see in February Travis arrives at the Alamo and then you have the battle of the Alamo in early March. Soon thereafter there is the massacre at Goliad where James Fanon and about 325 people are killed after failing to retreat and then finally in April you have the battle of San Jacinto. Right before the battle of the Alamo, Texas assigned the Declaration of Independence and one of the great ironies is the people of the Alamo had no idea Texas had actually declared independence by this time. A lot of what we know about the Alamo is Hollywood legend and myth. So we don't really know what they did if there was a line drawn in the sand or any of these other Hollywood conventions we often see in portrayals of the Alamo but we do know that they were fighting to maintain that piece of territory. Houston is appointed commander of the army and the Texas Constitution is adopted. Finally the battles the fighting ends at the battle of San Jacinto just to the east of Houston where the San Jacinto and Buffalo Bayou come together. Afterwards we have the Treaty of Velazquez there's actually two treaties and the runaway scrape comes to an end. Going back to the Alamo, the Alamo is really a battle that should have never have happened. Sam Houston as commander of the military forces had ordered the evacuation of Texans from San Antonio. However once Bowie got there, Jim Bowie got there and was ordered to destroy the Alamo he decided not to and Travis arrived later on and they both decided to stay and fight.  Once Santa Ana arrives in San Antonio and lays siege he offers them several times the ability to surrender and to leave but they refuse to take it and thereafter he does order their the overrunning of the Alamo and their execution. Fan at the same time takes La Bahia which is today we call it Goliad outside of Victoria and the mission and fortress there and he too refuses to leave. And so the death of these people at the Alamo and at Goliad these soldiers these Texians led to these two battle cries remember the Alamo remember Goliad. The government declared independence as I said earlier on March the 2nd and the battle of the Alamo happens on March the 6th. Houston receives word later on from some survivors some of the women and children and slaves who were held up in the Alamo and hiding were allowed to leave after the battle was over and they ran ahead and people ran ahead and told Sam Houston. Fan and surrendered on March the 20th to Eurea's forces and although they pled for the lives of these Texas soldiers Santa Ana ordered Eurea to execute them and this is the site of the so-called Goliad massacre. While the Alamo shouldn't have been defended in the first place and they should have retreated those who stayed and fought actually gave Houston time to train his troops and to get them prepared for battle. They trained up around Hymstead at a place called Gross's Plantation and then they started moving towards Harrisburg in south Houston near Harris Elementary around April the 12th in order to prepare for battle. Houston wanted to draw Santa Ana further and further east there was a hope maybe that US forces would intervene and also that he would stretch out his supply lines and Santa Ana took this bait and moved toward Harrisburg hoping to catch the Texan government. He encamped upon the San Jacinto River and once Houston learned of this he moved in close. The battle of San Jacinto took place on April the 21st Houston attacked and the Mexicans were routed in a matter of minutes many of them were killed. Houston only lost a handful of men. What ends the war are the Treaty of Velazquez. There's actually two treaties and the governor of the time David Burnett and Santa Ana met near Freeport Texas to sign these treaties. The Mexican government rejected the treaty which had called for recognition of Texas independence and land to the Rio Grande largely because Santa Ana was a prisoner of war at the time he signed it. So their argument was that international law did not recognize the head of a government being held as prisoner to sign treaties that he was signing under duress and so it was seen as illegitimate and Mexico did not accept this treaty. So at the end Texas remains according to Mexico still a part of Mexico while Texians believe that they are independent. This is a painting that hangs in the capital of Santa Ana's surrender and you see Sam Houston laying there injured after the battle at San Jacinto and the painting is meant to capture the glory of the surrender. A few days after the war was over two New York land speculators the Allen brothers bought land here and very quickly they would name the settlement after the hero of the war Sam Houston. Today Houston is a monument to the work of the Allen brothers and it's part of Texas history.