All right, ready? All right. Hello, everyone, and welcome to the session. Today, we're going to talk about OpenStack at scale inside NetApp, our trials and tribulations. Mansi and I both work in the NetApp product operations division. And hopefully, you're in the right room today as Wednesday, April 27th, 9.50 AM. So a little bit about us before we get started. Good morning, everyone. And thank you for showing up to do a morning for this session. I'm Mansi Prabhavalkar. I have been working as a systems architect at NetApp for the past two years now. I basically deal with all things OpenStack inside of our engineering-shared infrastructure services organization, or ECIS, as we call it. Before NetApp, I was doing my master's in computer science from NC State University. You can follow me on Twitter. My Twitter handle is at MansiP11. And hey, I'm David Kane. I'm a reference architect, technical marketing engineer among many hats at NetApp, the Bachelor of Science degree in computer science from NC State University. Go Wolfpack. Go Wolfpack. And I have about 12 years of data center experience. A little bit different in my role at NetApp. I evangelize NetApp storage products. Specifically, I sit in the FlexPod Converged Infrastructure Engineering division. But we're both in the core engineering division at NetApp. If you'd like to follow me on the Twitter's, my Twitter handle is there. That's the Dave Kane. So rather than a generic boring agenda slide, we have a timeline that we'd like to take you through for this presentation today. And with that timeline to take away from this slide is about a year and a half worth of great work internally at NetApp. We've segmented the presentation into four distinct interjection points. The first, we're going to give you a little bit of a background about our internal organization, which runs OpenStack. How we got started with OpenStack and really what we do and a little bit about some of the infrastructure bits that we have there. We're going to talk about Puppet, a little bit about some of the automation that we initially wrote and deployed in Research Triangle Park, North Carolina. We started our journey with OpenStack. Once we got there, we started doing automation of that through non-disruptive upgrades to the Keelor release. Then we went big with globalizing OpenStack at NetApp where a global company and we have labs all over the world. And once we did that, we globally did an upgrade of the Liberty release. After all that, we're going to give you some future steps of where we're taking our cloud next. But first, a little bit of history and a little bit about the organization. So let me tell you briefly what we do as an organization inside NetApp. We are ECIS, we are a global engineering shared infrastructure services organization that handles around nine R&D lab sites across the world and have a huge customer base of 5,000 customers. So our customers are basically NetApp engineers, QA testers, software developers who test out our NetApp products inside our infrastructure so that the products that ship out do not have any bugs in them and the other customers can benefit from those. So out of the 130 team members that I work with, eight of us currently support OpenStack inside our organization. Again, we are customer zero, so we consume the NetApp products before they ship out to our customers. So we try to be at the bleeding edge of technology by implementing pre-release NetApp and partner solutions. We also provide seamless resource delivery so that we can drive innovation inside NetApp. And keeping this in mind, we introduced our internal private cloud GEC back in 2013. So this is a global engineering cloud as we call it, which is operational today at five different sites across the world.  And these resources are processed by a workflow engine at the back end that talks to the various different hypervisors that we have in our environment. So currently we have VMware, Hyper-V, and the recent addition of KVM on OpenStack. Right, so that's a little bit of a background as to what the organization is. Now what about some of the infrastructure that underpins the cloud that we're talking about here? So a little bit more about the global engineering cloud inside of NetApp. At a glance, at a high level, we have about a 75,000 total VM capacity in that cloud, and that's comprised of those three hypervisor platforms that we mentioned earlier, VMware, Hyper-V, and KVM. Of that entire capacity today, we have about a 9,000 VM capacity worldwide comprising inside of that cloud there. So we checked right before we came out here and did this session, just exactly how many live VMs we had running right now servicing real workloads inside of the organization being used by our devs and testers who had about 3,600. Now, of the entire capacity that we have inside of the global engineering cloud, 15% is KVM, 45% is Hyper-V, and 40% is VMware. And this is an infrastructure as a service play. Remember the portal that Monzi mentioned? That's where the developers and the QA testers and everyone goes to a single place to select resources for their various job functions and roles. And they don't care about which hypervisor they get, they just want their resources and we just provide them. Right. So some of the hardware bits that underpin it because if you don't have infrastructure underneath that your cloud does not function very well. So to that end, we internally at NetApp utilize a FlexPod data center like architecture there. And what's a FlexPod for those that may not be familiar or aware of what that is? It's a joint technical engineering effort between Cisco and NetApp. It's a converged infrastructure platform. So it's storage, networking, and compute. So from the compute side, it's the Cisco UCS unified computing system. From the storage side, it's our NetApp FAS and or E-Series storage platforms. And from the networking side of the house, it's Cisco Nexus 5000 or 9000 series switches. So what about the automation bits that we have inside of this cloud? As I mentioned earlier, we utilize Puppet. And why did we choose Puppet over all the other various Chef, SaltSack, Ansible? We were most comfortable with that. We had a previous investment internally orchestrating some of the VMware and Hyper-V bits. And so it was a natural choice to begin our journey there. We utilize Jenkins for continuous integration, continuous delivery, and of course Git where we store our Puppet manifest as code, infrastructure as code to be consumed later by those other eight folks that work on OpenStack internally. Why OpenStack? Well, as Moncie mentioned, we're customer zero. We need to provide infrastructure services for all of NetApp that serve as a basis point for, our customers do development and deploy solutions in OpenStack. So we need to provide those same services internally there as well. And from a development perspective, NetApp has been a member of, as a chartered gold member of the OpenStack community. And we've been involved since the Folsom release in OpenStack in continuous driver development. All of our drivers are contributed upstream so you can take advantage of those today. So it was a natural extension to begin that and have those resources internally at NetApp. Now that you heard about the bits inside, now a little bit about the architecture that we've deployed. Now the technical stuff. So it all started back in August 2014 when I first joined at NetApp and this was my first project ever. So I'm very much close to this one. So we had decided to implement OpenStack inside our organization. But before we got started, we wanted to define a clear use case for it in our environment. We didn't want to do too many things at the same time and just get lost in there. So our goal was to deploy OpenStack as a part of the GEC workflow. In order to deliver VMs, we are the KVM hypervisor. We still wanted our GEC portal to work as the user front end. And we wanted OpenStack as just a package for the KVM hypervisor at the back end. So now we had to come up with an architecture which was production worthy. So we started off with phase one, which was the all-in-one controller. So in this phase, we hosted all of the components of OpenStack onto a single machine.  So we found out that the Keystone and the Horizon components were very chatty due to the token creation and everything and were overloading the controller node. So we went to phase two. In this phase, we decided to split out the Keystone and Horizon components and host them onto dedicated separate machines. This allowed the controller node to be relieved of all that overloading and it could focus all of its processing power on the more important VM operations. But now that we had a stable architecture, we wanted to make it fault tolerant as well. So we achieved this partially by going to phase three, which was HA services. In this phase, we spread the Keystone and Horizon components across three different machines and put them behind a pair of active passive HA proxy load balancers. Now the only concern remained was the controller, which was still a single point of failure for us. This takes us to the architecture that we have today in production. So far, we discussed the Keystone component, the Horizon component, and we also added a highly available GaleraDB cluster to our environment. Now to address the controller issue, we decided to adopt regions architecture. So let me explain what regions are in OpenStack. A region is its own deployment of OpenStack that has a central authentication service and a shared dashboard. We tailored this architecture to our needs by also adding a highly available GaleraDB cluster, as I mentioned before. We stamped out a region with one controller node, one database node, one MongoDB node, and 15 compute nodes. This allowed us to make our architecture modular and allowed us to scale by adding more regions to the environment that shared the same Keystone and Horizon components that were pulled out in the shared region, which was termed as region zero. So now let me tell you what the GaleraDB database hosts in our environment. So it hosts our Keystone database, which is again pulled out in the region zero, and it also hosts our Glance and Cinder databases because they are shared across our different regions in the environment. This allows us to have a shared image store as well as a shared Cinder volume across all the regions. And as you can see, the Glance and Cinder services still reside in each of the Nova regions, but they have the same database back end which is pulled out in our shared region zero. So let's talk about Nova and Neutron services.  So how does this help us? This helps us to scale out by 1,000 VMs at a time, and it gives us a starting point to start off a region with 1,000 instance capacity. Also our 15 compute nodes are backed by the same shared NetApp NFS back end, which allows us to live migrate VMs between the different compute nodes within a region. This greatly helps us during our non-destructive upgrades as well as when we want to put a compute node in maintenance mode. Let's talk about how this is highly available for us. So as mentioned before, our users go to the GEC portal in order to request for resources and they don't really see the OpenStack dashboard. So they don't know that there is this region thing going on at the back end. So when the OpenStack request comes in, it gets routed to any of these regions in the environment depending on their capacity score as well as their health score. So if a region is in maintenance or it's full of instances and is not able to process anything further, then the request gets routed to the other operational regions making it highly available for our customers. Okay. So now that you guys are familiar with our architecture, let's talk about what all we learned during this phase. So first and foremost, we learned that some of the keys of some of the OpenStack services can be bit chatty and we decided to make an early on decision to host them onto separate servers. Also, as an OS monitoring tool, greatly helped us make this decision and helped us get to the production stage very quickly as well. Also, using regions architecture, we can scale out in capacity by adding more regions to the environment as well as scale up in capacity by adding more compute nodes within that region. It also gives us a good starting point with a thousand VM capacity in each of our regions and it allows us to know about our scaling model because we know that if you want to add more capacity, we can always scale by thousand instances in our environment. And the most compelling reason why we went to regions architecture was its similarity with the VMware and Hyper-V architecture that we already had in our environment. So operations is a huge part of our engineering organization and we wanted them to be more comfortable with what we were doing with OpenStack. A region in OpenStack is synonymous to a vSphere or Hyper-V cluster of 15 compute nodes that we already have in GEC and this made our operations team a bit less skeptical in adopting OpenStack as a new addition to our team. Also segmented operations. So region is a smaller OpenStack deployment in itself and so it's easier to support or troubleshoot if something goes wrong. So you just have to worry about those 15 compute nodes if something goes wrong within a region which is a good thing to start off with. And that's what regions architecture helped us to do. Also, it allows us to add multiple generations of hardware within our environment. So being an engineering organization we keep on getting new gear and we keep on replacing our old gear as well. So we have some regions which are the newly added regions that are pretty faster than the older regions that we have. So the regions that are with the latest hardware have more processing power in them which allows us to add more compute nodes to the environment and gives us more VM capacity within those faster regions as well. And the multi-region approach allows us to do non-disruptive upgrades but I don't want to spoil that right now. We'll talk more about that later. Okay, so some advice for you. I know Moncy touched on a lot of those points and some of the lessons that we learned on this initial stage but really from a monitoring perspective, set expectations early, do a walk, crawl, run type mentality. Hopefully the timeline of this presentation accurately reflects that. So in the first stage, test things out, make sure that the services through maybe your already existing processes where you already have virtualization deployed internally in your organizations today. Make sure to monitor those with tool sets like Zenos, Nagyos, those are a couple good ones but you may have something you already have deployed there. Don't reinvent the wheel there and break out those busy services but monitor them at the same time. And as I mentioned, infrastructure matters. For us utilizing a convergent infrastructure like FlexBot is very, very easy to in tandem with the multi-segmented region architecture that we have for the OpenStack services, it's very easy to do the same with the architecture or the hardware services involved with the compute nodes. We can easily add compute nodes to the environment which I'll talk about here in the next slide selectively to those OpenStack deployments or those regions that we have there as well as storage. It shouldn't be rocket science to add storage to a OpenStack deployment. Just add a shelf to it. It's a modular-based architecture in FlexBot and you're up and going and ready to go and a lot of that really helps us with our constant upgrades that we have. We upgrade firmware. We upgrade firmware on the compute nodes whether the storage operating system has new firmware code or even new hardware like Monci mentioned. The architecture needs to be able to support that and even most importantly at all if your users don't notice that you're doing upgrades constantly there's less phone calls, less tickets and less headache. If you design it on the initial onset to cover upgrades and scaling, you'll sleep better at night. So now let's talk about automation and upgrades. So as I mentioned, converged infrastructure, FlexBot, we've got to start with a base before we enable some of that puppet automation that we hinted at earlier. So as Monci mentioned, there's a slash 22 network that we have that we augment and implement on a multi-region basis. So as we mentioned, we had VMware and Hyper-V in the environment there. We had a series of automation there that would spin up VLANs inside of the resulting architecture that 802.1 Q VLANs to support the eventual instances that we're gonna create. So create those VLANs on the top of rack networking switches. So next we spin up NetApp FlexVolumes for Cinder and Nova Storage. So FlexVolume can be thought of as an abstracted virtualized storage concept similar to how VMware abstracted compute resources in the data center. We at NetApp have NetApp FlexVolumes there. So it's a storage presented to the both Cinder and Nova nodes for the eventual consumption, but it also hosts our bootlines. So we do stateless booting for those that may not be familiar with that. We boot all of our compute nodes via iSCSI, all hosted on the NetApp storage device that we have inside of the FlexVolume architecture. And so what we can do is we've been really good with snapshots at NetApp for a number of years, our copy-on-write snapshotting technology, it creates instantaneous copies of golden bootlines that we have. So think of it the same with VMware where you create a golden template for your VMs and then you customize it afterwards. We do the same thing in this infrastructure. We have a golden REL7 image that we deploy onto the compute nodes. And that FlexVolume technology that I mentioned, we can clone a 20 gig image in 0.3 seconds. So it's very fast, it's an instantaneous clone of that. Now we assign Cisco UCS service profile, which is the compute node, that eventual node or that bootline so that it can come up seamlessly. Now Puppet takes over. So we use Puppet open source for automating deployments in OpenStack. And so this is our Puppet master, which represents the knowledge and the code that is necessary to spin up a production environment based on the architecture that we discussed before. So based on that, we have eight different roles in our Puppet master. The first four roles, which are web, load balancer, Keystone and GaleraDB make up our shared region zero. Whereas the last four roles, which are controller, compute, database and MongoDB, those make up are Nova regions. So when a node is fed to Puppet after assigning it the bootline and the service profile, it gets one of these roles assigned to it and it is configured by Puppet for us. Thus, all of the nodes in our environment go through these two phases of automation, hardware as well as software, and get transformed into a controller node, a compute node or a Keystone node, finally giving us a production ready OpenStack environment backed by NetApp storage. So now all we have to do is plug this into our GC portal and make it available for our customers to use. So thanks to our Puppet automation and our modular architecture, we were able to go to OpenStack Juno in production in just 90 minutes with 45 compute nodes and a VM capacity of 3000. And I think we did that in just two months when we started off our architecture and everything and in two months we were in production with OpenStack Juno, which was the latest release at that time. Okay, so now that we had done our deployments, it was time for upgrades. So as mentioned earlier, we wanted to achieve non-disruptive updates while in production and we were eager to go from the Juno to the kilo release of OpenStack. We already had a modular architecture. Now we needed a strategy that was repeatable for the other OpenStack releases, automated using Puppet and non-disruptive for our end users. So we segmented our architecture into three different sections and decided to tackle them one at a time. First was the region zero, which was the shared services. We first decided to upgrade the Keystone node as it was the central authentication service in the environment. We did that serially and this allowed us to maintain service continuity and no downtime for our end users. So once the Keystone was upgraded, the Kilo Keystone continued to work with the Juno components because of backwards compatibility in OpenStack. Then we moved on to Horizon component and we upgraded it serially as well. But then the users do not see the dashboard at all, they go to the GC portal, so this was non-disruptive again. Now that the shared regions were done, we moved on to region controllers. So we toggled off a region in the GC portal to stop any new deployments to it. Then we went on and we upgraded the region controllers serially and once it was upgraded successfully, we toggled the region back on in our GC portal. So again, when the region went down, still the VMs in that region continued to work because they were hosted on the compute nodes. So that caused no downtime for our end users. As well as when the new request came in during this time, they were routed to the other operational regions in our environment, making it non-disruptive for our new end users as well. Now it was time for our compute nodes.  So we took the first compute node in each of our regions, live migrated all of the VMs off it and only when it was empty, we upgraded it to the Kilo release. So as you remember, we had shared NetApp backend for each of these compute nodes which made the live migration pretty easier and efficient for us and that really cut down our upgrade timings also. So this was our upgrade strategy. We tested it out rigorously in our staging environment thanks to the continuous integration and automation using Jenkins, Git and Puppet again. And once we were comfortable with it, we rolled it out into production. So thanks to all of our testing and everything, we were able to upgrade our environment with zero service interruption for our end users. Yes, we pulled it off. Okay, so this was our first experience with deployments and upgrades of OpenStack. So we learned a lot along the way. First and foremost, we experienced it firsthand that you can actually do a non-destructive upgrade in production. All you need to do is plan. You have to define a strategy that is suitable for your architecture and then just roll with it after you're done testing it in the staging environment. Also, things were not all happy and everything. Something went wrong during the upgrades, but it was the compute resources. They had some bad memory issues and some dim errors which caused some roadblocks during our upgrade process. But we knew that the next time when we are going to do our upgrades, we should fix and investigate our hardware. And once we are sure about the hardware that is underneath, then we'll roll out the software upgrade on top of it using Puppet. Also, we forgot to take into account the VMs that were in the powered down state and needed to be cold migrated. So we took all of these lessons and we documented those so that we could apply it to our next upgrade cycle to make it a more smoother experience. So we documented the good things, the bad things, everything so that our good things can contribute to our best practices to deploy an upgrade open stack in our environment and the bad things will always tell us too that you need to keep on improving your strategies as you go ahead. Absolutely. And some advice for you. I'd like to take away from this section is really just to define a strategy for upgrades and non-disruptive operations in open stack. As we're all well aware, a six month release cadence doesn't have to be a pain point in your open stack deployment. If you plan ahead, you have automation that suits your user segments and can both scale whenever deployed both with the deployment of open stack but also with the upgrades in open stack. And a lot of that goodness that Monsy took us through really helps us to do that with Jenkins. And also with that automation, it needs to be able to support our user segments. So don't try to reinvent the wheel here with your own automation here. There's plenty of great tools out there that the community has that you can take advantage of. And one of the things to take away from that is, whenever you scale this stuff out globally with a global team, the team will be better suited to utilize known automation, something that exists out there that's customized for you versus a role in your own type deployment. And infrastructure matters. As I said, that really helped us take the open stack deployment internally to the next level because it could both scale with our architecture and the non-disruptive operations of that infrastructure really helped us to be successful and take it to the global globally. Now, I'm a numbers guy and so I mentioned earlier about some of the storage efficiency that we utilize, some of the fast and time copies that we use inside of NetApp. Well, as an exercise, we added up all of the inherent storage that we're using in our open stack environment, added it up, and we came to about 64 and a half terabytes. This is for all of the glance image stores, the Cinder volumes that we have in the architecture as well as the bootlines that I mentioned earlier. And through space efficiency technology that we have enabled on those volumes, thin provisioning and auto growing, we looked and saw exactly how much space, all of our volumes using and doing open stack internally, how much they took up. And that was 5.26 terabytes. So that's 91.8% savings. And this had our 50 glance images as well as our around 4,000 VMs that we had in production, but like savings were awesome. Yeah. All right. So we talked about locally what we did inside of RTP. Now it's time to go big. Yeah. So towards the end of 2015, we already had an open stack environment running in production. So this environment was at our local site in North Carolina. This had five regions, 75 compute nodes and a VM capacity of 6,000. We had scaled this out by now. And by this time, our operations team was comfortable enough to support open stack on a daily basis. We had successfully deployed as well as upgraded open stack while in production. We were constantly refining our automation and documenting all of the lessons that we were learning while gaining experience with open stack. So all of these factors motivated us and we decided that it was time for us to go big. We are a global organization. So we wanted to expand the scope of open stack globally as well. We had our core puppet master here at RTP North Carolina. This represented all of our learnings, our experiences, best practices with open stack. And we decided to use this as a basis to spin up three more puppet master at each of our other sites. So the first one was Bangalore, India. Then there was Sunnyvale, California. And then another one in RTP North Carolina. Each of these puppet masters were then used to spin up their own open stack environments. The smallest one was in Bangalore. This was pretty small. It had one region, seven compute nodes, and 100 VM capacity. This was because we didn't want to do too much at the same time. We wanted people to have a field of open stack, get acquainted with it. And after that, scale it out to a massive proportion as we had in RTP. So this was just a starter thing that we started in Bangalore as well as in California, which had two regions, 14 compute nodes, and again, a smaller 600 VM capacity. And the largest one in the globalization effort was a smaller site in RTP North Carolina with three regions, 37 compute nodes, and a VM capacity of 2,000. So now it was time for global upgrades to the Liberty release. As mentioned earlier, now we had four different sites, and not the one that we had before. So the smallest one was the Bangalore one, which we decided to do first because we were scared of doing it in production again. So this one had just 14 total nodes to be upgraded, and we just took an R to upgrade this environment to the newer Liberty release. Then we moved on to a slightly bigger environment, which was in California, which had 600 VM capacity again, and 22 total nodes to be upgraded. It just took us an R and a half to upgrade this to the newer Liberty release. So from back to back successes with the upgrade in production, it was time for us to come home back to North Carolina. We started with the smaller site, which had 30 total nodes to be upgraded, and it just took us two hours. And for the biggest site we had, like we have till now, it has 86 total nodes to be upgraded, which is six times larger than the smallest production environment that we had in Bangalore. But thanks to our serial and parallel approaches, it just took us four hours to upgrade this entire environment to the Liberty release. So also, as I mentioned, maybe I didn't mention this, but we use the RDO distribution internally at NetApp here. We are all about open source. And so you have to also define a strategy for release cadences of RDO. So like the Metaka release right now, that just came out recently, I'm sure. Mansi is very excited to employ the same methodology here, got back home and to globally upgrade all of the sites that we have to Metaka here. But if you look at this circular chart right here, we start with a staging-type environment where we download a release candidate of RDO and test our puppet automation there first, making sure that it both deploys and upgrades from the previous release, Liberty to Metaka and do that in staging. We refine the automation there. Once the GA release candidate comes out, we roll that into a segmented region where we can play around with the queue so specific users can go in there and we can make sure that it functions properly with the global engineering cloud front end that we've been talking about. Once two weeks pass there and we're confident with that, we roll that out into a smaller site like Bangalore and monitor that and then roll it out to all the rest of the sites. So a couple of lessons learned from this section here. For us, Keyload of Liberty was much easier. Once we had, like I said, documented those lessons learned from the previous experiences of previous upgrades, this is becoming easier and easier. Definitely a kudos to the community for a more polished release cadence and having the releases having us easier to be able to take advantage of internally. It keeps getting easier and easier for us but really take from this set expectations. OpenStack is a lot different from us internally what we've experienced in the past. It's not VMware, it's not Hyper-V but that's okay. Adapt a walk, crawl, run methodology. Test things out locally before rolling it out and have the backing and the support of your management as well. I can't stress that enough and with common automation like what we've demonstrated, you can really set yourself up for success there. And of course, as I mentioned, the NetApp stores that we had played a really positive role in the deployment and orchestration of our OpenStack deployment. It's non-disruptive, it's very easy to scale and one thing that we found through instance creation, the NetApp unified sender driver is actually 50% faster than utilizing the generic NFS driver in tandem with NetApp storage. Go ahead. Okay, so time for some advice. As Dave said, always test out your upgrade strategy in the staging environment before you roll it out into production and make use of known automation and known continuous integration CI CD tools so that your operations team and your other folks on your team are already familiar with it and it's not a huge learning curve to do just the testing of your strategy. Also read through the release notes carefully. We missed this a bit while doing an upgrade to the Liberty release. There was a new parameter added that limited the number of concurrent live migrations in an environment and by default it was set to one. So this can really bog down your upgrade times and you should really know about these parameters before you do your upgrades. Also, we are a globally dispersed team so we have our global peers who need to be brought up to speed with OpenStack in our environment. So we always, as Dave mentioned again, that you should always test your automation in your local geography before you roll it out globally. This helps you be more prepared and confident to roll those out in different production environments and if something goes wrong, you're always there to update your peers about whatever challenges they might face. And also training sessions play a huge part in globalization efforts. We went through that. We converted our months of documentation, our experience with OpenStack into resources to bring our global peers up to speed and get acquainted with OpenStack. What this enabled us was this enabled each side to take full control of its Liberty upgrade, making it easier like we just spent just a week to upgrade all of our four environments of OpenStack to the new Liberty release just thanks to the training sessions and the enthusiasm of our operations people. All right, now a little bit of a reflection on some next steps as to where we're taking things internally and up next. We already have some OpenStack projects in the pipeline. Ironic is really hot right now. Through GEC portal, we just provide virtualized resources right now to our users and we want to expand that scope to bare metal resources as well using the Ironic project. Then the second one is Trove, which is database as a service. DB servers are very popular with our test engineers and we want to use the Trove project in order to provide them with a wide variety of databases in the form of OpenStack images through our GEC portal. And the OpenStack Manila project, that's a project that NetApp spearheaded about four years ago and recently was certified production ready in the Liberty release. We're certainly gonna take that internal internal for consumption of our developers and testers. That's the file shares of service project for those that may not be familiar. Also, we're in the planning and implementation stages of deploying Cisco application-centric infrastructure. So we're gonna utilize a lot of the orchestration and policy engine that ACI provides to unite physical and virtual resources and to create multi-tenant, segmented lab environments for our users to be able to take advantage of in an OpenStack context. We're gonna repatriate some of our workloads from Public Cloud internally. As I mentioned, our OpenStack development team has some resources in the Public Cloud today and given the speed and the ease of this automation and the success that it's brought us internally, we're actually gonna repatriate some of those workloads back internally to be able to take care of that scale that the development team needs internally at NetApp. Not all of the workloads, but just some of them there. And we're gonna be able to, we're looking at bursting to Public Cloud as well. So that portal that Monty mentioned, having the ease of being able to select which resource or which region you're in, regardless of hypervisor, we're gonna extend that to the Public Cloud too, like Amazon AWS or Microsoft Azure. So we can test those workloads, our engineers and developers can have those workloads in the cloud as well. So as I mentioned earlier today, we have 15% KVM, 45% Hyper-V and 40% ESXi right now. And I'm proud to say that through all of the good work that we've done internally at NetApp, we're planning to, by the end of September 2018, to be 70% on the KVM hypervisor, 15% on ESXi and 15% on Hyper-V. We're all in on OpenStack at this point and through all of the goodness of automating the deployments and the upgrades, this is something that really makes sense for us and we're gonna continue to invest in that space. So some other collateral, well, I have a couple of minutes left. I just wanna mention, if you'd like to take advantage of some of the infrastructure bits to be successful in your own environment, some collateral for you that I wanna make sure you're aware of, we at NetApp just published a new technical report based on the Red Hat OpenStack Platform 8 release, which just came out a week or so ago based on the Liberty release of OpenStack. So this has prescribed guidance, deployment instructions, architectural diagrams, we love diagrams, as well as code collateral that is contained within that document to help you accelerate your production deployments of OpenStack. And we had a previous solution released in October of last year, it was Red Hat OpenStack Platform 6 based on the Juno release on FlexPod. It's a Cisco-validated design, those links are here. And if you'd like to hear more about how FlexPod can accelerate your production deployment of OpenStack, I'm giving another session today at 11.50 a.m. on this floor, I think in the meeting room 19 over there, if you'd like to hear more about that. And some key takeaways that we want to leave you with. Make sure you have a good foundation as we've been stressing. Have a good foundation that you can count on from both a infrastructure perspective as well as a architecture that makes sense on top of that infrastructure. FlexPod-like converged infrastructure provides a scalable and a highly efficient platform for us internally at NetApp and it can for you too. Also with OpenStack, you should always set your expectations right, plan ahead and document well. These things really come in handy when something goes wrong in production. Not that it does, but sometimes. Also automation and non-destructive upgrades played a huge part for our success in OpenStack. The non-destructive upgrades allowed us to include all of the recent developments and the goodness of OpenStack without causing any downtime to our end users. And the automation allowed us to stay consistent across the various global sites that we had in our organization. And last but not the least, thanks to the trials and tribulations that we went through with OpenStack, our global engineering cloud today is backed by an OpenStack ecosystem that is highly available, upgradable between various releases and provided at scale across the different geographical regions. Okay, unfortunately, I wanna be perspective of time. If you wanna come up and talk to us after the, down at the bottom of the stage right here, we'd be happy to answer any questions you have. And I can even give out some pamphlets that we have in our booth that lists some of the OpenStack sessions. A lot of them have occurred already, but from back of a better word, they're all listed in here. You can of course watch later on YouTube. And that's our presentation. Thank you so much. Thank you.


Live from Las Vegas, it's theCUBE, covering NAB 2017, brought to you by HGST. Welcome back to theCUBE, we are live in Las Vegas at the very exciting NAB show 2017, and I'm very excited to introduce you to our next guest, Andy Schenkler. Andy is the EVP Chief Solution and Technology Officer for Sony DADC New Media Solutions. Andy, welcome to theCUBE. Thank you very much for having me. You are a veteran, not only of the media and entertainment industry, but of NAB, with this year's theme of the Met Effect, this convergence of media entertainment technology. What are some of your initial thoughts about the show this year? Well, I haven't had a lot of time to visit the whole show yet, it's only opening day. I think that over the last 20 years of even attending these events, it's been heavily focused on kind of cameras and the backend production technology, and over the last several years we've seen, you know, cloud technology, software-driven, IP interaction take place, and even with the thematic change of it being met, that's clearly coalescing even more, right? It's no longer a, this is a thing that's coming, it's here, and how do people really take advantage of that as they kind of move forward? I'd love to get your perspective, as you were saying, you've been in the media and entertainment space for about 20 years around the time of NAPSR, which is like we were saying before, kind of hard to believe that was 20 years ago, but I'd love to just get kind of a high-level picture of you must have seen massive evolution in media and entertainment, where, tell us a little bit about that, some of the things that really stood out to you over those two decades as milestones. So, I mean, there's clearly the ones that we all as consumers know, right? The iPod and iTunes and the advent of Netflix and Amazon Video and things of that nature, and I think those are the very tangible ones. From behind the scenes, I think it's the challenges that the business has had to go through, right? How do you actually deal with rights problems that are global in nature, right? You suddenly have a world that's portable. You suddenly have problems where, I downloaded something or I want to consume a piece of content that I really enjoy, I get on a plane, and I'm suddenly in a territory where I no longer have the right to watch that. Those are significant challenges that have to be overcome, and it's not always just technology, right? There's huge legal issues and things like that. And so, there's a real striation between what we as consumers expect to find and what the business needs to do to change to accommodate that ever-growing kind of consumption rate that people want. So- Absolutely. So tell us about the supply chain solutions that Sony, DADC is delivering for the media and industry. Sure, so we started about nine years ago, and it's not that certainly supply chain solutions aren't nine years old, and I think our perspective on it was one where we were fortunate to start with a white piece of paper rather than transform a legacy business. And when we did that, we said, what does the solution five years from now need to look like? And so we run full supply chain offerings for companies like Sony Pictures, BBC Worldwide, Village Roadshow, PlayStation, Funimation, things of that nature. And we're talking about distribution of content to roughly 1500 endpoints globally. So that's multiple languages, multiple versions, trying to keep all of that stuff in track. And really the way we approached the problem was, I know it sounds terrible, but really to get humans out of the mix from the perspective of what's not actually good for people to do. Looking at millions of permutations of data is not really a strong suit for people. It's a good strong suit for a computer. It had up until that point in time being relegated to Excel spreadsheets and emails, and we tried to eliminate a lot of that by putting systemic decision making in place. And that's really what's allowed us to kind of scale at a fairly aggressive pace. So are we talking about artificial intelligence, machine learning? I wouldn't go so far as to say that. Much more rules-based engines, logic around it. So let's take an example, right? Maybe you have a motion picture we'll say like a Spider-Man. Spider-Man is made and it's available in 15 countries. Each one of those countries have different compliance and rules, cultural rules.  So now you've kind of left customer service reps to have a conversation that say, hey, I need you to send this to all of these places. How are they supposed to know all of the possible combinations of things? Then on top of that, not just knowing it, how are they supposed to interrogate a library of millions of assets and say, oh yeah, I figured out all of the combinations of these things to make that happen and do so within a timeline to hit a business goal. That worked great in the beginning when it was, hey, we're going to get 50 titles out. Now we deliver 60, 70, 80,000 titles a month. Suddenly, that is no longer sustainable for a human project. You couldn't get enough people in this building to go through that much content. God, it's really kind of rules-based. So you've got users of the Sony technology, film studios, broadcasters, music labels. Give us an example of say, on the broadcast side, about what they're looking to do with managing assets to meet consumer demand and ensure that it's, with this multi-channel distribution model, they're meeting consumer demand wherever those consumers are. So I think from a broadcast perspective, which even in that world, that's blending, right? I mean, there is no traditional broadcaster as we know it anymore. Even a broadcaster has VOD services, they might have some sort of mobile provisioning, OTT. And so that, therein lies their challenge, right? They've put in large infrastructure over many years. They continue to reinvest in that. Along comes, you know, a Netflix, a Google, whomever with, you know, global licensing, the ability to move incredibly rapidly. And so they're looking at it and saying, how do I compete? How do I stay relevant in this space? Market share, as we know, is starting to move away from the broadcast side, you know, linear television per se. And so where we come into play is we say, we've already got a massive amount of content available. You've licensed it already. Let us make that available, let us run that infrastructure for you. Your focus should not be on how do I make sure that the power plant stays up, but rather how do I market, how do I differentiate, how do I create a compelling proposition to consumers so that I can effectively compete as this grows. Okay, so you're really helping them to scale on ways that they would never have been able to do on their own? I think we're just helping them get there sooner. It's not to say that they could never do it. I think that's a lot of ego, a lot of hubris, but it's very much that we've leveraged kind of our position as, you know, as Sony and as what we've done for a lot of partners in the space. And we've said there's a reasonable way to kind of level the playing field, right? A supply chain should not be the level of differentiation, right? We don't simply say, oh, well, here's a really good manufacturing supply chain. There's only one company who should use it. It should be leveraged by many, many, you know, facilities. And so we take that same view from a digital perspective.  We've now moved to a model that said, why don't we just host it all singularly in any format that you want? Your choice, any spec, any DRM, but it's centralized. So for one of our customers, in fact, they air something in Japan and 24 minutes later it's available everywhere else. That couldn't be done if I also had last mile bandwidth considerations to take into account. And we believe that that 24 minutes is soft by about half. We think we can get that down to under 10 minutes. Question for you. And the speed theme has come up a number of times today with different folks that we've talked about. If we look at a Netflix, as we brought up, for example, you know, we think, well, from an audience perspective, the audience is so empowered and we have access to anything and we want it wherever we want it. We binge-watching, streaming, we're time-shifting. So you think, wow, Netflix has a great advantage because they know so much about the audience. At the same time, until they started creating unique content, they couldn't really change the content versus on the flip side in the film industry, they haven't really historically known their audience. It's been more of probably qualitative data decisions. At the same time, they can change content. So do you work with the streaming services as well as the traditional film studios do they have a similar challenge that can be solved by using media as a service? So from ones who want to use everything that we offer end-to-end, we kind of, again, that level playing field, we give everybody visibility. We believe data transparency is pretty important. We recognize that people hold onto data as kind of the keys to the kingdom at this point. You know, certainly Netflix does and look, they're leveraging it quite well, right? So it's hard to find fault with what they're doing from a business perspective.  That's not how capitalism works, so that's a different problem. But people who run on our platform, we think that there is a good balance and that both sides should have visibility to a lot of that data because it should help each other. They should really, you know, a rising tide should float all boats and not just create this imbalance because then it becomes very difficult to amortize costs if there's one and only one solution in the market. And that's really how we try and approach that problem. So in terms of the kind of volumes of content that we're talking about here. So we stored today just over 20 petabytes of content, roughly a million hours worth of, this is premium content, so this is not user generated. This is not like YouTube clips of somebody's cat. There's probably a couple in there. There might be a few in there, but that's not primarily what it is. We're talking about really high end premium content and in about 23 languages. The variations that we have are very high. Now, a lot of times people will say, well, it's easy to get to a million hours because people do bad data and so they'll store something like Spider-Man with a hyphen in the middle or a space or all together. We're actually very, very focused on not having that. So these are all unique assets. So it's a very large library when you look at it on a global scale. So how can a linear network versus a streaming network access a million hours of content? So we actually don't differentiate between a linear and a streaming network because at the end of the day we're a complete IP solution. The ability to uplink through satellite is fine. It's just another method of transport, but really all they do is they come to us with their licenses and then we provision the assets for them in their specification and we make it available to them anywhere. I mean, it's pretty straightforward. We try and take a lot of the heavy lifting off their plate, reduce their infrastructure costs, reduce the team sizes that they've had from a scaling perspective. They don't have to grow so much. We really try and flat rate a lot of this to make it easy and predictable. Fantastic. Last question, since we're running out of time here, I know that you guys have really migrated the media supply chain to the cloud going all in with AWS. You had mentioned before that really started about a year ago. Tell us about what you're doing with AWS and how has that influenced the genesis of media as a service? So I think that what I should tell you first is that when I went to the team to talk about this, I borrowed a line from the hunt for it October where they said Cortez reached the new world and burned his ship so that his men could not go back. We got rid of our data centers first and then told the team we're going AWS. And so there was no going back. We were making this move. There wasn't going to be hesitation and an all in model is the only model that worked for us. The hybrid model is just not cost-effective. We had to embrace something that was future-proofed and that seemed like the right one. Where we've benefited from it is clearly there's economic advantages but some of the other advantages are like what I was talking about before, 24 minute time from receipt to availability everywhere would have been unthinkable in a completely contained environment where I had to have huge lead times for scalability. I had to know in advance that I would need more storage or more transcoding capacity or more bandwidth. I no longer need to have that level of information upfront. I live in a world of unpredictability. People come in with requests all the time that I didn't know an hour ago was going to be asked for. I'm finally in a position to be able to offer a solution to all of them that says go ahead, do whatever you like. Our system will manage it and we have confidence in the AWS infrastructure to be able to support that. So it sounds like a fantastic partnership that's going to be really enabling a lot of more content creation and more uses of this content in the future. And we really want to see that. We want to see people create differentiated solutions for consumers without having to worry about how the sausage gets made. Exactly, nobody wants to know that. Nobody wants to know that. Well Andy, thank you so much for joining us on theCUBE and sharing your insight. I know you just got to the show not too long ago so we wish you and your feet healthy next few days. Thank you very much. And we look forward to seeing you on theCUBE sometime soon. I appreciate it and look forward to being with you. All right, well we want to thank you for watching. Again, Lisa Martin live at NAB in Las Vegas. Stick around, we'll be right back.


Hi everyone, Joe for Jaspy's casebreaks.com, coming at you with five packs of 2020 Panini Prism football retail packs. This is break number 36. You can see that the next one is loaded up and that will be the last fill of that, unlocks the hit parade. No, not the hit parade. The hit packs. The Jaspy hit packs. Big thanks to this group for making it happen. All 32 teams are in. Let's roll it. Let's randomize it. Three and a four. Seven times for names and teams. Two, three, four, five, six, and seven. Three and a four. Seven times for the teams. Two, three. All right. So here's the first half of the list right there and the second half of the list right over here. The trade window is closed, and that's print and rip. Elaine Johnson, checkerboard pattern, and they're coming right here. So nothing too crazy there. But it's going to be crazy. Who's going to win those hit pack spots? Let's gather everybody's names one through 32. New dice, new list. There's going to be a lot of sad faces in this one. Only the top four can get in. Top four after six, one and a five. Six times. Good luck. One, two, three, four, five, and once more, sixth and final time after six. Like I said, a lot of sad faces here. Saddest face is probably going to be spot five, where it's just like the close but no cigar spot. Justin, my apologies, five through 32. Thanks for giving it a shot. Remember, there is another one we've got to do. So if you're not in the top four, let's try again, jaspyscasebrace.com. Top four happy times because you've got a hit pack spot for a fraction of the price. Charles is happy. Tim is happy. Allen is happy. Eugene is happy. That's the top four. I'll see you in the video a little bit later tonight for those hit packs, jaspyscasebrace.com.


Hey everyone, welcome to tomorrow. Coming up we have a proton rocket that launched a military satellite for Russia and the next International Space Station crew is set to launch on a Soyuz rocket. This is your space pod for December 15th, 2015. So Russia's proton M rocket launched on its 7th flight of this year on December 13th at 019 UTC and it was launching the Garpoon Military Communication Satellite which went on a 9 hour journey into geostationary orbit which thankfully resulted in a successful deployment of the satellite. Not that I'm wanting Russia's military to have even more capabilities but at least the spacecraft separated successfully. Capable of making multiple burns, the Breeze M upper stage carried the Garpoon from a suborbital trajectory up to geostationary orbit. Unfortunately there is no footage of the launch itself but we do have some really high definition footage of the rocket being rolled out to the pad and you can see some very cool angles on this. But anyway, the Garpoon satellite it launched, meaning Harpoon, is a series of new generation space to ground communication satellites that are dedicated to support Russia's military space assets. Little is known about the Garpoon satellites themselves other than that they are designed to provide data relay capabilities for Russia's fleet of reconnaissance satellites such as the Persona Electro optical imaging spacecraft for example. The launch had originally been scheduled for earlier in the week however it was delayed after the failure of its Soyuz 2-1V to deploy the Canopus ST satellite last week. The proton launch was delayed to allow checks on its payload attachment and separation devices due to concerns of similarities between them and the device recently used on the Soyuz. This launch was the 79th orbital launch attempt of 2015 worldwide and the 7th proton launch of the year. Five of the six previous launches were successful with May 2015's launch of a MEX-SAT-1 satellite failing to achieve orbit. Proton has had 11 failures in the last 10 years. In any case, the next proton launch is scheduled for December 23rd and that is also going to be a proton M with a Breeze M upper stage and that hopefully will be carrying the Express AMU-1 communication satellite so hopefully everything goes well for that launch as well. So anyway moving right along, the next three crew members who are going to the International Space Station are set to launch today at 11.03 UTC on a Soyuz FG rocket and they will be riding inside of the Soyuz TMA-19M spacecraft and the TMA-19M is actually the 128th overall flight of the Soyuz spacecraft ever since their first flight in 1967.  The crew consists of astronaut Timothy Kopra of NASA, Tim Peake of the European Space Agency, also the first British astronaut and also Yuri Malenchenko from Roscosmos. The spacecraft will take advantage of the new three hour rendezvous maneuver to quickly arrive at the space station where it will stay for six months. Expedition 46 commander Scott Kelly and flight engineer Sergei Volkov and Mikhail Kornenenko of Roscosmos will return to Earth in March of 2016 on the Soyuz TMA-18M spacecraft. They will be replaced by the Soyuz TMA-20M spacecraft and three new crew members in the same month, March of 2016. At least for the new crew arriving for Kopra, Peake and Malenchenko they're going to be doing lots of science experiments and lots of really cool stuff at the station but I think our correspondent Lisa Stojanowski would do a much better job of explaining what type of science they're going to be doing there and what sort of experiments are planned for their expedition. So hopefully she'll be talking about that in her next space pod as well. In any case, thank you for watching everyone and please let us know what you think about these two particular missions. By the time that this video is live and you're actually watching this, the ISS crew may have already launched so hopefully everything goes off with that without a hitch and everything is perfectly safe and fine with getting them up to the space station. And as for the proton rocket, what do you think of the different series of failures that the proton has experienced over the years? Do you think that it's still going to be a good vehicle to use until it's planned to be retired in 2020? And if you have any other sort of ideas or thoughts about the proton rocket, please share them in the comments below or on any of our social media. Also if you were willing to enable, please consider contributing to our Patreon campaign so that we can continue to produce content like this. We have moved from a per video donation basis to a monthly donation basis so should be a lot easier for everyone to understand exactly how things are going to work for that. So if you can and you can help us to make these videos then please do so by visiting patreon.com slash space pod. Thank you again for watching this video. My name is Michael Clark and hopefully you know just a little bit more today than you did yesterday thanks to tomorrow. Keep moving onwards and upwards everybody and I will see you in the future.


That was a tough act to follow, but what I will talk about is a rewarding part of my professional portfolio which is working with senior executives one-on-one as a trusted advisor and to encourage you to consider it adding it to your own practices. So let me start with the client. The client is usually an exceptional human being, a senior executive at the top of the organization. And just like the top of a mountain, this could be a very lonely, windy, invisible place. And from this very peculiar place, he or she has the task to constantly manage growth, change, risk and uncertainty in an environment that's being shaped by forces way beyond her control. Things like changes in consumer preferences and competitive shifts and demographics. It's basically trying to win a game whose rules are constantly being rewritten. That's speaking about objectives. Well, in reality, an executive has multiple objectives. They are interdependent, they're conflicting, and they're poorly articulated. So then the advisor's job is to help advance the clarity and the conviction behind the executive's thinking, decisions and actions. I like the movie Analyze This as an illustration. Okay, I know it's an mobster movie. It talks about Robert De Niro being a mobster in a New York mafia family. But I find many parallels with today's CEOs. Well, hear me out. So the mobster boss is dealing with the Chinese and the Russian mafias coming in. Now, that's globalization in business terms, right? The FBI is picking up all the mobsters and locking them up. Well, that's her base, Oxley, in regulation.  Well, that's your cutthroat competition, right? And on all that, Robert De Niro himself is going through this soul-searching, life-revaluating quest for meaning in life, which is a present theme. Now, in this one scene, Billy Crystal, who is a psychiatrist, turned advisor or quote, conciliatory, is protesting seriously because he's being kidnapped in the middle of the night from his honeymoon room to talk to the boss. And the boss says, you don't understand. Nobody else talks to me like you do. Billy Crystal says, I take it you don't hear no that often. Oh, I hear it, but it's more like, no, no, please don't. Well, joking aside, Billy Crystal epitomizes the advisor. He's somebody who comes in as an equal in a spirit of a complete confidentiality in a space where any question can be brought up. He brings in an independent point of view, the courage to express it in a very orthogonal or different set of skills and experiences. And this is why I think that you are well-positioned to play that role. First of all, you already have access to these guys because you're in their organizations doing great work. So these conversations will organically emerge. Secondly, when the conversation comes up, well, you have all the skills, as we just heard in the mindset, to be a fantastic in a one-on-one setting. What you consider as a commodity in this room in terms of ability to be in the moment and listen and interact, well, that's not a commodity out there in the corporate world. That's a very rare, rare presence. Thirdly, you have an endless bag of tricks and games and exercises that can develop insights into the executive's mind by just experiencing it in the moment right there and then traditional advisors who are coming from MBAs or McKinsey, they don't have that skill set. And finally, you have language that can expand their thinking. And let me explain. When I sit down with a CEO and I say something like, target customer segment value proposition, five words. Because it's a common-shared language, I can use those five words and convey massive amounts of information and take the conversation to a much more sophisticated level because we share this language. Now, in emerging markets, that language doesn't exist. And I found that just bringing the vocabulary in and explaining what that meant allowed executives to think in a new way and structure reality in a completely different way. Well, use improvisers. You come in and now you can talk about your vocabulary that complements the regular business language. Well, you explained the word status and all of a sudden you have empowered an executive to intentionally choose a different leadership style in a different situation just because they didn't have the words to put to it before. So, in a summary, being a trusted advisor to a senior executive is a very, very privileged role and you develop a very well positioned to play it. Thank you.


Hi everyone at Bodybuilding.com, my name is Noah Banks and this is my submission for the 2018 Bodybuilding.com Spokesmodel Search. First off I'm going to get a little bit of a background about myself and then go ahead and answer the three questions of YTEAMBODYBUILDING.COM and why do I build my body and how do I inspire others to build their body. So to give a little brief overview about me, my name is Noah Banks as I stated earlier, 23 years old, living in New York, New York, but I'm also from Atlanta, Georgia Bulldog, Go Dogs. So to give a little bit of background about me, my fitness journey started back when I was in middle school actually.  And I was like, you know what, I need to start working out. So I started doing push-ups and sit-ups, but then once I got to high school I started really getting into sports, doing track, basketball, wrestling, and then a little stint and football. And I really needed to build my body a lot bigger than I had it. So I went to the gym at LA Fitness and walked in there and was like, I do not know any of this. So I went back home, looked on the computer, best arm workout and it came up. The first thing on the first search bar was actually bodybuilding.com was an arm workout. So I did it and it felt great. That started the whole addiction of using it every single workout that I needed to use it for. So that was kind of like my high school years.  So I started really just diving deep into fitness and that's actually where I ended up getting my personal training certification once a lot of people started asking me how I did it myself. I started training people and once I graduated I actually created what my mission is right now which is hype. That's my lifestyle brand, my fitness lifestyle brand and it stands for healthy young professionals every day because fitness is actually not my full time job. I actually work as an analyst on Wall Street and my biggest thing with hype is I want to motivate young professionals to feel happy, youthful, productive and excited about their fitness, their nutrition and their lifestyle while working a 9-5 job. It's crucially important. So that's where my mission is, a little bit brief background about myself. Now to go ahead and answer the question of why team bodybuilding.com, first off I just think it's a great brand. It's what sparked my love for fitness and really understanding how to really train.   So to be a representative of such a giving brand and a brand that really cares about people's health and their body and making the best body of themselves is huge to me. Now why do I build my body? At first it was for very vain reasons. When I was in high school I did it for sports and for girls but now what I notice is growing my body is more than just my physical. It's actually helping me grow my mind and help me, I tell people right now like I'm bulking right I'm getting bigger but I'm not getting bigger just to you know look a little bit heavier in my suit or whatever. No it's because by growing bigger I know that one I'm staying consistent with something over time and then two I'm also growing bigger to pass barriers that are in my way. I have so many big dreams for a hype in my life and you know working out just helps me like look if you could do this in the gym grind to go for this goal you could do this in your life you know you could really grind and get this goal that you want in life and it's the there's so much correlations between fitness and your life and it's just amazing and that's why I build my body because it's a growth and it's passing a challenge that's in front of me. Now the last reason is you know how do I inspire others? Like I said I created hype, healthy young professionals every single day there's no S in there but it's healthy young professionals every day and the whole point is to provide people with the fitness knowledge, nutrition knowledge and the right behavior knowledge to basically be healthy and to live a healthy life and to make basically make tell them and motivate them like hey look it's possible you know I work a nine to five job and sometimes later sometimes work earlier and I still find a way to be fit let's motivate you and hey let's be fit together too many people trade health for wealth in the beginning of their life and then end up spending all the wealth to regain their health and at the end it's backwards you can't think like that so anyway that is my submission video again I just want to say thank you bodybuilder.com for changing my life and really invoking a passion within me and I love it and of course I want to be another George Bulldog with Leanna Carr and Lacey Don being in here and my mentor Amanda Bucci so that's also why I mean it's just awesome they love the opportunity and I'm excited so thank you so much and I'll catch you on the flip side.